type equality symbol

[Brian Hulley]

Lennart Augustsson wrote:
> I agree.  There are other ways that to solve the same problem as the 
> case distinction does.
> 
> On Dec 7, 2007 12:45 PM, Johannes Waldmann <waldmann at imn.htwk-leipzig.de 
> <mailto:waldmann at imn.htwk-leipzig.de>> wrote:
> 
>     On Fri, 7 Dec 2007, Manuel M T Chakravarty wrote:
> 
>      > The problem is that Haskell 98 already messed that up.
>      > If type functions are to use lower-case letters, [...]
> 
>     Yes.
> 
>     The broken thing is that the upper/lower case distinction
>     has syntactic importance in the language definition at all.
> 
>     I guess this was introduced to avoid writing out
>     some declarations. This is a bad design goal,
>     especially so for a declarative language.

I agree that it is problematic that type synonyms need to start with 
uppercase because this means that if you convert between multi-param 
type classes and associated types etc you need to change the case of the 
relevant type "variables" (ditto for parameterized modules vs 
translucent modules, both possible extensions).

However in general I think having the case distinction is a good idea, 
since it provides these benefits:

1) Allows tyvars in types to be identified and implicitly quantified

2) Eliminates pattern matching errors caused by mis-spelling 
constructors (although Cayenne solves this by putting parentheses around 
constructors)

3) Avoids the chaos of individual programmers making up their own 
idiosyncratic conventions regarding where to use lowercase and where to 
use uppercase. Having the distinction built into the language therefore 
eliminates controversy ... ;-)

There is nevertheless a tricky problem with 2 possible extensions: ML 
style translucent modules + typecase. typecase would need data types to 
be in uppercase since they are constructors of (*) whereas translucent 
modules would expect to be able to use a data type where the signature 
expected a type (which needs to be lowercase). Of course a solution 
could be:

	-- abstract/ translucent module acts as a signature
	module FOO where
		type t : *

	module Foo :> FOO where
		data T = ...
		type t = T
but not
	module Foo :> FOO where
		data t = ...	-- as in ML


Regards, Brian.