DIP 50 - AST macros

Jacob Carlborg doob at me.com
Mon Nov 11 01:24:30 PST 2013


On 2013-11-11 09:31, Rikki Cattermole wrote:

> Theres a few other things I think would need to be cleared up.
> For example take this code:
>
> shader {
>   program
>   vertex {
>    #version 150
>    void main() {
>    }
>   }
>   fragment {
>    #version 150
>    void main() {
>    }
>   }
> }
>
> At this point the vertex / fragment segments would be treated as strings
> instead of calling their macros. So perhaps a rule to identify macros
> inside macros calls? It would save a lot of time for parsing reasons.

They way I see that is the AST of the whole block would be passed to 
"shader". I have though a bit about macros inside macros, but I haven't 
come to a conclusion. The easiest way from a design point of view seems 
to be that "shader" to basically return the whole AST it receives plus 
any addition it needs to do. The the "vertex" and "fragment" macros are 
expanded recursively.

> Also can you alias a macro?
>
> alias fragment = tostring;
>
> That would make things a lot simpler creating nice structures of them.

I don't see why not.

> Perhaps a condition on a macro like the if's we got for templates would
> be useful in the sense of being able to say:
>
> if (lexer.compareLine(0, "[a-zA-Z]{1}[a-zA-Z_0-9]*") &&
> lexer.isSymbol(1, SymbolTypes.Macro, vertex))

I don't think I understand how this should be used.

> This would require us to develop a lexer library. But if done right I
> don't see why it wouldn't be usable for more than just D macro checks.
> Preferably also for e.g. c/c++ wink wink for when D's front end is in D.
>


-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list