On Saturday, 6 June 2020 at 09:57:36 UTC, Jan Hönig wrote:
We have two (little) student projects, which should use D for
meta-programming/code generation.
More specifically string mixins and templates.
I understand (at least I think so :)) string mixins. The task
is to create a small internal DSL, which is capable of printing
out D code, which we then will use as a mixin. So basically
using CTFE to create code at compile time. (any additional
sources/ideas are welcome).
The second project considers templates.
My idea was to recreate some template expressions, like we all
know and love (hate) in C++.
However I am not so sure if that is a really good idea.
As far as I understood it, that is basically what ranges in D
do.
So this would just mean "code linear algebra with ranges",
which I am sure plenty of D's libraries do already (mir?).
(that doesn't mean, it is not a good learning experience for
the student).
I would love to hear some opinions on that matter.
D is pretty good for meta-programming. For certain other things
it is terrible. One of the key features of D is it's meta
programming.
String mixins simply mix in D code. It lets you build generic D
code. The big problem here is debugging. There is ZERO ability to
properly debug string mixins. Well, what it boils down to is
writing out the string mixin and then debugging that. Visual D
does have the ability to open up the output and one can try to
compile such things but it can be a pain for complex cases.
It would be nice if D had a special D code string that the IDE
could interpret properly.
Templates are just templates, just generic code. D is far better
than C++ and most other languages. Template are more than ranges.
Ranges use templates.
Templated code simply means generic code. E.g., rather than
working with specific integers you work with integer variables.
Generally the type of the variable is undefined it constrained
but otherwise unknown.
R foo(T)(T a)
R and T are types. We can call foo with any type, it no longer
requires overloading and all that. But if the code in foo depends
on specific types then it must be dealt with using various means
to constrain the type.
D basically tries to resolve things after the fact so
R add(T)(T a, T b)
{
return a + b;
}
this will attempt to + on a and b after the types are known. If
they can't be added then an error will occur, which is usually
cryptic for templates. When using templates one generally also
cannot debug them as easy. One might get a long error message for
simple issues. R above is deduced from type of a + b, which
probably would be a T.
So such a simple templated function, or generic function can be
used to add doubles, ints, floats, etc... anything with +
operator.
Further more there are more tools available such as passing
compile time parameters and such.
One can do quite a lot with D's string mixins and templates but
the biggest issue is error messages and debugging. Sometimes
things are not so easy to do with templates or require strange
workarounds, but otherwise probably 98% of all things can be done.
When one is working with generic types one has to learn more
machinery such as `is`, traits, etc.
The issue in using D should not be made based on it's
metaprogramming. It will be a mistake! Now, if the only goal is
to use D for it's metaprogramming then it is an excellent
choice... although there are other languages starting to compete
with D and functional languages probably offer better overall
cohesiveness if you want to go down the functional
route(ultimately there is little difference but the syntax and
some of the semantics seem vastly different).
D, IMO, is not capable of writing sophisticated programs... this
is why you do not see any. No one writes large commercial apps in
D. There is not one! The D ecosystems is poorly structured
compared to the top contenders. D is good for small apps,
utilities, etc. D can be integrated with other apps though but
then one loses some of the meta capabilities(since they won't
translate).
