Naming types

[Simon Peyton-Jones]

| > 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.

Simon