Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: Is this supposed to happen?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier@T...>
Subject: Re: Is this supposed to happen?
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.