search

haskell-numerics / random-fu

A suite of Haskell libraries for representing, manipulating, and sampling random variables
42 stars 21 forks source link

Resolve status of 'Prim' #1

Closed mokus0 closed 13 years ago

mokus0 commented 13 years ago

I've done a fair amount of work to re-base the random-source system so that it is no longer necessary to use the 'Prim' interface to define a RandomSource or MonadRandom instance. In some cases it is still currently convenient to do so, and for that reason the low-level API is exposed through an "Internal" module. I have no problem with that; anyone that imports a module with that name should have a pretty clear understanding that future changes very well may break their code.

What I need to resolve for myself, though, is what the status of 'Prim' should be throughout the rest of the API. Presently I see a couple options:

  1. It goes away entirely (or becomes strictly internal, with the understanding that it could go away at any moment).
  2. It becomes a part of the 'rvar' public interface. I'm leaning toward this option.

I'm not at all convinced that these are all of the reasonable options, or even that all of these options are reasonable. I don't even know what the relevant concerns are right now. Concerns I can think of right now:

  1. Forwarding instances: currently the main reason for importing the internal code is as a quick and dirty way to forward instances (e.g., in Data.Random.Source.IO or Data.RVar). The TH interface currently has some undesirable qualities for this purpose.
  2. Types of 'runRVar', 'runRVarT', etc. Presently the ones in Data.RVar use a (Prim a -> m a) callback, which is a nice way to think of the operation but has the practical drawback that additions to Prim will break all code using it. Possible solutions I can think of include changing it to be more like Data.Random.RVar or providing a TH solution for declaring Prim a -> m a functions, which would probably be a good idea anyway within the current system, because the logic that does that now should probably be separated from the instance-construction logic anyway.
mokus0 commented 13 years ago

I think I'm OK with things as they stand right now; Prim is a primarily-internal construct used mostly by rvar to do its magic. With the latest commits it is no longer exposed in any public API (as far as I know), so anyone that makes use of it should know that they are playing with internal stuff that is subject to change (or even disappearance).