At Fri, 6 Feb 2009 17:47:23 -0500, Ryan Culpepper wrote: > > On Feb 6, 2009, at 5:32 PM, Matthew Flatt wrote: > > > At Fri, 06 Feb 2009 14:10:54 -0500, Dave Herman wrote: > >>> Unquote for the value part of a `#hash' could work. I'm less sure > >>> that > >>> it's a good idea for the key position, since the reader constructs a > >>> hash table. > >> > >> Good point. For example: > >> > >> (define table > >> `#hash((,(read) . foo) > >> (,(read) . bar) > >> (,(read) . baz))) > >> > >> The reader constructs a hash with a single entry whose key is the > >> S-expression (unquote (read)), and it's too late for `qq' to > >> reconstruct > >> the source. > >> > >>> Aside from the possible constraint on keys, it's not so much a > >>> reader > >>> issue as a question of what the `quasiquote' macro recognizes. The > >>> source of `quasiquote' is "collects/scheme/qq-and-or.ss". > >> > >> I've mostly implemented this on my machine. I can submit a patch, but > >> which behavior do you prefer? > >> > >> 1) qq leaves the key position quoted and interprets the value > >> position. > >> 2) qq errors on any occurrence of `unquote' in a key position. > >> 3) scrap this whole extension and leave `qq' as is. > > > > I like 2. It seems like a sensible and useful extension. The change > > could potentially break some old code, but that seems unlikely.
Oops --- I meant to vote for "1", not "2". > Doesn't that mean that some hash tables that should have literal > representations won't? Yes, at least in terms of quasiquote. That's a good reason against 2.
