July 04, 2017 Parsing string mixin as normal code | ||||
---|---|---|---|---|
| ||||
Hi all, After going through the compiler code that does parsing, I noticed that whenever a mixin is encountered, a CompileStatement node is created and its contents are parsed later on when semantic is performed. I am not sure for other cases, but at least for simple string mixins you could parse the string right away without instantiating a new parser. Is there a reason for deferring the parsing to the semantic analysis phase? Thank you, RazvanN |
July 19, 2017 Re: Parsing string mixin as normal code | ||||
---|---|---|---|---|
| ||||
Posted in reply to RazvanN | On Tuesday, 4 July 2017 at 14:48:00 UTC, RazvanN wrote:
> After going through the compiler code that does parsing, I noticed that whenever a mixin is encountered, a CompileStatement node is created and its contents are parsed later on when semantic is performed. I am not sure for other cases, but at least for simple string mixins you could parse the string right away without instantiating a new parser. Is there a reason for deferring the parsing to the semantic analysis phase?
Guess with parsing right away you mean during the initial module parsing.
It's the distinguishing between simple and complex that mandates the later parsing.
Temporal/order dependencies between different stages are tricky enough in the compiler, better to just stick with one behavior.
Also most mixin expressions aren't trivial (at least require concat and usually formatting), so it's hardly optimizing.
Might be more interesting for `mixin(import("code.d"));`, but it's fine as is.
|
Copyright © 1999-2021 by the D Language Foundation