Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: [Caml-list] Implicit parameters (was Future of labels)
> [The following is probably off-topic and probably needs quite a lot of
> work to be put in O'Caml but we can expect miracles from the Caml team,
> can not we?]
> A wish about optionnal arguments: I would use them a lot if they where a
> bit more... optionnal, in the style of implicit parameters of
> This would be really helpful when defining printers (where you have to
> carry everywhere the channel on which you are printing), when you are
> defining a type-checker (you must carry the current environment that is
> unchanged in all your rules but the one about lambda-abstraction, ...).

For those who didn't read the paper, this is really more about dynamic
scoping than default parameters.
In particular, their framework does not subsume ours (defaults cannot
be defined individually for each function).
(*They refer to label-selective lambda calculus (the foundation for
labeled argument in Caml), with the interesting comment that "it is
unclear whether such a change would integrate well in existing
functional languages"*)

Their system in itself uses the same mechanism as type classes, of
putting information into a constraint environment. I do not see how
one could do that in ML.

You can easily do dynamic scoping in ML (contrary to Haskell), by
using references. The only pitfall is that the produced code is not

     let set_dynamic r v f x =
       let old = !r in
       try r := v; let y = f x in r := old; y
       with exn -> r := old; raise exn

     let r = ref default
     let f () = !r
     let g x = set_dynamic r x f ()

A variant of this can be applied to printers, since by default they
call Format.std_formatter.

I suppose you might add some better syntax with camlp4.
Can this be made to work in a threaded program ?
This is a very interesting question...

For the specific case of a type checker, optional arguments can help:

let rec type_expr env expr =
  let type_expr ?(env=env) = type_expr env in
  match expr with ...
  | Lambda (var, body) -> ... type_expr ~env:(Env.add var ty env) body...

If your problem is that you have many such arguments to pass around,
then commuting labeled argument can also be helpful: you just have to
copy/paste the argument list at each function call, without caring
about their order.

I hope some of these methods can fit your needs.

Jacques Garrigue      Kyoto University     garrigue at
		<A HREF=>JG</A>
To unsubscribe, mail  Archives: