[m-users.] The new random module(s)

[Mark Brown]

Hi,

On Thu, Sep 5, 2019 at 4:09 PM Julian Fondren <jfondren at minimaltype.com> wrote:
>
> On 2019-09-05 00:17, Mark Brown wrote:
> > Since you are using this module, can I ask your opinion on how long to
> > keep the old implementation around? Removing it will force people to
> > update their code sooner, but will also free up the namespace so we
> > can add a new version of random.permutation/4.
> >
> > Or we could add them now, both to the random module, if the names are
> > changed to permute_array and permute_list.
>
> It seems weird to me that the predicate is random.permutation/4 at all,
> and not list.permutation/4.

Probably the word "random" should appear in the name somewhere, if
it's not in the module qualifier.

> In the permute_array/permute_list future,
> will permute_X be added for other data structures?

I wasn't planning to. Permutation is (mathematically) usually only
defined for sets and sequences so I'm not sure what you'd be expecting
for other library types. I suppose there could be a set permutation
predicate that returns a randomly ordered list of the elements.

In my view, the reason to put them in the random module is that they
are more related to each other, and to the other predicates that do
random stuff, than they are to predicates that merely work on lists or
arrays. But no matter, I can add list.random_permutation now unless
anyone else wants to add their opinion?

(array.random_permutation ought to wait until the old RNG has been
sufficiently obsoleted. Note that I have only obsoleted the
random.init predicate as that is sufficient to produce a warning, and
declaring all predicates of the old implementation to be obsolete
would only result in getting multiple warnings for essentially the
same issue. I'll make that clearer in the docs for random.init.)

> And will random then
> have to occasionally contain duplicate code (or import secret parts of
> module interfaces) so that it can efficiently access underlying data
> structures to do these permutations?

No. For sets, as an example, I would convert to a sorted list then
randomly permute that.

>
> And permute_X seems like an odd naming scheme when Mercury is fine with
>
>    ...
>    permutation(!X, !RS),  % !X is an array
>    permutation(!Y, !RS),  % !Y is a list
>    ...
>
> if these refer unambiguously to permute/4 of two separate modules with
> different types.

Sure. I suggested alternative names in case they were in the random
module together, and not in separate modules.

>
> As for how long to keep the old code, mainly I wouldn't want to put "you
> need to get a ROTD between these two dates" in a README. But that could
> only happen after at least one more breaking change, or if I couldn't
> avoid a bug that was fixed after a breaking change.

It's not intended that the old and new generators be used in the same
code. As you say, we need to add predicates to replace
random.permutation and array.random_permutation to avoid that. I just
need two names that don't clash with existing names or concepts, then
I can add the predicates now.

So what's the choice?

1. Add random.permute_* (or whatever) now.
2. Add list.random_permutation and make a backwards incompatible
change to array.random_permutation now.
3. Add list.random_permutation now, but wait before changing
array.random_permutation.

BTW, thanks for trying out the new code, Julian.

Mark