A vision for Parrot

[Jeff Epler]

> > 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.

> Darren New wrote:
> > Seems like an awful lot of overhead for every keystroke, window event,
> > and async file operation.
> 
On Mon, Nov 11, 2002 at 02:31:33PM -0500, Benjamin Goldberg wrote:
> Why would any of these require that strings be eval()ed?

In Tk, every event binding is a string which is substituted and then
treated as code, eg
    bind .b <Button> { puts "Clicked %W" }
This substitution is of a different kind than the normal $-substitution
of commands as they are executed (indeed, $-substitution will take place
next, so that
    bind .b <Button> { puts "$%W" }
will write to stdout the contents of the variable with the same name as
the clicked widget.

Tcl/Tk optimization guides seem to have long recommended putting no code
of consequence in a widget binding, for this very reason.

Jeff