CTFE and DI: The Crossroads of D

[Adam Wilson]

On Wed, 09 May 2012 15:43:57 -0700, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Wed, May 09, 2012 at 06:17:41PM -0400, Nick Sabalausky wrote:
>> My take, FWIW:
>>
>> 1. DI is only useful for those anachronistic corporations who beleive
>> in code-hiding (and even then, only the ones who release libs), which
>> regardless of everything else, isn't even *realistic* anyway - there's
>> always reverse-engineering, and with the super-popular JS there *IS
>> NO* pre-compiled form, and yet non-OSS companies *still* get by just
>> fine anyway. If you're relying on the increasingly-irrelevent practice
>> of code-hiding (which there is *no such thing* - only obfuscation,
>> which is exactly what compiling does, it only obfuscates the source,
>> it doesn't hide it), then you need to accept that there *are* going to
>> be things you will *never* be able to do, period, like virtual
>> templates (which *are* possible in theory if all the source is
>> available, even if D doesn't currently allow it).
>
> This is why I kept proposing that .di's should have zero implementation.
> ZERO. No function bodies, no template bodies, NOTHING except API
> information. All of the implementation stuff should be compiled into
> some intermediate form and stuck into special sections in the object
> file that the compiler understands. For example, it can be a serialized
> AST of the corresponding source. When you import the module, the
> compiler automatically looks up the corresponding section in the
> precompiled library and gets whatever info it needs (template bodies,
> CTFE function bodies, whatever).
>
> Yes such a thing can be reverse-engineered, but that is no different
> from distributing your binary in the first place (someone determined
> enough to steal your code will be able to reverse-engineer even the most
> sophisticated obfuscations you apply to your code -- if the CPU can run
> the code, it can be reverse-engineered). It really is just a matter of
> deterring the casual shoulder-peekers from peeking at your "precious"
> code. Code in the form of ASTs stored in the compiled library should be
> deterrent enough -- anyone that actually bothers to reverse engineer
> that is determined enough that you will not be able to stop him no
> matter what you do anyway.
>

I am 100% for this. It would be very .NET like. In fact I'm curious enough  
what it would take to make this work that I could see myself trying. My  
guess is that it needs a new linker with the glorious side-effect of  
dumping optlink! In that case it would mean upgrading the D backend to  
emit COFF (ELF and Mach-O already support custom sections), which I am  
fine with trying to do. Then you would add your AST or other intermediate  
representations to a custom section in the object file and the linker  
could then link it in. D would then need a way to extract said  
information. Which would not be terribly hard. Except that you'll have to  
train other compilers how to read that IR. Maybe we could train D to read  
the LLVM IR?

>> 2. We should be seriously looking into the idea of making CTFE work by
>> executing already-compiled code, a la Nemerle (but without needing the
>> extra build step). There may be enough technical hurdles involved to
>> hold this back for [the still-hypothtical] D3, but it should at least
>> be a direction we should be seriously considering. (Unless someone can
>> already come up with a deal-breaking reason now.) Actually, there's
>> *FAR* more important things than this right now, like a solid
>> ARM-tablet toolchain, so this should definitely just be an "on hold
>> for now" feature.
> [...]
>
> +1. You do have the problem of what to do in a cross-compiler, though.
>
>
> T
>


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/