Am 10.05.2012 20:37, schrieb Adam Wilson:
On Thu, 10 May 2012 11:24:04 -0700, Paulo Pinto <[email protected]>
wrote:
Am 10.05.2012 01:01, schrieb Adam Wilson:
On Wed, 09 May 2012 15:55:36 -0700, Mehrdad <[email protected]>
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
