Semantic of label: The best (only ?) solution to merge both mode

From: Christophe Raffalli (Christophe.Raffalli@univ-savoie.fr)
Date: Wed Mar 29 2000 - 10:42:45 MET DST

  • Next message: Christophe Raffalli: "Re: 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



    This archive was generated by hypermail 2b29 : Wed Mar 29 2000 - 19:24:41 MET DST