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
