Hi John,
> I think this could be made sane by a reform of how the optional
> arguments work. There are a couple of interesting possibilities:
>
> # let f ?style:x _ = x;;
> - val f : ?style:('a option) -> 'b -> 'a option
>
> # let f (style:x : 'a option) _ = x
> - val f : style:('a option) -> 'b -> 'a option
Bingo, you've just found how it's implemented!
Omitting the option constructor for optional arguments is just
a small comfort. This can be pretty important when you have 10 or 20
optional arguments in the same function.
By the way, having a default case for a non-optional argument was
legal in O'Labl. I just didn't include it in O'Caml because I thought
I would be more confusing than useful.
> The first is dirty because there are two kinds of special arguments
> (optional and non-optional). The second because it gets into the type
> system. I think the second must lose, since "knowing" that something
> is an option type is complex.
In fact the distinction between optional and non-optional arguments is
useful, because it allows a nice interaction between classic and
modern mode. Optional ones behave the same in both modes, only
non-optional ones behave differently.
[..]
> Of course, this is all radically different from O'Labl, so it will
> never happen.
I do not intend to be so exclusive...
In fact there are even a number of differences between ocaml 2.99 and
olabl, and some from you.
The only point is that O'Labl has been around for a while, and we have
had the time to test in practice that this model works, and is not
difficult to grasp. Another model would take lots of time testing
again.
Best regards,
Jacques
This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 16:27:33 MET