On Wednesday, 3 June 2020 at 03:06:37 UTC, Basile B. wrote:
> On Wednesday, 3 June 2020 at 02:32:54 UTC, Walter Bright wrote:
>>        [...]
>
> looks like abstractions are not zero cost in fine

Looks like you haven't used `-vcg-ast` either.
If you do you'll see what's going on.

Some of these can be replaced with CTFE.
Generally only things that need to work on template parameter lists are forced to be templates.

Well and legitimate type parameterization of course.
But those are the minority.

If the template sounds like a question about a type,
Like (CharTypeof or isIntegral) it probably should not be a template.

On Wednesday, 3 June 2020 at 03:19:37 UTC, Walter Bright wrote:
> The thing is, `writeln("hello")` can be expanded to `core.stdc.stdio.puts("hello")`. Done.

How does writeln tell that a zero terminated string has been passed?

On Tuesday, 2 June 2020 at 06:47:54 UTC, Walter Bright wrote:
> Many people are trying to figure out what templates are blowing up their compile. This should help:
>
> https://github.com/dlang/dmd/pull/11208

This makes me happy, thank you!

On Tuesday, 2 June 2020 at 08:37:35 UTC, FeepingCreature wrote:
> On Tuesday, 2 June 2020 at 06:47:54 UTC, Walter Bright wrote:
>> Many people are trying to figure out what templates are blowing up their compile. This should help:
>>
>> https://github.com/dlang/dmd/pull/11208
>
> Nice!
>
> Wishlist: if you could dump out a template instantiation backtrace combined with system time for every template declaration start and end, it should be easy to convert this into callgrind format ( https://valgrind.org/docs/manual/cl-format.html ), which would let us use graphical profilers with it.

Update: I've hacked up an extremely basic callgrind dump, just to test the format. It's based on line numbers, not functions, which callgrind doesn't like: "functions" are "file_filename_line_linenr". https://github.com/FeepingCreature/dmd/commit/aa379ba7750b8d32f35906dc93d3c381cfa90e45 Note I'm *really* not sure if I'm doing the inclusive/exclusive accounting correctly.

Did some internal testing. format!() seems to eat up a lot (40%?), not sure if I'm reading this right, but it wouldn't surprise me.

On Wednesday, 3 June 2020 at 08:40:18 UTC, FeepingCreature wrote:
> On Tuesday, 2 June 2020 at 08:37:35 UTC, FeepingCreature wrote:
>> [...]
>
> Update: I've hacked up an extremely basic callgrind dump, just to test the format. It's based on line numbers, not functions, which callgrind doesn't like: "functions" are "file_filename_line_linenr". https://github.com/FeepingCreature/dmd/commit/aa379ba7750b8d32f35906dc93d3c381cfa90e45 Note I'm *really* not sure if I'm doing the inclusive/exclusive accounting correctly.
>
> Did some internal testing. format!() seems to eat up a lot (40%?), not sure if I'm reading this right, but it wouldn't surprise me.

Looks correct.
Format is awful.

On Wednesday, 3 June 2020 at 04:52:37 UTC, Stefan Koch wrote:
> [snip]
>
> If the template sounds like a question about a type,
> Like (CharTypeof or isIntegral) it probably should not be a template.


I was a little confused by this.

Given your recent work on type functions, do you mean that type functions should replace templates in situations like that? That would imply that things like `isIntegral` has to be a template now, but could be changed in the future, correct? Do you think something like mir's `sumType` [1] should not be a template?


[1] https://github.com/libmir/mir-algorithm/blob/f111c311eadb0057f5a233c156b772a010ceab71/source/mir/math/sum.d#L1986

On Wednesday, 3 June 2020 at 11:09:56 UTC, jmh530 wrote:
> On Wednesday, 3 June 2020 at 04:52:37 UTC, Stefan Koch wrote:
>> [snip]
>>
>> If the template sounds like a question about a type,
>> Like (CharTypeof or isIntegral) it probably should not be a template.
>
>
> I was a little confused by this.
>
> Given your recent work on type functions, do you mean that type functions should replace templates in situations like that? That would imply that things like `isIntegral` has to be a template now, but could be changed in the future, correct? Do you think something like mir's `sumType` [1] should not be a template?
>
>
> [1] https://github.com/libmir/mir-algorithm/blob/f111c311eadb0057f5a233c156b772a010ceab71/source/mir/math/sum.d#L1986

Oh yes.
sumType does not need to introduce new symbols.
Therefore it should be handled in a way which does not introduce new symbols.

type functions are one way to make this happen.
However changes to the language are hard justify therefore I am currently revisiting,
approaches to infer type-function-like behavior and transform them behind the scenes.
(Which is a HUGE pain, because you have to transform recursion into loops, which is a hard problem in itself, AND the user probably would rather have written a loop, but was forced by the language to use recursion. )

alas having my work being useful in the language is more important than to have a better language.

I will continue on type functions; if the conservative approaches don't work out.

On Wednesday, 3 June 2020 at 03:19:37 UTC, Walter Bright wrote:
> The thing is, `writeln("hello")` can be expanded to `core.stdc.stdio.puts("hello")`. Done.

iff it is a string literal and only a string literal. tho the zero-terminator can be fixed with fwrite of course.

> Phobos seems to do a lot of "going around the Horn" instead of taking the canal.

It actually tries to special-case string literals (and it does a fine job - the compile time on my computer is scarcely different than using `core.stdc.stdio`), but turns out this is trickier than it might seem since there's a lot of edge cases in real generic D code.

On Linux, this generic implementation costs about 0.04s in compile time. On Windows, it costs about 0.08s (which is probably more the cost of importing core.sys.windows.windows than anything else).

tbh I think this case looks worse than it is.

On Wednesday, 3 June 2020 at 14:04:23 UTC, Adam D. Ruppe wrote:
> On Wednesday, 3 June 2020 at 03:19:37 UTC, Walter Bright wrote:
>> [...]
>
> iff it is a string literal and only a string literal. tho the zero-terminator can be fixed with fwrite of course.
>
>> [...]
>
> It actually tries to special-case string literals (and it does a fine job - the compile time on my computer is scarcely different than using `core.stdc.stdio`), but turns out this is trickier than it might seem since there's a lot of edge cases in real generic D code.
>
> On Linux, this generic implementation costs about 0.04s in compile time. On Windows, it costs about 0.08s (which is probably more the cost of importing core.sys.windows.windows than anything else).
>
> tbh I think this case looks worse than it is.

Try to print an enum please.

On Wednesday, 3 June 2020 at 11:22:23 UTC, Stefan Koch wrote:
>
> Oh yes.
> sumType does not need to introduce new symbols.
> Therefore it should be handled in a way which does not introduce new symbols.

In other words, we want a way to give our templates AST-macro-like evaluation semantics. It's the same thing with Manu's `...` and staticMap. :)

I wonder if a DIP to add something like "Macros: the Good Parts" to D would be accepted?