Simon Peyton-Jones
Personally I think there are strong advantages to ".":
I'm sorry, but I don't see it. Function composition is one of /the/ most central concepts to functionaly programming. Overloading dot further is a terrible idea. I don't see why using it for record field selection or as flipped application makes sense at all - unless we change the function composition operator (Haskell prime?).
* For record selectors, currently written (x r), writing r.x is exactly right
Why?
* For these unary operators, r.x really does mean (abstractly) "select the x field from r"
How so? I guess I don't understand how particular (concrete) symbols can have an "exactly right" or intrincic (abstract) meaning.
* And that is the way that "." is used for modules: "M.x" means "select the x function from module M"
Granted, but I think this was a mistake, too.
* You can think of qualified names for modules in the same way "Control.Monad" means pick the Monad module from the Control group.
Fair enough.
* It culturally fits with the way "." is used on OO languages
I don't think this is very convincing argument. Some syntax is fairly universal, like arithmetic or string quotes, but record selection isn't among the most consistent. Learning a new one is the least of your worries if you're approaching Haskell from an OO direction. And similar syntax might lead people to expect similar semantics, something likely to be wrong.
What is the disadvantage? Well, Haskell already uses "." for composition. But
* "." is already special. If you write M.x you mean a qualified name, not the composition of data constructor M with function x
See above.
I merely propose to make it even special-er!
This would be okay if special is good, but I think special is rather the opposite. Is there really no other symbol we can use? E.g. one of # , @ & ' ?
I'll keep quiet about syntax now.
Okay, me too. -k -- If I haven't seen further, it is by standing in the footprints of giants