At 06:28 PM 12/2/00 -0500, Bradley M. Kuhn wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > It's more than just the parser. You've got the bytecode compiler and
> > possibly the optimizer as well, and they're probably going to be all, or
> > mostly, C. On the other hand they might not have any internal hooks for
> > perl code to wedge into, in which case they're just black boxes and not of
> > much concern.
>
>This is exactly why I have been pushing for the internals APIs to be very
>clearly defined. I expect to have to replace various parts of it with Java
>code, so that it will run natively on the JVM. Anything that must be
>present at run-time for Perl code will likely need to be reimplemented in
>Java to make a full-fledged JVM port.
Let's also not rule out the possibility of a port with only partial
functionality. While I don't want to ghettoize the JVM port (or any other),
it's not unreasonable for some targets to not have complete functionality.
(Though it may just be the palm and wince ports with no parser, compiler,
and optimizer modules)
It also brings up another subject--classes of perl ports. There are a
several pieces that could be considered optional, including:
* Supporting parsing. (String eval, and do/require of perl source)
* Supporting module loading (do/require of compiled perl modules)
* Supporting the parser/compiler/optimizer/interpreter internal wedges (to
modify the parser, for example)
* Supporting the embedding API
* Supporting the extension API (And presumably binary perl extensions)
* Supporting the opcode API (for doing heavy-duty interpreter thwacking)
It's not unreasonable for something like the palm port to support none of
these, while the JVM port might support the first three, or something like
that.
> > That probably didn't talk you down, did it? :-/
>
>No, but I figured this would be hard, anyway. As long as it's an order of
>magnitude easier than it is to use B:: to port Perl to the JVM, I think I'll
>be satisfied.
Keen. Let's shoot for two orders of magnitude, just to give us some slop space.
>(And, I should not that simply writing clear, well-defined APIs for all
>internal data structures should be enough to reach that goal.)
This is probably the second-biggest requirement of the finished perl 6. (A
working perl 6 being the first... :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
