Hallo! I just wonder why map (^2*3) [1..9] returns [1,64,729,4096,15625,46656,117649,262144,531441] . [i^2*3|i<-[1..9]] return the expected [3,12,27,48,75,108,147,192,243]. And so does map (\a->a^2*3) [1..9]. So why is (^2*3) not equvalent to \a->a^2*3 ? Thanks, Andreas
I think so. The language grammar requires (if I read it correctly) that the expr in an aexp of the form (op expr) have a higher priority than op. On Mon, 12 Mar 2001 andreas.marth@daimlerchrysler.com wrote:
So why is (^2*3) not equvalent to \a->a^2*3 ?
Because it's being parsed as (^(2*3)) when it should be rejected. Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
Jón Fairbairn writes:
So why is (^2*3) not equvalent to \a->a^2*3 ?
Because it's being parsed as (^(2*3)) when it should be rejected.
Interestingly enough, all of Hugs, nhc98, and hbc make the same mistake. Only ghc rejects the expression, correctly complaining that the fixities do not match. Regards, Malcolm
On Tue, 13 Mar 2001, Malcolm Wallace wrote:
Interestingly enough, all of Hugs, nhc98, and hbc make the same mistake. Only ghc rejects the expression, correctly complaining that the fixities do not match.
Why is this common? The language design seems to be correct and it's not hard to get the implementation right, surely? Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (pm only, please)
| On Tue, 13 Mar 2001, Malcolm Wallace wrote: | > Interestingly enough, all of Hugs, nhc98, and hbc make the same | > mistake. Only ghc rejects the expression, correctly complaining that | > the fixities do not match. | | Why is this common? The language design seems to be correct | and it's not hard to get the implementation right, surely? Getting infix right is one of the hardest parts of parsing Haskell. The main difficulty arises because fixities and priorities can be declared in the source itself (local to definitions - indeed, fixity can be declared /after/ the use of the symbol). Most systems tend to have a liberal parser, accepting all kinds of infix expression, then later on, typically during renaming, they attempt to detect errors and patch-up the expressions given the declared fixity that was in scope. Hbc is the only system that actually changes its parsing rules on-the-fly as it reads a fixity decl. This is one reason why it is interesting that hbc makes the same mistake as Hugs - it shows there is a different mechanism/assumption at work. The mistake arises because of the operator section. After finding the outermost operator, the system (at least in nhc98) simply treats the whole of the rest of the expression as its argument, essentially demoting the sectioned operator to zero priority. Regards, Malcolm P.S. Now fixed in nhc98.
participants (3)
-
andreas.marth@daimlerchrysler.com -
Jon Fairbairn -
Malcolm Wallace