Up to top level
compiler bugs   dustin's bugs   fixed   incoming   nonproblems   tests   website bugs  

Logged in as guest

Viewing nonproblems/43
Full headers

From: ewd@dai.ed.ac.uk
Subject: More errors with =>'s
Compose reply
Download message
Move To:
1 replies: 1
1 followups: 1

Private message: yes  no

Notes:

Notification:


Date: Wed, 14 Feb 2001 10:51:46 -0600 (CST)
From: ewd@dai.ed.ac.uk
To: teyjus@cs.umn.edu
Subject: More errors with =>'s
Full_Name: Ewen Denney
Version: 1.0-b30
OS: Solaris 2.6
Submission from: (NULL) (194.82.103.76)


This is related to my previous question (#42). 
A simpler example which fails with the "Predicate name indeterminate" error is:

type curry (list o) -> o -> o.

curry [] C :- C.
curry (H::Hs) C :- H => (curry Hs C).

I thought we might get round this by having clauses for every possible o we
might
be concerned with, so for example:

type new_type string -> o

curry ((new_type S)::Hs) C :- ((new_type S) => (curry Hs C)).

Curiously, then, curry L true only succeeds when L is empty or a singleton.

ie. curry [new_type "s", new_type "t"] true.
fails.

Then I replaced this clause with

curry (H::Hs) C :- (true => (curry Hs C)).

which gives the strange error "attempt to redefine pervasive predicate true".


Ewen

Reply 1

Resend
From: Gopalan Nadathur <teyjus@cs.umn.edu>
To: ewd@dai.ed.ac.uk
Subject: Re: More errors with =>'s (PR#43)
Date: Sun Mar 25 18:46:49 2001
CC: teyjus@cs.uchicago.edu
The first question is that if curry is defined through the clauses

   curry [] C :- C.
   curry ((new_type S)::Hs) C :- ((new_type S) => (curry Hs C)).

then why is it that the query 

   curry [new_type "s", new_type "t"] true.

fails? The answer to this is that there is an ambiguity in the 
query arising from two different interpretations for the comma. 
Notice that the comma can be interpreted either as a conjunction
or as a separator of list items. The conjunction reading is possible
when the items on the left and the right are of predicate type as
they are in this case. As explained in the Teyjus manual, the 
preferred reading of comma in this case is that of a conjunction; 
see the material at the URL

http://teyjus.cs.umn.edu/language/teyjus.html#SEC29.

If the query is read this way, it is easy to see that it must 
fail. To circumvent this problem, you can retype the query as 

   curry (new_type "s" :: new_type "t" :: nil) true.

The observation of ambiguity is an old one made originally by Frank 
Pfenning. Frank proposed to avoid the ambiguity by eliminating the 
Prolog like syntax for lists altogether. This was consider a daconian 
measure in the Teyjus implementation, but perhaps the issue should
be reconsidered! 

The second question is why the clause 

   curry (H::Hs) C :- (true => (curry Hs C)).

produces the error "attempt to redefine pervasive predicate true".
The answer to the following. The body of the clause has an 
implication goal in which true appears on the left. Thus, this goal 
actually involves adding a new clause to the definition of true.
You are not permitted to redefine builtin predicates, so the compiler
flags this as an error. 

Notice that the implication goal in the clause is actually redundant.
The following would be equivalent and would not give the error:

   curry (H::Hs) C :- (curry Hs C).




Followup 1

Compose reply
Download message
Date: Wed, 28 Mar 2001 14:41:37 +0100
From: Ewen Denney <ewd@dai.ed.ac.uk>
To: Gopalan Nadathur <teyjus@cs.umn.edu>
CC: teyjus@cs.uchicago.edu
Subject: Re: More errors with =>'s (PR#43)
Gopalan Nadathur wrote:

> there is an ambiguity in the
> query arising from two different interpretations for the comma.
> Notice that the comma can be interpreted either as a conjunction
> or as a separator of list items.

> The observation of ambiguity is an old one made originally by Frank
> Pfenning. Frank proposed to avoid the ambiguity by eliminating the
> Prolog like syntax for lists altogether. This was consider a daconian
> measure in the Teyjus implementation, but perhaps the issue should
> be reconsidered!

It seems more natural to me that the ambiguity in this case should be
resolved in favour of the list interpretation. If you want to force the
reading as a conjunction you can always disambiguate with parentheses,
but the other way round you have no option.

Personally, I prefer the "prolog-like" list syntax, anyway, and I would
also request that the teyjus interpreter  produce output in this format.
The explicit "::" format is difficult to use when you have multiple
embedded lists.

Ewen


Up to top level
compiler bugs   dustin's bugs   fixed   incoming   nonproblems   tests   website bugs  

Logged in as guest


[ Home | Overview | Download | Language Documentation | Bug Tracking | Implementation Documentation | Links ]