[Haskell-cafe] Fractional/negative fixity?

[Simon Marlow]

Nicolas Frisby wrote:
> Let's remember that if something is broke, it's only _right_ to _fix_
> it. I patiently waited for someone else to make that pun.
>
> Understanding the language won't be much harder, but understanding
> fixity declarations will become a task. Consider:
>
> infixl -1.7521  -- what and why?
>
> As the operator space becomes more dense, negative and fractional
> fixities are going to become more obfuscated. The negative and
> fractional fixities will satisfy a number purposes well, but they will
> also be abused and lead to confusion.
>
> This smells like a wart growing on a wart to me.

All these are valid points.  However, given that we can't completely redesign, implement and test a new fixity system in time for Haskell', it makes sense to make a simple change that unambiguously improves the current system, and is no more difficult to implement (in fact, I bet it adds zero lines of code to the compiler).

Cheers,
        Simon


> Nick
>
> On 11/7/06, David House <dmhouse at gmail.com> wrote:
>> On 07/11/06, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> wrote:
>>> I must say though, that I don't like the reasoning that we
>>> can put in fractional fixities because it's a small
>>> change. The way to hell is through a series of small
>>> steps. If using integers to express fixities is a bit of a
>>> hack, switching to rational numbers is a hack on top of a
>>> hack.
>>
>> Well, It's a _conceptually_ simple idea, one that doesn't make
>> understanding the language much harder.
>>
>> Also, it provides an infinite space for fixities. I think the problem
>> 'binds tighter than X but not as tight as Y', where X and Y are only
>> fixity integer apart is somewhat common, and this would fix it. It
>> would allow for extensibility into the future, where the operator
>> space will only become more dense, and maintaining a complete order
>> with only 10 integers to play will become more and more difficult.
>> Allowing an infinite amount of operators to come between any two
>> operators sounds like a solid design decision to me.
>>
>> --
>> -David House, dmhouse at gmail.com
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe