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

[Don Clugston]

Jari-Matti Mäkelä wrote:
> 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.

True, but for the common case where a D expression is embedded, it's a 
chunk of uninteresting code that needs to be maintained with compiler 
changes. Especially this precedence stuff.

In answer to your question, the great value of the string representation 
is that it is not required to be valid D code.

Consider println("the value of x is ${x} and next value is ${next(x)}") 
-- you need to extract the parts which are expressions, before passing 
it back to the compiler for parsing.

> 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.

Perhaps. I think that the Lisp approach is not going to be optimal for 
D, though. I think that most of the compiler's functionality could be 
exposed to metaprogramming simply by adding properties to string 
literals and tuples. Including something to make a tuple out of the 
elements of the string. I envisage moving back and forth between string 
and tuple representations, since certain operations are much simpler in 
one representation than the other.