reflection based on my experience so far on compile-time meta-programming in D as a novice user: the problems

[H. S. Teoh]

On Tue, Sep 15, 2020 at 01:44:25AM +0000, mw via Digitalmars-d wrote:
> On Tuesday, 15 September 2020 at 00:41:12 UTC, H. S. Teoh wrote:
> > 
> > If you already have these declarations, what's the purpose of
> > "generating" them?  Just curious if there is a reason for this, or
> > this is just some arbitrary decision?
> 
> The is the same usage pattern to call hundreds of such TA_xxx
> functions, i.e.
> 
> -- check the input params
> -- calculate TA_xxx_lookback
> -- call the raw C func
> -- zero out the lookback area
> -- return status

Sounds like the code example I wrote would work.  It's not *that*
complicated, really, it's just grouping the input arguments based on
some criterion.

If that's not desirable to you for whatever reason, then just write a
string function to generate the code and mix it in.  Or better yet --
and this is actually my preferred approach if I were to do hundreds of
such TA_xxx functions -- write a D program that parses some input file
(perhaps even the C header itself, if it follows a simple to parse
format) and generates a .d file.

As I said, the heavy metaprogramming machinery in D is really intended
more for D code that would benefit from compile-time type information,
manipulation of type lists, and CTFE computations.  It's not really
intended to generate arbitrary token strings.  Past a certain point, IMO
it's no longer worth the trouble to try to do it all in one compile
pass; just write a helper program to parse the input data and generate D
code into a .d file, and import that.  You'll have the benefit of faster
compilation (only need to generate the .d file once, assuming the C
library isn't constantly changing), and being able to read the actual
generated code in case something goes wrong and you need to debug it.
Debugging a deeply-nested mixin string buried deep in multiple layers of
templates is Not Fun(tm), and unless you have some special needs that
require that, I don't recommend it.  It's also faster for a D program to
read data and do whatever transformations you fancy on the string
representation, than to do all of that in CTFE/templates at compile-time
anyway.  Plus, you get to even unittest your generation code to ensure
there are no regressions -- which may be a LOT harder to do deep inside
nested templates and mixins.

In my own projects, I often write little helper programs to do exactly
this sort of transformation.  In fact, in one project I even used the C
preprocessor to transform a C header file into D code. :-D (It had a
specific format with specific macros that can be redefined to emit D
code instead of C -- and it so happened to be exactly what I needed.)
With a proper build system, none of this is anything special, just a
routine day's work. (Off-topic rant: this is why I can't abide dub. It
wants me to jump through hoops to do something I can do in 3 lines with
SCons. No thanks.)  Like I said, use the right tools for the right job.
If heavy metaprogramming machinery isn't cutting it for you, then use a
string function to generate code. Or use the C preprocessor. Whatever
gets your job done with a minimum of fuss.


[...]
> I'm wondering if Paul, Steven, and you have time each to summit a
> proper working PR, and we ask the forum users to vote which one is
> most readable, and maintainable; and which one is most fragile? :-)

Sorry, I have very limited free time, and I've already spent enough time
to elaborate on a solution that, really, ought to be obvious to anyone
who has spent some effort to learn and use D's templating system.  I'm
really not inclined to spend any more time on this, sorry.  But now you
have at least 4 different approaches to weigh to find one that works
best for you.  Try them out and see how they work out in practice, and
let us know about it.  Who knows, maybe you might even come across
something worthy of a DIP that will improve the state of D's
metaprogramming capabilities. ;-)


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom