No household is perfect
Dmitry Olshansky
dmitry.olsh at gmail.com
Wed Dec 4 10:55:25 PST 2013
04-Dec-2013 20:22, Andrei Alexandrescu пишет:
> On 12/4/13 7:06 AM, H. S. Teoh wrote:
>> On Wed, Dec 04, 2013 at 04:23:59AM +0100, bearophile wrote:
>>> Joshua Niehus:
>>>
>>>> This would make for a good blog post/wiki article. Does one
>>>> already exist?
>>>
>>> If you have a AST macros like in Julia language, I think you can
>>> write something like:
>>>
>>> @setExpr(a ∪ (b ∩ c));
>>>
>>> The main difference is that the compiler gives you a tree in the
>>> macro to work on, instead of a string to parse and munge.
>> [...]
>>
>> The problem with having the compiler parse it is that it has to be in a
>> syntax understood by the compiler. If your DSL needs a radically
>> different syntax, it won't work (e.g., regex: how is the compiler to
>> know '+' is a postfix operator instead of an infix one?).
>>
>> By having a compile-time string as input, you have maximum flexibility.
>> It's essentially writing a mini-compiler embedded in D, because it runs
>> in CTFE.
>
> Yah, my thoughts exactly. Looks like we're in a sweet spot there.
I'll just add a bit of my experience on this.
The coolest side of things is that you get to code a mini-compiler that
has a very nice backend - D code. More then that you get optimizer and
such for free. Then you only do the fun stuff - your frontend, and if it
wasn't for CTFE speed/stability the experience is _very_ pleasant.
Compare that with writing a fully fledged JIT compiler for say, regex
patterns. Don't forget to account that you'd need to port it to X
architectures times Y OS ABIs and generate code of at least moderate
quality.
JIT would have the benefit of being usable for patterns not known ahead
of time though.
--
Dmitry Olshansky
More information about the Digitalmars-d
mailing list