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

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

[Frederic GAVA]

Hi David,

Another difference is that (If I remember) record of float are unboxed and not tuple of float. But perhaps it could be done.

Also, I do understand the true difference between write
{x=1;y=2} (9 caracters) and (~x:1,~y:2) (11 caracters) except syntaxic one (I thinks that = is simpler that : which is more for type)

Frédéric Gava



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

[David Teller]

Frederic GAVA a écrit :
> Hi David,
>
> Another difference is that (If I remember) record of float are unboxed and not tuple of float. But perhaps it could be done.
>   
I assume that's not a real difficulty. I might be wrong.
> Also, I do understand the true difference between write
> {x=1;y=2} (9 caracters) and (~x:1,~y:2) (11 caracters) except syntaxic one (I thinks that = is simpler that : which is more for type)
>
>
>   

I grant you that it is syntactically shorter. So we can keep it as a 
syntactic shortcut.

I'm more concerned about having to
* declare every record type I use -- that looks to me clumsy and Java-like
* differenciate between records and tuples during pattern-matching
* having to learn/teach two different implementations of what is 
essentially the same concept
* having to learn/teach that third meaning of operator = (the first one 
being comparison between values and the second one being its use in let 
x = ...).


Cheers,
 David

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

[Jacques Garrigue]

From: David Teller <David.Teller@ens-lyon.org>
> Frederic GAVA a écrit :
> > Another difference is that (If I remember) record of float are
> > unboxed and not tuple of float. But perhaps it could be done.
> >   
> I assume that's not a real difficulty. I might be wrong.

Not theoretically difficult, since it is already done for float
arrays, but there could be a severe performance hit: since
a tuple can be created inside a polymorphic function, one would need
to check all components to see whether they are floats or not.
(The situation is better with float arrays: one only needs to check
the first component, since all the others are bound to have the same
type.)
So I would say that unboxing tuples of floats would not be worth it.

More generally, one has much more freedom for using clever
representations when using nominal (declared) types than when using
structural ones. This also includes the use of embedded mutable
fields, for instance.

Another advantage of nominal typing is that the intended types become
explicit. This way you can immedietely see how a value is supposed to
be used. This also gets you early error message for missing fields when
you change a type definition.

So nominal typing has some advantages both in terms of efficiency and
detection of errors, the second advantage being particularly helpful
for beginners.

On the other hand structural typing avoids extra definitions, and
allows more code sharing and polymorphism. One cannot imagine ML
without structural tuples. In ocaml, you have also objects that can
mimic records, and polymorphic variants for sum types.

> I'm more concerned about having to
> * declare every record type I use -- that looks to me clumsy and Java-like

See above for one rationale.

> * differenciate between records and tuples during pattern-matching

Hard to avoid when one type is structural and the other nominal.

> * having to learn/teach two different implementations of what is 
> essentially the same concept

Again, they have both the same set-theoretic interpretation, but the
distinction nominal/structural is fundamental at the type level.
I agree with you that this will be hard to explain this to beginners.

> * having to learn/teach that third meaning of operator = (the first one 
> being comparison between values and the second one being its use in let 
> x = ...).

Ah, syntax...
Unfortunately, it is as it is, and this from the beginning of ML.
Even SML shares the same syntax.

If you want a far fetched a posteriori explanation: a record is
basically the same thing as a first class module with only value
components. Field access uses the same syntax. So you can see
  {x = 3; y = 5}
as a shorthand for 
  struct let x = 3 let y = 5 end
See the "=" in both?
Of course this does not explain other differences between records and
modules...

Cheers,

Jacques Garrigue

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

[Jon Harrop]

On Thursday 22 February 2007 16:16, David Teller wrote:
> I'm more concerned about having to
> * declare every record type I use -- that looks to me clumsy and Java-like
> * differenciate between records and tuples during pattern-matching

The same can be said of ordinary and polymorphic variants. You must declare 
ordinary variants. You must distinguish between the two in patterns.

Similarly, polymorphic variants (that are structurally typed and provide more 
inference) weaken the type system. The main disadvantage of this is in 
reporting errors, which become prohibitively obfuscated.

> * having to learn/teach two different implementations of what is
> essentially the same concept

Although tuples and records are both product types, I think people have cited 
several fundamental differences between them: typing, performance, robustness 
etc.

> * having to learn/teach that third meaning of operator = (the first one
> being comparison between values and the second one being its use in let
> x = ...).

You would rather teach another use of ":"?

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

[Richard Jones]

On Fri, Feb 23, 2007 at 10:39:45AM +0900, Jacques Garrigue wrote:
> On the other hand structural typing avoids extra definitions, and
> allows more code sharing and polymorphism. One cannot imagine ML
> without structural tuples. In ocaml, you have also objects that can
> mimic records, and polymorphic variants for sum types.

The penalty of having the extra definitions wouldn't be so bad if
'type t = ...' could appear inside let statements (ie. not just at the
top level).  At the moment, type definitions are often a long way away
from where they are used.

Rich.

-- 
Richard Jones
Red Hat UK Limited

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

[Till Varoquaux]

I also agree:
IMHO , it woud feel natural to have
 open .. in (* <-- there's already a camlp4 extension that brings this*)
 type ... in
etc...
it would be coherent with the let syntax. However I don't know the
deep implications of such a change and happen to be very prompt
criticizing. I'm sure there is a profound reason for the language not
be like this.

Till

On 2/23/07, Richard Jones <rich@annexia.org> wrote:
> On Fri, Feb 23, 2007 at 10:39:45AM +0900, Jacques Garrigue wrote:
> > On the other hand structural typing avoids extra definitions, and
> > allows more code sharing and polymorphism. One cannot imagine ML
> > without structural tuples. In ocaml, you have also objects that can
> > mimic records, and polymorphic variants for sum types.
>
> The penalty of having the extra definitions wouldn't be so bad if
> 'type t = ...' could appear inside let statements (ie. not just at the
> top level).  At the moment, type definitions are often a long way away
> from where they are used.
>
> Rich.
>
> --
> Richard Jones
> Red Hat UK Limited
>
> _______________________________________________
> 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

[Nicolas Pouillard]

On 2/23/07, Till Varoquaux <till.varoquaux@gmail.com> wrote:
> I also agree:
> IMHO , it woud feel natural to have
>  open .. in (* <-- there's already a camlp4 extension that brings this*)
>  type ... in
> etc...
> it would be coherent with the let syntax. However I don't know the
> deep implications of such a change and happen to be very prompt
> criticizing. I'm sure there is a profound reason for the language not
> be like this.

You already have it in some sense:

let module M = struct
  type t = ...
end in
   ... M.t ...

>
> Till
>
> On 2/23/07, Richard Jones <rich@annexia.org> wrote:
> > On Fri, Feb 23, 2007 at 10:39:45AM +0900, Jacques Garrigue wrote:
> > > On the other hand structural typing avoids extra definitions, and
> > > allows more code sharing and polymorphism. One cannot imagine ML
> > > without structural tuples. In ocaml, you have also objects that can
> > > mimic records, and polymorphic variants for sum types.
> >
> > The penalty of having the extra definitions wouldn't be so bad if
> > 'type t = ...' could appear inside let statements (ie. not just at the
> > top level).  At the moment, type definitions are often a long way away
> > from where they are used.
> >
> > Rich.
> >
> > --
> > Richard Jones
> > Red Hat UK Limited
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>


-- 
Nicolas Pouillard

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

[Lukasz Stafiniak]

On 2/23/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Thursday 22 February 2007 16:16, David Teller wrote:
> > I'm more concerned about having to
> > * declare every record type I use -- that looks to me clumsy and Java-like
> > * differenciate between records and tuples during pattern-matching
>
> The same can be said of ordinary and polymorphic variants. You must declare
> ordinary variants. You must distinguish between the two in patterns.
>
You can define a syntax extension to translate (note you can use your
preferred syntax):

`{x=u; y=v; z=w}
    ==>
object val x=u val y=v val z=w method x=x method y=y method z=z end

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

[Lukasz Stafiniak]

On 2/23/07, Lukasz Stafiniak <lukstafi@gmail.com> wrote:
> On 2/23/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> > On Thursday 22 February 2007 16:16, David Teller wrote:
> > > I'm more concerned about having to
> > > * declare every record type I use -- that looks to me clumsy and Java-like
> > > * differenciate between records and tuples during pattern-matching
> >
> > The same can be said of ordinary and polymorphic variants. You must declare
> > ordinary variants. You must distinguish between the two in patterns.
> >
I have this idea... We could have row polymorphism in tuples, without
any impact on performance! Instead of insisting that ('a * 'b) means
exactly two elements, we could have (> 'a * 'b) at least two elements.
Any projections or pattern matching fetches the tuple fields without
problems: it doesn't need to care that there are more than it needs.

Say you realize that you need to return another value from a function
(which already returns a tuple): you would only modify the function
and not its uses.

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

[Brian Hurt]

On Sat, 24 Feb 2007, Lukasz Stafiniak wrote:

> I have this idea... We could have row polymorphism in tuples, without
> any impact on performance! Instead of insisting that ('a * 'b) means
> exactly two elements, we could have (> 'a * 'b) at least two elements.
> Any projections or pattern matching fetches the tuple fields without
> problems: it doesn't need to care that there are more than it needs.
>
> Say you realize that you need to return another value from a function
> (which already returns a tuple): you would only modify the function
> and not its uses.

Not being able to do this is one of the reasons I *like* Ocaml.

Consider the case where the calling location is:
 	let a, b = foo ... in
 	...

Now you change foo to return 3 tuples instead of just 2.  What happens?

If you say "The third element quietly gets dropped", I'll respond with "if 
I wanted that behavior, I'd be coding in Perl."

If you've changed what you're returning, you've change the semantics of 
the function- what it means is now different.  And it's a good idea to go 
look at every place where it's called, and consider what effect this 
change in semantics will have on that code.  Ocaml is very helpfull in 
that it will tell you every place you need to look at to deal with this 
change- filename and line number.  Note that if you, the programmer, 
decide that the right thing to do is to just drop the new third argument, 
it's real easy ro change the calling code to just:
 	let a, b, _ = foo ... in
 	...


Brian

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

[skaller]

On Sat, 2007-02-24 at 10:50 -0500, Brian Hurt wrote:
> 
> On Sat, 24 Feb 2007, Lukasz Stafiniak wrote:
> 
> > I have this idea... We could have row polymorphism in tuples, without
> > any impact on performance! Instead of insisting that ('a * 'b) means
> > exactly two elements, we could have (> 'a * 'b) at least two elements.
> > Any projections or pattern matching fetches the tuple fields without
> > problems: it doesn't need to care that there are more than it needs.
> >
> > Say you realize that you need to return another value from a function
> > (which already returns a tuple): you would only modify the function
> > and not its uses.
> 
> Not being able to do this is one of the reasons I *like* Ocaml.
> 
> Consider the case where the calling location is:
>  	let a, b = foo ... in
>  	...
> 
> Now you change foo to return 3 tuples instead of just 2.  What happens?
> 
> If you say "The third element quietly gets dropped", I'll respond with "if 
> I wanted that behavior, I'd be coding in Perl."

I think you're taking his idea too literally: consider instead
an explicit syntax which allows tuples to be pattern matched
like lists. Felix can actually do this:

/////////////////////////////////////////
#import <flx.flxh>

typedef fun xcur(t:TYPE):TYPE => typematch t with
  | ?a -> ?b => a * xcur b
  | _ => t
endmatch;

var x : xcur (int->long->double) = (1,(2L,3.0));

match x with
| ?a,(?b,?c) => { 
  print a; print " "; 
  print b; print " "; 
  print c; endl;
}
endmatch;
//////////////////////////////////////////

The thing to note here is that we have a generic pattern match
which can fold along the components of a function type
using recursion. (This is an example of my version of Jay
pattern calculus).

But you cannot recurse over a tuple like this because it
isn't built up inductively from a binary operator.

We can adapt Lukasz suggestion to make it possible,
by for example the syntax:

  head, tail ...

or some such, which treats a tuple like a list. Of course
such a construction should be *explicit*.

Similarly, a version of this could work for arrays: it would
be data polymorphic but not generic (since all array elements
have the same type).


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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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