[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[tlaplus] Specifying an arbitrary function and then using it in TLC
In https://groups.google.com/u/1/g/tlaplus/c/jnlmYhh4jmo/m/HTGFDZimCAAJ, when asked about a generic hash function in TLA, Ron Pressler wrote:
> Unless what you're specifying is at the level of the hash function itself, you might be > thinking about this at too-low a level. If the algorithm you're specifying should work with
> any hash function, make that a part of your specification: ∃ hash ∈ [Source → Bits].... If
> there are other requirements on the hash, add them to the quantifier.
Which is a lovely high-level way to specify that such a function exists. I'm facing something similar in a toy spec I'm trying to write for a transpiler, where I can say there exists such a function mapping instructions on architecture A to those on Architecture B, something like ∃ TranslateFn ∈ [INSTRUCTIONS_A → INSTRUCTIONS_B]. Good so far.
I'd like to use that function in a TLC model, but just using the existential quantifier doesn't expose TranslateFn. So the next thing that looks right is TranslateFn == CHOOSE f ∈ [INSTRUCTIONS_A → INSTRUCTIONS_B] : TRUE , because I don't care what that function is, just that there is one and that I can use it.
But won't that ask TLC to (senselessly?) explore the whole space of possible mapping functions? If so, is there a way around that?
Cheers; still learning (slowly...)
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/df467f71-77d1-4bed-a83c-d126d5da226fn%40googlegroups.com.