static map as a type function

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Sep 24 15:34:06 UTC 2020


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."


More information about the Digitalmars-d mailing list