Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] First alpha release of LablGTK2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] about optionnal argument ?
From: Christophe Raffalli <>

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


Jacques Garrigue
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: