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
(λ (k)
(with-continuation-mark 'errortrace-k (let ([here 'f])
(cons (if k (car k) here)
here))
f))))
Something other than a pair could keeps the first plus up to 5 most
recent calls. But then you'd probably want the errortrace annotator to
be a little smarter and not useless report syntactically enclosing
expressions, like a sequence of `begin`s in something like
(begin
....
(begin
....
(begin
....
....)))
Overall, your simple change seems clearly worth trying out in
errortrace, and maybe other variants would be interesting to explore.
Matthew
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/20200727072658.3df%40sirmail.smtp.cs.utah.edu.
