Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: Syntax for label
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christophe Raffalli <Christophe.Raffalli@u...>
Subject: Semantic of label: The best (only ?) solution to merge both mode

I posted a first solution to merge modern and classic mode. It was a bit
wrong. But there is indeed a reasonnable solution:

The trick is not to consider the absence of label as a specific label
like the actual modern mode does.

Then we can have:
- possibility to write or not label when applying a function
- possibility to permutte arguments if labels are written
- optional arguments

---

BUT we need a restriction over admissible types. One can choose between
two restrictions:

- Strong restriction: all the arguments have a label in types. Only
arrows of the form l:t -> t' are allowed.

- Weak restriction: all the arguments without labels in types comes
after arguments with labels. If a function returns a polymorphic results
(type 'a) all arguments have labels. (So function like List.assoc or
List.fold_left still must have a label for all the arguments).

These restrictions are stable by substitution so they are meaningful and
implementable.

These restrictions are reasonable because they only force you to add
labels when defining functions. Not when applying them ! It does not
cost much to add labels when defining functions especially if you do not
have to write labels when you apply arguments to the function. 

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

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

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.

- If you do not write labels you can not capture at compile time bugs
caused by incorrect permuttation of arguments. But the user is free to
write the label !

What do you think about this ?

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI