J'ecris, puis Michel repond :

> > Pour quelles raisons le pattern matching sur les streams est-t'il
> > destructif ?  
> >
> > Est-ce simplement une question de performance. Si oui il faut que le gain
> > soit important. En effet, le pattern matching destructif implique un effet
> > de bord implicite. Je trouverais plus propre d'avoir a utiliser soi-meme un
> > pointeur lorsque-l'on veux simuler le pattern matching destructif.
>
> Non, ce n'est pas simplement une question de performance: un autre
> avantage est d'e^tre bien adapte' aux entre'es-sorties destructives de
> ML. Un stream se manipule un peu comme un canal d'entre'e (type
> in_channel): lorsqu'on lit un caracte`re sur un canal (resp. stream),
> une seconde lecture lit le caracte`re suivant.
>
> Avec une semantique destructive du filtrage de streams, un stream
> construit a` partir de std_in aura le me^me comportement qu'un autre
> stream (construit par programme). Avec une se'mantique
> non-destructive du filtrage, cela n'est possible que si ce stream
> garde en me'moire le stream d'entre'e en entier (a` moins de garantir
> qu'il n'existe pas de pointeur vers ce stream).

N'est-ce pas au GC de recuperer l'espace occupe par le debut d'un stream, s'il
n'y a plus de pointeur dessus ?

A t'on deja chiffrer la perte en performance, si l'on n'utilise que des
streams conservateurs ?

--------------------

Un autre petit probleme avec le pattern matching : le fait qu'il soit
predictif (c.a.d. qu'il decide uniquement sur le premier element du stream).

Cela n'est pas grave : si l'on veut matcher [< '0 ; '1>] ou [< '0 ; '2 >], 
on ecrit [< '0 ; f c >] ou f match [< '1 >] ou [< '2 >]. 

Est-ce que le compilateur ne pourrait pas faire cela automatiquement ?

C'est a dire faire cette decomposition des qu'un certain nombre de patterns
consecutifs commencent par une suite de patterns egaux (au noms des variables
pres) ?

Cela simplifierait l'ecriture de la plupart des grammaires courantes. Tout en
sachant bien que la semantique est la meme. 


Christophe