Browse thread
Subtyping structurally-equivalent records, or something like it?
[
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: | 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
<anthony.tavener@gmail.com> 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 ->
kinematic
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