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

[mw]

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


> I don't understand this phobia of string mixins -- they were 
> included in D

I'm not phobia to string mixins; I'm saying that because Steven 
provide one such solution already (see summary 3 below), and pure 
string mixins solution is no different from C's macros solution 
(or use a Python script to output strings as generated D code).

> I'd say, the way I'd do it is to slurp the entire argument list 
> into a single variadic parameter, and handle the breakdown of 
> the parameter groups manually

I saw you method.

That's what I want to avoid, as the discussion with Paul earlier, 
because ...

> So now, what do with do with the arguments we received? 
> According to the above linked page, we have a list of start/end 
> indices, which I assume should come in pairs? (Correct me if 
> I'm wrong.)  At first I thought the number of pairs must match 
> the number of input arrays, but apparently I'm wrong, based on 
> your examples above?

to use a single variadic parameter and *then* break them down, 
you need extra assumptions on the different groups of actual 
parameters.

(1) we do NOT have so much assumptions on these groups of params, 
neither on each individual type, or the total number of them in 
each of the groups.

(2) even if we do have some assumptions, this kind of breakdown 
(a kind of simple parsing) code is fragile to maintain.

That's why I also asked Paul, is there any D Marker type I can 
use: i.e. split the single variadic parameter based on some 
Marker type.


> 	bool TA(string funcName, Float, Args...)(Args args)
> 		if (is(Float == float) || is(Float == double))
> 	{
> 		enum nPairs = NumPairs!Args;
> 		enum arraysStart = 2*nPairs;

As said, we don't have such assumptions to calculate the 
arraysStart index; let's just assume we have some other ways to 
calculate, this breakdown code is going to be more complex than 
you are showing in your solution.


So far, I've got 4 solutions:

1) my C-macros based solution,
https://github.com/mingwugmail/talibd/blob/master/source/talibd/talib_func.h#L139

#define MA_INS  int MA_optInTimePeriod, TA_MAType optInMAType
#define MA_OUTS outMA
DECL_TA_FUNC(TA_MA, MA_INS, MA_OUTS, (MA_optInTimePeriod-1))

Note: the input parameters are *logically* grouped, no need the 
breakdown parsing logic.


2) Paul's solution based on the same logical grouping idea as 
mine, but use D-template:
https://forum.dlang.org/post/nrziyhvdgkqvarlccmmf@forum.dlang.org

which I quoted to started this thread in general.


3) Steven's solution based on D string mixin
https://forum.dlang.org/post/rjoc7h$234g$1@digitalmars.com


4) your solution based on breakdown single variadic parameter.
https://forum.dlang.org/post/mailman.5794.1600130478.31109.digitalmars-d@puremagic.com


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? :-)