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.
