Closed jstolarek closed 7 years ago
It seems that with exceptions tracing has just become a major pain. On paper we need a new tracing construct for let (because exception can be raised in a binding) but in reality this means we need a new tracing construct for every expression that consists of more than one unconditional subexpression. This includes: assignment, sequencing, pairs and application. I'm also having trouble figuring out how to handle operators. Say I have raise "foo" + 2
represented as EOp OpPlus [ERaise "foo", EInt 2]
. What should a trace look like for this? My guess would be TOp OpPlus [TRaise "foo"]
but this means I now have OpPlus
applied to incorrect number of arguments.
Looking at the rules I think that instead of creating new constructs I could just insert holes as traces of expressions that weren't executed. So let_F T_1
from the paper would be encoded as TLet t1 x THole
. Does that sound reasonable?
Yes, I think putting holes in for subtraces that do not execute is reasonable. Alternatively we could make the potentially-missing subtraces Maybe
, but this would be more verbose and I'm not sure whether this distinction matters. Alternatively one could add a trace form "Missing" for such subtrace components if we want to distinguish them from holes.
TODO:
writes
(Fig. 4)lub
for new language constructspslice
for trace slicingCleanup
pslice
tobwdslice
. Also rename the primitiveVStar
can only be introduced in an environmentThis is a note-to-self ticket.