From: Benjamin Goldberg <goldbb2@...>
Date: 2002-11-12T04:26:39+09:00
Subject: Re: A vision for Parrot

Darren New wrote:
> 
> Benjamin Goldberg wrote:
> > In all cases that I can think of, your dynamic code is essentially a
> > string which gets eval()ed (with a language-dependent eval).  The
> > solution is to make the eval() function/operator compile into a
> > sequence of operations along the lines of: Load the compiler for
> > this language, (if it's not already loaded), pass that string to the
> > compiler, run the generated bytecode.
> 
> Seems like an awful lot of overhead for every keystroke, window event,
> and async file operation.

Why would any of these require that strings be eval()ed?

You compile the string to bytecode, *once*, and pass this compiled code
as the callback for your keystrokes, window events, and async file
operations.  You wouldn't pass a string to be eval()ed -- that would be
silly.

Furthermore, even if one did do something that foolish, the compiler
needs to be loaded only once...  So, (ignoring the first one, where the
compiler gets loaded) each keystroke, window event, or async file
operation would merely compile the string to bytecode, then run the
bytecode.  This is no different from what Tcl does all the time, except
that it's a different kind of bytecode.

-- 
my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
.."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]