On Sat, Oct 21, 2000 at 08:59:21AM -0700, Larry Wall wrote:
> Joshua N Pritikin writes:
> : http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html
>
> Perl 5 is already stackless in that sense, though we never implemented
> continuations. The main impetus for going stackless was to make it
> possible to implement a Forth-style treaded code interpreter, though
> we never put one of those into production either.
Threading Perl bytecode would be nice about 98% of the time, and
should offer a speed increase. But that would also wreak havoc
with idioms like:
*main::localtime = \&localtime_replacement;
$bignum = factorial(25);
memoize("factorial")
$bignum = factorial(25); # either threaded or memoized, not both
And that 2% is *quite* convenient, if rarely used.
Forth handles this through 'vectored execution' with DOER/MAKE.
Standard colon-defined words cannot globally change their behavior
at runtime (e.g. *sub = \&replacement) because of the way threading
works. DOER defines a word in the dictionary that will always have
a single indirection to it's current code definition, defined
at runtime through MAKE [1].
If Perl bytecode were to become threaded, it would be rather troublesome.
It would probably require some attribute or early compile time
declaration (in main::BEGIN) to tag specific subs/builtins to be
overridden at runtime. It would also force a runtime error when
attempting to override a threaded sub; that it can't be overridden
anymore violates the principle of least surprise wrt Perl5.
It would also mean that if anything was overriden anywhere, no
module code could be read in as bytecode, since it may need to be
rethreaded to incorporate overrideable subs/builtins.
Z.
[1] See Thinking FORTH for details.
