Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Subtyping structurally-equivalent records, or something like it?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-05-07 (09:42)
From: AUGER <Cedric.Auger@l...>
Subject: Re: [Caml-list] Subtyping structurally-equivalent records, or something like it?
Le Sun, 02 May 2010 04:59:48 +0200, Anthony Tavener  
<> a écrit:

> Wow! Thanks Stéphane... that was a little piece of magic I was
> hoping for. It's a bit verbose, but at least it doesn't affect
> performance and it allows all the control over types I need.
> I now see I didn't really grok phantom types whenever they were
> mentioned. A bit of "in one ear and out the other". Now I have
> better grasp on yet another feature of the language.
> I know I read that one before, Dario... that title about NASA
> is familiar! Too bad I didn't remember it was a solution to the
> problem I was now having. Thank-you for that link -- an
> excellent description of the problem and a nice solution.
> Ah, great stuff... that looks like something to consider too,
> Sylvain! There's plenty of material on phantom types but I never
> made the connection that they were what I was looking for.
> Thank-you everyone for the help and clear explanations! I'm
> going to go play with this now. :)
> Anthony Tavener

Just one last thing about this thread:
It is not really related to type checking,
but more on a way to convince the programmer that it uses rightfully a  
force and not a position;
it is the use of labels. Imagine you have this function:

(** [next_position p v dt] is the next position of an object on position  
[p] with
     a speed [v] in a time [dt] *)
val next_position: kinematic -> kinematic -> float -> kinematic

as far as you have the documentation next to you, you won't make mistake  
between the two `kinematic';
but if you don't have it, then you may not recall if you have to write  
`next_position v p dt' or `next_position p v dt'

but now, imagine you have:

(** [next_position p v dt] is the next position of an object on position  
[p] with
     a speed [v] in a time [dt] *)
val next_position: pos:kinematic -> speed:kinematic -> laps:float ->  

then you just have to use the right labels to make it work:
`next_position ~speed:v ~pos:p ~laps:dt'.

As I said, this is not a type checking solution, but it can make the  
program clearer and allows the user to forget parameters order (but he  
needs to memorize label names)

Just beware with higher order:

# let g ~x ~y = x - y;;
val g : x:int -> y:int -> int = <fun>
# let app (f: y:int -> x:int -> int) a b = f ~x:a ~y:b;;
val app : (y:int -> x:int -> int) -> int -> int -> int = <fun>
# app g;;
Error: This expression has type x:int -> y:int -> int
        but an expression was expected of type y:int -> x:int -> int

Cédric AUGER

Univ Paris-Sud, Laboratoire LRI, UMR 8623, F-91405, Orsay