Idea #1 on integrating RC with GC

deadalnix deadalnix at gmail.com
Mon Feb 10 16:21:21 PST 2014


On Monday, 10 February 2014 at 23:29:25 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 10 February 2014 at 23:13:56 UTC, deadalnix wrote:
>> You seems to knows everything in and out. You tell me. If you
>> aren't sure, please start parsing D to clang AST. After all, 
>> that sound like a great idea.
>
> No, I don't know everything, but I said "modified subset of D", 
> that would be a different language. Suitable for my needs (I 
> don't need RTTI or exceptions etc).
>
> I know I can do it, because source-2-source compilation is not 
> that difficult and could be the first step. And (slow) parsers 
> are not so difficult to write with the tools we have today.
>
> After looking at the SVN repositories for clang I am becoming a 
> bit more familiar with the source code which looked chaotic the 
> first time I looked at it.
>
> The AST looks ok from skimming through the repository, I assume 
> I can get it through a visualization tool and generate visual 
> graphs of the hierarchies.

Long story short, if you want to map thing on top of clang AST, 
you'll have to reduce significantly the subset of D you want to 
use, or build a full fledged front end, at which point you'd 
better use LLVM directly or GCC, or whatever backend suit your 
desires.

For instance, static ifs, template constraints and CTFE require 
full understanding of language semantic by the frontend. Runtime 
reflection, is also out. That mean UDA could work but become 
useless. Type inference also require almost complete 
understanding of the language by the frontend.

And even with these drastic restrictions, you'll still need a 
significant amount of semantic analysis in the frontend before 
feeding clang. You'll have to instantiate templates yourself (or 
bye bye alias parameters, string parameters and so on). Track 
variables used in closures (well, on that one you can arguably 
allocate every stack frame on heap and pas the whole stack frame 
to C++ lambda, that should work, but that will excruciatingly 
slow and memory consuming) to allocate them on heap.

With CTFE, compile time reflection and static ifs/mixins, D wraps 
around itself in a way that makes it all or nothing in 
implementation.


More information about the Digitalmars-d mailing list