Caml Special Light 1.07

Caml Special Light 1.07

[Xavier Leroy]

Release 1.07 of Caml Special Light is now available.
This is a bug-fix release that corrects the main problems
reported with 1.06:

* syntax: optional ;; allowed in compilation units and structures
  (back by popular demand)
* cslopt:
    generic handling of float arrays fixed
    direct function application when the function expr is not a path fixed
    compilation of "let rec" over values fixed
    multiple definitions of a value name in a module correctly handled
    no calls to ranlib in Solaris
* csltop: #trace now working
* standard library: added List.memq; documentation of Array fixed.

The complete sources and diffs from 1.06 are available by anonymous
FTP at the usual place ftp://ftp.inria.fr/lang/caml-light.

General info about Caml Special Light can be found on the Web, at
http://pauillac.inria.fr/csl/.

- Xavier Leroy

Re: Caml Special Light 1.07

[Christophe Raffalli]

Bonjour,

J'ai essaye CSL, et dans l'esemble je suis tres content d'avoir enfin un
compilateur petit et rapide.

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

  - where rec a disparu ?
  - fun ne marche qu'avec une seul cas de matching ?
  - == dans les definition de type remplace par = (le script convert ne fait
       pas cette transformation automatiquement)
  - 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 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)

   je pense comprendre pourquoi ce changement (le cout cache de la
   construction de la paire ?). Mais alors pourquoi ne pas ecrire les
   constructeurs a plus d'un argument sous forme "uncurried" (et aussi pouquoi
   ne pas autoriser l'application partielle d'un constructeur) ?

A par ca, 
Encore merci a toute l'equipe ...
Christophe Raffalli

Re: Caml Special Light 1.07

[Xavier Leroy]

> 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

Re: Caml Special Light 1.07

[Christophe Raffalli]

>>   - where rec a disparu ?

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

J'aimerai bien qu'il revienne : cela rend souvent le code plus agreable a
lire. mais peu-etre qu'il faudrait ajouter un "do" "end"

  do .... where [rec] .... end

car le scope de where etait un peu embetant a manipuler.

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

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

Si c'est aussi efficace, il serait utile que le tool convert fasse cette
transformation automatiquement (meme pour les fun a un seul cas).

>>    Mais alors pourquoi ne pas ecrire les
>>    constructeurs a plus d'un argument sous forme "uncurried"
>
>Ca devient une question de syntaxe uniquement.

Cela aiderait a eliminer la confusion entre 
        type b = B of int * int         (2 arguments entiers)
        type b = B of (int * int)       (1 argument qui est une paire)

De plus ca faciliterait le portage des programmes caml-light :

on pourrait ecrire        
       type b = B of int & int    pour B avec deux arguments 
                                 (le & est un choix arbitraire... )
et
       type b = B of int * int  pour B avec un seul argument

Ainsi les vieux programmes caml-light tournerait (avec une perte d'efficacite)
sans que l'on ait a modifier les matchings du genre "B c -> ..."

>>    (et aussi pouquoi
>>    ne pas autoriser l'application partielle d'un constructeur) ?
>
>Je ne sais pas si ca servirait tres souvent.

J'appelle souvent map ou it_list avec un constructeur partiellement ou
pas du tout applique, et c'est un peu penible d'avoir a ecrire (fun x -> B x)
a la place de B ! Bien sur cela est loin d'etre important !

Christophe.

PS: for the parser problem, I just realised that $1 in a semantic-action could
be a function and So i could rewrite my parser quite easely with camlyacc
which therefore is not only a context-free parser !