D's memory-hungry templates

[tsbockman via Digitalmars-d]

On Thursday, 9 June 2016 at 22:03:36 UTC, Alex Bradbury wrote:
> On Thursday, 9 June 2016 at 14:46:12 UTC, tsbockman wrote:
>> Ultimately, I believe it was a mistake for D to implement a 
>> separate, inferior programming language just for templates. 
>> However, it is too late to change that now (at least for D2), 
>> so I will offer some suggestions as to how memory consumption 
>> can be reduced within the current design:
>
> If you have a design in mind, I'd be interested in hearing your 
> proposals for an alternative.

I have an incomplete design for a new programming language, and 
the beginnings of a proof-of-concept implementation (written in 
D). It was inspired mainly by D and Lisp, with goal being to 
distill the power and performance that D strives for down into a 
language that is much closer to the simplicity and conceptual 
purity of Lisp.

The project is still at a very early stage, and I haven't decided 
yet how serious I am about completing it, but I'll give you a 
brief sketch anyway:

* Very simple syntax, with the goal that a person should be able 
to easily visualize the resulting AST. Inspired by Lisp, but with 
a little extra complexity to keep people from getting Lost In a 
Sea of Parentheses.

* statically typed

* functional, but not pure - mutability and global state are 
permitted

* what D calls a template is really just a function

* symbols, AST nodes, functions, templates, and data types are 
all regular values which can be manipulated via normal code

* function call syntax explicitly (and concisely) indicates 
whether to evaluate the call at compile-time, run-time, or 
whenever

* currying: evaluating a function with some, but not all, of its 
parameters returns another function that can later be fed the 
rest of its parameters

* currying a function at compile-time and then calling the result 
at run-time is equivalent to instantiating and calling a template 
function in D

* most complex features, such as polymorphic classes, lambdas, 
reified generics, inlining, tail recursion, and string mixins can 
be implemented in the standard library

The above approach to meta-programming would be vastly simpler 
than what D has done, and offer much better compile-time 
performance if implemented sensibly. (I also have other ideas 
about managing memory, mutability, and multi-tasking, as well, 
but they're off-topic and less fully formed.)

For D itself, though, we must work with what we have. I think the 
suggestions I gave at the beginning of this thread, combined with 
the CTFE system upgrade that Stefan Koch is working on, would 
bring huge improvements to D's compile-time performance.