thinking about proper implementation of tail calls
Florian Weimer
fw at deneb.enyo.de
Sat Sep 1 08:26:37 PDT 2012
* Remi Forax:
>> I would be surprised if tail calls give more flexibility. Usually
>> it's the opposite, the mini-interpreter wins in terms of flexibility:
>>
>> <http://www.enyo.de/fw/notes/tail-calls.html>
>
> This trick can work with a lexer because usually you don't keep states
> between each recognized tokens, it's harder to use the same trick with
> a parser or an interpreter.
I think the Go lexer from which this is derived has quite a bit of
state (not just the input position). The state is global, so it might
not apply in a scenario where you use tail calls combined with massive
concurrency, but I don't think that's the interesting case anyway.
>> The mini-interpreter turns direct calls into difficult-to-predict
>> indirect calls. This could be a drawback. But optimizing that is
>> probably not much more difficult than a general implementation of hard
>> tail calls.
>
> no, I don't think so because as you said direct calls are not hard to
> predict.
Is implementing efficient hard tail calls on the JVM really *that*
easy?
More information about the mlvm-dev
mailing list