[armedbear-devel] [armedbear-cvs] r12620 - trunk/abcl/src/org/armedbear/lisp

[Erik Huelsmann]

Hi Tobias,

On Fri, Apr 30, 2010 at 3:20 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:

>> In my eyes, there are 2 ways forward with this: 1) We undo this
>> option; this leaves users at a loss when compilation fails; they'll
>> need to use the entire file uncompiled. 2) We make the fallback a
>> selectable restart; this way, compilation gets interrupted, the user
>> is aware and we're much more likely to receive our feedback. But the
>> user isn't restricted to using a fully interpreted file anymore.
>>
>> Quite possibly, you can read my preference through the lines already:
>> I think option (2) is *really* nice.
>>
>> What's your opinion on the matter?
>
> For a semi-outsider: When does compilation fail where interpretation
> would succeed?

In case of compiler bugs. It's relatively difficult to generate
correct Java byte code: in the ticket #89 example: a statement left a
value on the stack which wasn't going to be used ever after. The code
would have run correctly in all cases, however, the byte code verifier
found that another code path left fewer arguments on the stack before
jumping to a common follow-up path. The excess value on the stack
would have been cleared upon function-return.

The same code would be interpreted without problems.

I hope that answers your question. If not, don't hesitate to ask!

Bye,


Erik.