Re: Definable operators (was: Problems with Hardware, Languages, and Compilers)

Nick Maclaren <nmm1@cus.cam.ac.uk> 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
>>priority.


Joe English <jenglish@crl.com> 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
>aren't commutative.


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
course.


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
>read.


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
agreement :-)


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
--

Return to the comp.compilers page.
Search the comp.compilers archives again.