GSOC Linker project

[Alex Rønne Petersen]

On Friday 04 May 2012 08:56 PM, Andrew Wiley wrote:
> On Fri, May 4, 2012 at 1:46 PM, foobar <foo at bar.com
> <mailto: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 <mailto: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.
>

Storing the AST would basically equal storing the source code except 
'trivia' like white space and unneeded tokens. At that point, you may as 
well ship the source.

-- 
- Alex