🚀 go-pugleaf

In article <CHIK.92Sep22103654@ss38.icot.or.jp>, chik@icot.or.jp (Takashi Chikayama) writes:
> In article <PLUMMER.92Sep21105425@cilantro.cs.swarthmore.edu>
> 	plummer@cs.swarthmore.edu (David Barker-Plummer) writes:
>  DBP> With [distfix ops] you declare an operator as a collection of symbols
>  DBP> including an opener, closer and separators.  So for example, a distifx
>  DBP> operator declared with < as the opener, > as the closer and , as the
>  DBP> separator, would allow you to read <a,b>, as perhaps '<,>'(a,b).
> 
> That may be handy in some cases, but I think declaring only the
> parentheses will be enough, and thus we don't have to further
> complicate the mechanism.

The advantage of a formalized distfix syntax extension is the same as
the advantage of formalized bracketing:  error detection.  For example,
if you wanted to add if-then-elseif-then-else-endif syntax to Prolog,
you could declare each of these words as an operator of the appropriate
precedence.  But this would push syntax checking out of the reader, and
into your term_expansion/2 code (or to runtime).  Prolog's reader would
quite happily read

	test :- if foo.

as a valid clause.  Adding a bracketing syntax extension would prevent
this by requiring the matching endif, but would still be quite happy to
read

	test :- if foo endif.

which is equally nonsensical.

I haven't seen any formal proposals for a distfix extension; does anyone
have one?  Does it support required and optional term parts?  Repeated
parts?  What kind of flexibility does it give users to control the
structure of the (sub)term ultimately returned?  It seems to me like a
hard problem to design such an extension.

-- 
-Peter Schachte
pds@quintus.com