prefix operators
Christian Maeder
Christian.Maeder at dfki.de
Tue Jul 13 07:53:28 EDT 2010
Simon Peyton-Jones schrieb:
> Yes, I somewhat hacked up the rules for ! in an ad-hoc way. I really wanted to allow
>
> f !x !y = (x,y)
>
> which meant a bit of fiddling, because LHSs are parsed as terms, so this is parsed as
>
> (f ! x) ! y
>
> (ie as infix operators) and I have to squizzle around to re-interpret them as prefix operators. Not very cool. Something unified would be a Good Thing.
I assume
f -x -y = ...
is also parsed as
(f - x) - y
and later rejected as "Parse error in pattern".
The (possibly) indented interpretation "f (-x) (-y)" or "f (!x) (!y)"
simply contradicts the interpretation as terms with binary operators.
With bang patterns the binary operator "!" can no longer be defined as:
f !x =
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/bang-patterns.html#bang-patterns-sem
This case is not mention under
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#syntax-stolen
One could consider whitespace (which already happens with "$" in
template haskell), but that's questionable, too.
Since we make a new language spec knowing many extensions, it would be
possible to disallow more bits in the standard in order to avoid stolen
syntax by extensions.
But disallowing infix pattern using "!" is non-orthogonal and making "!"
a reserved op like "~" would break some libraries.
Should "rec" become a reserved keyword, because I had to rename it when
switching on extensions?
I would not mind if "forall" (and "exist") became a keyword (although
not required, since forall can only occur within types).
Should "$" be followed by whitespace (or forbidden), just to allow
compilation using template haskell, too?
I don't know the impact of -XMagicHash on infix stuff using # or ##.
I think, it's unfortunate that the (scanner and) parser depends on
extensions. It would be better to parse a language superset and let
static analysis deal with (known) extensions.
Christian
>
> Simon
>
>
>
> | -----Original Message-----
> | From: haskell-prime-bounces at haskell.org [mailto:haskell-prime-
> | bounces at haskell.org] On Behalf Of John Meacham
> | Sent: 08 July 2010 00:59
> | To: haskell-prime at haskell.org
> | Subject: prefix operators
> |
> | It occurred to me the other day that Haskell (w/ bang patterns) now has
> | 3 prefix operators, all of which are defined independently and follow
> | their own special rules for parsing. we have (-), (!) and (~).
> |
> | It would seem to me that we should somehow be able to unify the
> | mechanism behind parsing these, as in practice, it seems that prefix
> | operators are useful in haskell.
> |
> | We have some similarities, - and ! are both infix and prefix operators,
> | ~ is not. ! and ~ can only be in patterns as prefix, (-) can be in both
> | patterns and expressions.
> |
> | But it seems like we may be able to come up with a common way of parsing
> | them all, prolog has had user defined infix, prefix, and postfix
> | operators (sharing the same name even) and is still able to parse things
> | properly so I don't think there will be a technical issue.
> |
> | My first impulse is to treat application as just another binary operator
> | with a certain precedence and find appropriate precedences for !,~,- in
> | the new framework.
> |
> | note: I am not proposing user defined prefix operators, just musing
> | about whether we can unify the rules behind parsing the current three
> | prefix operators, perhaps folding them into the fixity resolution
> | algorithm.
> |
> | John
> |
> | --
> | John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
> | _______________________________________________
> | Haskell-prime mailing list
> | Haskell-prime at haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell-prime
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w at public.gmane.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
More information about the Haskell-prime
mailing list