🚀 go-pugleaf

In article <34366@oliveb.olivetti.com>, chase@Ozona.orc.olivetti.com (David Chase) writes:
> 
> A flaw in Icon's implementation of optional terminators is hardly a
> condemnation of optional terminators; other parsers have been getting
> it right for years.

The problem is more the fact that Icon's syntax was not designed with the
idea of making trailing semicolons options. As Gary Levin pointed out it
is an expression oriented laguage. Suppose you write the rather strange
expression

   return {
      y := a
      -b
      }

It is translated as

   return {
      y := a;
      -b;
      }

which is meaningful. y is assigned a and -b is returned. On the other hand

   y := a
   -b
   x := 2

is also translated similarly

   y := a;
   - b;
   x := 2

It is not until you get deeply into the semantics that you determine that
-b has no effect. At that point it is getting a little late to change your
mind on how to parse the expression (not that it is impossible with a
hand coded parser, but I wouldn't care to do it). Icon actually adds
semicolons in the lexical analyser and does so based only on the last
token of the line and the first one of the next. This is not a perfect
solution, but as David pointers out:

> I should add that the trailing operator to indicate continuation
> rapidly becomes a part of your style when working in such a language.
  
The syntax of C is actually worse than Icon if you want to make semicolons
optional "after the fact" (of language design). It has suffix operators, so
you cannot use the trailing operator rule to continue a line.

(I find I have no problems with Icon's approach to not requiring trailing
semicolons, except that the C compiler doesn't like my coding style
any more :-)

   Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
   +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker