Ya. But speeds are rather different.
I admittely missed a comparison with Umacs in my short demo.
However, from some early experiments (I'm doing while I'm writing), as
I suspected, my approach results being many times faster than Umacs,
even if one doesn't specify samplers as C code. Things goes even
better for my demo implementation if one tries to plug in samplers
specified as pure C code, which would further eliminate a lot of
memory allocations/deallocations behind those "rnorm()".
My aim is to obtain something which achieves decent speed, compared
with JAGS. I mean, I can easily experiment new samplers by using an
interpreted language, but if at the end I obtain something which is
*many* times slower than JAGS (which is moreover much more robust and
easier to work with), the whole stuff results being of little pratical
interest.
More: how can one really experiment a new custom sampler if doing some
thousands iterations takes forever, so that checking your sampler
pratical behaviour is a pain (I speak about my personal experience)?
That's why I want to always keep attention on speed, and give the
possibility to the user to either use R or C code at his choice, with
the ability to modify model node values in place, without unneeded
'malloc's. Ya, I would abandon pure functional style...