Hello Cale, Wednesday, April 23, 2008, 11:26:49 AM, you wrote:
f x+y = (x+y)^2
f x + y = x^2 + y
imho, it's easy to see what there are no spaces around + on first line, but there are spaces at the second. imho, it's just our habits - ignore spaces and split expression by operators actually, shift from usual style of f(x+y,z*t) to f (x+y) (z*t) was no less dramatic. i propose to go one step further and use spaces instead of brackets as one more way to control precedence. this idea born from my haskell programming practice - these additional parentheses are rather common and avoiding them will make program reading easier. but it needs to shift habits
That's a pretty hard to see bug, and it sneaks right past the typechecker. I'm all for a certain amount of whitespace sensitivity, but that might be going too far.
my main point is that considering space-less operators as having larger priority is our natural habit. consider this: f a*b x+c imho, my interpretation of this expression sounds more natural than haskell's current one
for now, wee need to standardize current haskell practice just for compilers interoperability and teaching purposes (noone wants to write book about ghc 6.8 or teach students to it)
Well, my point is that if we can see these changes that we want to make to the libraries, it makes little sense to let people write those books and then change all the libraries out from under them a few months down the road. Maybe it's what we'll end up doing anyway, but it's worth considering.
unfortunately, it will be not a few months. there are many important things we may change in haskell. sometime ago it was said that haskell' will just standartize existing haskell (ghc/hugs) state and haskell 2 will be new, probably incompatible language. fixing just one oddity in haskell' will give us worst of both worlds - broken compatibility and lots of oddities still remaining -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com