Bengt,
> would it be beneficial to have the use of and output of the generated
> random source, as in (make-random-source) => s, described?
> ie, to make it possible for somebody else to generate random floating
> point numbers from s it is neccessary to know what the output looks
> like (say 0 or 1, or #t or #f), and how to get it (say (s 'bit)).
>
> i admit that this kind of thinking would (ultimatly) lead to the
> removal of all but one, (random-source? s), of the random-source
> procedures and their replacement by
>
> (s 'randomize)
> (s 'state)
> (s 'state new-state)
>
> but i still think that the question is worth asking.
The question certainly is worth asking!
In fact, your proposal is more or less what I have started with.
It has the advantage that there is only one object that you
have to maintain in your application instead of two (a random-source
object and the actual generator procedure) in the SRFI proposal.
The disadvantages are that you are introducing a *certain*
object-oriented way of using random sources and that it can
be difficult for Scheme systems to implement it because
you require typed procedures. (How does random-source? know
this procedure is a random-source procedure?)
For this SRFI my intention was to stay away from any specific
type of object-oriented framework. This implies that the only
way to deal with objects are procedures make-xyz xyz? xyz-ref
xys-set! etc. However, for what I call the "no fuss"-interface
it is necessary to just have a generator procedure. And there
you go with two related objects.
In the sense of the SRFI, a 'random source' is an opaque object
that provides you with random bits---but the only way to get
these random bits is to create a generator procedure for a
certain type of data (integers, uniform reals, permutations,
whatever) and use this generator. Hence, there is a portable
way to get other types of random objects from a random source.
There is no way, however, to fiddle with the internal workings
of the generator.
For the next revision I have put the topic on my list
to discuss.
Sebastian.