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.
Ron
On Tuesday, February 26, 2019 at 3:36:57 PM UTC, Dominik Tornow wrote:
Hello,
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