Re: Caml Special Light 1.07

[Xavier Leroy <xleroy@pauillac.inria.fr>]

> J'ai remarque plus d'incompatibilite avel Caml-light que le document html ne
> le dit (il serait bon de les y ajouter) :

Oui, la liste donnee dans "Questions & Answers" n'est pas complete.

>   - where rec a disparu ?

Exact. "where" aussi, d'ailleurs. Redondant avec "let" et "let rec".

>   - fun ne marche qu'avec une seul cas de matching ?

Oui. C'est une simplification pour reduire la redondance entre "fun"
et "function" -- a defaut de la faire disparaitre -- que Pierre Weis
et moi-meme voulions faire depuis longtemps. La version francaise du
``Manuel de reference'' de Caml Light ne documente d'ailleurs pas le
"fun" a plusieurs cas.

Il suffit d'ecrire a la place:

        let f x y z =
          match (x,y,z) with
            (..., ..., ...) ->
          | (..., ..., ...) ->

C'est aussi efficace que le "fun" a plusieurs cas en Caml Light: le
compilateur Caml Special Light n'alloue pas le n-uplet (x,y,z).

>   - == dans les definition de type remplace par = (le script convert ne fait
>        pas cette transformation automatiquement)

Oui, c'est une erreur dans le script.

>   - le pattern matching sur les streams. C'est dans le document html, mais le
>     point d'interrogation m'inquiete car j'ai un gros parser qui ne peut
>     s'ecrire avec yacc et que je n'ai pas tres envie de reecrire ....

Le stream matching est un peu penible a implementer dans le
compilateur, c'est pourquoi je ne l'ai pas encore fait. Aussi, le
rapport "quantite de code dans le compilateur pour traiter le stream
matching" sur "vitesse des parsers produits" est legerement
decevant. Je reve parfois d'un systeme de parsing ou bien moins lourd
a implementer (pas de "support" dans le compilateur, juste une
bibliotheque de fonctions de parsing) ou bien nettement plus efficace.

>   - le matching sur les constructeurs a plus d'un arguments a change ?
>    #type b = B of int * int;;
>    type b = B of int * int
>    #let f (B c) = c;;
>    The constructor B expects 2 argument(s), but is here 
>    applied to 1 argument(s)

Oui, les constructeurs de Caml Special Light ont une arite (un nombre
d'arguments) fixe. On distingue entre

        type b = B of int * int         (2 arguments entiers)
        type b = B of (int * int)       (1 argument qui est une paire)

Cette restriction est necessaire pour representer de maniere efficace
les types concrets (B(x,y) est un seul bloc contenant x et y, non pas
un bloc contenant un pointeur vers la paire (x,y)). Caml Light
utilisait cette representation efficace tout en maintenant l'illusion
que l'argument du constructeur est un n-uplet, mais en presence du
calcul de module il est extremement difficile de continuer a maintenir
cette illusion. Exemple:

        module type SIG =
          sig
            type t
            type u = B of t
            ...
          end
        module S =
          struct
            type t = int * int
            type u = B of int * int
            ...
          end
        module S' = (S : SIG)

Les utilisateurs de S et les fonctions de S font l'hypothese que
B(x,y) est represente a plat (deux champs avec x et y), mais les
utilisateurs de S', voyant S'.t abstrait, supposent B(x,y) represente
avec une indirection supplementaire, d'ou code incorrect.

Mettre une arite aux constructeurs assure que S ne remplit pas la
specification SIG et elimine le probleme.

>    Mais alors pourquoi ne pas ecrire les
>    constructeurs a plus d'un argument sous forme "uncurried"

Ca devient une question de syntaxe uniquement.

>    (et aussi pouquoi
>    ne pas autoriser l'application partielle d'un constructeur) ?

Je ne sais pas si ca servirait tres souvent.

- Xavier Leroy