Introduction, I suppose.

No traffic yet, so I suppose I'll open with a couple statements and a
couple questions.

First of all, do we talk, or submit PDDs? Are we aiming for a single PDD
from this group, or a short number of them, or a short number to be
collated into one? I'm not quite clear how this works, and what we end up
with. The official definition from ask seemed to indicate that we're
wanting to end up with one, but the later definition seemed to indicate
the opposite... that we might end up with more than one PDD per working
group.

Ok, statements are, I've been working on something that may be of some
assistance at least in testing the perl parsing. Based on Larry's notion
of perl parsing perl, I've begun to work on a perl (not a fork, not a
module, somewhere inbetween) that makes perl OOP easier to write and read.
(I'm considering creating an actual application in Perl, and don't want
the hassle of the perl OOP verbosity, so I shorthanded it to make it
easier to write, read, maintain, and comprehend.) The basic idea is to
take Perl 5 and stick in a parsing script embedded as a char*, let the
perl executable parse that since it's compiled in, import the script to be
run, run it through the parser, and eval it. (Two interpreters are at
work, the one that runs the parser, and the one that runs the parsed
script.) This is all in C naturally, compiled into the perl executable. I
think this would be helpful in testing whatever theories we come up with,
given that we don't have a perl6 to do any real tests with. Basically, in
other words, it's a perl executable with a compiled-in script that
preprocesses then evals the script to be run. The preprocessing script
could serve as a testing ground for whatever we choose to come up with. It
"translates" the syntax I've come up with into much longer but actual perl
code.

No, I'm not going to put the OOP grammar up here for a syntax proposal,
that's not what I'm offering. Just the concept of a parser testing method.

Frankly, this method could virtually be used to build up a working perl6
parser even before perl6 is ready to parse anything. Once we have a
language definition, the parsing algo's should be flexible enough to match
the differences between perl5's implementation and perl 6's. What concerns
me here is the need to keep things flexible enough to handle _multiple_
ways of parsing. Like larry said, if people want to write perl in python,
they should... we can test that without needing perl6, as scary as it
sounds. This might be a good point... if we can be flexible enough to
handle the transition from perl5 to perl6, we might be able to come up
with a parser that understands visual forth...

It seems that our parsing job is less one of strict grammatical
recognition and more one of providing the general capability of providing
strict grammatical recognition to come up with a common language (perl 6),
that (off topic) could eventually be written out as other code for Java,
C#, etc. IOW less of a translator and more of a how-to-translate kind of
thing. Less of mapping syntax to opcode, but of mapping syntactic
alternatives to grammar that would be mapped to opcode (or later, maybe
skip the middle step), if that makes any sense. So we would have somewhat
of a three-way translation to opcode...

1. \bclass\b\s+ => \bpackage\b\s+ => opcode
2. \bdef\b\s+ => \bsub\b\s+ => opcode
3. \bfunc\b\s+ => \bsub\b\s+ => opcode
4. \bsub\b\s+ => \bsub\b\s+ => opcode
5. \bvar\b\s+ => \bmy\b\s+ => opcode

Where 2, 3, and 4 express the same thing, depending on how the
parser-writer wanted to write it... perl style, python style, or tcl
style. The gist being that several alternative modes of self expression
translate to the same perl concept which translates directly to perl
internals. Since those internals aren't invented yet, it might be
beneficial to concentrate on the modes of self expression translating to
some form of commonality that exists at a higher level than opcode, even
if it eventually translates to opcode in perl6. If we can translate it to
perl 5 for testing, we can translate it to perl6 opcode later for
implementation. The key here being the flexibility of the parsing
mechanism.

It also makes sense to test the thing initially using pure perl, whereas
the eventual perl parsing mechanisms would probably not be embedded perl
but perl api itself translating the modes into perl opcode proper. I don't
think it would be a good testbed to use existing perl api rather than
embedded perl code within the executable, if for no other reason than that
it would take longer to write and our fingers would get sore.

(My vocabulary is lacking, I do confess.)

If this should be a PDD, I'll be happy to propose it that way, but I will
need some slight help in the specific implementation of the C code that
does it. I've just about got it going, and if I hadn't seen some funky new
grammar in the Camel III that bummed me out for a couple of days would
probably have been complete.

As for parsing, are we more concerned with speed and efficiency or with
implementation? In other words, which reigns, regexen or indexen? The
latter would be much faster, but far more difficult to implement in a
parser. Larry said he wanted to leverage perl regexen, so I assume that
the indexen would be minimized (otherwise, C/lexx/yacc would be more
appropriate, right?).

If I'm off target with any of this, let me know how better to go about it.
I'm not quite sure how this process is to work yet.

Also, Dan, as per your instructs, if I do go for a PDD with this, I'd like
some minimal help with the implementation if possible. Parsing I have 7
years under my belt in perl. API and opcode I'm new at, and the executable
that does this wants some API that I'd like a second set of eyes on before
I propose anything in a PDD.