[m-users.] Random Number Generator

[Mark Brown]

Hi all,

On Tue, Aug 1, 2023 at 6:06 PM Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Montag, dem 31.07.2023 um 23:28 +1000 schrieb Zoltan Somogyi:
> > This does bring up what I think is the root issue raised by the original
> > question, which is: given that the urandom type class could be designed
> > without this extra argument (since its instances could include
> > the info that is now in the extra argument in the rng state instead),
> > why wasn't that design chosen?

The question I started with was, why would a programmer choose a
polymorphic vs monomorphic interface?

You'd want a polymorphic interface because you don't want to commit to
a particular RNG. For that reason I've aimed for a good trade-off
between flexibility and runtime cost (I didn't consider lexical cost
to be a high priority). The extra argument allows code that is
polymorphic across three kinds of generator: a dummy type and an
array, a mutvar and an I/O state, and a user-defined key/store
arrangement with a unique store (like in the store module).

You'd want a monomorphic interface if you're happy to commit to a
particular RNG. The benefit is a bit less overhead, and an interface
that is more relevant.

I didn't see a particularly good benefit in a medium-generality
interface that is polymorphic over just the first kind of generator. I
do see a cost in having more interfaces, however.

>
> Yes, that's what I was wondering. And if it was possible to get rid of that
> extra argument.

You can use one of the submodules directly.

Cheers,
Mark

>
> Cheers
> Volker
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users