From mboxrd@z Thu Jan  1 00:00:00 1970
Received: by margaux.inria.fr, Wed, 17 Mar 93 19:06:06 +0100
Received: from localhost.inria.fr by margaux.inria.fr, Wed, 17 Mar 93 18:13:05 +0100
To: caml-list@margaux
Subject: Re: Stream patterne matching 
In-Reply-To: Your message of Wed, 17 Mar 93 14:47:49 +0100.
             <9303171347.AA17396@pauillac.inria.fr> 
Return-Receipt-To: murthy@margaux
Date: Wed, 17 Mar 93 18:13:03 N
Message-Id: <9370.732388383@margaux.inria.fr>
From: murthy@margaux
Sender: weis@margaux


CR==Christophe
MM==Michel Mauny

CR> Y a-t'il des exemples plus complexes ?

	MM> On doit tomber sur de ve'ritables casse-te^tes lorsqu'il
	MM> s'agit de traduire une grammaire BNF existante (Yacc ou
	MM> whatever) en analyseurs de Caml-Light, mais je n'ai
	MM> personnellement que peu d'expe'rience en la matie`re.

J'ai fait pas mal des parsers pour l'analyse syntaxique, au niveau de
lexing et aussi ua niveau de parsing.  C'est un peu dificil, mais pas
vraiement.  Il s'agit simplemet d'ecrire un "analyseur", comme Michel
disait, et pas un "grammaire".  C'est-a-dire, dites a l'ordinateur
exactement ce que tu veux qu'elle fasse.  C'est tout.

C'est vrai que la factorisation serait utile.  Mais, comme Michel
disait, seulement en certains cas.  Ces cas-la, sont les cas quand on
veut utiliser cette systeme des "analyseurs", etc, comme un systeme
des "grammaires".

Boeuf.  En Anglais.  Having factorization done automatically is only
useful when you are using parsers/printers as a grammar facility.  It
is NOT such a facility.  In lots of other cases, having factorization
around could be a very bad thing.  Because it would change the
behaviour of your program.

An analogy which is quite familiar could be an ML compiler which used
beta-reduction for code inlining, rather than beta-value reduction.
If you aren't careful, you can end up "improving" programs which do
not terminate, into programs which _do_ terminate.  Its easy to do.
And this is bad because when I start debugging a non-terminating
program, I cut out pieces of the code, and start running them in a
context which is different from that of the original program.

So if the compiler all of a sudden can do new optimizations, say,
because I feed in more specific arguments to a function, and this
causes the compiler to "make the function terminate", then I can't
even do debugging.

The same thing is going on here.  Factorization could make buggy
parsers become un-buggy, when I replace an abstract parser by
something more concrete.

And this would make debugging of analyzers impossible.  Completely
impossible.

And frankly, if that happened, I'd stop using them.

Besides, if you want a "grammar" facility, then just write one.  It
isn't that hard.

--chet--