Version française
Home     About     Download     Resources     Contact us    
Browse thread
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: Sven LUTHER <luther@d...>
Subject: Re: Same label in different types, how do people solve this?
On Mon, Dec 11, 2000 at 08:17:47PM +0100, Pierre Weis wrote:
> > >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
> 
> I tried a lot of more attractive alternative:
>  -- type::label but :: is already used for lists (consing).
>  -- type@label, but @ also used (append). 
>  -- type`label, but the symbol ` introduces variant
>  -- type'label (as in Ada), but ' is used in identifier and chars and ...
> 
> Another available notation could be type.:label, or type.'label ...
> 
> Cheers,
> 
> PS: I added something in the FAQ about the problem of overloading of
> labels, see one of (or both :)
> 
> http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-fra.html
> http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-eng.html

Why not automatically produce some kind of module for every type declaration,
or at least the one that involve records and labels, but it could be usefull
also for variants.

when you type :

  type point_2d = { x:int; y:int}

it would be automatically converted to :

module Point_2d = struct
  type point_2d = { x:int; y:int}
end
open Point_2d

Then you can easily use :

let p2 = {Point_2d.x=10; Point_2d.y=10}

Sure there can be problem with module namespace conflicts, but a trick could
be found (well types are lowercases, while module are uppercases, isn't it ?)

Is there a big space or efficiency issue involved with this ?

Another idea would be to have the record cast to the correct type :

let p2 : point_2d = {x=10; y=10}
or
let p2 = {x=10; y=10} : point_2d

Or maybe this causes problems with the typer ?

Friendly,

Sven Luther