GSOC Linker project

[Andrew Wiley]

On Fri, May 4, 2012 at 1:46 PM, foobar <foo at bar.com> wrote:

> On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
>
>> On 5/4/12, foobar <foo at bar.com> wrote:
>>
>>> The di files are mostly meant to be machine read (e.g. the
>>> compiler) and this belongs as part of the library file in order
>>> to provide ease of use and maintain the relationship between the
>>> binary code and it's interface.
>>>
>>> maintaining two sets of files that could easily get out of sync
>>> and *not* using the docs is way more insane.
>>>
>>>
>> I'd say the docs are more likely to be out of sync than .di code. If
>> the .di code is really out of sync you'll likely even get linker
>> errors. And not everything ends up being documented.
>>
>> And then what about existing tools like IDEs and editors. E.g.
>> autocomplete wouldn't work anymore.
>>
>
> I'd say you'd be wrong.
> Both di and docs are auto-generated from the same source.
> As I said docs are designed for human consumption. This includes all sorts
> of features such as a table of contents, a symbol index, the symbols should
> have links, the docs provide usage examples, etc, etc.
> Docs can be put online thus ensuring they're always up-to-date.
>
> Tools should either read the data from the lib file or retrieve it from
> the web. Keeping separate local di files is simply insane.
>
> And really, have you never heard of Java? How about Pascal?
> Should I continue back in history to all the languages that implemented
> this feature decades ago?
> C/C++ is a huge PITA with their nonsense compilation model which we
> shouldn't have copied verbatim in D.
>

I like the idea, but what about templates? For them, you'd basically be
stuffing source code into the object files (unless you came up with a way
to store the AST, but that seems like the effort/benefit ratio wouldn't be
worth it since we currently have no way to preserve an AST tree between
compiler runs).
Otherwise, I find this idea very compelling. I'm sure there are probably
other issues, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120504/f4c1d2e2/attachment.html>