At 10:46 PM 12/7/00 -0500, Bradley M. Kuhn wrote:
>John Porter <[EMAIL PROTECTED]> wrote:
>
> > Almost. You're potentially taking away Perl6, which is vaporware.
> > I wonder: In what order will the following exist on Handheld Device
> > Foo:
> >
> > - C
> > - C++
> > - Java
> > - Perl6
>
>I know of at least one hand-held on the market (PocketLinux) that is
>basically Java-based. (My understanding is that they run enough of Linux to
>make the JVM work. ;)
>
>As mentioned elsewhere in the thread, Motorola has a JVM-based device coming
>out, too.
There are going to be two classes of perl systems--those that can turn perl
source into something executable, and those systems that can execute that
output.
The handhelds, palmtops, and embedded systems (as well as most of the JVM
targets, honestly) are in the latter class. Something somewhere eats the
perl source and spits out either perl bytecode or something native to the
platform. (Java bytecode, executable images, or something of the sort) You
transfer the output over to the target system and execute it. Sure, the
target can't do string eval, or compile it's own perl code, but that's not
a big deal. The eval issues can be easily worked around if you know the
target system doesn't support it, and the lack of a compiler in general's
not a huge deal, since nobody sane would try and scribble in any perl
source of consequence. (And no, I won't take bets that nobody on this list
would ever try... :) (I should point out that lots of folks manage to run a
lot of code written in C without having an embedded C compiler in each of
those apps)
The former class will initially consist of systems that can run the
reference version of perl we put out, but one of the big goals I have is to
get everything specified enough that someone can produce another version of
perl from scratch. That may be one written in Java, and that's fine, or it
may be some nutcase that produces a perl front-end for GCC, or it might be
IBM deciding that they can just do it better than we can. Any one, or all,
of those is fine. (I, for one, would be thrilled if someone with some
serious engineering talent produced their own perl...)
The final specs that define those bits of perl's internal behavior that are
user-visible (like the hooks in the parser, or how you write scalar vtable
functions in perl) will be either language neutral or perl-centric. The
parts that aren't user-visible (like how the GC is implemented (as opposed
to its existence), or the internal format of scalars) will likely be
C-centric. Or eccentric. Or both. Regardless, it's not important, since
they're pieces that won't need to be emulated by anyone writing their own
version.
That should, I think, be enough to put this to rest.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
