On 11/21/05, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Luke Palmer wrote:
> > On 11/21/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> >
> >>Of course, the compiler is free to optimize these things if it can prove
> >>that runtime's &statement_control:<if> is the same as the internal
> >>optimized &statement_control:<if>.
> >
> >
> > Which it definitely can't without some pragma.
>
> Isn't the question just 'when'? I think at the latest it could be
> optimized JIT before the first execution, or so. The relevant AST
> branch stays for later eval calls which in turn branch off the
> sourrounding module's version from within the running system such
> that the scope calling the eval sees the new version. And this in
> turn might be optimzed and found unchanged in its optimized form.
>
> Sort of code morphing of really first class code. Everything else
> makes closures second class ;)
This is very close to a proposal I made to the ruby-dev mailing list
(which was Warnocked). I proposed a very basic engine that would work
with the parser/lexer to determine what action to take instead of
using the huge case statements that are the heart of both P5 and Ruby.
It would look something like:
TOKEN:
while ( my $token = get_next_token(<params>) ) {
for my $length ( reverse length($token) .. 1 ) {
if ( my $actions = find_actions( substr( $token, 0, $length ) ) ) {
$action->[-1]->( < params, if necessary > );
}
next TOKEN;
}
throw SyntaxError;
}
The for-loop + substr() would be to handle longest-token-first rules.
So, "..." is correctly recognized instead of handled as ".." and ".".
The key would be that the $actions arrayref would get push'ed/pop'ed
as you enter/leave a given lexical scope.
Obviously, this could be optimized to an extremely large degree, but
it -should- work.
Rob
