From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA09955 for caml-red; Thu, 14 Dec 2000 18:44:15 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA00026 for <weis@pauillac.inria.fr>; Tue, 12 Dec 2000 10:53:03 +0100 (MET)
Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.6.1])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eBC9r2X21355;
	Tue, 12 Dec 2000 10:53:03 +0100 (MET)
Received: from lambda.u-strasbg.fr (lambda.u-strasbg.fr [130.79.90.63])
	by dpt-info.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id KAA11927;
	Tue, 12 Dec 2000 10:52:10 +0100
Received: from luther by lambda.u-strasbg.fr with local (Exim 3.20 #1 (Debian))
	id 145mGB-0006g9-00; Tue, 12 Dec 2000 11:02:11 +0100
Date: Tue, 12 Dec 2000 11:02:11 +0100
To: Pierre Weis <Pierre.Weis@inria.fr>
Cc: Chris Hecker <checker@d6.com>, caml-list@inria.fr
Subject: Re: Same label in different types, how do people solve this?
Message-ID: <20001212110211.A25607@lambda.u-strasbg.fr>
References: <4.3.2.7.2.20001211101656.00c12320@shell16.ba.best.com> <200012111917.UAA18607@pauillac.inria.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200012111917.UAA18607@pauillac.inria.fr>; from Pierre.Weis@inria.fr on Mon, Dec 11, 2000 at 08:17:47PM +0100
From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
Sender: weis@pauillac.inria.fr

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