From mboxrd@z Thu Jan  1 00:00:00 1970
Received: by margaux.inria.fr, Mon, 15 Mar 93 18:32:56 +0100
Received: from concorde.inria.fr by margaux.inria.fr, Mon, 15 Mar 93 15:13:05 +0100
Received: from dcs.ed.ac.uk (stroma.dcs.ed.ac.uk) by concorde.inria.fr; Mon, 15 Mar 1993 15:12:59 +0100
Received: from damsay.dcs.ed.ac.uk by dcs.ed.ac.uk id aa28356;
          15 Mar 93 14:11 GMT
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
Subject: Stream patterne matching
Sender: weis@margaux


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.

De plus le pattern matching destructif augmente la complexite de toutes
grammaires "parametrables". En effet, 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
;;

Mais vous devez ecrire :

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

Ainsi, je trouve qu'un pattern matching non destructif permettrait d'ecrire
des programmes plus naturels, dont les bugs seraient moin inextricables.  Par
exemple essayez de programmez un analyseur lexical qui soit efficace et qui
reconnait un ensemble de tokens stockes dans une table (sous un format
adequate). Cette table pouvant etre modifiee.


A par ca je trouve que le pattern matching est une tres bonne methode pour
ecrire des grammaires. On peut ecrire des grammaires dont les regles modifient
la grammaire elle-meme .....


Christophe Raffalli.
LFCS Edinburgh
Logic team of Paris VII