System programming in D (Was: The God Language)
Manu
turkeyman at gmail.com
Mon Jan 9 03:58:02 PST 2012
On 9 January 2012 12:01, Martin Nowak <dawg at dawgfoto.de> wrote:
> Am 04.01.2012, 15:33 Uhr, schrieb Vladimir Panteleev <
> vladimir at thecybershadow.net>:
>
> On Wednesday, 4 January 2012 at 14:28:07 UTC, Andrei Alexandrescu wrote:
>>
>>> Hmmm, I see that the other way around. D CTFE-generated macros are much
>>> easier to debug because you can actually print the code before mixing it
>>> in. If it looks like valid code... great.
>>>
>>
>> Paging Don Clugston: would it be feasable to have the compiler remember
>> the source position of every single char/string literal or
>> compile-time-evaluated string expression?
>>
>> I'm thinking that if the compiler tracks the source of every string/char
>> literal in the source code, all across to any manipulations, debugging
>> CTFE-generated code would be a lot easier - the compiler would emit error
>> messages pointing inside string literals, and debuggers could step inside
>> code in string literals. (The one thing this doesn't allow is allowing
>> debuggers to step through a DSL with no D code in it.)
>>
>> The naive implementation would store the position of every character,
>> which would blow up the memory usage by about 13 times or so on 32-bit?
>> (For every character, add a struct with 3 fields - char* filename; int
>> line, column). A rope-like structure could cut down on that but possibly
>> drastically complicating the implementation.
>>
>
> Last time I generated big and complex mixin I let the compiler
> output mixins to separate files. This gives you nicer debugging
> and readable error lines.
> https://github.com/D-**Programming-Language/dmd/pull/**426<https://github.com/D-Programming-Language/dmd/pull/426>
>
Amazing idea, this should be standard!
That totally changes my feelings towards mixins :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120109/7d2fdf0c/attachment.html>
More information about the Digitalmars-d
mailing list