[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.