On Thursday, 24 September 2020 at 05:38:07 UTC, H. S. Teoh wrote:

>
> What we need is imperative syntactic sugar that lowers to recursive templates under the hood.  (After all, in theory, every Turing-complete language is just syntactic sugar over lambda calculus. :-P)
>
> That, plus implement template optimization schemes to lower the cost of recursive templates.  The template analogue of tail-call optimization is a good first step, for example.  Another good direction to investigate is instantiation elimination: i.e., defer the actual instantiation of a template (with its associated costs of copying the AST and substituting arguments, generating symbols, etc.) until it's determined to be necessary.
>
>
> T

I am not sure if what you are saying is actually serious or not ...

You're suggesting to provide in iterative syntax for the programmer.
Rewriting that internally into recursive templates.
And then try to recover the iterative form to get the speed.

Did I paraphrase correctly?

On Thu, Sep 24, 2020 at 03:08:05PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 24 September 2020 at 05:38:07 UTC, H. S. Teoh wrote:
> > 
> > What we need is imperative syntactic sugar that lowers to recursive templates under the hood.  (After all, in theory, every Turing-complete language is just syntactic sugar over lambda calculus. :-P)
> > 
> > That, plus implement template optimization schemes to lower the cost of recursive templates.  The template analogue of tail-call optimization is a good first step, for example.  Another good direction to investigate is instantiation elimination: i.e., defer the actual instantiation of a template (with its associated costs of copying the AST and substituting arguments, generating symbols, etc.) until it's determined to be necessary.
[...]
> I am not sure if what you are saying is actually serious or not ...
> 
> You're suggesting to provide in iterative syntax for the programmer.
> Rewriting that internally into recursive templates.
> And then try to recover the iterative form to get the speed.
> 
> Did I paraphrase correctly?

OK, it sounds ridiculous when you put it that way. :-D  But what I had in mind was what Walter said about leveraging the existing language instead of adding new features.  My thought was to introduce new syntax that maps to the current template implementation (recursion, etc.): new syntax won't significantly add to the weight of the language since you're not defining new semantics.  This solves the writability / readability problem.  Then the next step is to improve the implementation, so that it benefits both existing template code and, by extension, the new syntax. This would solve the performance issue, or at least address it.

Or maybe a more sensible approach is to implement a template optimizer with the current language, that optimizes certain patterns into iterative code, then at a later point introduce primitives that let you access this iterative code directly.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."

On Thursday, 24 September 2020 at 15:34:06 UTC, H. S. Teoh wrote:

> what I had in mind was what Walter said about leveraging the existing language instead of adding new features.  My thought was to introduce new syntax that maps to the current template implementation (recursion, etc.):

That means changing the langauge.

> new syntax won't significantly add to the weight of the language since you're not defining new semantics.  This solves the writability / readability problem.

It's debatable of that won't add to the weight of the language.

>  Then the next step is to improve the implementation, so that it benefits both existing template code and, by extension, the new syntax. This would solve the performance issue, or at least address it.

Sure, if there is any theoretically sound way to extract a monomorphic iterative form out of a polymorphic recursion in O(1).
And when you have found it you _just_ have to implement it, correctly.

> Or maybe a more sensible approach is to implement a template optimizer with the current language, that optimizes certain patterns into iterative code, then at a later point introduce primitives that let you access this iterative code directly.

So you are saying first introduce type functions to be used under the hood an later on make them available?

On Thursday, 24 September 2020 at 14:36:45 UTC, Stefan Koch wrote:
> Let me show you the code that does only typeid.name

What if TypeInfo was templated instead of magically generated? So the compiler doesn't need to do all this stuff.

On Thursday, 24 September 2020 at 15:54:55 UTC, Adam D. Ruppe wrote:
> On Thursday, 24 September 2020 at 14:36:45 UTC, Stefan Koch wrote:
>> Let me show you the code that does only typeid.name
>
> What if TypeInfo was templated instead of magically generated? So the compiler doesn't need to do all this stuff.

You still have to instantiate all those templates and do it correctly.
Which means the compiler needs some way of exposing all the information via the templates system.

Which essentially requires the same code.

On Thursday, 24 September 2020 at 15:57:03 UTC, Stefan Koch wrote:
> On Thursday, 24 September 2020 at 15:54:55 UTC, Adam D. Ruppe wrote:
>> On Thursday, 24 September 2020 at 14:36:45 UTC, Stefan Koch wrote:
>>> Let me show you the code that does only typeid.name
>>
>> What if TypeInfo was templated instead of magically generated? So the compiler doesn't need to do all this stuff.
>
> You still have to instantiate all those templates and do it correctly.
> Which means the compiler needs some way of exposing all the information via the templates system.
>
> Which essentially requires the same code.

Oh and typeinfo has to be generated eagerly!
Whereas the current way it works with ctfe is lazy.
Which means as long as nothing else requires typeinfo, using it at CTFE does not require you to generate it.
So code that only uses type info at ctfe does compile with -betterC.

On Thursday, 24 September 2020 at 15:57:03 UTC, Stefan Koch wrote:
> Which essentially requires the same code.

But only once (as trait) instead of three times (trait, RTTI, CTTI).

On Thursday, 24 September 2020 at 15:59:51 UTC, Stefan Koch wrote
On Thursday, 24 September 2020 at 15:59:51 UTC, Stefan Koch wrote:
>
> Oh and typeinfo has to be generated eagerly!
> Whereas the current way it works with ctfe is lazy.
> Which means as long as nothing else requires typeinfo, using it at CTFE does not require you to generate it.
> So code that only uses type info at ctfe does compile with -betterC.

So, to confirm:

1) type functions, as proposed, will work with -betterC? and, related

2) type functions leave no footprint in .o files?

On Thursday, 24 September 2020 at 15:59:51 UTC, Stefan Koch wrote:
> Oh and typeinfo has to be generated eagerly!
> Whereas the current way it works with ctfe is lazy.

Eh, if it is unreferenced except at CTFE the linker can strip it from the binary (the ctfe functions of course would have to be marked as discardable/ctfe-only)

I'll try to make a test in library later when I'm free. I'm barely able to type these emails and chat messages while holding the baby, lol two-handed typing is more important to programming than I like to admit.

On Thursday, 24 September 2020 at 16:18:22 UTC, Bruce Carneal wrote:
> On Thursday, 24 September 2020 at 15:59:51 UTC, Stefan Koch wrote
> On Thursday, 24 September 2020 at 15:59:51 UTC, Stefan Koch wrote:
>>
>> Oh and typeinfo has to be generated eagerly!
>> Whereas the current way it works with ctfe is lazy.
>> Which means as long as nothing else requires typeinfo, using it at CTFE does not require you to generate it.
>> So code that only uses type info at ctfe does compile with -betterC.
>
> So, to confirm:
>
> 1) type functions, as proposed, will work with -betterC? and, related
>
> 2) type functions leave no footprint in .o files?

1 and 2 confirmed!