At 12:25 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
>On Monday 12 February 2001 12:40, Branden wrote:
> > Probably Perl 6 programs will be cached/distributed in optimized byte code
> > format.
>
>I'm not sure about the leading 'probably'. Perl 6 programs will most likely
>be like most other open-source programs in other languages - either source,
>which you build, or compiled, which you don't. I haven't seen any numbers
>which indicate which is currently more prevalent for, say, C, let alone how
>things will be with Perl.
I'd generally expect perl code to be distributed as source. The point of
distributing bytecode isn't to allow obfuscated/one-file distribution as
much as it is to decouple the optimization and run stages. I'd expect (with
nothing to back me up) that you'll see things distributed as source and
compiled locally with heavy optimization either at install time or for
big/long-running programs. (mod_perl stuff, or interactive apps that run
for hours) You might see some apps actually run from source with heavy
optimization enabled, but that'll likely be for one-off things that eat a
lot of data.
> > Putting the burden of optimize code above the interpreter allows a quicker
> > interpreter (since it doesn't need to do expensive optimizations) and
> > allows more optimized code, since the code can go through a real expensive
> > optimizator once and be stored to be used by the interpreter many times
> > (this could be done for distributing the production version of the
> > program).
>
>But that also depends on the program. Anything runtime opens yourself up for
>the interpretation/compilation/(heavy optimization) stage again.
Huge amounts of stuff, yep. It may limit what sorts of optimization can be
done, depending on what limits Larry puts on things, if any. (We'll allow
the user to place limits on things too, but that may not help in the
general case)
>I suppose one could say, run the expensive optimization threads for the -
>what's it called? The first level? The static compile? The original eval?
>- and forego it for any runtime evals that need to be done. Of course, Perl
>is more complicated that that.
You may find that takes care of a lot of the cases. Or it might not, but
there's no reason that runtime evals can't also go through heavy
optimization. (Though the fact that you're eval-ing at all may kill many of
the heavy optimizations...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
