>>>> This doesn't work at all, due to a namespace collision.
>>>
>>> A /severe/ design bug, if I'm asked. Nothing I'd expect from a
>>> contemporary programming language.
>>
>> It's embarrassing, sure. But it's not really an especially severe bug;
>> it's just a nuisance having to manually prefix all your field names with
>> the name of the type that they belong to (or some abbreviation thereof).
>
> ... which is exactly why namespaces were invented in the first place.
> Any contemporary programming language that bothers to use namespaces
> should avoid such nuisances once and for all.

Well, the other alternative is to define each record in a separate 
compilation unit. That'll do it. But that's also rather inconvenient.

In mitigation, Haskell programs tend not to have quite so many data type 
definitions as a typical C program, and they tend to have a lot fewer 
fields. That's not to say that name collisions don't happen though.

There have been a couple of solutions suggested. GHC has a mode in which 
names are allowed to overlap, and the compiler tries to "guess" what you 
meant at compile-time. This mostly works, but many people consider it to 
be a deeply evil hack. Then there's Frege, which is basically a very 
slightly modified Haskell which compiles to Java source code. In Frege, 
every type is its own namespace, and in case of ambiguity you must 
prefix the field name with the type name. (Note that C# does this with 
enum values.)

Ultimately the problem is type inference. Pascal lets you write 
"foo.bar" to access a field - but then, in Pascal the type of "foo" must 
be explicitly stated in a type signature. Haskell is trying to let you 
write the same expression but still let the compiler automatically 
detect the type of "foo" - a much harder problem...

Post a reply to this message