[plt-scheme] quasiquote confusion with printable<%> interface

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Wed Dec 9 13:46:46 EST 2009

Dare I suggest that things that are reader macros should not be
allowed to be rebound lexically?

Robby

On Wed, Dec 9, 2009 at 12:15 PM, Ryan Culpepper <ryanc at ccs.neu.edu> wrote:
> Sam TH wrote:
>>
>> On Wed, Dec 9, 2009 at 12:41 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>>>
>>> At Wed, 9 Dec 2009 10:44:16 -0600, Robby Findler wrote:
>>>>
>>>> Oh boy! That's a subtle bug! I think that explains what Todd was
>>>> seeing. unqoute was being locally shadowed (as a field).
>>>
>>> Yes.
>>>
>>>> Perhaps inherit field should have signalled an error that unquote
>>>> wasn't in the superclass?
>>>
>>> No, it's worse. The problem is that `unquote' became the local name for
>>> `name' as inherited from the superclass. That is,
>>>
>>>  (inherit-field [unquote name])
>>>
>>> means "inherit `name', but locally bind it as `unquote'".
>>
>> Here's an idea: `syntax-parse' could, at least in some cases, reject
>> syntax-lists created by `quote', `quasiquote', and `unquote' when they
>> appear in places that list structure was explicitly specified.
>>
>> Ryan, would that work?
>
> That test would be fragile, since it involves checking source locations,
> which aren't always available. I also dislike the idea of macros making
> distinctions based on lexical syntax.
>
> Ryan
>
>


Posted on the users mailing list.