caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: Judicael.Courant@lri.fr
Cc: caml-list@inria.fr
Subject: [Caml-list] Implicit parameters (was Future of labels)
Date: Fri, 30 Mar 2001 12:42:37 +0900	[thread overview]
Message-ID: <20010330124237D.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <3AC33042.94F387B@lri.fr>

> [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
> http://citeseer.nj.nec.com/lewis00implicit.html.
> 
> 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
reentrant.

     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 kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  reply	other threads:[~2001-03-30  3:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-29  0:44 [Caml-list] Future of labels Jacques Garrigue
     [not found] ` <AAEBJHFJOIPMMIILCEPBEEFHCHAA.mattias.waldau@abc.se>
2001-03-29  6:43   ` Jacques Garrigue
2001-03-29 11:44     ` Mattias Waldau
2001-03-29 17:52     ` Mattias Waldau
2001-03-29  8:22 ` Chris Hecker
2001-03-29  9:46 ` Markus Mottl
2001-04-09  1:28   ` John Max Skaller
2001-04-09  8:33     ` [Caml-list] Indexed and optional arguments (was Future of labels) Jacques Garrigue
2001-04-10 18:23       ` [Caml-list] " John Max Skaller
2001-04-09  8:45     ` [Caml-list] Future of labels Markus Mottl
2001-04-10 18:42       ` John Max Skaller
2001-04-10 22:01         ` Markus Mottl
2001-03-29 12:53 ` Judicael Courant
2001-03-30  3:42   ` Jacques Garrigue [this message]
2001-03-30  7:55     ` [Caml-list] Implicit parameters (was Future of labels) Markus Mottl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010330124237D.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=Judicael.Courant@lri.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).