You could try adding ' * frame' to the problematic assumption. Here frame is a variable. -- Magnus<br><div class="gmail_quote"><div dir="ltr">On Thu, 3 Nov 2016 at 07:45, Ramana Kumar <<a href="mailto:Ramana.Kumar@cl.cam.ac.uk">Ramana.Kumar@cl.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Hi Magnus,<br class="gmail_msg"><br class="gmail_msg"></div>The proof in ioProgLib does not work on the translator-cf-basic branch, so I don't want to merge it into master yet. I tried fixing it, but it's not a trivial fix, and you might like to comment on the strategy. The problem stems from the "junk" references that the translator now must assume that any constant declaration might produce.<br class="gmail_msg"><br class="gmail_msg"></div>In ioProgLib, you prove lemmas (like raw_evaluate_prog) of the form:<br class="gmail_msg">(CHAR_IO * one FFI_split * STDIN input * STDOUT [])<br class="gmail_msg">     (st2heap p (auto_state_2 ffi)) ⇒ ...<br class="gmail_msg"></div>The heap predicate there is simply taken from the specification of the main program. The problem is that this assumption is no longer true. The heap of auto_state_2 also includes the junk references. So this lemma becomes useless.<br class="gmail_msg"><br class="gmail_msg"></div>What we do have is a lemma of the form:<br class="gmail_msg"><div class="gmail_msg">|- ∀h_i h_k st.<br class="gmail_msg">     SPLIT (st2heap p st) (h_i,h_k) ⇒<br class="gmail_msg">     (CHAR_IO * one FFI_split * STDIN input * STDOUT []) h_i ⇒ ...<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Previously, you would instantiate h_i with the whole auto_state_2 and h_k with the empty heap. Now we need to figure out how to extract the junk references to put them into h_k. Do you have any ideas? I guess I could start with st2heap p (auto_state_2 ffi) and the delete the junk...<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">For more clarification of what auto_state_2 contains, here is what I get from EVAL:<br class="gmail_msg">store2heap (auto_state_2 (io_ffi input)).refs =<br class="gmail_msg">   Mem 0 (W8array [0w]) INSERT<br class="gmail_msg">   store2heap_aux 1<br class="gmail_msg">     (... ++ ... ++ stack_remove_max_stack_alloc_refs ++<br class="gmail_msg">      stack_remove_stack_err_lab_refs ++ stack_names_x64_names_refs ++<br class="gmail_msg">      stack_names_arm_names_refs ++ lab_to_target_ffi_offset_refs ++<br class="gmail_msg">      basisprog_basis_refs ++ x64_dec_fail_refs ++ x64_config_refs ++<br class="gmail_msg">      init_env_refs ++ prim_config_refs ++ x64_compiler_config_refs)<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This problem blocks the translator-cf-basic merge. I don't know if you envisioned generalising more of the contents of ioProgLib, or whether it's already considered in a good state... I would think ideally the main theorem would follow more directly from what comes out of CF...<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,<br class="gmail_msg"></div><div class="gmail_msg">Ramana<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div>
</blockquote></div>