Let me jump in here and say a few things that maybe everyone already knows :).
The stepper’s annotation places a *ton* of annotation on a computation, and
allows the reconstruction of the full computation. Errortrace does less, and
provides less.
The both share a goal of allowing the programmer to see “where you are in the
computation”, by capturing “what remains to be done in the computation”, and
neither one tries to capture “how we got here”.
Specifically, in the (* (loop (sub1 n) n) expression, a mark on the application
of loop is currently overwritten immediately by the mark on the body of the
called function. In this case, the still-present mark on the multiplication is
telling you “this multiplication still remains to be done”, but in fact you’ve
lost important information on *which* of the subterms of the multiplication is
currently being evaluated. In the stepper, this is essentially converted to
a-normal form so that the mark isn’t just “the multiplication isn’t done yet”
but rather “the second argument hasn’t yet been evaluated.”
My understanding of your proposal is that it suggests preserving the first mark
that is associated with a continuation, rather than (or perhaps in addition to)
the last.
I do think that this could be helpful in some situations.
I also think that the fundamental problem that you point to in the beginning
isn’t one of what information to store, though, but rather how it’s presented.
Specifically, the presence of the mark around the multiplication captures the
following information: “we’re currently in a call to loop, and we’re evaluating
either the first or second argument of this multiplication”. I’m not sure what
a good way to present this information would be:
> in call to ‘loop’, at either (* [] n) or (* (loop (sub1 n) []).
yeah, that was terrible. Ugh. Surely someone can do better than that.
Anyhow, my point is that for the example that I believe you’re examining, the
information you want can be extracted from the information that’s present.
I would like to acknowledge though, that that’s definitely *not* always the
case; if you have a bunch of calls that only make tail calls, then you can
easily lose information about how you got here. I understand that from a
programmer’s standpoint, the question “how did we get here” may be more
relevant than “where are we now,” and I do think that it might make sense to
take the same approach that (IIRC) Andrew Tolmach & others took in the ML
debugger of saving a rolling sequence of up to five marks (or six or ten or
whatever you choose).
Put differently, I think that there is potentially a “lost information”
situation here, but I think that if you want to preserve that information, you
should do so by using a rolling buffer, rather than by supplementing “last
expression” with “first expression”.
More broadly, I also think that errortrace’s display of information is probably
not the best; I think it’s been a long time since anyone was thinking hard
about how best to convey the errortrace information to the programmer.
Apologies if I’m wrong about that.
AND, as always, apologies if I’m misunderstanding something important about
your proposal!
Best,
John
> On Jul 27, 2020, at 09:26, Matthew Flatt wrote:
>
> At Sun, 26 Jul 2020 20:21:56 -0700, Sorawee Porncharoenwase wrote:
>> I have been toying with another way to instrument the code. It roughly
>> expands to:
>>
>> (define-syntax-rule (wrap f)
>> (call-with-immediate-continuation-mark
>> 'errortrace-k
>> (λ (k)
>> (let ([ff (thunk f)])
>> (if k
>> (ff)
>> (with-continuation-mark 'errortrace-k 'f
>> (ff)))
>
> This variant probably generates faster code:
>
> (define-syntax-rule (wrap f)
> (call-with-immediate-continuation-mark
>'errortrace-k
>(λ (k)
> (with-continuation-mark 'errortrace-k (or k 'f)
>f
>
>
>> Now, the question: why is the current errortrace implemented in that way?
>> Am I missing any downside of this new strategy? Would switching and/or
>> integrating with the new strategy be better?
>
> I don't recall there was any careful study of the alternatives. Always
> setting the mark is easiest, and so that's probably why the current
> implementation always sets the mark. Maybe keeping the first expression
> for a frame instead of the last is consistently more useful.
>
> At Sun, 26 Jul 2020 20:39:35 -0700, Sorawee Porncharoenwase wrote:
>> (By "integrating" with the new strategy, I meant having two keys: one for
>> the new strategy and one for the old strategy. I can see that the first
>> entry of the old strategy is useful, and it's missing in the new strategy).
>
> Instead of a separate mark, `or` above could be replaced by some
> combinator that keeps more information in the mark value, such as a
> first and last call using a pair:
>
> (define-syntax-rule (wrap f)
> (call-with-immediate-continuation-mark
>'errortrace-k
>
