strange behavior with record type definition

strange behavior with record type definition

[Florent]

Hi, I have defined two distinct record's types with a field's name in 
common. But when I try to define a function that uses the first of the 
types, the compiler gives me a type error.
How can I use my first type in a function ??

This is what I did:

# type t0 = { i : int ; s : string };;
type t0 = { i : int; s : string; }
# type t1 = { i : int ; f : float };;
type t1 = { i : int; f : float; }
# let f (x:t0) = match x with {i= a; s= b} -> b;;
Characters 28-40:
  let f (x:t0) = match x with {i= a; s= b} -> b;;
                              ^^^^^^^^^^^^
The record field label s belongs to the type t0
but is here mixed with labels of type t1
#

Re: [Caml-list] strange behavior with record type definition

[Jon Harrop]

On Friday 11 November 2005 22:59, Florent wrote:
> Hi, I have defined two distinct record's types with a field's name in
> common. But when I try to define a function that uses the first of the
> types, the compiler gives me a type error.
> How can I use my first type in a function ??
>
> This is what I did:
>
> # type t0 = { i : int ; s : string };;
> type t0 = { i : int; s : string; }
> # type t1 = { i : int ; f : float };;
> type t1 = { i : int; f : float; }
> # let f (x:t0) = match x with {i= a; s= b} -> b;;
> Characters 28-40:
>   let f (x:t0) = match x with {i= a; s= b} -> b;;
>                               ^^^^^^^^^^^^
> The record field label s belongs to the type t0
> but is here mixed with labels of type t1

Either use different field names, e.g.:

  type t0 = { i0 : int ; s0 : string }
  type t1 = { i1 : int ; f1 : float }

or put them in separate modules.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] strange behavior with record type definition

[Michael Wohlwend]

Hi,

On Friday 11 November 2005 23:59, Florent wrote:
> How can I use my first type in a function ??

give different (distinct) names to the members of your records, then it should 
work (although it's a annoying "feature" to have to do this :-) 

cheers
 Michael

Re: [Caml-list] strange behavior with record type definition

[Martin Jambon]

On Fri, 11 Nov 2005, Florent wrote:

> Hi, I have defined two distinct record's types with a field's name in common. 
> But when I try to define a function that uses the first of the types, the 
> compiler gives me a type error.
> How can I use my first type in a function ??

The answer is there: 
http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-eng.html#labels_surcharge


Martin

--
Martin Jambon, PhD - http://martin.jambon.free.fr

Re: [Caml-list] strange behavior with record type definition

[Florent]

Mmhh, why do we have to use differents label names in distinct record 
types ?
It makes record types not easy to use when a lot of them are needed ...


Martin Jambon wrote:

> On Fri, 11 Nov 2005, Florent wrote:
>
>> Hi, I have defined two distinct record's types with a field's name in 
>> common. But when I try to define a function that uses the first of 
>> the types, the compiler gives me a type error.
>> How can I use my first type in a function ??
>
>
> The answer is there: 
> http://pauillac.inria.fr/caml/FAQ/FAQ_EXPERT-eng.html#labels_surcharge
>
>
> Martin
>

Re: [Caml-list] strange behavior with record type definition

[skaller]

On Sat, 2005-11-12 at 11:58 +0100, Florent wrote:
> Mmhh, why do we have to use differents label names in distinct record 
> types ?

So that the type of an expression:

	{ x = 1; y = 2 }

can be determined.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] strange behavior with record type definition

[Nicolas Cannasse]

>>Mmhh, why do we have to use differents label names in distinct record 
>>types ?
> 
> 
> So that the type of an expression:
> 
> 	{ x = 1; y = 2 }
> 
> can be determined.

It could still be determined using all the labels together instead of 
the first one only, but that will not go well with the { r with ... } 
construct.

Nicolas

Re: [Caml-list] strange behavior with record type definition

[skaller]

On Sat, 2005-11-12 at 21:20 +0900, Nicolas Cannasse wrote:
> >>Mmhh, why do we have to use differents label names in distinct record 
> >>types ?
> > 
> > 
> > So that the type of an expression:
> > 
> > 	{ x = 1; y = 2 }
> > 
> > can be determined.
> 
> It could still be determined using all the labels together instead of 
> the first one only, but that will not go well with the { r with ... } 
> construct.

Hmmm .. but that must have the type of r, so if you had
a 'multi-label' solution this would be quite nice, since
it would help constrain the type of r.

In a whole program analyser this would always be enough:
if there is any doubt due to some unused fields, then those
fields would just be dropped since they're not used .. :)

[Felix will do this for classes, not so much by design
as because that's how the instantiator works ..]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] strange behavior with record type definition

[Michael Wohlwend]

On Saturday 12 November 2005 13:51, skaller wrote:
> > > So that the type of an expression:
> > >
> > > 	{ x = 1; y = 2 }
> > >
> > > can be determined.

I would have no problem to write in these situations Type1.{ x = 1 } or  
Type2.{x = 2} , I think there exists  camlp4 program for this.

 Michael

Re: [Caml-list] strange behavior with record type definition

[Florent]

Ok but with these two record types defined :
    type t0 = { x : int ; y : int } ;;
    type t1 = { x : int } ;;

There is no ambiguity about the following expression's type:
    { x = 0 ; y = 0 } ;;
Why can't the t0 type be infered ?

And with this function definition,
    let get_y (t:t0) = t.x ;;
I explicitly say to the compiler that t is of type t0, so why does the 
compiler infer a t1 type when trying to get the x label of a t0 type value ?



Matthieur Dubuget wrote :
 > If there is y.x in your code, and the type t = {x : blabla; ...} was
 > declared,
 > then y's type is infered to be of type t

Skaller wrote :
 > So that the type of an expression:
 > { x = 1; y = 2 }
 > can be determined.

Re: [Caml-list] strange behavior with record type definition

[skaller]

On Sat, 2005-11-12 at 15:15 +0100, Michael Wohlwend wrote:
> On Saturday 12 November 2005 13:51, skaller wrote:
> > > > So that the type of an expression:
> > > >
> > > > 	{ x = 1; y = 2 }
> > > >
> > > > can be determined.
> 
> I would have no problem to write in these situations Type1.{ x = 1 } or  
> Type2.{x = 2} , I think there exists  camlp4 program for this.

This looks quite a nice solution to me (though I prefer builtin
syntax not camlp4). Anyone see any problems with it?


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] strange behavior with record type definition

[Christophe TROESTLER]

On Sat, 12 Nov 2005, Michael Wohlwend <micha-1@fantasymail.de> wrote:
> 
> On Saturday 12 November 2005 13:51, skaller wrote:
> > > > So that the type of an expression:
> > > >
> > > > 	{ x = 1; y = 2 }
> > > >
> > > > can be determined.
> 
> I would have no problem to write in these situations Type1.{ x = 1 } or  
> Type2.{x = 2} , I think there exists  camlp4 program for this.

You can do almost the same with modules:

module T1 = struct type t = { x : int; y : int } end
module T2 = struct type t = { x : int; y : int } end

{ T1.x = 1; y = 2 } (* No need to repeat the module name *)
{ T2.x = 2; y = 3 }

ChriS

Re: [Caml-list] strange behavior with record type definition

[Christophe TROESTLER]

On Sat, 12 Nov 2005, Florent <florentflament@aist.enst.fr> wrote:
> 
> Ok but with these two record types defined :
>     type t0 = { x : int ; y : int } ;;
>     type t1 = { x : int } ;;
> 
> There is no ambiguity about the following expression's type:
>     { x = 0 ; y = 0 } ;;
> Why can't the t0 type be infered ?

As said by Nicolas, what would be the type of

let f r = { r with x = 1 }

> And with this function definition,
>     let get_y (t:t0) = t.x ;;
> I explicitly say to the compiler that t is of type t0, so why does the 
> compiler infer a t1 type when trying to get the x label of a t0 type value ?

Because (at this point) t.x implies t is of type t1.  If you do not
care to access the fields of t0 after, just reorder your definitions:

  type t0 = { x : int ; y : int }
  let get_y t = t.x
  type t1 = { x : int }

ChriS

Re: [Caml-list] strange behavior with record type definition

[Florian Weimer]

* Florent:

> Ok but with these two record types defined :
>    type t0 = { x : int ; y : int } ;;
>    type t1 = { x : int } ;;
>
> There is no ambiguity about the following expression's type:
>    { x = 0 ; y = 0 } ;;
> Why can't the t0 type be infered ?

Other common cases are ambiguous, for example:

  let proj_x v = v.x

Standard ML provides what you want, and you must specify all record
fields unless the record type can be inferred by other means.  For
example,

  fun proj_x v = #x v

or 
  fun proj_x { x = x, ... } = x

does not type-check, you must write:

  fun proj_x { x = x, y = _ } = x

This becomes quite cumbersome if there are more than two or three
components.  There is a workaround using datatypes, i.e. write

  datatype t0 = T0 of { x : int, y : int }

and

  fun proj_x (T0 { x = x, ... }) = x

So both approaches have their drawbacks.

Re: [Caml-list] strange behavior with record type definition

[Jacques Garrigue]

From: Florent <florentflament@aist.enst.fr>

> Ok but with these two record types defined :
>     type t0 = { x : int ; y : int } ;;
>     type t1 = { x : int } ;;
> 
> There is no ambiguity about the following expression's type:
>     { x = 0 ; y = 0 } ;;
> Why can't the t0 type be infered ?
> 
> And with this function definition,
>     let get_y (t:t0) = t.x ;;
> I explicitly say to the compiler that t is of type t0, so why does the 
> compiler infer a t1 type when trying to get the x label of a t0 type value ?

It is not a question about it being possible or not (it is possible,
and can even be made "principal"), but whether we want it in the
language or not.
Essentially, ocaml has two kinds of records: explicitly
declared records, and objects. Of course, objects as records
are not very efficient, but in many cases this doesn't matter.
You can even find a syntax extension to do it with the same syntax as
records.
  http://www.math.nagoya-u.ac.jp/~garrigue/code/ocaml.html

Knowing this, the choice is currently to make explicit records
non-ambiguous. This way you just have to look at any of the the
labels to know exactly which type is involved. This could be changed,
but you would loose this property.  Which would be fine with me, as
long as the information is still still easy to deduce without relying
on type inference.

Jacques Garrigue

Re: [Caml-list] strange behavior with record type definition

[Florent]

Thanks for your responses ,

Well, this is not an usual behavior for records, but why not.
If this choice has been made by the ocaml team, I'll use different label 
names for my records.

florent



Jacques Garrigue wrote:

>It is not a question about it being possible or not (it is possible,
>and can even be made "principal"), but whether we want it in the
>language or not.
>Essentially, ocaml has two kinds of records: explicitly
>declared records, and objects. Of course, objects as records
>are not very efficient, but in many cases this doesn't matter.
>You can even find a syntax extension to do it with the same syntax as
>records.
>  http://www.math.nagoya-u.ac.jp/~garrigue/code/ocaml.html
>
>Knowing this, the choice is currently to make explicit records
>non-ambiguous. This way you just have to look at any of the the
>labels to know exactly which type is involved. This could be changed,
>but you would loose this property.  Which would be fine with me, as
>long as the information is still still easy to deduce without relying
>on type inference.
>
>Jacques Garrigue
>  
>