🚀 go-pugleaf

In article <178@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>I think John Lacey (lacey@tcgould.tn.cornell.edu) said this:
>>The parse would be more difficult.  The problems aren't analogous.  The
>>dangling-else problem is one of ambiguity.  Parsing a general relational
>>expression is difficult because the same string will be used for multiple
>>tokens.  For example, in (a < x < b), x has to be associated separately
>>to its left and right.
>
>I have to object here. Way back at the university I took a compiler
>course. In the tiny language I made for my assignment I defined the 
>grammar relational expression something like:
>   rel_exp ::= exp (rel_op exp)*
>()* meaning 1 or more times easy. Trivial, isn't it? The semantic
>interpretation was AND. I.e. 0 < x < 10 was interpreted as (0 < x)
>AND (x < 10), which seems as the natural interpretation for the
>case you would like to use it for. A thing like
>    a = b <= z > y < b
>wouldn't something to recommend but the langauge dealt with it the same
>way.
>
>Actually I have always been surprised that no language I have dealt
>have had this feature since it is so easy to implement. Am I overlook-
>ing something?
>-- 

Sorry for the long insertion, but context is important.

A couple of years ago I developed a small special-purpose language for
the project I was involved in.  One of the things I did was to
implement extended relational expressions such as described above.  I
wrote both an interpreter and a compiler for the language, and it got
a fair amount of use.  It wasn't hard.

I don't think you're overlooking anything.  I had no trouble at all
with that part of the language.  You do have to decide what to do
about expressions such as "x < (y < z)" ["illegal" is a good choice!].

I don't think it would be a good idea to try to extend C in this way,
since x < y has an interpretation that only a hacker could love (an
integer rather than a truth value), but Pascal-like languages are no
problem.  Like you, I don't know why more languages don't have this
perfectly natural construct.

BTW, I also implemented

        all <variable> in <set or list> satisfy <logical expression>
        each <variable> in <set or list> satisfies <logical expression>

        some <variable> in <set or list> satisfies <logical expression>

(The first two are just syntactic variants of each other.)  I also
meant to add the following, but never got around to it:

        no <variable> in <set or list> satisfies <logical expression>

The <variable> is used in the logical expression; if "all/each" or
"no" fails, or if "some" succeeds, the <variable> retains the (first)
value that caused this to happen, otherwise the <variable> is
undefined.  These aren't hard either, and save the programmer from
explicitly writing loops for some common cases.  I think these are not
common because Pascal-like languages do not generally have sets or
lists as supported data types.

-- Dave Matuszek (dave@prc.unisys.com)
-- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA  19301
-- Any resemblance between my opinions and those of my employer is improbable.
Remember, too, that 1989 is the 17th anniversary of the LAST man on the moon.