April 20, 2021

On Tuesday, 20 April 2021 at 15:37:25 UTC, Brian wrote:

>

I suppose what I want to do is traverse the compiler's transformation of the mixin. The mixin page suggests it performs that work at semantic evaluation time.

~Brian

I try to explain how it does that.

First off, as the article says, a mixin must always expand to either a complete statement/declaration, or to an expression. This let's the compiler to complete the grammar pass (of stuff outside the mixin) before the semantic analysis, without needing to worry about the content of the mixin. This is why mixin("{") won't work - the grammar pass would have to analyze what is in the string to understand that.

Secondly, a mixin can accept any string available at compile time. D has a compile time function execution engine, that is used if a result of a function is needed at compile time. This is the case for mixin arguments, but it's not the only thing. Behold:

import std;

//a regular function, callable at both runtime and compile time
string makeSymbol(const char c){return "in" ~ c;}

//a template
alias Type(T) = T;

//compile-time constant that behaves like a variable
enum intStr = makeSymbol('t');

void main()
{
    //same as int x = 15;
    //all work to determine the type done by CTFE engine at semantic pass
    Type!(mixin(intStr)) x = 15;
    x += 10;
    x.writeln;
}
April 20, 2021

On Tuesday, 20 April 2021 at 15:37:25 UTC, Brian wrote:

>

On Tuesday, 20 April 2021 at 15:26:28 UTC, Petar Kirov [ZombineDev] wrote:

>

Not sure if that's quite what you want, but you can use [pragma(msg, typeOrValueKnownAtCompileTime)][1] [²][2] to print stuff at CT.

I suppose what I want to do is traverse the compiler's transformation of the mixin. The mixin page suggests it performs that work at semantic evaluation time.

~Brian

-vcg-ast is your friend then! See for example: https://run.dlang.io/is/RlX9Ks

Other than using the compiler frontend as a library (which is possible, but not yet straightforward), and the above mentioned switch, the typical way most people check the generated code is by simply printing the string that is being mixed-in (either at compile-time with pragma(msg), or at run-time). Unlike some languages, where macros are essentially a separate language, in D, if you can call a function at compile-time you can certainly call it at run-time as well. So to check that mixin(generateSomeCode()) does what you want, you can simply unit test generateSomeCode as usual.

April 23, 2021

On Tuesday, 20 April 2021 at 17:58:07 UTC, Petar Kirov [ZombineDev] wrote:

>

On Tuesday, 20 April 2021 at 15:37:25 UTC, Brian wrote:

>

On Tuesday, 20 April 2021 at 15:26:28 UTC, Petar Kirov [ZombineDev] wrote:

>

Not sure if that's quite what you want, but you can use [pragma(msg, typeOrValueKnownAtCompileTime)][1] [²][2] to print stuff at CT.

I suppose what I want to do is traverse the compiler's transformation of the mixin. The mixin page suggests it performs that work at semantic evaluation time.

~Brian

-vcg-ast is your friend then! See for example: https://run.dlang.io/is/RlX9Ks

Other than using the compiler frontend as a library (which is possible, but not yet straightforward), and the above mentioned switch, the typical way most people check the generated code is by simply printing the string that is being mixed-in (either at compile-time with pragma(msg), or at run-time). Unlike some languages, where macros are essentially a separate language, in D, if you can call a function at compile-time you can certainly call it at run-time as well. So to check that mixin(generateSomeCode()) does what you want, you can simply unit test generateSomeCode as usual.

D rox! How do we get more ppl to know about it? Is it because it can do "anything" and therefore ppl get suspicious? Like "that's not possible" (which can be partly true ofc).

I've only known D2 for about 2 years, and recently started writing real stuff in it. Imo, if we continue polishing D2 it will be awesome. (Then for those wanting a D3, fork it so you can make the changes without worrying about compact, then see if it could be made compatible).

For example, a conversion bw D1 and D2 could be done. And if we got a D3, the same thing could apply. The other way around is not as important imo.

Anyway, D roks

April 23, 2021
On Friday, 23 April 2021 at 09:43:30 UTC, Imperatorn wrote:
> On Tuesday, 20 April 2021 at 17:58:07 UTC, Petar Kirov [ZombineDev] wrote:
>> [...]
>
> D rox! How do we get more ppl to know about it? Is it because it can do "anything" and therefore ppl get suspicious? Like "that's not possible" (which can be partly true ofc).
>
> I've only known D2 for about 2 years, and recently started writing real stuff in it. Imo, if we continue polishing D2 it will be awesome. (Then for those wanting a D3, fork it so you can make the changes without worrying about compact, then see if it could be made compatible).
>
> For example, a conversion bw D1 and D2 could be done. And if we got a D3, the same thing could apply. The other way around is not as important imo.
>
> Anyway, D roks

People know about it, that is how C++, C#, Java got influenced in some of their latest features, while enjoying the large ecosystem of libraries and IDE tooling.

Where do you think stuff like constexpr if or System.Span<T> was inspired from?
April 23, 2021
On Friday, 23 April 2021 at 11:27:50 UTC, Paulo Pinto wrote:
> On Friday, 23 April 2021 at 09:43:30 UTC, Imperatorn wrote:
>> [...]
>
> People know about it, that is how C++, C#, Java got influenced in some of their latest features, while enjoying the large ecosystem of libraries and IDE tooling.
>
> Where do you think stuff like constexpr if or System.Span<T> was inspired from?

Hmm, true. Well, then I guess it's the ecosystem we have to work on! That's a bit of a chicken and egg thing though
April 23, 2021
On 4/20/21 6:02 AM, Dukc wrote:
> Even better is if you make a global array of opCodes and pass that to `static foreach`. The opcode array needs to be available in compile time, so mark it `enum` instead of `immutable`, like: `enum opcodes = ["nop", "lxi", "stax", <...>];`

Just FYI, immutables are accessible at compile-time. it can sometimes be advantageous to use immutable instead of enum, as an enum doesn't exist at runtime (so e.g. every use will construct a new array).

-Steve
May 04, 2021
I can't make it due to a conflict but reminding everyone:

On 4/19/21 1:05 PM, Brian wrote:

> I'm giving a talk about all the different
> languages I have helped port to OpenBSD (about 40 or so that I can
> remember as of now). It won't all be about D, but D will be an
> exclusive, highlighted, part of it. Humorously, everyone is going around
> calling it "the D on OpenBSD talk" because that one blog post really
> gained traction in the *BSD community too. Anyhow, it's May 5 at 18:45
> NY time. Free and virtual (Zoom):
> https://www.nycbug.org/index?action=view&id=10683
>
> ~Brian

Ali

May 05, 2021
On Tuesday, 4 May 2021 at 23:03:55 UTC, Ali Çehreli wrote:
> I can't make it due to a conflict but reminding everyone:

Thanks for the info, and I hope someone will share this on youtube later, for those who can't access through current alternative.

Matheus.




May 05, 2021
On Wednesday, 5 May 2021 at 00:18:07 UTC, Matheus wrote:
> On Tuesday, 4 May 2021 at 23:03:55 UTC, Ali Çehreli wrote:
>> I can't make it due to a conflict but reminding everyone:
>
> Thanks for the info, and I hope someone will share this on youtube later, for those who can't access through current alternative.
>
> Matheus.

Yes. Speaking as one of the admins of NYC*BUG (where I'm giving this talk), we record all of our talks and they are posted.

~Brian
May 05, 2021
On Wednesday, 5 May 2021 at 15:21:17 UTC, Brian wrote:
> On Wednesday, 5 May 2021 at 00:18:07 UTC, Matheus wrote:
>> On Tuesday, 4 May 2021 at 23:03:55 UTC, Ali Çehreli wrote:
>>> I can't make it due to a conflict but reminding everyone:
>>
>> Thanks for the info, and I hope someone will share this on youtube later, for those who can't access through current alternative.
>>
>> Matheus.
>
> Yes. Speaking as one of the admins of NYC*BUG (where I'm giving this talk), we record all of our talks and they are posted.
>
> ~Brian

Awesome and I'll wait for it! Thanks.

Matheus.
1 2
Next ›   Last »