[mercury-users] a typeclassful random.m

[doug.auclair at logicaltypes.com]

Dear Julien, we wrote:

>> I've been using Julian's typeclassed random.m, and I find myself
>> using the following pattern when typeclassing arguments of a
>> predicate:
>typeclassing?  (Why not just constraining?)

Sorry: s/typeclassing/constraining/.

>> [...]maillist have input, too -- is there a need to have the second
>> argument at all in the typeclass?
>Yes.
>> If so, what are the uses of the
>> second argument, and how would it be used practically.
>The second argument is the type of the seed of the random number 
>generator.  You use it practically by passing a value of that type
>to the seed method.

Okay, then -- here's my problem, I've added a seed method to a set
of general utilities that gives a RNG, so I just call that method with
the io state var and there after just use the RNG.  In short, I never
see the second argument (becaused it's masked behind the protocol),
and when I am using the RNG throughout the code, the constraints
seem "weird", as have all these '<= prng(RNG, _)" constraints on preds.

After the initial seed, can the second argument be dispensed with? In
my view, having all these don't care constraints on preds throughout
a system with only one use of the second argument (in main/2 -- and
that's only if one is not going with the provided tausworthe3 algorithm)
reduces the readability of code.  In the current system I'm building, 6
using modules have 13 constraints with a second don't care argument,
none have the second argument assigned.

Sincerely,
Doug Auclair

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------