opMixin or mixin function templates with convenience operator?

[Ola Fosheim Grøstad]

On Friday, 13 December 2019 at 15:24:32 UTC, mipri wrote:
> On Friday, 13 December 2019 at 14:52:27 UTC, Ola Fosheim 
> Grøstad wrote:
>> What is impolite is to try to shoot down the relevance of
>> having AST macros by pointing to Forth and Lisp.
>
> What I am trying to do is state that a bias towards specialized
> features rather than generic ones is a very reasonable bias for
> a language designer to have. That's it. If a metaprogramming
> DIP came along I wouldn't object that "Lisp tried this and it
> was bad".

It was reasonable for D1, which was a simple language!

But when they went full on meta-programming with D2, and stated 
that this was their focus then they should try to do a lot better 
than other competing languages in that department.

You have to cut down bloat somewhere. So you have to choose:

1. have lots of special features

2. enable libraries to implement it and have lots of meta 
programing features

If you do both, you end up with an umanagable mess that goes 
nowhere.

> I mentioned PARSE and REFILL from Forth, and reader macros from
> Common Lisp. The age and identifiers of these languages has
> nothing to do with the capabilities of those features. What

Well, it kinda does, but regardless. Nobody has stated what AST 
manipulation in D would look like, so what outdated languages 
have done isn't really relevant unless someone propose exactly 
the same.

> they represent is a kind of 'final DIP'. If any DIP can be
> objected to with "this can be done in a library", then the
> final DIP is the one that lets you do anything at all in a
> library. If you *don't* have a bias towards specific solutions
> then I think you'll eventually come up with a solution like
> this, and I propose that it -- not "AST macros" -- is a bad
> idea.

Golden rule in  programming language design:

1. implement it as a library construct first

2. enhance the language so it can be done as a library construct

3. if it still is too heavy on syntax add syntactic sugar for it

4. if it cannot be done at all, then most reluctantly consider a 
language change, but resist, resist resist…

5. if you find yourself adding more and more features. Freeze the 
language. Start over from scratch, build a new language, because 
what you started with has aggregated too much cruft and is in 
danger of becoming unmanagble. That means there was something 
insufficient in the language premises.

> How should you do that? Well, you can do it entirely in the
> ugly macro system, or you can have 1-2 lines of code that just
> emits `"hi" --> "hi"`, using the template.

Nobody has suggested that D should add anything ugly.

Did you look at Term Rewriting?

> I imagine I'd come to the same conclusions about how best to
> employ AST macros in D.

Why would you imagine anything about a design nobody has even 
proposed???