Open vmchale opened 6 years ago
Why was this closed? This is still an issue.
Reopening if it is still an issue.
The name of the issue is misleading
happy fails to generate valid Haskell when
<$>
is used.
It generates valid Haskell, just not the Haskell that you expect. Happy treats <$>
as <
followed by $>
, where $>
is a reference much like $1
, $2
, $3
, etc, that refers to the last (rightmost) item.
Something like fn <$> arg
turns into fn <happy_var_n arg
, which is of course valid Haskell – it is the use of the <
operator.
One way to fix this would be to abstain from substituting $
-references if they are preceded by a symbol that could be a Haskell operator.
I suggest we simply emit an error when <$>
is used in code
fragments. When the user meant <$>
, they could use fmap
instead. When the user meant < $>
(as in 1 < $>
), then the user can just insert a space.
The bug in question came from a parser hosted here. In short, if you write
instead of
it will fail during compilation with an arcane error message, viz.
I didn't see anything in the manual indicating that this would not be allowed. I think it would be nice to have
happy
return some sort of error message before GHC does - the one I ran into was not particularly user-friendly.Thanks!