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