From mboxrd@z Thu Jan  1 00:00:00 1970
Received: by margaux.inria.fr, Tue, 16 Mar 93 09:43:55 +0100
Received: from concorde.inria.fr by margaux.inria.fr, Mon, 15 Mar 93 21:46:50 +0100
Received: from dcs.ed.ac.uk (stroma.dcs.ed.ac.uk) by concorde.inria.fr; Mon, 15 Mar 1993 21:46:47 +0100
Received: from damsay.dcs.ed.ac.uk by dcs.ed.ac.uk id aa06435;
          15 Mar 93 20:45 GMT
From: cr@dcs.ed.ac.uk
Date: Mon, 15 Mar 93 20:45:23 GMT
Message-Id: <26877.9303152045@damsay.dcs.ed.ac.uk>
To: Michel.Mauny@inria.fr
Cc: caml-list@margaux
In-Reply-To: Michel Mauny's message of Mon, 15 Mar 1993 20:12:13 +0100 (MET) <9303151912.AA10634@pauillac.inria.fr>
Subject: Stream patterne matching
Sender: weis@margaux


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