Compilation strategy

[Walter Bright]

On 12/17/2012 4:47 PM, deadalnix wrote:
> On Tuesday, 18 December 2012 at 00:42:13 UTC, Walter Bright wrote:
>> 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?
>>
>
> Because it is CTFEable efficiently, without requiring either to recompile the
> source code or even distribute the source code.

I've addressed that issue several times now. I know I'm arguing against scores 
of billions of dollars invested in JVM bytecode, but the emperor isn't wearing 
clothes.


>>> 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.
>>
>
> You do not need more information that what is in a di file.

Yeah, which is source code. I think you just conceded :-)


> Java and C# put more
> info in that because of runtime reflection (and still, they are tools to strip
> most of it, no type info, granted, but everything else), something we don't need.

There's nothing to be stripped from .class files without rendering them unusable.