@property - take it behind the woodshed and shoot it? - writefln

[Artur Skawina]

On 01/26/13 08:50, Philippe Sigaud wrote:
>>> please give us your own code and preferred solution
>>> to compile-time formatting string checking.
>> I am not interested in formatting at all. I wrote about the
>> general problem to incorporate expectable many DSL's into one big
>> source base, as D is intended to serve large scale coding.
> 
> And what's the solution, for you? Using strings as DSL is somewhat common in D.

I think his point was that inventing a custom dsl for everything does
not scale. And he's of course right. Having one, or at most a few,
common "std" dsls, plus ability do define custom ones is enough. But
the "std" ones must be able to handle 95%+ of cases. So that everyone
does not need to learn a set of custom per-site and/or per-project dsls.

BTW, the std compile-time string formatting "dsl" is not only checkable,
but can relatively easily be parsed at CT; the compiler will then do
the rest. So there's really no point in using such a CT checker - if
the string can be checked then it can also be handled directly, skipping
any runtime parsing overhead completely.

> As for DSL, well, I have a parser generator project here
> (https://github.com/PhilippeSigaud/Pegged), and I recently added the
> capacity to add new rules to a grammar at runtime and modify the
> resulting parse tree. I also used the existent, but unused macro
> keyword in D to get source code that can define its own subsequent
> grammar and parse tree transformations.
> Oh, and grammars can call one another, so adding a new sublanguage to
> a parent language is doable (I use this from time to time). I still
> have weeks fo work on this to have it reach the level I want, but I
> did not hit any wall up to now.
> So adding clean-looking DSL can be done in D, I think.

Yes, this is possible, and desirable, to avoid "polluting" the main
language with certain "features". However it's likely not enough, as
there are aspects of D which make pure macro/dsl solutions not as
simple as they could be (consider static-foreach).

Your inline, parse-time, grammar extensions only work when the parser
runs at CT, so the performance issues remain, right? Still, sounds
interesting; and could be enough to explore the trickier cases and
identify further problems. Must find time to play with it. Is that
feature already in the repo?

artur