Carl A. B. Pearson

> > I think that makes this PR a no-go > > I was a bit surprised to see breakage. Which went away in the main branch. I haven't time...

Can do a PR for just converting macros => functions, sure. Then maybe draft something for one of the others, and see how it looks w/o (initially) super polishing it?...

Porting discussion from closed PRs #215 / #218 here: - any overhead reductions in digest need maintain code readability - better approach may be to introduce no-frills functionality What could...

Draft approach for a refactor that would allow users to skip some of the overhead optionally: https://github.com/eddelbuettel/digest/pull/220 - would appreciate some feedback there about those outlines before pursuing further.

In the broken up version of #220 - next step is #222. Pending feedback, this is essentially encapsulating all the algorithms. The next would be to register all of them.

> A split that I could see make sense (and perhaps what you meant initially, @pearsonca) would be one package (`socialmixr`) that does all the transformation from a survey to...

N.B.: I'm not super-pumped about the macro-based approach. I like it conceptually, but the actual language support is dicey in C and macros seem like the best (of bad) ways...

> Thanks for picking this back up. I have the ability to access C-level functions in a packages directly from other packages in a few places so this is surely...

> What were you thinking in terms of minimal input? Don't we always start from raw vector we get from the serializating function? Wouldn't that make it type-agnostic as we...

Got it, will have a look - but so should expect just shifting serialization to the C side will yield useful gain? Definitely much easier engineering lift. (and can be...