simonpj at microsoft.com
Fri Sep 26 11:31:23 EDT 2008
| > Arguably we should drop the upper/lower case distinction altogether, on
| > the grounds that some (written) languages don't even have it. That
| > would solve this problem and restore unity, but it's a much bigger
| > change and has other disadvantages.
| I was suggesting that this change shouldn't be made, not that a larger
| change should be made. (a larger change would be nice in principle, but
| the obvious possibilities would make code uglier in the common case).
I don't want this discussion to get out of control! All I'm after is a way to make (+) into a type constructor, which I think is highly desirable notationally. We saw another instance yesterday, when Dov was writing session types like (Chan (Int :?: Bool :?: Emp)) when he should have been able to say (Chan (Int ? Bool ! Emp)). To achieve this I just need a way to distinguish the type constructors and values in export lists.
| Incidentally, it might be worth breaking proposal 1 into two separate
| proposals: It would be useful to be able to disambiguate imports/exports
| even if we don't change the lexical rules for types, as it would allow
| the class and type namespaces to be separated.
I don't advocate splitting the type and class name spaces. Classes occur *in* types, and we parse (C a, C b) => foo by parsing the (C a, C b) bit as a tuple. Since the => comes later we don't know we are looking at classes. We could fix this up with a later pass, but I'm not hearing our users crying out for this.
More information about the Cvs-ghc