From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
To: whitley@cse.buffalo.edu
Cc: caml-list@inria.fr
Subject: Re: OLabl optional arguments and higher order functions
Date: Wed, 24 Mar 1999 10:38:24 +0900 [thread overview]
Message-ID: <19990324103824S.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Thu, 18 Mar 1999 01:35:40 -0500 (EST)" <14064.39685.480989.489383@hadar.cse.Buffalo.EDU>
*** This is an olabl specific message ***
From: John Whitley <whitley@cse.buffalo.edu>
> Consider the following example, from OLabl 2.02:
>
> # let ack ?:x [< 0 >] :y = x * y;;
> val ack : ?x:int -> y:int -> int = <fun>
> # let hack funarg = funarg x:4 y:5;;
> val hack : (x:int -> y:int -> 'a) -> 'a = <fun>
> # hack ack;;
> Characters 5-8:
> This expression has type ?x:int -> y:int -> int but is here used with
> type
> x:int -> y:int -> 'a
>
> This seems like a bug. Intuitively, labels x: and ?x: should unify.
> If not, I would appreciate a brief explanation as to why not...
Here is the explanation:
Optional arguments are essentially a first-order feature.
If a function is known to have optional arguments, and is applied to
less arguments than needed, then the system automatically fills in the
gaps and corrects the type.
However, if we do not know the type of the function, we cannot do this
processing. This is why in hack funarg's x argument is inferred not to
be optional.
Internally, x: and ?x: are represented differently (?x: uses an option
type), so we cannot unify them safely, which explains the type error.
Once you have read that, you realize that this is meaningless to pass
a function with unnapplied optional arguments to a functional: you
would not be able to use it anyway. Olabl avoids the problem by
automatically discarding all optional arguments when a function is
passed as parameter to a functional (the error message is a bit
misleading about that).
The following definition works fine:
# let hack f = f y:5;;
val hack : (y:int -> 'a) -> 'a = <fun>
# hack ack;;
- : int = 0
> Forcibly replacing the optional argument with the same label via
> fun works just fine:
> # hack (fun :x -> ack :x);;
> - : int = 20
This is the only reasonable solution I see.
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>
prev parent reply other threads:[~1999-03-24 14:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-18 6:35 John Whitley
1999-03-24 1:38 ` 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=19990324103824S.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=whitley@cse.buffalo.edu \
/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