Re: [Caml-list] about optionnal argument ?

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>

> I wonder why optionnal argument are implemented through the option
> type instead  of giving a default value ?
> 
> Obviously the type should carry the default value which should be a closed 
> constant (like None, 0, 0.0, [1;2;3], etc ...) but this would preserve the 
> possibility of using optionnal arguments and unboxed int or float arguments
> and it will save the None/Some test !

There are several reasons to use optionals rather than defaults.
One is semantical: the meaning of defaults is quite clear with
second-class functions, much less with first-class ones.  If we want
to keep an untyped semantics, your idea of putting the default in the
type is not satisfactory. It would also have other implications: if I
have a list of functions taking optional arguments, does it mean that
they should all have the same defaults?
The optional approach appears to be a nicer fit for first-class
functions: it is not by chance that common lisp has the same
approach.  It is also more expressive: the default value may depend on
the other arguments.

>From the implementation point of view, default arguments with
first-class functions would be also cumbersome: either we depend
strongly on types, and allow to write arbitrary values in types (not
only simple ones, functions too!), or we must think of a way to put
the defaults arguments in the closure when needed. Hairy.

All-in-all, deriving default arguments from optionals is much simpler,
and the extra cost generally doesn't matter.
But you have a good point that if a function is very simple
(arithmetic or data copying) and called very often, then using
optionals with it is maybe not such a good idea. The overloading of
glVertex is a bit of an overkill anyway.
I don't know how glVertex is implemented on the C side, but if it is
only copying its data to a queue, then we may want to optimize the
marshalling.  But again it depends how your data was layed out
originally: if it is in a table, the vector form is best as no copy is
needed. If you have to compute it for each call, then the flat unboxed
calls are best.

Regards,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners