October 17, 2021
On 17.10.21 12:33, IGotD- wrote:
> 
> Why do people call it "hygienic macros"?

"Hygienic" means it avoids name clashes/confusion between parameters and temporaries declared in the macro and identically-named variables at the call site.

https://en.wikipedia.org/wiki/Hygienic_macro
October 17, 2021
On Sunday, 17 October 2021 at 08:15:26 UTC, Walter Bright wrote:
> On 10/16/2021 11:05 PM, Paulo Pinto wrote:
>> On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:
>>> https://www.youtube.com/watch?v=d2VRuZo2pdA
>>>
>>> About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.
>> 
>> If you mean compile time evaluation, D wasn't the first with such features and it is quite far from what Common Lisp is capable of.
>
> Lisp is fundamentally different. It started out as an interpreter and later added native code generation. There never really was a difference between compile time and runtime for Lisp.
>
> Nobody even thought of compile time function evaluation for C and C++ until D did it.
>
> Nobody.
>
> As evidence, when people discovered that C++ templates could be used to evaluate things at compile time, everyone was completely agog over it. I never heard *anyone* suggest that maybe ordinary functions could do this, too.
>
> Now everyone does it. Even C is considering adding it.

Maybe you should have read more SIGPLAN papers then, there are several examples of those capabilities.

Always screaming D did it before C and C++ is not going to increase D's userbase, specially since they get the feature without leaving their ecosystem.

Maybe instead of complaining about who did it first, the community should focus on fixing all lose ends.
October 17, 2021

On Sunday, 17 October 2021 at 06:05:21 UTC, Paulo Pinto wrote:

>

On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:

>

https://www.youtube.com/watch?v=d2VRuZo2pdA

About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.

If you mean compile time evaluation, D wasn't the first with such features and it is quite far from what Common Lisp is capable of.

I mean 50% of the whole thing, and without concern for who's first. D looks familiar(TM), it has a fast compiler, you can relax and treat it like it's a dynamic language but still come back and get picky about unnecessary copies et al., it has UFCS, it has excellent static reflection and is capable of similar tricks like diffType().

Someone who watches this while knowing D is going to think "yeah, I like that about D" about half the time.

October 17, 2021

On Sunday, 17 October 2021 at 05:26:25 UTC, Araq wrote:

>

On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:

>

https://www.youtube.com/watch?v=d2VRuZo2pdA

About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.

Ha, good one. So where is D's hygienic AST macro system that lets you reflect over types? No, string mixins and experimental std.reflection in some offside branch don't count.

I like how Andrei talks about mixin in https://youtu.be/WsgW4HJXEAg?t=3354

"and like an idiot you get to put a string in and give it to the compiler to compile for you. Which sounds ridiculous, right?", while the slide adds that this "isn't glamorous".

But in Common Lisp you are also "like an idiot, putting a list in and giving it to the compiler to compile for you". Lists have structure but a typical macro is heavy on quoting and you can read the quoted parts to understand what the resulting code would look like. The 'code' of macros, the parts that aren't quoted but are doing work like constructing lists or modifying them, are generally also perfectly normal Common Lisp code, they just happen to be constructing lists of code rather than lists of numbers or strings.

If you want to write or maintain a simple macro in Common Lisp, you don't need specialized knowledge: it is enough to know Common Lisp.

What Nim has is more like browser DOM manipulation: knowing Nim is not enough, either to write a macro or maintain a macro. You must also know have copious specialized macro knowledge about nnkSmthng and nnkSmthngElseTy. The 'easy' way to approach Nim macros is to perform the equivalent of opening a browser's developer inspection tool on the desired Nim code.

Common Lisp's macros scale from absolutely trivial

(defmacro sleep-units (value unit)
  `(sleep
     (* ,value
        ,(case unit
           ((s) 1)
           ((m) 60)
           ((h) 3600)
           ((d) 86400)
           ((ms) 1/1000)
           ((us) 1/1000000)))))

to whatever this is: https://github.com/thephoeron/let-over-lambda/blob/master/let-over-lambda.lisp#L356

For trivial cases, Nim has templates. Why? Why not remove templates from the language and tell people to use macros for trivial cases as well?

Or suppose that during a presentation this code were put on the screen:

struct Object {
    float[2] position, velocity, facing;
    float size;
}

struct Player {
    mixin parent!Object;
    int hp;
}

mixin template parent(Struct) {
    static foreach (i, alias f; Struct.tupleof) {
        mixin("typeof(f) ", __traits(identifier, f), " = Struct.init.tupleof[i];");
    }
}

void main() {
    import std.stdio : writeln;

    writeln(Player([0, 0], [0, 0], [0, -1], 5.0, 100));
}

I could say "as you can see, I'm looping here over the members of the given struct, and am injecting new field definitions that have the same types, names, and initial values that the struct has." And the "as you can see" would be literal, not ironic. People really can look at that mixin and see what it does.

Do you think deech could've said something like that about https://github.com/deech/NimNuggets/blob/master/backup/migrationmacros.nim#L11 ? Do you think including that code in his presentation would've done more or less to sell Nim to the audience?

Nim macros are more capable than string mixins, but Nim's metaprogramming story is really not that enviable.

October 17, 2021
On Sunday, 17 October 2021 at 10:03:12 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 17 October 2021 at 08:20:24 UTC, Imperatorn wrote:
>> And still, in 2021 using C++20, compile time features are severely crippled.
>
> How so? Anyway, what Walter said was not accurate. Languages are usually defined in a way where compile-time optimizations are optional and an implementation detail. Compile time evaluation of functions is nothing new, and a common optimization.
>
>> I tried just some days ago doing some simple math pow stuff and the answer I got from the C++ community was "eh, well you'd have to use a constexpr compatible library for that"
>
> Because pow may be system specific at runtime. A compile time optimization should not lead to a different outcome.

I'm not sure if you write C++ or not. But if you do a side by side ct/meta comparison of common things you do in D vs C++, C++ is really behind when it comes to convenience, if it's even possible.

Well pow was just a random example, but as an example, what would the C++ version look like?
October 17, 2021

On Sunday, 17 October 2021 at 11:10:16 UTC, jfondren wrote:

>

On Sunday, 17 October 2021 at 05:26:25 UTC, Araq wrote:

>

[...]

I like how Andrei talks about mixin in https://youtu.be/WsgW4HJXEAg?t=3354

[...]

D rox

October 17, 2021
On Sunday, 17 October 2021 at 11:04:26 UTC, Paulo Pinto wrote:
> On Sunday, 17 October 2021 at 08:15:26 UTC, Walter Bright wrote:
>> On 10/16/2021 11:05 PM, Paulo Pinto wrote:
>>> On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:
>>>> https://www.youtube.com/watch?v=d2VRuZo2pdA
>>>>
>>>> About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.
>>> 
>>> If you mean compile time evaluation, D wasn't the first with such features and it is quite far from what Common Lisp is capable of.
>>
>> Lisp is fundamentally different. It started out as an interpreter and later added native code generation. There never really was a difference between compile time and runtime for Lisp.
>>
>> Nobody even thought of compile time function evaluation for C and C++ until D did it.
>>
>> Nobody.
>>
>> As evidence, when people discovered that C++ templates could be used to evaluate things at compile time, everyone was completely agog over it. I never heard *anyone* suggest that maybe ordinary functions could do this, too.
>>
>> Now everyone does it. Even C is considering adding it.
>
> Maybe you should have read more SIGPLAN papers then, there are several examples of those capabilities.
>
> Always screaming D did it before C and C++ is not going to increase D's userbase, specially since they get the feature without leaving their ecosystem.
>
> Maybe instead of complaining about who did it first, the community should focus on fixing all lose ends.

you are the one that started with:

"X did it first"

then you complain when people correct you, and then you say it's useless to focus on "who did it first"

come on!

October 17, 2021
On Sunday, 17 October 2021 at 11:14:15 UTC, Imperatorn wrote:
> Well pow was just a random example, but as an example, what would the C++ version look like?

Not sure what you mean, but in C++ floating point is considered system specific. So the same executable could yield different results on different machines for more complex constructs. Since pow() could be provided by the OS/CPU there is no portable optimization for it. Basically, the result is unknown at compile time.

October 17, 2021
On Sunday, 17 October 2021 at 14:39:08 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 17 October 2021 at 11:14:15 UTC, Imperatorn wrote:
>> Well pow was just a random example, but as an example, what would the C++ version look like?
>
> Not sure what you mean, but in C++ floating point is considered system specific. So the same executable could yield different results on different machines for more complex constructs. Since pow() could be provided by the OS/CPU there is no portable optimization for it. Basically, the result is unknown at compile time.

Maybe we're talking about different things.

What I mean is basically (stupid example, but just for the sake of discussion):
https://run.dlang.io/is/S3mZwq

How would you write it in C++ without modifying the stdlib
October 17, 2021
On Sunday, 17 October 2021 at 14:47:15 UTC, Imperatorn wrote:
> How would you write it in C++ without modifying the stdlib

Well, you can't because pow() is not known at compile time (in a portable way). It is only known, in the general case, when executed. If you allow it to be evaluated at compile time you risk a compiletime pow(x,y) value to be different from a runtime pow(x,y) value even though the parameters are exactly the same. Which could lead to bugs (like comparing for equality).