As Alexis notes, getting the arrows right in general is tricky. But `block`
is also currently buggy in that it does not expand to `#%expression` when
not in an expression context. (`block` is buggy in at least one other way
as well, but that needs a deeper fix:
Wow, so block is currently buggy?!
On Sun, Jun 7, 2020 at 3:31 PM Michael Ballantyne <
michael.ballant...@gmail.com> wrote:
> Hah! You're right. The arrow points to the inner definition. But it's even
> worse than that---the value comes from the outer definition! At least for
> `block`, which is
Hah! You're right. The arrow points to the inner definition. But it's even
worse than that---the value comes from the outer definition! At least for
`block`, which is what I'm testing with as I haven't copied down your code.
Try this:
#lang racket
(require racket/block)
(define-syntax-rule
Perhaps I missed something, but the error in the first example is because
there’s no expression at the end of let. If I use this code instead, it
seems to work fine, with the arrow of m pointing to the “new” one.
(define-syntax-rule (m) 'old)
(let ()
(list+ (m))
(define-syntax-rule (m) 'new)
> I am unable to come up with a program where this difference is
significant though
Here's an example:
(define-syntax-rule (m) 'old)
(let ()
($list
(m))
(define-syntax-rule (m) 'new))
> So I am curious why internal-definition-context-track is needed.
A similar example shows the need
Thank you so much, Michael! This is very helpful.
I can see that when this form is used within another internal definition
context, then my version and your version will expand in different order,
and I agree that yours makes more sense. I am unable to come up with a
program where this difference
6 matches
Mail list logo
