[Caml-list] Sumtypes of records

[Caml-list] Sumtypes of records

[Christophe Poucet]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

Why can't constructors of sumtypes take nameless records? (Warning stupid example follows)

type plop = Foo | Bar {age : int};;

doesn't work, but                            

type person = {age : int};;
type plop = Foo | Bar of person;;

does.

Anyone know why?

Thanking you in advance,


[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

Re: [Caml-list] Sumtypes of records

[Ville-Pertti Keinonen]

> Why can't constructors of sumtypes take nameless records? (Warning 
> stupid example follows)
>  
> type plop = Foo | Bar {age : int};;

  ...

Probably because it wouldn't make much sense.  Either the only way you 
could access age in the above is by matching Bar { age = x }, which is 
not very useful (you might as well have Bar of int, or a tuple for 
multiple fields), or the record type needs to have a name so that x in 
the pattern Bar x has some printable type.

-------------------
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

Re: [Caml-list] Sumtypes of records

[Chris Hecker]

>>Why can't constructors of sumtypes take nameless records? (Warning stupid 
>>example follows)
>>type plop = Foo | Bar {age : int};;
>Probably because it wouldn't make much sense.  Either the only way you 
>could access age in the above is by matching Bar { age = x }, which is not 
>very useful (you might as well have Bar of int, or a tuple for multiple 
>fields),

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.

>or the record type needs to have a name so that x in the pattern Bar x has 
>some printable type.

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?

Chris


-------------------
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

Re: [Caml-list] Sumtypes of records

[Ville-Pertti Keinonen]

> 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

Re: [Caml-list] Sumtypes of records

[Ville-Pertti Keinonen]

>  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...

Correcting myself - that wouldn't work because you also have to be able 
to write Bar x -> Bar x...

So a sum type of a record is inevitably indirect.

-------------------
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

Re: [Caml-list] Sumtypes of records

[Marcin 'Qrczak' Kowalczyk]

Dnia sob 17. maja 2003 03:35, Chris Hecker napisał:

> 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?

let foo x = x.bar
What is the type of foo if there is no named record in scope having field bar?

I don't say that I like it but it's a consequence of the OCaml's type system. 
Haskell has that too (but theoretically type classes could be made to help). 
SML is what you would like; it has sort of overloading of certain builtin 
operations and in this case requires the type of x to be statically known 
somehow. There is no problem with dynamically typed languages, and 
"non-functional" statically typed ones require to explicitly write the type 
of bound variables anyway. Having the same field name in various record
types just doesn't mix well with type inference.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
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

Re: [Caml-list] Sumtypes of records

[Chris Hecker]

>let foo x = x.bar
>What is the type of foo if there is no named record in scope having field bar?

It could have a type, it just doesn't have a programmer defined name.  This 
has nothing to do with having the same field names in various 
records...field names would hide previous ones just like they [annoyingly] 
currently do.  This is just about whether there's some way to do anonymous 
records.  So for "Bar { age : int; }" the compiler would generate some 
internal name to use for the record type.  It would be shorthand for:

type bar_anonymous_record_type_name_123 = { age : int; }
type foo = Bar bar_anonymous_record_type_name_123

The only difference is you wouldn't be able to use "bar_anon...123" 
explicitly, only via inference since it's generated.  This isn't a big deal 
or a high priority to add, but I don't see why it wouldn't just work and be 
somewhat useful.

Chris

-------------------
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

Re: [Caml-list] Sumtypes of records

[Marcin 'Qrczak' Kowalczyk]

Dnia nie 18. maja 2003 08:33, Chris Hecker napisał:

> This is just about whether there's some way to do anonymous
> records.  So for "Bar { age : int; }" the compiler would generate some
> internal name to use for the record type.  It would be shorthand for:
>
> type bar_anonymous_record_type_name_123 = { age : int; }
> type foo = Bar bar_anonymous_record_type_name_123

Ah, I see. Like in Turbo Pascal (I don't know about Pascal in theory) where it 
applies to arrays and pointers too. And like structs and unions in C and C++.

I don't like it because it's confusing. The syntax suggests that record types 
are built on the fly like tuples (like in SML) but the semantics is that they 
are explicitly defined somewhere like algebraic types. And this would be the 
only such case.

When you would write:
   type foo = Foo of {x : int}
   type bar = Bar of {x : int}
then this is a type error:
   let f (Foo y) = Bar y

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
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

Re: [Caml-list] Sumtypes of records

[John Max Skaller]

Marcin 'Qrczak' Kowalczyk wrote:


>>type bar_anonymous_record_type_name_123 = { age : int; }
>>type foo = Bar bar_anonymous_record_type_name_123
>>
> 
> Ah, I see. Like in Turbo Pascal (I don't know about Pascal in theory) where it 
> applies to arrays and pointers too. And like structs and unions in C and C++.
> 
> I don't like it because it's confusing. The syntax suggests that record types 
> are built on the fly like tuples (like in SML) but the semantics is that they 
> are explicitly defined somewhere like algebraic types. And this would be the 
> only such case.
> 
> When you would write:
>    type foo = Foo of {x : int}
>    type bar = Bar of {x : int}
> then this is a type error:
>    let f (Foo y) = Bar y
 
There is no reason for it. The compiler

already does sophisticated signature matching.
There's no reason it can't identify all anonymous
record types with the same structure the
same way it does for tuples (and polymorphic variants).


So this *could* be consistently supported if it

was deemed useful, but I would have to warn
that anonymous types invariable lead to
difficult to understand error messages
(I use polymorphic variants extensively
and regularly get 200 line error messages).

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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