Re: Fractional/negative fixity?
On Nov 7, 2006, at 11:47 , apfelmus@quantentunnel.de wrote:
Henning Thielemann wrote:
On Tue, 7 Nov 2006, Simon Marlow wrote:
I'd support fractional and negative fixity. It's a simple change to make, but we also have to adopt
http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/ FixityResolution
I've added the proposal to the end of that page. In fact, the page already mentioned that we could generalise fixity levels, but it didn't mention fractional or negative values being allowed.
Maybe that page could also mention earlier proposals and the solutions without precedence numbers. I prefer the non-numeric approach with rules like "(<) binds more tightly than (&&)", because it says what is intended and it allows to make things unrelated that are unrelated, e.g. infix operators from different libraries. Consequently a precedence relation to general infix operators like ($) and (.) had be defined in each library.
I think that computable real fixity levels are useful, too. A further step to complex numbers is not advised because those cannot be ordered.
But ordering of the computable reals is not computable. So it could cause the compiler to loop during parsing. :) -- Lennart
by all means, lets have warm fuzzy precedence declarations infix(nearly right) (exp (2*i*pi) + 1) :-) infix(mostly left) (((\x->cos x + i*(sin x)) (2*pi)) + 1) (-: who says that all the fun has to start in the type system?-) we would probably need to refer to hyperreals, in order to introduce infinitesimal differences between real precedence levels? oh, and let us not forget the early Basic's contribution to language design: renum (who could ever to without it!-) ah well, to justify the use of bandwith (and because you should never let your design decisions be influenced by someone making fun of any of the suggestions): - absolute numbers for operator precedence are a hack that reminds me strongly of my Basic times: I used steps of 100 starting with 1000 for line numbers, I used renum to make space for additions or to clean up (was that refactoring?-), but I was still happy to leave all that nonsense behind! - googling for "operator precedence relative" suggests that some parser generators already use something other that absolute preferences - prolog has more precedence levels, as well as simple declarations for pre- and postfix operators (fx, xf) sorry, I just couldn't resist any more;-) claus -- unsagePerformIO: some things are just not wise to do
participants (2)
-
Claus Reinke -
Lennart Augustsson