<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Your idea looks _much_ better from code
clarity point of view, but it's unclear to me, how to deal with it
internally and in error messages. I'm not a compiler guy, though.<br>
<br>
Worse, it does not allow to set up fixity relative to operator
that is not in scope and it will create unnecessary intermodule
dependencies. One should fall back to numeric fixities for such
cases, if it is needed.<br>
<br>
On 08/13/2012 11:26 PM, Ryan Ingram wrote:<br>
</div>
<blockquote
cite="mid:CA+XKtKijgyTOJZASLMQdo-fvTNs5JP-raC-a5o1JsCvOATmaow@mail.gmail.com"
type="cite">When I was implementing a toy functional languages
compiler I did away with precedence declarations by number and
instead allowed the programmer to specify a partial order on
declarations; this seems to be a much cleaner solution and avoids
arbitrary precedences between otherwise unrelated operators
defined in different modules.<br>
<br>
You could write statements like<br>
<br>
-- define + and - to have the same precedence<br>
infixl + -<br>
<br>
-- define * to have higher precedence than +<br>
infixl * above +<br>
<br>
-- define / to have the same precedence as *<br>
infixr / equal *<br>
<br>
-- $ is right-associative<br>
infixr $<br>
-- you can also separate precedence from fixity declaration<br>
precedence $ below +<br>
<br>
-- function application has higher precedence than all operators
by default, but you can override that<br>
infixl . above APP<br>
<br>
-- == is non-associative<br>
infix ==<br>
<br>
Here's some parses with this system:<br>
<br>
a + b - c => (a+b)-c<br>
f.x.y z == g w => (((f.x).y) z) == (g w)<br>
a == b == c => parse error (non-associative operator)<br>
a * b / c => parse error (left-associative/right-associative
operators with same precedence)<br>
a == b $ c => parse error (no ordering known between == and $)<br>
a $ b + c => a $ (b+c)<br>
<br>
I think this is a much cleaner way to solve the problem and I hope
something like it makes it into a future version of Haskell.<br>
<br>
-- ryan<br>
<br>
<div class="gmail_quote">On Sun, Aug 12, 2012 at 11:46 AM, Евгений
Пермяков <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:permeakra@gmail.com" target="_blank">permeakra@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> fixity declaration has
form <b>infix(l|r)? [Digit]</b> in haskell. I'm pretty
sure, that this is not enough for complicated cases.
Ideally, fixity declarations should have form <b>infix(l|r)?
[Digit](\.(+|-)[Digit])</b>* , with implied infinitely
long repeated (.0) tail. This will allow fine tuning of
operator priorities and much easier priority selection. For
example, it may be assumed, that bit operations like
(.&.) operator have hightest priority and have
priorities like 9.0.1 or 9.0.2, anti-lisps like ($) have
lowest priority like 0.0.1, control operators have base
priority 1.* and logic operations like (&&) have
priority of 2.* and it will be possibly to add new operators
between or above all (for example) control operators without
moving fixity of other ones.<br>
<br>
Agda2 language supports wide priority range, but still
without 'tails' to my knowledge. Is there any
haskell-influenced language or experimental syntactic
extension that address the issue?<br>
</div>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a moz-do-not-send="true"
href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://www.haskell.org/mailman/listinfo/haskell-cafe"
target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>