[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[tlaplus] Re: UUID

I would say it does, and on two levels:

1. It is not definable (with the same behavior) as a mathematical _expression_.
2. It misses the point as it relies on particular implementation rather than capturing the essence of what you'd expect from a specification of UUID (i.e., a universally unique value, which could be expressed as CHOOSE).

Having said that, sometimes we do want to compromise, especially when working with TLC (and the TLC module does contain several non-mathematical, but useful, operators), but in light of point 2, you need to ask yourself why must you rely on a low-level implementation detail.


On Tuesday, February 26, 2019 at 3:36:57 PM UTC, Dominik Tornow wrote:


I have a rather "philosophical" question: For my specification I created a TLA+ UUID extension:

import tlc2.value.StringValue;
import tlc2.value.Value;

public class UUID {

    public static Value UUID() {
        return new StringValue(java.util.UUID.randomUUID().toString());

Sample output from "Evaluate Constant _expression_"

UUID -> "f06b120c-2c66-40b1-a025-dc8479436fa9"
UUID -> "06d6291d-4792-4666-87e4-06eb44c25270"

By design, the operator never yields the same result. I believe this is different from CHOOSE that given the same set and predicate will yield an arbitrary yet always the same result.

The specification and the operator work as expected. However, I wonder if that operator violates "the spirit" of TLA+

Thanks and best, Dominik

You received this message because you are subscribed to the Google Groups "tlaplus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to tlaplus@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/tlaplus.
For more options, visit https://groups.google.com/d/optout.