CTFE and DI: The Crossroads of D

[Paulo Pinto]

Am 10.05.2012 20:37, schrieb Adam Wilson:
> On Thu, 10 May 2012 11:24:04 -0700, Paulo Pinto <pjmlp at progtools.org>
> wrote:
>
>> Am 10.05.2012 01:01, schrieb Adam Wilson:
>>> On Wed, 09 May 2012 15:55:36 -0700, Mehrdad <wfunction at hotmail.com>
>>> wrote:
>>>
>>>>> 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?
>>>>
>>>>
>>>> :O I was writing a response pretty much exactly like this (i.e. doing
>>>> what .NET does), but then I dumped it, thinking it'd be dismissed as
>>>> too huge of a change...
>>>
>>> :-D This isn't the first time it's been suggested in recent forum
>>> history. I think there is a significant body of support for making D
>>> libraries single file with no import files, it solves a *TON* of issues
>>> around how to import API's. I imagine that it's much the same reason
>>> .NET went with their metadata plan. And ended up where we are suggesting
>>> to go.
>>>
>>
>> And also possible in languages like Turbo Pascal, Delphi or more
>> recent, Go.
>>
>> Actually, this is one of the features I really like in Go.
>>
>> --
>> Paulo
>
> I am seriously considering starting this type of project given how
> strong the support for it is. However, I'd need help. Linkers aren't
> easy and the modifications that DMD will require are even worse. In the
> end we get a modern linker, written in D, and COFF support for DMD. At
> least that's how it goes in my head. I am thinking of kicking off the
> project proposal with a more detailed post later today.
>

Thanks to open source, here is some information how Free Pascal stores
the required information,
http://www.freepascal.org/docs-html/prog/progap1.html#progse67.html


There is also some Oberon documentation at the ETHZ web
sites, but those compilers usually spit an extra .sym file. Which could
be easily embedded in the object file anyway.


For Go, I am afraid currently the only information how they store the
symbol table is "read the code".

--
Paulo