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