From mboxrd@z Thu Jan  1 00:00:00 1970
Received: by margaux.inria.fr, Tue, 16 Mar 93 15:30:14 +0100
Received: from peray.inria.fr by margaux.inria.fr, Tue, 16 Mar 93 12:09:52 +0100
Received: by peray.inria.fr; Tue, 16 Mar 93 12:09:34 +0100
From: Daniel de Rauglaudre <ddr@peray>
Message-Id: <9303161109.AA03199@peray.inria.fr>
Subject: Stream patterne matching
To: caml-list@margaux
Date: Tue, 16 Mar 1993 12:09:34 +0900 (MET)
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text/plain
Sender: weis@margaux

> From: cr@dcs.ed.ac.uk
> Date: Mon, 15 Mar 93 14:11:28 GMT
> Message-Id: <25753.9303151411@damsay.dcs.ed.ac.uk>
> To: caml-list@margaux.inria.fr
> Subject: Stream patterne matching
>
> 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.

Personnellement, j'aimais bien aussi la version purement
fonctionnelle. L'imple'mentation ne pose pas de proble`me. Cela permet
en plus de pouvoir imple'menter e'ventuellement un backtrack limite',
ce que la version impe'rative ne permet pas de faire.

La`, il y a eu un choix a` faire. Je crois que l'argument de mes
petits camarades est que le stream doit pluto^t e^tre vu comme
"quelque chose venant de l'exte'rieur". En effet, "stream_from" et
"stream_of_channel" rec,oivent leurs donne'es d'ailleurs, donne'es
qu'on ne peut pas leur demander de "recracher" a` la demande, ce
qu'exigerait une version purement fonctionnelle; ou alors, il faut
garder les donne'es rec,ues dans un coin, ce qu'est cense' faire
"stream_get" (il ne le fait pas, d'ailleurs, dans la version de
distribution, mais ce sera corrige' dans la future version de
Caml-Light, qui parai^tra a` la Saint-Glinglin).

Il y a certes un proble`me d'efficacite', quoique 1) on n'ait pas fait
de mesures 2) a` mon avis, avec les machines rapides qu'on a
actuellement, et l'imple'mentation ge'niale du runtime, ce n'est pas
si grave.

Je crois que le de'bat est ouvert et je trouve bien qu'il le reste. Je
trouve que la programmation fonctionnelle, c'est joli, plus su^r, et
c,a confe`re de "bonnes proprie'te's" aux programmes. La question est
de savoir comment les langages fonctionnels communiquent avec
l'exte'rieur. Et il n'y a pas (encore) de re'ponse de'finitive et
satisfaisante a` cette question.


> let test c s = let (b,_) = stream_get (s) in
> 	if b = c then (stream_next(s);c)
> 	else raise Parse_failure
> ;;

Mmm... Comme je disais ci dessus, si le stream passe' en parame`tre
vient de "stream_from" ou de "stream_of_channel", c,a ne marche pas;
il y a un bug dans Caml-Light 0.5, bug corrige' chez nous, mais pas
dans la distribution.


> si vous voulez parsez un element 
> donne en argument a une fonction, vous ne pouvez pas ecrire :
> 
> let test c = function
> 	[< 'b >] -> if b = c then c else raise Parse_failure
> ;;

Non, mais tu peux e'crire:

            stream_check (prefix = c)

"stream_check" est fait pour c,a. Son avantage est que si la condition
est fausse, la valeur n'est pas consomme'e dans le stream. La fonction
"stream_check" ne peut pas se simuler. C'est une fonction de base.


	Daniel