Talk on what a systems programming language needs to replace C

[Laeeth Isharc]

On Wednesday, 4 September 2019 at 23:13:21 UTC, Walter Bright 
wrote:
> On 9/3/2019 3:37 PM, Laeeth Isharc wrote:
>> But is it unfair to say D is missing an AST that's pleasant to 
>> work with?
>> 
>> I'm not sure whether it would be better to construct a parse 
>> tree or AST for this purpose but eg with DPP my personal sense 
>> is it would be useful to have a way to generate D code at a 
>> more abstract level than strings.
>> 
>> Anyway if you could translate C to D it surely wouldn't hurt.
>
> This is essentially what AST macros are, a feature that has 
> been repeatedly proposed for D. I've blocked it each time.

Yes,so I understand though I do recall seeing your talk from ages 
back.

> The trouble is, it is incredibly powerful. People find 
> themselves unable to resist its siren call, and use it to 
> invent their own language. They never bother to document this 
> language. It winds up balkanizing the underlying language so 
> they cannot share code or even talk to each other.

Funnily enough we have written our own language that's quite 
coupled to D and that even allows you to write inline D.  I just 
realized last night that means you could write inline asm in it 
too :O (it took 1hr 15 minutes to implement inline D as a first 
version and it's not yet in master so I haven't fully absorbed 
the implications yet).

Would be nice to be able to transpile the language to D for 
performance - by far the easiest route as once we have type 
inference it should map quite cleanly from SIL to D.

Anyway,I suppose in a systems language you trust the programmer 
but having gone to extraordinary lengths myself to solve the 
problem of balkanisation I also understand your point.  There are 
negative spillover effects.

I don't see how allowing creating D AST via a library presents a 
serious risk though.

And I wonder a bit about DSLs.  I agree with you about not 
abusing operator overloading.  You should make it an explicit DSL 
instead.

But then the answer ought to be that there are libraries that 
make it easy to develop DSLs.

The competition is quite stiff. There are frameworks that build 
editor plugins with syntax highlighting etc all in an integrated 
way.

In some ways D is peculiarly suited to writing DSLs.  It's not 
difficult to write a parser but having Pegged can make the 
difference between an unrealistic project and just about being 
able to accomplish something.  The type marshalling capabilities 
makes the standard library easy.

But I guess if you compare to what's easy with LINQ and Rosslyn 
there is something missing.  It's not trivial to hook up the AST 
of your DSL to LLVM or similar.  Not difficult but it's not no 
work if you don't already know it.

What's your take on Rust macros?  I am not familiar with them so 
I don't know myself.