Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!sdd.hp.com!caen!uwm.edu!csd4.csd.uwm.edu!markh
From: markh@csd4.csd.uwm.edu (Mark William Hopkins)
Newsgroups: comp.lang.prolog
Subject: Re: Does Prolog have an unambiguous syntax definition?
Message-ID: <9796@uwm.edu>
Date: 28 Feb 91 01:03:21 GMT
References: <12388@darkstar.ucsc.edu> <4834@goanna.cs.rmit.oz.au>
Sender: news@uwm.edu
Organization: University of Wisconsin - Milwaukee
Lines: 68

In article <12388@darkstar.ucsc.edu>, kjell@saturn.ucsc.edu (Kjell Post) writes:
>  But what about this example?
> 	:- op(500,xfy,@).	% infix
> 	:- op(600,xf,@).	% postfix
> 	:- op(700,xf,#).	% postfix
> 	display(a @ #).
> Quintus Prolog Release 2.2 (Sun-3, Unix 3.5)	=>	@(a,#)
> SICStus 0.6 #18: Mon Oct 22 13:46:21 PDT 1990	=>	#(@(a))

In article <4834@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>
>... I think that #(@(a)) is the better answer here.

I agree.  When you get to: a @ ..., the parser should immedicately interpret
'@' as postfix, since the postfix operator has higher precedence and since it's
in a infix/postfix context.

That example's not quite as good as this Garden Path example:

 	:- op(600,xfy,@).	% infix
 	:- op(500,xf,@).	% postfix
 	:- op(700,xf,#).	% postfix
 	display(a @ #).

A good parser will try all possibilities either in breadth-first manner or by
backtracking and report the first example as a precedence conflict, and
actually accept the second as equivalent to: display(#(@(a)) (or maybe report
this as a precedence conflict too).

The problem is allowing operators to be used with different arities, which
I personally find to be an extremely confusing and terrible style (so how
could I blame a parser for getting confused too).

>... We need a model implementation and a whole lot of
>nasty test cases like this that show that what the standard specifies
>can in fact be done..

Not really.  A good mathematical analysis of the underlying syntax will
reveal where all the critical points lie.  For instance, applying a LALR(1)
parser generator to the syntax for Prolog terms reveals these to be the
critical points:

(1) Op ( ... where Op can be a prefix operator.
   Is this to be interpreted as a prefix operator followed by a bracketed
term or a prefix operator applied to an argument list in standard operator
notation?
   Actually this is NOT a true ambiguity in most contexts, since either
interpretation yields equivalent results.  The only real problem ... wouldn't
you guess ... is when your prefix operator has also been defined as an operator
of different arity.  Another place where it's a problem is in this context:

		 prefix (Term) operator...

where the second operator has smaller precedence than the first.

   This conflict is resolved by a certain convention concerning the placement
of the bracket next to the prefix operator (at least in the dialects of Prolog
I know of).

(2) Op Op ... Any two adjacent operators (which is the operand?)

(3) Op Term Op ... a prefix/infix operator, followed by a term, followed by
		   an infix/postfix operator.
   This is mostly handled by operator precedences.

(4) The comma in [...], f(...) contexts ...
(5) High-precedence operators in similar contexts...
   these are handled by the precedence rules too.