On Thu, 10 Aug 2000, David L. Nicol wrote:
> "Bryan C. Warnock" wrote:
>
> > This was the ass that I never found the gall to scratch, because I've
> > identified no solutions, and have found only problems.
> >
> > --
> > Bryan C. Warnock
> > ([EMAIL PROTECTED])
While I appreciate the creative combination of several key points in
my post, I'd appreciate it more if you wouldn't state that I actually
wrote that. Or perhaps you were making your own point. :-)
The rest of your paraphrasing is pretty much on, I guess. Perl already
is two (similar, but distinct) languages, of which only one is required
to work in Perl. They are Perl, the defined language, and the internal
API to Perl. (Okay, so that's still fuzzy, but you should get the
idea.)
Ideally, it wouldn't involve Yet Another Language, but could be done in
one of the two Perl already has. (Or both, I suppose.) What I don't
believe should be the goal, although it may be an unfortunate
side-effect, is to, in essence, write the parser in Perl, and to
require writing a full parser for every case That would, in essence,
require dropping the user parser inline between the lexer and the real
parser, capturing all the tokens coming out, doing the necessary
identification and modifications, and passing the new token stream to
the real parser. I think this was one of Nat's hook areas, and is
similar to what Chaim suggested with how macros could work.
This could work with very simple requirements, and could even partially
extend to adding lexer extensions. Otherwise, why not just rewrite the
parser in its entirety, and drop it in as a new front end?
Alternately, to keep things simple, you could have a signature callback
type mechanism, where the parser only calls your code upon certain rule
reductions. This requires the lexer to have already sent the data to
the parser, which could make for some icky situations, particularly
with inspection and modification of what the parser has already done.
Or, to keep things really simple, have parser pragma types that affect
the parser internals runtime much like the rest of Perl modules affect
Perl runtime. (This would, of course, require the parser to be able to
support much deeper introspection than it does now. Yet Another
Language, more complexity. But would allow for only a limited number
of hooks, which would be a little easier to contain and a little less
scary to deal with.) This last was basically what I was looking for
with RFC 40. This would allow people to write their own pragmas, as
long as they only needed what hooks were available. More radical
changes would involve adding more hooks.
I'll ponder all this today, and maybe give some examples this evening,
perhaps showing how some of the current RFCs could be addressed.
--
Bryan C. Warnock
([EMAIL PROTECTED])
