Compilation strategy

[Dmitry Olshansky]

12/18/2012 4:42 AM, Walter Bright пишет:
> On 12/17/2012 3:03 PM, deadalnix wrote:
>> I know that. I not arguing against that. I'm arguing against the fact
>> that this
>> is a blocker. This is blocker in very few use cases in fact. I just
>> look at the
>> whole picture here. People needing that are the exception, not the rule.
>
> I'm not sure what you mean. A blocker for what?
>
>
>> And what prevent us from using a bytecode that loose information ?
>
> I'd turn that around and ask why have a bytecode?
>
>
>> As long as it is CTFEable, most people will be happy.
>
> CTFE needs the type information and AST trees and symbol table.
> Everything needed for decompilation.
>

The fact that CTFE has to crawl AST trees is AFAIK a mere happenstance. 
It does help nothing but the way to hack it into the current compiler 
structure.

There should be a far more suitable IR (if you don't like the bytecode 
term) if we are to run CTFE at least at marginally comparable to 
run-time speeds.

> I know that bytecode has been around since 1995 in its current
> incarnation, and there's an ingrained assumption that since there's such
> an extensive ecosystem around it, that there is some advantage to it.
>

I don't care for ecosystems. And there is none involved in the argument.

> But there isn't.

Compared to doing computations on AST tries (and looking up every name 
in symbol table?), creating fake nodes when the result is computed etc?

I'm out of words.

-- 
Dmitry Olshansky