[m-dev.] proposal: add uuid module to the standard library

Julien Fischer jfischer at opturion.com
Sat Oct 31 17:51:23 AEDT 2020


On Sat, 31 Oct 2020, Peter Wang wrote:

> On Sat, 31 Oct 2020 17:22:09 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> 
>> 2020-10-31 17:18 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
>> > We do have a uuid module in Prince but all it does is generate random
>> > UUIDs by reading from a cryptographic RNG (which is platform specific)
>> > and knocking out the relevant bits, and converting the uuid to a string
>> > or byte array representation.
>> 
>> Julien's module does that too.
>
> (The glue code to read from a cryptographic RNG needs to be supplied.)

Yes, you need to supply a random number generator.

>> > I'm not sure why anyone ever needs to
>> > inspect the internal structure of a UUID.
>> 
>> I don't either. But if the structure is published, then I see no point
>> in hiding it either.
>
> If no functions were provided to inspect the internal structure then a
> simpler representation could be used, e.g.
>
>    :- type uuid
> 	--->	uuid(string).
>
> where the string is in a canonical format. This would remove quite a lot
> of code.

It also seems a bit heavyweight, with argument packing the compiler
ought to be pack uuids into two 64-bit words or four 32-bit ones.

> But perhaps there is some reason to maintain a specific ordering of
> UUIDs.

There are multiple ordering used in practice; lexicographic seesm to be
most prevelant so that's what I went with.

Julien.


More information about the developers mailing list