Re: [Gnu-arch-users] Re: Tla spork

[Robin Farine]

On Friday 27 August 2004 18.02, John Meinel wrote:

> I still think having the operator *next to* the thing it is
> operating on, rather than having to parse a lot of parenthesis is
> easier. But I will say that if you have a list of things and the
> + operator becomes the sum operator instead, you can clean up
> some things.

Yeah, it is one of the advantages.

> I'm not sure what you are saying about not prefering rules of
> precedence. Perhaps just because it isn't as explicit.

Considering only the syntax, a grammar for infix expressions does 
not in general induce a one to one relationship between expressions 
and their derivation trees. The only way of removing the resulting 
ambiguity is to either use parenthesis around every <operand1, 
operator, operand2> triplets, or to add precedence rules that 
select one of the derivation trees as the "official" one.

In C for instance, making use of precedence rules to spare a few 
( and ) is a good way to force the next developer to stare for a 
few minutes at an expression before he finally decides to add the 
spared ( and ) for safety.

> I will also say, though, Andrew Suffields alternative Fibbonacci
> sequence using Haskell looks rather clean.

Yes, but it looks clean mainly because of the semantics of the 
guards (not unlike how forward inference engines like OPS-5 work by 
the way), not really thanks to its syntax.

The nice property of the syntax of Lisp dialects is that everything 
is either an atom, an empty list or a list of atoms. A program can 
manipulate a program as it manipulates data. I do not know if 
Haskell is able to this in such an elegant way, though.

Robin