On Tuesday, 3 September 2019 at 22:44:08 UTC, Adam D. Ruppe wrote:
> On Tuesday, 3 September 2019 at 22:37:04 UTC, Laeeth Isharc wrote:
>> 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.
>
> You can always build an AST in objects, then mixin(that_tree.toString()); and let CTFE translate it over. I have used this with various DSL type things in D before, and you could (in theory anyway) do the same thing with full D as well.

Yes - it's not difficult.  It's just that with quite a few things it's a matter of how much you can bite off at once and also continued maintenance cost.  So if there's a good library for it then what might be just beyond what's possible becomes possible.

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.

On Tue, 2019-09-03 at 22:40 +0000, Laeeth Isharc via Digitalmars-d wrote:
> On Tuesday, 27 August 2019 at 17:04:40 UTC, Russel Winder wrote:
[…]
> > My excuse is that I used C on PDP-11 and VAX-11,
> 
> Like this one? :)
> 
> 
> https://www.ioccc.org/2018/mills/hint.html

Seems like fun, but no.

I meant real physical PDP-11 (I can't remember if it was a 45 or a 70) with tape drives various RK05 and a weird disk subsystem that presented as 4 * RK05, and about 40 or so cheap VT100 emulating terminals. Also there was a GT/44 (I think that was the designation it was a rack mounter PDP-11 with a 14" vector graphics display very suitable for playing Lunar Lander).

Octal was clearly the correct number base for all systems programming using a PDP-11.

Then we got a VAX-11 750 with three 20Mb drives (that looked like top loading
washing machines).

Huge upgrade as hexadecimal became the one true number base for all systems programming.

It is left as an exercise for the reader to deduce or even infer why octal and hexadecimal were so important in these different cases.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wed, 2019-09-04 at 16:15 -0700, Walter Bright via Digitalmars-d wrote:
> On 9/4/2019 9:30 AM, bpr wrote:
> > DasBetterC is really quite brilliant. I'm a bit disappointed that so many
> > D fans
> > on this forum react negatively to it.
> 
> Sometimes I think it is what D should have been in the beginning.

But then you wouldn't have a sensible binding/wrapper of GTK+ for D and thus no actual usefulness of D. ;-)

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wed, 2019-09-04 at 16:13 -0700, Walter Bright via Digitalmars-d 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.
> 
> 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.

This didn't happen in Groovy. AST macros were added, and new language capabilities ensued and all in all it was agreed that Groovy was better for AST macros and that they should have been added earlier.

> This doesn't happen overnight, it takes a few years. And then it's too late.
> 
> Some examples:
> 
> 1. Lisp macros

There is not just one Lisp. SBCL, CLisp, and Clojure do things differently but all do things really rather well.

> 2. Macro assemblers
> 3. C macro preprocessor
> 4. C++ expression templates

5. Groovy AST macros.

> (3) is a bit of an interesting case. The C macros are very limited in
> capability, but that barely slowed down the rush to build crazy
> contraptions
> with it and embed them everywhere.
> 
> I've fallen into this trap myself with both (2) and (3). It took 10+ years
> of
> experience to finally realize what a bad idea it was, as it is an enemy of
> writing understandable, maintainable, reusable, and encapsulated code.

As are almost all programming language features. The lesson from Groovy was to actively avoid doing stupid things and to trust programmers not to f### things up. Which they didn't.

> You don't hear much about C++ expression templates these days. For a few
> years
> they were quite the darling, until the scope of the horror became apparent.
> 
> Think of it like when the devil says you can have anything you want. It
> seems
> great for a while, but nothing good comes from it.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thu, 2019-09-05 at 00:32 +0000, Laeeth Isharc via Digitalmars-d wrote: […]
> I don't see how allowing creating D AST via a library presents a serious risk though.

There are certainly risks, but either you assume all programmers are evil and must be protected by the language designer from making errors the language designer doesn't like, or you assume a community of sensible programmers who work together to make the best of potentially dangerous features.

Groovy took the latter view and the community pulled together and even produced some totally unexpected by totally wonderful features.

The general history of programming languages does tend to be the knowledgeable authority kindly protecting programmers from trying to do bad (in the eyes of the authority) things.

The history of programming is the history of trying to protect programmers from doing things.

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

Internal or external DSLs. For internal DSLs (my experience is Python and Groovy) then operator overloading is essential to make any sensible progress. Also, perhaps bizarrely, using an object oriented view of program execution (i.e. messages passed to receivers) helps a great deal.

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

External DSLs maybe but not internal DSLs.

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

I have only dabbled a little, but they are quite good. And fully typed checked. I am sure you can do nasty things with them, but for the simple cases I have used them for they do the job as needed.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 2019-09-05 01:13, Walter Bright wrote:

> This is essentially what AST macros are, a feature that has been repeatedly proposed for D. I've blocked it each time.

I just going to leave this here for everyone:

https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h05m38s

:)

-- 
/Jacob Carlborg

On Wednesday, 4 September 2019 at 23:15:37 UTC, Walter Bright wrote:
> On 9/4/2019 9:30 AM, bpr wrote:
>> DasBetterC is really quite brilliant. I'm a bit disappointed that so many D fans on this forum react negatively to it.
>
> Sometimes I think it is what D should have been in the beginning.

I think that too!

It would have been hard to see this when D came out; Java was on a roll, C++ seemed to be waning, and Moore's Law was still going strong. DasBetterC is, as its name suggests a better C, much more so than C++ IMO. I believe DasBetterC would have lessened the need for Rust. Ah, counterfactuals...

There's still room in the world for DasBetterC, so I hope the development continues. It's great that many of the annoying restrictions have been lifted.

On Thursday, 5 September 2019 at 12:32:16 UTC, Jacob Carlborg wrote:
> On 2019-09-05 01:13, Walter Bright wrote:
>
>> This is essentially what AST macros are, a feature that has been repeatedly proposed for D. I've blocked it each time.
>
> I just going to leave this here for everyone:
>
> https://www.youtube.com/watch?v=FRfTk44nuWE&t=1h05m38s
>
> :)

Ha, I agree that AST macros would be useful, but I don't think they're coming to the D language. Maybe a general purpose macro processor could satisfy some of these desires?

On Thursday, 5 September 2019 at 17:56:09 UTC, bpr wrote:

> It would have been hard to see this when D came out; Java was on a roll, C++ seemed to be waning, and Moore's Law was still going strong. DasBetterC is, as its name suggests a better C, much more so than C++ IMO. I believe DasBetterC would have lessened the need for Rust. Ah, counterfactuals...

Well, quite simply, D would have seen little interest in the early days if didn't have a GC, based on my recollection. Stroustrup was even talking about garbage collected C++. I could be wrong, since there was no Hacker News or Reddit to teach me about the one true path, but D would not have been the marvelous language it is today, and would have had a marketing problem without a GC.

It's true that Rust does appeal to the sliver of programmers that think memory management is an awesome way to spend Saturday night, but let's let Rust have those users and worry about a good experience for the rest.

> There's still room in the world for DasBetterC, so I hope the development continues. It's great that many of the annoying restrictions have been lifted.

Exactly. There's no reason to choose between D and betterC because we can have both.