Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: Same label in different types, how do people solve this?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Mattias Waldau <mattias.waldau@t...>
Subject: RE: Same label in different types, how do people solve this?
My problems isn't the restriction as such. If I know about the restriction,
I can code around it.

The problem is that this particular restriction is very unusual, and
therefor I need to be informed about this. Now it is in the faq, but why not
put it into the error message "two fields in different types in the same
file/module cannot have the same name."

/mattias

-----Original Message-----
From: Dave Berry [mailto:dave@kal.com]
Sent: Wednesday, December 13, 2000 2:17 PM
To: Chris Hecker; Mattias Waldau; Caml-List
Subject: RE: Same label in different types, how do people solve this?


The same issue arises with variant types -- a constructor defined in one
type cannot be defined in a later type.  Do you find this to be a problem as
well?  One could make an argument that languages should be consistent in how
they treat these two cases.  OCaml was consistent until it added polymorphic
variants.  SML is not consistent, because it forbids redefinition of
constructors but permits fields to be used in different record types.
(Technically, SML record types are types in their own right, unlike CAML
record types which must be named).

Also, I'm curious as to why the module approach doesn't meet your
requirements.  Do you really need to use different types with the same label
in the same module?

Dave.


-----Original Message-----
From: Chris Hecker [mailto:checker@d6.com]
Sent: Monday, December 11, 2000 18:24
To: Mattias Waldau; Caml-List
Subject: RE: Same label in different types, how do people solve this?



>I understand that all you functional experts thinks this restriction is
>obvious, but for me it is more like a bug/misfeature. So this 'misfeature'
>should actually be stated for all us who aren't interested how types are
>infered in functional programming.

I'm with Mattias on this one.  I'm practical above theoretical.  All of the
workarounds for this problem seem like they generate way more tedious work
for the programmer, and they still don't quite accomplish the goal 100%.
This characteristic of doing more work and only asymptotically approaching
your goal is a bad taste I associate with C++.

Anyway, my "vote" would be to allow specification, with : if it's possible
since it's the obvious syntax, but even with @@ if necessary (even though I
think it's really ugly).

Chris