|[4 earlier articles]|
|Re: Definable operators (was: Problems with Hardware, Languages, and C firstname.lastname@example.org (1997-03-14)|
|Re: Definable operators (was: Problems with Hardware, Languages, and C email@example.com (1997-03-16)|
|Re: Definable operators (was: Problems with Hardware, Languages, and C andy@cs.Stanford.EDU (1997-03-16)|
|Re: Definable operators (was: Problems with Hardware, Languages, and C firstname.lastname@example.org (1997-03-16)|
|Re: Definable operators (was: Problems with Hardware, Languages, and C email@example.com (1997-03-18)|
|Re: Definable operators (was: Problems with Hardware, Languages, and C firstname.lastname@example.org (1997-03-18)|
|Re: Definable operators (was: Problems with Hardware, Languages, and C email@example.com (1997-03-21)|
|From:||firstname.lastname@example.org (Nick Maclaren)|
|Date:||21 Mar 1997 10:12:09 -0500|
|Organization:||University of Cambridge, England|
|References:||97-03-037 97-03-047 97-03-070 97-03-105|
Nick Maclaren <email@example.com> wrote:
>>> [ re: user-defined infix operators ]
>>Algol 68 did, and was by no means the first. But Haskell has made a
>>very old mistake in being too general - consider the problems about
>>parsing a mixture of left- and right-associative operators of the same
Joe English <firstname.lastname@example.org> wrote:
>Haskell treats this condition (correctly, IMO) as a parse error. (I
>think ML does the same thing).
Fine. I agree that is the right solution! I misunderstood your
posting, as I am not a Haskell programmer.
>> Even worse, consider varying commutativity and distributivity.
>Distributivity and commutativity are semantic properties, not
>syntactic ones; I don't see why this should affect parsing. Haskell
>does allow you to specify an operator as non-associative -- so that (X
>`op` Y `op` Z) will be flagged as an error without further
>parenthesization -- which is sometimes useful for operators that
No, that depends on a particular parsing model. Consider a fully
associative (left and right) and commutative operator '*' defined for
all combinations of 'real' and 'int'. Because the compiler knows
those properties, the user has to provide just (real,real), (real,int)
and (int,int) versions - or (real,real) and an int->real converter, of
But it makes 'real*int*real' syntactically ambiguous, though legal in
my parse model (because it is NOT semantically ambiguous). And, yes,
I am aware that few languages use that parse model nowadays.
>> The 1960s experience was that allowing user- defined operators
>> (including redefinition) was fine, as was allowing user-defined
>> precedences for textually new ones, but beyond that lies madness.
>I think the 1990s experience has been somewhat different :-) Judicious
>use of user-defined infix operators has been very beneficial to
>clarity of exposition in most of the Haskell code I've written and
Are you really claiming that you redefine the priorities of standard
operators, and that clarifies your code? Oh, come now!
I think that you just misread what I said, and we are actually in close
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Tel.: +44 1223 334761 Fax: +44 1223 334679
Return to the
Search the comp.compilers archives again.