February 02, 2022

On Wednesday, 2 February 2022 at 12:24:32 UTC, Nick Treleaven wrote:

>

String interpolation would be pretty much just as bad for performance because it still requires the entire declaration to be put in a string, rather than just an identifier. That whole string needs to be formatted and turned into code, when we'd rather be reading code in the first place!

If you have to use a mixin for an identifier on a regular basis then that suggests to me that something is wrong with the design of the application or that some other language feature is missing.

mixin should be viewed as an emergency escape hatch compenstating for language deficiencies, not as a solution.

February 02, 2022

On Wednesday, 2 February 2022 at 13:13:13 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 2 February 2022 at 12:24:32 UTC, Nick Treleaven wrote:

>

String interpolation would be pretty much just as bad for performance because it still requires the entire declaration to be put in a string, rather than just an identifier. That whole string needs to be formatted and turned into code, when we'd rather be reading code in the first place!

If you have to use a mixin for an identifier on a regular basis then that suggests to me that something is wrong with the design of the application or that some other language feature is missing.

mixin should be viewed as an emergency escape hatch compenstating for language deficiencies, not as a solution.

Yes, exactly. Mixin variable names as used here is imho a code smell. The variables are parametrized by a name and that is probably better solved by an array indexed on an enum, or a structure or even by an associative array.

February 02, 2022

On Wednesday, 2 February 2022 at 13:13:13 UTC, Ola Fosheim Grøstad wrote:

>

If you have to use a mixin for an identifier on a regular basis

No one said that. It is only to replace using a mixin string for an entire declaration. If you hate mixin strings logically you should not oppose something which restricts their use to a much smaller scope. I do not buy any argument that it would encourage mixin strings. In metaprogramming you do what is necessary for best runtime performance.

February 05, 2022

On Wednesday, 2 February 2022 at 16:24:25 UTC, Nick Treleaven wrote:

>

much smaller scope. I do not buy any argument that it would encourage mixin strings. In metaprogramming you do what is necessary for best runtime performance.

I agree with the concern for runtime performance, but if that really is an issue then maybe it would better to instead improve on the language rather than adding more string-manipulation.

February 07, 2022

On Monday, 31 January 2022 at 07:19:49 UTC, bauss wrote:

>

On Saturday, 29 January 2022 at 21:24:09 UTC, mesni wrote:

>
static foreach(name; ["boo", "foo"]){
    string file_#name = readText(name~".txt");
    string file_#name#_info = readText(name~".meta");
    auto ##name = file_#name#_info.parseInfoFile;
}

writeln(file_boo);
writeln(boo);
writeln(file_foo_info);

To make it easier to read/write code in D, I would introduce new mixins. These mixins can only represent identifiers. Also, the advantage of such mixins, the parser and semantic analysis will be able to detect some errors before the code is completely "opened". Also, I think they can speed up compilation.

I believe a DIP would be necessary, but to be honest I don't see a reason for this.

You can just do this which isn't really much less readable.

    static foreach (name; ["boo", "foo"])
    {
        mixin(`string file_%1$s = readText("%1$s.txt");`.format(name));
    }

    writeln(file_boo);
    writeln(file_foo);

And if D ever gets interpolated strings then the whole format can be removed and it could probably become something like this:

    static foreach (name; ["boo", "foo"])
    {
        mixin(i`string file_$name = readText("$name.txt");`);
    }

    writeln(file_boo);
    writeln(file_foo);

So personally I don't see a reason for your suggestion to be added.

I think it's just going to introduce more complexity than it's worth.

One big disadvantage interpolated strings have is you have to put the full declaration in a string. No big deal for a statement, but if the name of a function depends on compile-time stuff, the whole function is a string.

A much easier solution to this is allowing mixin() as an Identifier in general:

 Identifier:
     IdentifierStart
     IdentifierStart IdentifierChars
+    MixinExpression

So, you'd do

static foreach(name; ["boo", "foo"])
{
    enum string file_name_info = "file_" ~ name ~ "_info";
    string mixin("file_", name) = readText(name ~ ".txt");
    string mixin(file_name_info) = readText(name ~ ".meta");
    auto mixin(name) = mixin(file_name_info).parseInfoFile;
}
February 07, 2022

On Monday, 7 February 2022 at 10:49:13 UTC, Quirin Schroll wrote:

>

On Monday, 31 January 2022 at 07:19:49 UTC, bauss wrote:

>

On Saturday, 29 January 2022 at 21:24:09 UTC, mesni wrote:

>
static foreach(name; ["boo", "foo"]){
    string file_#name = readText(name~".txt");
    string file_#name#_info = readText(name~".meta");
    auto ##name = file_#name#_info.parseInfoFile;
}

writeln(file_boo);
writeln(boo);
writeln(file_foo_info);

To make it easier to read/write code in D, I would introduce new mixins. These mixins can only represent identifiers. Also, the advantage of such mixins, the parser and semantic analysis will be able to detect some errors before the code is completely "opened". Also, I think they can speed up compilation.

I believe a DIP would be necessary, but to be honest I don't see a reason for this.

You can just do this which isn't really much less readable.

    static foreach (name; ["boo", "foo"])
    {
        mixin(`string file_%1$s = readText("%1$s.txt");`.format(name));
    }

    writeln(file_boo);
    writeln(file_foo);

And if D ever gets interpolated strings then the whole format can be removed and it could probably become something like this:

    static foreach (name; ["boo", "foo"])
    {
        mixin(i`string file_$name = readText("$name.txt");`);
    }

    writeln(file_boo);
    writeln(file_foo);

So personally I don't see a reason for your suggestion to be added.

I think it's just going to introduce more complexity than it's worth.

One big disadvantage interpolated strings have is you have to put the full declaration in a string. No big deal for a statement, but if the name of a function depends on compile-time stuff, the whole function is a string.

A much easier solution to this is allowing mixin() as an Identifier in general:

 Identifier:
     IdentifierStart
     IdentifierStart IdentifierChars
+    MixinExpression

So, you'd do

static foreach(name; ["boo", "foo"])
{
    enum string file_name_info = "file_" ~ name ~ "_info";
    string mixin("file_", name) = readText(name ~ ".txt");
    string mixin(file_name_info) = readText(name ~ ".meta");
    auto mixin(name) = mixin(file_name_info).parseInfoFile;
}

Yeah, I'm definitely not against mixin working for identifiers.

My example was as a solution if it's never accepted.

February 07, 2022

On Monday, 7 February 2022 at 10:49:13 UTC, Quirin Schroll wrote:

>

A much easier solution to this is allowing mixin() as an Identifier in general:

 Identifier:
     IdentifierStart
     IdentifierStart IdentifierChars
+    MixinExpression

So, you'd do

static foreach(name; ["boo", "foo"])
{
    enum string file_name_info = "file_" ~ name ~ "_info";
    string mixin("file_", name) = readText(name ~ ".txt");
    string mixin(file_name_info) = readText(name ~ ".meta");
    auto mixin(name) = mixin(file_name_info).parseInfoFile;
}

This looks fantastic!

February 07, 2022

On Monday, 31 January 2022 at 20:45:53 UTC, Paul Backus wrote:

>

On Monday, 31 January 2022 at 07:19:49 UTC, bauss wrote:

>

I believe a DIP would be necessary, but to be honest I don't see a reason for this.

You can just do this which isn't really much less readable.

    static foreach (name; ["boo", "foo"])
    {
        mixin(`string file_%1$s = readText("%1$s.txt");`.format(name));
    }

    writeln(file_boo);
    writeln(file_foo);

Using std.format for this incurs a substantial compile-time performance penalty--dozens of templates must be instantiated, memory must be allocated for CTFE, the format string must be validated, etc. If the mixin is inside a template which is itself instantiated many times, this overhead can really add up.

mixin(string file_, name, = readText(", name, .txt"););

1 2
Next ›   Last »