caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Matej Košík" <kosik@fiit.stuba.sk>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Ocaml: typing by name vs. typing by structure
Date: Sun, 16 Oct 2011 22:24:06 +0200	[thread overview]
Message-ID: <4E9B3D66.6080203@fiit.stuba.sk> (raw)
In-Reply-To: <CAPFanBHM=HEmbVwEDmyS=r7O2DY_dKm+kB5abAtNWBW=o8sinQ@mail.gmail.com>

On 10/16/2011 09:24 PM, Gabriel Scherer wrote:
> If record were structurally typed, there would be an ambiguity as to,
> for example, what this function mean:
> 
>   let access_foo t = t.foo
> 
> What would the type of `access_foo` be ? { foo : 'a } -> 'a ? { foo :
> 'a; bar : 'b } -> 'a ?

{ foo : 'a } -> 'a

seems plasible

> Should `access_foo { foo = 1 }` be typable? And `access_foo { foo = 1;
> bar = true }` ?
> 
> In this situation, you want record subtyping. This get more
> complicated than the relatively simple OCaml records.

This may be too troublesome to support but I guess it is plausible language change and it would enable additional Ocaml terseness. Let me clarify.

At the moment, it is not possible to do this:

  type t = {l1:int} * {l2:int};;

It is a syntax error. We are forced to do it gradually:

  type t1 = { l1 : int; }
  type t2 = { l2 : int; }
  type t = t1 * t

This is somewhat cumbersome.

Similarly, you cannot do this

  type t = A of {l1:int}
         | B of {l2:float}
         | C of {l1:int; l2:float}

Only this works:

  type t1 = { l1 : int}
  type t2 = { l2 : float}
  type t3 = { l1 : int; l2: float}
  type t = A of t1
         | B of t2
         | C of t3

We were forced to introduce three superfluous type-names [t1;t2;t3].
How would you feel if you were forced to do that for every tuple-type?

Sometimes tuples are not ideal
(when they have lots of members)
Records are better in those cases because you can access elements by their label and when you construct records with lots of fields, the labels clarify which field has what meaning. But switching from tuples to records is not smooth. What could be gained in readability (labeled fields) is lost by cluttering the program by auxiliary record type definitions.

> In fact, OCaml
> has structurally typed structures with named fields : objects
> 
>   # let access_foo t = t#foo;;
>   val access_foo : < foo : 'a; .. > -> 'a = <fun>
>   # access_foo (object method foo = 1 method bar = true end);;
>   - : int = 1

Interesting.

> 
> Tuples don't have this issue as they don't have an universal accessor
> function : there is no way to get the first element of a tuple
> whatever its width is. Therefore, all tuples manipulation make the
> structure concrete, and structural subtyping comes at no complexity
> cost ... if you accept the absence of universal accessors. SML has
> them (#1 #2 etc.) and I'm not sure how they handle this.

-- 
Matej Košík

  reply	other threads:[~2011-10-16 20:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-16 18:51 Matej Kosik
2011-10-16 19:24 ` Gabriel Scherer
2011-10-16 20:24   ` Matej Košík [this message]
2011-10-16 20:54     ` Gabriel Scherer
2011-10-17 13:53     ` AUGER Cedric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E9B3D66.6080203@fiit.stuba.sk \
    --to=kosik@fiit.stuba.sk \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).