Christophe Raffalli wrote:
> Then you can implement the following rule for applying a function to an
> argument:
> 
> f (a:l) means a is the argument corresponding to the first occurence of
> the

	You mean f (l:a)

>         label l in the type of f (optional or not) (permuttation are
>         possible)
> 
> f a     means a is the argument corresponding to the first non
> optionnal
>         argument of f

	Which 'default' arguments are passed when?
 
> This is quite simple to explain and use and
> modifying the actual code to get this is trivial (I can post it if you
> want, but it does bootstrap because I did not modify the library which
> does not respect any of the restrictions).

	This means that

	f (l:a)

is a version of f with one parameter bound to a, like (f a), except
currying can now be done on any argument?

	Hmm. So we could write:

	f la:a x lb:b y z lc:c ...

which now means:

	(((((f la:a) x) lb:b) y) z) lc:c)

When the last argument is 'used up', all remaining optional arguments
are bound and the 'final' function applied?

> I see only two problems:
> 
> - One must make existing library compatible with one of the restriction:
> I think the restriction is not too strong because we have not to always
> write labels when applying functions.

	I agree. Mandatory writing of labels on definition
is not as onerous as mandatory writing on use.
 
> What do you think about this ?

	This gives the olabl people their old labels back,
while merely requiring classic uses to decorate definitions
with labels. In this case a temporary compiler mode switch
to allow classic users to upgrade piecemeal would be ideal.

	To me, this proposal appeals. (Will it work? Do I understand it?)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net