[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