On Sun, 17 Dec 2000, David Grove wrote:
> > "Little languages", on the other hand, are a somewhat different matter.
> > They will presumably be not-so-complex and hence won't require such
> deep
> > hooks, and some redundancy there won't be such a big problem.
>
> I'm not sure how this is incongruent with your first paragraph. Could you
> elaborate a bit?
You had expressed concern about redundancy if each parser had to
re-implement a whole slew of stuff:
p> a prefilter of some sort, or multiple parsers (or worse, multiple
p> "parser/lexer/tokenizer single-entity parts"... meaning redundant
p> duplication of extra effort over and over again repeatedly).
I was just trying to say that for many small tasks, I would guess that
most of the default actions would not need to be overridden, and hence
there would not, in practice, be all that much redundancy.
> > Another route to keep in mind is spending effort working on and with
> > things such as perl-byacc
> That sounds too complex for what seems like a more simple solution. When
> you say "turn simple 'languages' into perl", that's what Dan's told me is
> my source filter.
Correct. perl-byacc is a source filter. It takes in yacc source and
outputs perl code. It just may not be what folks first think of as a
"source filter" in the sense of using the Filter:: modules. For
some problems, it's certainly too complex. For others it might not
be.
Not all problems need be shoe-horned into the same solution box. That's
all I'm trying to say.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
