At Thu, 27 Jul 2017 18:55:56 -0400, Jay McCarthy wrote:
> On Thu, Jul 27, 2017 at 5:00 PM, Matthew Flatt <
mfl...@cs.utah.edu> wrote:
> > It's strange that a mutable hash table is otherwise ok. The mutable
> > hash table in that case is getting coerced to an immutable hash table
> > as a convenience for some internal data in a bytecode form. Whatever
> > that use of a hash table, though, it's not supposed to have syntax
> > objects inside.
>
> That's strange to me because
>
> (define-syntax (m6 stx)
> (syntax-case stx ()
> [(_ x)
> (let ([ht (hasheq 'y #'x)])
> (quasisyntax (define-syntax x #,(foo #'x ht))))]))
> (m6 e10)
>
> works for me. (I expected the mutable thing to be coerced into an
> immutable thing. In the real code, the hash can only be modified
> during the initial construction.)
>
> Should I consider the answer to be that I need to stick to things that
> can be syntax literals without conversion?
I wonder whether that one (and some of the earlier examples) work the
way you're expecting. You'll get a symbol back if you later extract the
first field of the `foo` struct that's bound to `e10` --- not an
identifier.
In this example, the `foo` instance is being coerced to a syntax object
by `unsyntax`. The resulting syntax object is the same as
#'#s(foo x #hasheq((y . x)))
which, as an expression, self-quotes as a prefab struct containing a
symbol and a hash table mapping a symbol to a symbol.
So, that one is not 3-D code. Among your original examples, `m4` does
bind `e8` as 3-D code, but it (accidentally) gets converted to a
non-3-D code in the process of marshaling. None of the other working
examples are 3-D.