caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: mottl@miss.wu-wien.ac.at
Cc: caml-list@inria.fr
Subject: Re: Initializing default arguments
Date: Fri, 14 Jan 2000 12:00:12 +0900	[thread overview]
Message-ID: <20000114120012E.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Thu, 13 Jan 2000 16:05:27 +0100 (MET)" <200001131505.QAA12513@miss.wu-wien.ac.at>

From: Markus Mottl <mottl@miss.wu-wien.ac.at>

> using labels and default arguments. There I found a problem with functions
> like:
> 
>   let rec tautology ?(:vs = variables t) t = ...
> 
> It is not possible to reference arguments (here: 't') from default
> arguments if they appear later in the function definition.  It is clear
> that this would be problematic if the other argument also had a default
> value and if it referenced the first value again (recursion).
> 
> However, I believe it should be always ok to use non-default arguments
> regardless of order, because they are always already initialized.

We indeed thought about it. It is technically possible, since the
compiler automatically moves the computation of [variables t] inside
the body of the function. The only difficulty is that it changes the
definition of scopes. Currently you can use several times the same
variable in a function definition:

        # let ck x x = x;;
        val ck : 'a -> 'b -> 'b = <fun>

With the new semantics you suggest, this would be ambiguous.
On the other hand, prohibiting the above function definition might
seem reasonable.

Another problem is cascading definitions:

  let sub ?(:pos = 0) ?(:len = String.length s - pos) s =
    String.sub s pos len

Here we want to access the value of pos inside the default definition
of len. Again we can consider all these definitions as working in the
same scope, and do a topological sort to get the right order.

Last, what to do with definitions like:

  let f ?(:x = y) = fun y -> ...
  let f ?(:x = y) : int -> int = fun y -> ..

Should we refuse both, accept both, accept only the first one ?
Currently the parser does not distinguish between the first one and
let f  ?(:x = y) y = ...

Conclusion: this is possible, and if nobody opposes I think it should
be in a future release. Since it's a bit tricky to implement I do not
say 3.00.

By the way, there is a workaround. Write by hand what the compiler
generates:

  let rec tautology ?:vs t =
    let vs = match vs with None -> variables t | Some x -> x in
    ...

A bit heavier, but works ok in 2.99.

Regards,

        Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>




      reply	other threads:[~2000-01-14  7:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-13 15:05 Markus Mottl
2000-01-14  3:00 ` Jacques Garrigue [this message]

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=20000114120012E.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=mottl@miss.wu-wien.ac.at \
    /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).