From: murthy@margaux
To: caml-list@margaux
Subject: Re: Stream patterne matching
Date: Wed, 17 Mar 93 18:13:03 N [thread overview]
Message-ID: <9370.732388383@margaux.inria.fr> (raw)
In-Reply-To: Your message of Wed, 17 Mar 93 14:47:49 +0100. <9303171347.AA17396@pauillac.inria.fr>
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--
next prev parent reply other threads:[~1993-03-17 18:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9303171031.AA15612@pauillac.inria.fr>
1993-03-17 11:31 ` cr
1993-03-17 13:47 ` Michel Mauny
1993-03-17 18:06 ` murthy [this message]
1993-03-17 20:26 ` Stream pattern matching Xavier Leroy
1993-03-16 3:09 Stream patterne matching Daniel de Rauglaudre
-- strict thread matches above, loose matches on Subject: below --
1993-03-15 14:11 cr
1993-03-15 19:12 ` Michel Mauny
1993-03-15 20:45 ` cr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9370.732388383@margaux.inria.fr \
--to=murthy@margaux \
--cc=caml-list@margaux \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox