Compilation strategy

[deadalnix]

On Monday, 17 December 2012 at 21:36:46 UTC, Walter Bright wrote:
> On 12/17/2012 12:49 PM, deadalnix wrote:
>> Granted, this is still easier than assembly, but you neglected 
>> the fact that
>> java is rather simple, where D isn't. It is unlikely that an 
>> optimized D
>> bytecode can ever be decompiled in a satisfying way.
>
> Please listen to me.
>
> You have FULL TYPE INFORMATION in the Java bytecode.

That is not true for scalla or clojure. Java bytecode don't allow 
to express closure and similar concept. Decoded scalla bytecode 
is frankly hard to understand.

Java bytecode is nice to decompile java, nothing else.

> You have ZERO, ZERO, ZERO type information in object code. 
> (Well, you might be able to extract some from mangled global 
> symbol names, for C++ and D (not C), if they haven't been 
> stripped.) Do not underestimate what the loss of ALL the type 
> information means to be able to do meaningful decompilation.
>
> Please understand that I actually do know what I'm talking 
> about with this stuff. I have written a Java compiler. I know 
> what it emits. I know what's in Java bytecode, and how it is 
> TRIVIALLY reversed back into Java source.
>

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.

And what prevent us from using a bytecode that loose information 
? As long as it is CTFEable, most people will be happy.