caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier@Theory.Stanford.EDU>
To: onomoto@netcom.com (Young and Loud)
Cc: caml-list@margaux
Subject: Re: Is this supposed to happen?
Date: Tue, 16 Nov 1993 13:37:40 -0800 (PST)	[thread overview]
Message-ID: <9311162137.AA28706@Tamuz.Stanford.EDU> (raw)
In-Reply-To: <199311161813.KAA02998@mail.netcom.com> from "Young and Loud" at Nov 16, 93 10:14:56 am

Dear Young and Loud,

The short answer to your question is: yes, this is supposed to happen.
One could argue that what actually happens is, always, in some sense,
supposed to happen, but let's not get into philosophy. In this
particular case, it's not even a bug; it's a feature -- though the
error message could indeed be made more informative <blush>.

What happens is that in Caml record type declarations are generative,
just like sum type ("concrete" type) declarations. Hence, when you
define
        type bar = {
                a : int;
                c : float
        } ;;

you define two labels, "a" from int to bar, and "c" from float
to bar. Following the standard lexical scoping rules, this label "a"
hides the one defined before as part of the declaration of "foo".
Hence, when you write

        let v1 = {
                a = 1;
                b = "typefoo?"
        } ;;

the typechecker complains that you're mixing labels from two different
record types: "a" from "bar" and "b" from "foo". It says this in
slightly less explicit terms, but that's the, uh, intended meaning.

The bottom line is: once you've declared "bar", you won't be able to
build any values of type "foo", because the "a" label of "foo" is no
longer reachable.

The behavior you expected -- if you give "a" and "b", then that's a
record of type "foo"; if you give "a" and "c", that's a record of type
"bar" -- requires a different treatment of record labels, as in SML or
Caml V3.1. SML does not declare record types; Caml V3.1 declares record
types, but allows overloading of labels. Both approaches make
programming with record more comfortable, but add considerable
complexity to the type inference algorithm, and result in some
programs being rejected as ambiguous for reasons that are hard to
figure out.

Hope this helps,

- Xavier Leroy

PS. Just for the record, Caml Light is not an "interpreter", but a
bytecode compiler. Admittedly, it's not GCC, but it's not QBasic either.




      reply	other threads:[~1993-11-17 14:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-11-16 18:14 Young and Loud
1993-11-16 21:37 ` Xavier Leroy [this message]

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=9311162137.AA28706@Tamuz.Stanford.EDU \
    --to=xavier@theory.stanford.edu \
    --cc=caml-list@margaux \
    --cc=onomoto@netcom.com \
    /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).