Operational semantics in K

[Ayberk Tosun]

Our primary goal is to implement the operational semantics in K. The following rules from the Eisenberg spec need to be implemented.

• S_Var
• S_App
• S_Beta
• S_Push
  • Deferred for now.
• S_TPush
  • Deferred for now.
• S_CPush
  • Deferred for now.
• S_Trans
  • Deferred for now.
• S_Cast
  • Deferred for now.
• S_Tick
  • Deferred for now.
• S_Case
  • Consider how this plays with S_LetRecCase.
• S_MatchData
• S_MatchLit
• S_MatchDefault
• S_CasePush
  • Deferred for now.
• S_LetNonRec
• S_LetRec
  • We should decide how to implement the modification of Σ.
• S_LetRecApp
• S_LetRecCast
  • Deferred for now.
• S_LetRecCase
  • We might need to discuss this further.
• S_LetRecFlat
  • We might need to discuss this further.
• S_LetRecReturn

[Ayberk Tosun]

To implement S_Var, I and @lucaspena considered the following rule:

// S_Var
rule
  <k> tmVar(_, name(R)) => E ... </k>
  <store> ... L |-> thunk(E, _) ... </store>
  <env> ... R |-> val(L) ... </env>

Does this seem correct to you @bmmoore ? Do we need to do something else for data constructors or closures? How would you implement this S_Var rule from the Eisenberg document?

[bmmoore]

You need to use the saved environment while evaluating the thunk, and include something to update the store with the result. For values that have already been forced, I think just evaluating to val(L) is correct. Indirection in the store may need to be handled.