Re: To get things started...

Thanks for the clarifications, Simon.

Simon Cozens <[email protected]> wrote:

 > On Tue, Nov 21, 2000 at 07:36:11AM -0500, David Grove wrote:
 > >  > 1) The API presented to the rest of the world. This is likely one
 > call,
 > > 
 > > These are almost two separate things entirely. (I don't get the "one
 > call"
 > > thing. What do you mean?)
 > 
 > A parser does, essentially, one single thing: it takes text and turns
it
 > into
 > an op tree. That's the only call you need to make from an external
 > perspective.

I'm not sure that it's possible to do this, or disirable. If Larry wants
Perl to use different modes, creoles, or ways of interpreting or
understanding the "perl" language, then we have to let the parser have a
bit more information. This includes the ability to tell it what creole
it's currently interpreting (it will probably need a stack for that, since
I can foresee people trying "use tclish" within a "use pythonic", unless
one overrides the other and turns off the previous mode: in which case it
just needs to know its current mode. It also needs to know where to get
its information. If we want a small kernel, then we can't give it
information about how to parse the different modes within the micro-kernel
itself. It would have to be bound to the kernel, or loaded as a file.

If we were simply feeding it perl with a single syntax, we could get away
with a "one call" scheme. But since we're dealing with almost certainly
mutually exclusive syntax and semantics, it probably needs more
information.

As a point of clarification, I am seeing the external parser as that part
of perl that sees the user's script directly.

 > > the external API needs to be flexible to handle perl in different
writing
 > > styles
 > 
 > This doesn't need to be the case; the external API may be
 > language-agnostic,
 > with the language rules set by internal calls.

Then I'm misunderstanding the difference between external and internal. If
external touches the user's script, it can't separate itself from whatever
particular syntax is currently in use. The internal portion of the parser
that I suppose I've now proposed is what can be user-syntax independent.
I'm seeing the external api as being the part that receives the user's
script from different modes and turns it into an intermediary <whatever>,
and the external as what takes the intermediary <whatever> and turns it
into whatever form of output that we've chosen. From what I understand of
Larry's desires for the language, we need multiple possible ways to input,
and multiple possible ways to output, but internally we need that language
agnostic thing.

Maybe I'm going beyond the purpose of "API". Let me know if this is the
case.

 > >  > * The parser needs to be reentrant
 > > No clue what this means. I need this defined in context.
 > 
 > While parsing text, you should be able to dive into a separate bit of
text,
 > parse that, ("re-enter" the parser's routines) come out and carry on
 > *exactly*
 > where you left off, without your state being lost.

Thanks. That's basically what it sounded like. Can you give an example? I
mean, are we expressing the need for do {BLOCK} with this, or threads, or
multiplicity, or something else?

 > > perl6  perl5  python  tclish
 > > \      \           /       /
 > >  \      \         /       /
 > >  ---------------------------
 > >  READSTDIN and other commons
 > >        full tree here
 > >  ---------------------------
 > >              |
 > >              | <- required
 > >              |
 > >  ---------------------------
 > >           OPCODES
 > >  ---------------------------
 > >  /     /            \      \
 > > /     /              \      \
 > > run  store           exe    a
 > > bc   bc           binary    java thingy
 > 
 > I think you've just invented the compiler! :)

I don't think so. In a compiler I don't believe that the intermediate step
is there, and I've never seen any compiler accept multiple input semantics
and multiple output (meaning binary, bytecode, java, c#) (okay, C++
Builder can accept pascal... but that's an one). However, I've foreseen
the output of compiled code as a part of this. The desire there was to
make it easier to make a compiler, or at least possible to output
executable code as an output mode. Thie exe-binary is actually, of course,
several different pidgins within the creole, since we're outputting to
Linux, Solaris, Win32, etc. ad nauseam...

Keep in mind that I don't have a clear definition for the intermediate
step except that it is desired to separate the external from the internal
as I understand them. (For now, I'm conceptualizing it as a one-to-one
that can change without hurting the internal or external, solely for the
purpose of the desired flexibility and separation.) But then, I've yet to
see whether I'm understanding them. I also realize I'm off the topic of
the bytecode itself, but I'm not sure how much bytecode I can apply to an
undefined language. Can somebody let me know if any of what I've said is
relevant? Thanks.

Do we want to borrow some of the internals from Perl5, or start over? From
my understanding of the goals of Perl6, we're starting over...

p