🚀 go-pugleaf

In article <14251@haddock.ima.isc.com> 
>	karl@haddock.ima.isc.com (Karl Heuer) writes:
>	...	 You simply add a new production rule
>which parses "a < x < b" as a ternary operator, 
>and produce code equivalent to
>	evaluate x into temp
>	compare a with temp
>	jump-if-ge FALSE-BRANCH
>	compare temp with b
>	jump-if-ge FALSE-BRANCH
>Generating the temporary is trivial for a compiler; 
>it's not as if this had to
>be parsed by a macro preprocessor.
>
>The lookahead to distinguish the constructs "E < E < E" and "E < E" is, I
>believe, no worse than the problem of distinguishing "if (E) S;" and
>"if (E) S; else S;".

But you wouldn't want a single production to get a<b<c as a ternary operator;
you really want to be able to handle a < b < c < ... < n

And do you want it restricted to conditionals, or extended
to all expressions/statements?

This should all be easy; but I don't like it.  It feels "unnatural."
I think the problem is that you want to make relational operators
into a sort of control flow thing -- not really operators at all.
Compare + with your version of <.

	a+b+c     means           (a + b) + c
but
	a<b<c    doesn't mean     (a < b) < c
			   or      a < (b < c)


So, I guess it's a doable idea; it's just going to feel
really unnatural to a lot of people.  I prefer Pascal's
version, where it is illegal to write a<b<c at all.
This avoids any misinterpretation.  On the other hand,
I'd prefer a few more levels of precedence allowing me
to write
	a<b and b<c
instead of
	(a<b) and (b<c)

On the other hand, versions of LISP allow things like
	(+ a b c d)
and
	(< a b c d)

which seems best of all.  Maybe we should just give up on
"normal" algebraic notation as a bad idea extended too far.

Regards,
Preston Briggs
preston@titan.rice.edu