opMixin or mixin function templates with convenience operator?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Fri Dec 13 15:38:14 UTC 2019
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
If you do both, you end up with an umanagable mess that goes
> 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
> 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
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
More information about the Digitalmars-d