*** 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>