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