> I disagree, it would be useful, it's far more self-documenting than a 
> tuple (which usually need a record-like comment right next to their 
> declaration to tell what's what), and you could match the record like
>
> Bar x -> x.age
>
> and it wouldn't need a type name.  I've wanted this feature myself a 
> number of times.

If you can say Bar x -> x.age, you can say Bar x -> x, which implies 
that the type of x should be a type in its own right, independent of 
Bar.

I think this is consistent.

> It has type { age : int; }, just like int * int has type int * int and 
> doesn't need a name.  Does the record need a name for some other 
> reason?

int * int denotes a type, { age : int } defines a type.  One { age : 
int } is not compatible with a different { age : int }.

It would probably be possible for { age : int } to be made a valid type 
expression, but it would change the language significantly and provide 
you with fairly little gain (it would save you one type definition when 
using it as part of a sum type).

Also note that sum types of records are less storage-efficient than sum 
types with multiple arguments (the record is indirect, because you must 
be able to write Bar x -> x).  Incidentally, if the record weren't 
indirect, Bar x could be Obj.magic-compatible with x, but that's just a 
detail of the implementation...

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners