It can be done any which way but loose, and I'm trying to keep my thinking
flexible for any applied use in this sense. What I'm _doing_ for my own
work at this point is simply making a creole filter (or source filter),
and spitting out perl5 which is then sucked into eval_pv(). For this, I'd
probably look for it to be writable either in perl or in api, and create
what amounts to a hash where input (keys) := output (hash) where output is
[(index|regex), output_code]. Naturally it's more complicated than that,
but I don't yet see it being _much_ more complicated. The (index|regex)
indicates how the source token is found, and the output_code is somewhat
of a predefined list of musts (the perl6 language definition, or perhaps
how the creole differs from it), along with a per-creole list of niceties
above and beyond perl6.
For example, in my own parser now, I have "class foo {" creating "package
Foo", collecting information about class-global variables and constants,
autogenerating a constructor, and in "scope" until the terminating /^\}/.
I'm currently using "public" and "private" variable members (for lack of
better keywords) that get turned into tied variables that can be read-only
when private (my definition of private in this sense). The gist is, what
my input is isn't relevant, what's relevant is that I'm spitting out pure
perl. If I were to make this generic enough for general purpose, it would
basically be a translation hash from input spec to perl spec.
If I go down this path, then, my creole parser doesn't need much for hooks
beyond what will be available in perl itself. I'm just making it more
legible to the programmer, which is the purpose of the creoles in the
first place. I'm a bit leery of making it more complicated for fear of
creating an unnecessary monster.
Let me explain that better...
For "Perl Spec", I'm referring to the generic:
if conditional := if(CONDITION) {BLOCK} [elsif {BLOCK}] [else {BLOCK}]
in pythonish I would make the above the value of a hash (speaking very
generically, and in high level terms, not in detailed specification) where
the key is
if conditional := if CONDITION NL IND BLOCK UND [elsif IND BLOCK UND]
[else IND BLOCK UND]
The "value" of the "hash" never changes. The value is the pure perl
version of whatever funky is defined. To my mind, I'm calling this the
"Pure Perl API" (meaning the set of commands available to my perl code,
though it could also be defined as sets of API in the sense that API is
actually defined) where I should be calling it the "Pure Perl 6 Spec".
Anything beyond translating the structure to pure perl could be defined,
but would be creole specific, such as expanding "private constant $foo :=
1" into several lines and making "public member $bar := undef;" into a
tied scalar with a default given within an autocreated constructor
(example only, from my current work).
The only thing I don't like about using this method is that when the user
runs the debugger, he/she will be debugging pure perl, and not the creole,
so he/she won't be seeing the original code, in this instance. I can only
provide that by "going off the deep end" into creating the "monolithic"
creole parsers that not only know how to translate to perl, but can
translate from debuggese back into the creole. But then, given some
thought, this might just be a reversed form of the translation
hash-type-of-thinking structure...
eval_pv() gots ta be smarter than just eval_pv, then, if we want to
reverse it. I believe this might be the "hooks" Dan wants. However, I'm
not looking to make the creole parser spit out syntax trees. For each
creole created, it would be necessary to have a _complete_ language spec
(where currently it's additive or at least replaces only what it
specifically defines) rather than a subset of perl output which is what
has the complete spec.
It's 3am, don't expect me to make too much sense. I'm also a bit
linguistically challenged as far as creating a parser/interpreter goes...
I'm basically getting in on the ground floor of a new language with people
who have done this all before, trying to comprehend major perl5 perlguts
and predefined terms (more or less specific to this purpose) in a perl6
sense. I'm not going to understand all of the words unless they're spelled
out, as Dan has done for a lot of them already (merci bien a lui).
David Grove
[EMAIL PROTECTED]
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote:
> > My only worry is, how do we reconcile this with the idea of
> > >Perl having an easily modifiable grammar and being a good
environment
> for
> > >little-language stuff?
> >
> > That's a good question, and it depends on what Larry's thinking of
for
> > little languages. Smacking the perl parser around enough to handle,
say,
> > something C or Pythonish shouldn't be a huge hassle. Making it handle
> > something Lisp-like, though, is another matter entirely.
>
> I think my worry was more general than that: if we've got a big
monolithic
> parsebeast which is making lots of Perlish decisions, at what levels do
we
> allow the user to modify that? Do they get to replace the whole thing
and
> implement their own tokeniser, lexer and parser, or can we find a way
to
> apply
> "hooks" to replaceable components?
>
> --
> "Dogs believe they are human. Cats believe they are God."
>
