Use Series{T,N} instead of SeriesN{T}

[kmsquire]

In generate type, you generate each type programmatically, attaching the size to the name via string concatentation. Why not just define the type as Series{T,N} or Series{N,T} instead? Each different N and T define a distinct type, and you do this already for AbstractSeries.

There may be good reason to do things the way you are, in which case, please feel free to close this.

[jwmerrill]

Is it possible to have different fields for a set of parametric types? Series1 has two fields, c0, and c1, Series2 has three fields, c0, c1, and c2, and so on.

I initially hoped to have things as you suggest, but couldn't figure out how to do it, and ended up copying some ideas for the current design from https://github.com/twadleigh/ImmutableArrays.jl

[kmsquire]

That's a good question. Other than changing c to an array, I thing the answer is no, but could you pose the question on julia-dev? Even if it isn't possible, it's good to let the main secs know someone is looking to do this.

[jwmerrill]

I am intentionally not backing these series by arrays because the most useful truncated series are short ones, and I would like to avoid allocating lots of small temporary arrays. I want these series to be practical computing tools, so I'm shooting for zero overhead compared to what you could write by hand for the same computation--or as close as possible.

I'm busy fiddling with README.md right now, then I'd like to make a general announcement of the package, and then I'll ping the dev list.

[kmsquire]

Seems reasonable to me.

it's good to let the main secs know someone is looking to do this.

"main secs" => "main devs" (autocorrect...)

[jwmerrill]

Closing as currently impossible, to the best of my understanding.