Feature request : Tuples vs. records

Feature request : Tuples vs. records

[David Teller]

A long time ago, I used to believe that there was a large difference 
between tuples and records: tuples constructors/patterns use the order 
of their arguments to determine where they fit in the data structure, 
while records use the name of arguments. And then, labels arrived and 
somehow made possible to use either style when it comes to defining and 
applying functions.

Now, of course, I have the task of teaching OCaml to students. When it 
comes to explaining the difference between tuples and records, I'm 
suddenly unsure. Why is there a difference at all ? Aren't records the 
same thing as tuples with labels ? Couldn't/shouldn't the next version 
of OCaml uniformize both syntaxes and get us rid of {} once and for all ?

I envision something like
# (1,2);;
- : int * int = (1, 2)

# let pair_2 = (~x:1, ~y:2);;
pair_2 : x:int * y:int = (1, 2)

# let pair_3 = (~y:2, ~x:1);;
pair_3 : y:int * x:int = (2, 1)    (*or perhaps normalisation, say based 
on the lexicographical order of labels*)

# pair_2 = pair_3;; (*structural equality*)
true

# match pair_2 with (~y:y, ~x:x) -> (x,y);;
- : int * int = (1, 2)


Is anything such considered ?

Thanks,
 David

Re: [Caml-list] Feature request : Tuples vs. records

[Andrej Bauer]

Tuples and records are the same thing from the mathematical point of 
view, namely they are all just finite products. The only difference is 
that in once case the components are called 1, 2, 3, .., n and in the 
other the components have custom names. When I teach this stuff to 
students I first introduce tuples and later records. I tell them records 
are like tuples with named components, from which it follows that the 
order is not important. I also tell them (since they know Java), that 
records are a bit like simple-minded classes without inheritance, 
interfaces, methods and constructors (except they have constructors 
"built-in").

 From programmer's point of view it is better to have both tuples and 
records because they serve different purposes:

1) Tuples are syntactially "light-weight" and allow one to easily
    handle several values at the same time (without having to define a
    datatype)

2) Records allow the programmer to remember which component is what by
    naming them.

By the way, I always wondered why ocaml doesn't have generic projection 
operations from cartesian products (I belive they are writen #1, #2, #3 
... in SML).

Andrej

Re: [Caml-list] Feature request : Tuples vs. records

[skaller]

On Thu, 2007-02-22 at 11:42 +0100, Andrej Bauer wrote:

> By the way, I always wondered why ocaml doesn't have generic projection 
> operations from cartesian products (I belive they are writen #1, #2, #3 
> ... in SML).

There's another difference in Ocaml: records
are nominally typed, tuples are structurally typed.


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

Re: [Caml-list] Feature request : Tuples vs. records

[David Teller]

Yes, that's actually the only real difference I see between records and 
tuples. I have the feeling that every other difference is just syntactic 
sugar.

Now, unless I'm mistaken, OCaml's design is mostly towards structural 
typing. Usually, when one wants nominal typing, one resorts to abstract 
types safely hidden in modules. From this point of view, nominal typing 
of records is therefore somewhat surprising.

Am I getting something wrong ?

Cheers,
 David

skaller a écrit :
> On Thu, 2007-02-22 at 11:42 +0100, Andrej Bauer wrote:
>   
> There's another difference in Ocaml: records
> are nominally typed, tuples are structurally typed.
>   

Re: [Caml-list] Feature request : Tuples vs. records

[Andreas Rossberg]

skaller wrote:
> 
>> By the way, I always wondered why ocaml doesn't have generic projection 
>> operations from cartesian products (I belive they are writen #1, #2, #3 
>> ... in SML).
> 
> There's another difference in Ocaml: records
> are nominally typed, tuples are structurally typed.

In fact, these are closely related. In SML, tuples *are* records: the 
syntax (x,y) is merely syntactic sugar for {1=x, 2=y}, where 1 and 2 are 
numeric labels. Record projection #lab thus naturally applies to tuples. 
However, that definition of tuples requires structural record typing.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Re: [Caml-list] Feature request : Tuples vs. records

[Jon Harrop]

On Thursday 22 February 2007 13:55, David Teller wrote:
> Yes, that's actually the only real difference I see between records and
> tuples. I have the feeling that every other difference is just syntactic
> sugar.
>
> Now, unless I'm mistaken, OCaml's design is mostly towards structural
> typing. Usually, when one wants nominal typing, one resorts to abstract
> types safely hidden in modules. From this point of view, nominal typing
> of records is therefore somewhat surprising.
>
> Am I getting something wrong ?

Structural typing is weaker. So tuples are only suitable for simple cases 
(primarily returning pairs of values from functions). Whenever things get 
complicated (>3 fields) you should switch to records.

Structural typing is often slower. So records are preferable when performance 
is critical.

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

Re: [Caml-list] Feature request : Tuples vs. records

[Till Varoquaux]

Another simple difference is that you have to declare the type of the
records whereas types of tupples can be infered. Since the typechecer
actually uses the type information given, you can use polymorphic
fields to implement general reccursivity.
I would also mention row polymorphisme and "mutable" as notable
differences. You could also note that they are not always
interchangeable: whilst you wouldn't want to define a new record type
for every tupple you use (very verbose), direct access to a defined
field and the "with" keyword (e.g let b={a with x=1}) make records
nice to handle large structures.

Till

On 2/22/07, Andreas Rossberg <rossberg@ps.uni-sb.de> wrote:
> skaller wrote:
> >
> >> By the way, I always wondered why ocaml doesn't have generic projection
> >> operations from cartesian products (I belive they are writen #1, #2, #3
> >> ... in SML).
> >
> > There's another difference in Ocaml: records
> > are nominally typed, tuples are structurally typed.
>
> In fact, these are closely related. In SML, tuples *are* records: the
> syntax (x,y) is merely syntactic sugar for {1=x, 2=y}, where 1 and 2 are
> numeric labels. Record projection #lab thus naturally applies to tuples.
> However, that definition of tuples requires structural record typing.
>
> --
> Andreas Rossberg, rossberg@ps.uni-sb.de
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Feature request : Tuples vs. records

[Till Varoquaux]

On 2/22/07, David Teller <David.Teller@ens-lyon.org> wrote:
> Sounds interesting. Do you have documentation on this use of records for
> general recursivity ?
>
> Thanks,
>  David

I really put my foot in my mouth for my previous post (I had just read
the part about unlabeled tupple in SML...). Anyway here I come:

let rec f a b=
 if false then
  (*Although this is never called it breaks polymorphisme*)
  f print_string "a";
 a b;;

And here is the same using records (and having a more general type):

type my_rec={f:'a 'b.('a -> 'b) -> 'a -> 'b};;

let rec r={
 f=(fun a b ->
     if false then
      (*Polymorphisme is not b0rken...*)
      r.f print_string "a";
     a b
 )
};;
r.f print_int 5;;

This is a very useless example. Thierry Martinez (I know you are
reading us) had a cool example and some of the fixpoint operators on:
http://okmij.org/ftp/ML/fixpoints.ml
use this trick.

Cheers,
Till




>
> Till Varoquaux a écrit :
> > Another simple difference is that you have to declare the type of the
> > records whereas types of tupples can be infered. Since the typechecer
> > actually uses the type information given, you can use polymorphic
> > fields to implement general reccursivity.
> > I would also mention row polymorphisme and "mutable" as notable
> > differences. You could also note that they are not always
> > interchangeable: whilst you wouldn't want to define a new record type
> > for every tupple you use (very verbose), direct access to a defined
> > field and the "with" keyword (e.g let b={a with x=1}) make records
> > nice to handle large structures.
> >
> > Till
>
>

Re: [Caml-list] Feature request : Tuples vs. records

[brogoff]

On Thu, 22 Feb 2007, Till Varoquaux wrote:
> On 2/22/07, David Teller <David.Teller@ens-lyon.org> wrote:
> > Sounds interesting. Do you have documentation on this use of records for
> > general recursivity ?

For polymorphic recursion, how about this?

http://caml.inria.fr/pub/ml-archives/caml-list/2002/08/9e1089a04ce714a0541373be008c3130.en.html

And, since I brought it up, I noticed in the CVS that someone wrote the
test for directly expressing polymorphic recursive functions in OCaml.
Any chance we'll see that in the future?

-- Brian

Re: [Caml-list] Feature request : Tuples vs. records

[Tom]

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

On 22/02/07, David Teller <David.Teller@ens-lyon.org> wrote:
>
>
> Now, unless I'm mistaken, OCaml's design is mostly towards structural
> typing. Usually, when one wants nominal typing, one resorts to abstract
> types safely hidden in modules. From this point of view, nominal typing
> of records is therefore somewhat surprising.
>
>
In general, there is a problem with structural (sub)typing... Although it
seems better and in all ways superior to nominal (sub)typing from the
theoretical point of view, practically, it is... slow. (At least when
compared to nominal (sub)typing).

- Tom

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

Re: [Caml-list] Feature request : Tuples vs. records

[skaller]

On Thu, 2007-02-22 at 20:45 +0100, Tom wrote:

> In general, there is a problem with structural (sub)typing... Although
> it seems better and in all ways superior to nominal (sub)typing from
> the theoretical point of view, practically, it is... slow. (At least
> when compared to nominal (sub)typing). 

It isn't slow if you actually use the power: your program
compiles and runs with amortised O(1) dispatch.

The equivalent C++ program can be written, and requires
a base for each method, and a base for every possible
combination of methods .. and whilst you're uploading
the sources for these combinations to the Klingon computer
network fortunately the universe suffers heat death.
[This is a good thing because there's no way you were
going to be able to pay Enterprise ISP P/L the network
traffic charges]

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