Jump to page: 1 2
Thread overview
Metaprog can be abstruse
Jul 04, 2022
user1234
Jul 04, 2022
Bastiaan Veelo
Jul 04, 2022
user1234
Jul 04, 2022
Bastiaan Veelo
Jul 04, 2022
Dom Disc
Jul 06, 2022
kdevel
Jul 06, 2022
Dom Disc
Jul 04, 2022
bauss
Jul 04, 2022
drug007
Jul 04, 2022
kdevel
Jul 05, 2022
Alexandru Ermicioi
Jul 06, 2022
kdevel
Dec 28, 2022
Dom Disc
Jan 01, 2023
kdevel
Jan 02, 2023
Dom DiSc
Jul 04, 2022
bauss
Jul 04, 2022
user1234
Jul 04, 2022
bauss
Jul 04, 2022
ryuukk_
July 04, 2022

Example:

auto genDecimalRanks()
{
    import std.conv;
    auto r = 1;
    auto result = "[";
    foreach (i; 1 .. 11)
    {
        result ~= to!string(r);
        if (i < 10)
            result ~= ", ";
        r *= 10;
    }
    result ~= "]";
    return result;
}

/// like [1,10,100,1000,10000,100000,1000000,10000000,100000000,1000000000]
immutable decimalRanks = mixin(genDecimalRanks);

It takes much more space and time to write DDOC + the generator than the space + time required to write the equivalent explicit declaration without comments, i.e "self documenting".

So metaprog is not the panacea, do you think to that before "meta-progrogramming", or do you "meta-prog" just because it's nice ?

July 04, 2022

On Monday, 4 July 2022 at 08:24:01 UTC, user1234 wrote:

>

Example:

auto genDecimalRanks()
{
    import std.conv;
    auto r = 1;
    auto result = "[";
    foreach (i; 1 .. 11)
    {
        result ~= to!string(r);
        if (i < 10)
            result ~= ", ";
        r *= 10;
    }
    result ~= "]";
    return result;
}

/// like [1,10,100,1000,10000,100000,1000000,10000000,100000000,1000000000]
immutable decimalRanks = mixin(genDecimalRanks);

It takes much more space and time to write DDOC + the generator than the space + time required to write the equivalent explicit declaration without comments, i.e "self documenting".

So metaprog is not the panacea, do you think to that before "meta-progrogramming", or do you "meta-prog" just because it's nice ?

Not necessarily.

immutable decimalRanks = iota(10).map!(p => 10.pow(p)).array;

-- Bastiaan.

July 04, 2022

On Monday, 4 July 2022 at 09:40:45 UTC, Bastiaan Veelo wrote:

>

Not necessarily.

immutable decimalRanks = iota(10).map!(p => 10.pow(p)).array;

-- Bastiaan.

Hi, to this alternative I'd say that it's not self documenting.
So it still has 50% of the initial problem.

July 04, 2022

On Monday, 4 July 2022 at 09:43:11 UTC, user1234 wrote:

>

On Monday, 4 July 2022 at 09:40:45 UTC, Bastiaan Veelo wrote:

>

Not necessarily.

immutable decimalRanks = iota(10).map!(p => 10.pow(p)).array;

-- Bastiaan.

Hi, to this alternative I'd say that it's not self documenting.
So it still has 50% of the initial problem.

I can see your point, but it depends on how used you are to reading chains of range algorithms. I read this as "given the integers 0 to 9, use them as the powers of ten and put them in an array". There is a point to be made that this is more self-documenting than the hand-written alternative: Here it is obvious that the ranks cover all powers of 10 from 0 to 9 in order. In the hand-written alternative you'd either assume that is the case, or have to meticulously count all the zero's to be sure.

-- Bastiaan.

July 04, 2022

On Monday, 4 July 2022 at 09:43:11 UTC, user1234 wrote:

>

On Monday, 4 July 2022 at 09:40:45 UTC, Bastiaan Veelo wrote:

>

Not necessarily.

immutable decimalRanks = iota(10).map!(p => 10.pow(p)).array;

-- Bastiaan.

Hi, to this alternative I'd say that it's not self documenting.
So it still has 50% of the initial problem.

I think that depends on your expertise. It's self-document if you understand the functionality of iota, map, pow and array.

Saying it's not self documenting is the same as saying:

writeln("Hello World!") isn't self documenting, but I do believe we can both agree on that it pretty much is.

It's self documenting for the same reason, you understand the functionality behind writeln and thus knows what it is doing.

The same can be said about the above function chain.

It's very much straight-forward in what it's doing and it's only when one doesn't understand these "basic" functions that one don't find it self-documenting.

July 04, 2022
On 7/4/22 12:43, user1234 wrote:
> On Monday, 4 July 2022 at 09:40:45 UTC, Bastiaan Veelo wrote:
>> Not necessarily.
>> ```d
>> immutable decimalRanks = iota(10).map!(p => 10.pow(p)).array;
>> ```
>>
>> -- Bastiaan.
> 
> Hi, to this alternative I'd say that it's not self documenting.
> So it still has 50% of the initial problem.
> 
> 

As for me it is self documenting. And it is more readable than your hand written imperative version.
July 04, 2022

On Monday, 4 July 2022 at 08:24:01 UTC, user1234 wrote:

>

Example:

auto genDecimalRanks()
{
    import std.conv;
    auto r = 1;
    auto result = "[";
    foreach (i; 1 .. 11)
    {
        result ~= to!string(r);
        if (i < 10)
            result ~= ", ";
        r *= 10;
    }
    result ~= "]";
    return result;
}

/// like [1,10,100,1000,10000,100000,1000000,10000000,100000000,1000000000]
immutable decimalRanks = mixin(genDecimalRanks);

It takes much more space and time to write DDOC + the generator than the space + time required to write the equivalent explicit declaration without comments, i.e "self documenting".

So metaprog is not the panacea, do you think to that before "meta-progrogramming", or do you "meta-prog" just because it's nice ?

If you don't like the iota version then you can just do this:

(Modified version of yours.)

auto genDecimalRanks()
{
    import std.conv;

    auto r = 1;
    int[] result = [];

    foreach (i; 1 .. 11)
    {
        result ~= r;
        r *= 10;
    }

    return result;
}

/// like [1,10,100,1000,10000,100000,1000000,10000000,100000000,1000000000]
static immutable decimalRanks = genDecimalRanks();

Everything at compile-time doesn't have to be strings and mixin :)

static and enum will trigger ctfe.

July 04, 2022

On Monday, 4 July 2022 at 10:29:24 UTC, bauss wrote:

>

On Monday, 4 July 2022 at 08:24:01 UTC, user1234 wrote:

>

[...]

If you don't like the iota version then you can just do this:

(Modified version of yours.)

auto genDecimalRanks()
{
    import std.conv;

    auto r = 1;
    int[] result = [];

    foreach (i; 1 .. 11)
    {
        result ~= r;
        r *= 10;
    }

    return result;
}

/// like [1,10,100,1000,10000,100000,1000000,10000000,100000000,1000000000]
static immutable decimalRanks = genDecimalRanks();

Everything at compile-time doesn't have to be strings and mixin :)

static and enum will trigger ctfe.

still the same problems as the initial version (even if yes I know it's absurd code)

July 04, 2022

On Monday, 4 July 2022 at 10:37:14 UTC, user1234 wrote:

>

still the same problems as the initial version (even if yes I know it's absurd code)

I'm actually not sure what you're even trying to achieve or what problem you're trying to solve tbh.

Could you perhaps give an example of what your expectations are and how exactly this differs from your expectations of runtime?

Because my modified version of yours works both at ctfe and runtime, so it has nothing to do with ctfe really. The only thing ctfe about is that it's statically initialized, but you can use it for runtime arrays too, where the function will be executed at runtime.

So there's really no metaprogramming involved in that.

July 04, 2022

I personally only use metaprogramming for tasks i will know will become repetitive

For your example it is not worth it, you only would write that code once anyways

For my case here, it perfectly worth it, adding new packet handler is a matter of an attribute

The complexity of the code added should be relative to its benefits, no need to over do it

screenshot

« First   ‹ Prev
1 2