Browse thread
Type-checking bug (or feature?) in O'Caml 1.06
-
Paul Stodghill
- Pierre Weis
-
Paul Stodghill
- Pierre Weis
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Pierre Weis <weis@p...> |
| Subject: | Re: Type-checking bug (or feature?) in O'Caml 1.06 |
> The new behavior is even more bizarre than I had first thought.
>
> ---------------------------------------------------------------------------
> % cat foo.mli
> type ('a, 'b) t;;
> val iter: ('a -> 'b -> 'unit) -> ('a, 'b) t -> unit
[...]
> % ocamlc -v -i -c foo.mli
> [...]
> val iter : ('a -> 'b -> 'c) -> ('a, 'b) t -> unit
>
> Why is the generated type different than the declared type?
It is not, since you declared iter with the same type scheme:
> val iter: ('a -> 'b -> 'unit) -> ('a, 'b) t -> unit
^
the ' symbole turns out 'unit to be a type variable. Free variables
<I>names</I> in type schemes are irrelevant (as for functions
abstracted arguments in programs). Thus, in its messages, the compiler
generates new names for type variables as 'a, 'b, 'c, ..., and
the original names written in the source programs are forgotten.
For instance:
# type ('key, 'assoc_val) t = ('key * 'assoc_val) list;;
type ('a, 'b) t = ('a * 'b) list
Thus, the declared type scheme and the generated type scheme are equivalent.
Best regards,
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/