Request: (expression).stringof should return a textual AST

[Jari-Matti Mäkelä]

Don Clugston wrote:
> Don Clugston wrote:
>> Many uses of textual macros involve D expression syntax.

>> Almost all the difficulty could be avoided by standardizing the
>> behaviour of (expression).stringof.

>> For use in metaprogramming, it would extremely useful if instead, it
>> parsed the string, without reference to types, removed unnecessary
>> spaces and parentheses, and inserted parentheses to indicate precedence.

> After experimenting with this a bit more, wrapping everything in () is
> not necessary or even desirable -- it does look pretty ugly.
> It would be enough to ensure all terminal expressions are
> space-terminated, and () is only required when the order of evaluation
> should not be left-to-right, due to precedence or associativity. So my
> examples would be:
> 
> (1.2e+58+2*3).stringof --> "1.2e+58 + ( 2 * 3 )"
> (func(var, var1*3.6).stringof --> "func ( var , var1 * 3.6 )"
> and
> (2*3+1.2e+58).stringof --> "2 * 3 + 1.2e+58"

What is the single greatest value in the string representation? I mean
you're proposing that the compiler should basically posses the power to
construct these expressions (it already has, but it does not add the
parenthesis atm) and also parse them afterwards (already possible). Still,
the library level code should reimplement a parser or at least a lexer of
its own.

Why not let the compiler do the heavy lifting, and concentrate on the
interesting parts? Nested tuples with S-exp properties could very well
handle this kind of expression passing and manipulation. They could be
flattened and .stringof'ed afterwards.