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

Re: [tlaplus] Specifying an arbitrary function and then using it in TLC



CHOOSE is arbitrary but deterministic choice. In other words, with your definition, TLC will generate one function (likely a very trivial one, perhaps mapping every instruction of A to the same instruction of B) and explore the spec for that particular function. If you want to explore the spec for every possible function, make the mapping a variable of your spec, add

translateFn \in [...]

to the initial condition and UNCHANGED translateFn to all actions. And if you want to play with different hand-picked functions, add a CONSTANT TranslateFn to your module and write

ASSUME TranslateFn \in [...]

then you define the particular function in the model. What is the right way to go depends on whether you want to explore if your transpiler works for some fixed function, for all functions or for some specific ones.

Stephan

On 25 Nov 2020, at 19:11, Vic Putz <vbputz@xxxxxxxxx> wrote:

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.

--
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/32D3FDF4-6067-44C3-97E3-77595B362A48%40gmail.com.