[plt-dev] #hash vs. #s

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.

Doesn't that mean that some hash tables that should have literal  
representations won't? What will the following code produce?

(define t (make-hash))
(hash-set! t '(unquote 5) 'value)
(let-values ([(in out) (make-pipe)])
   (parameterize ((current-input-port in)
                  (current-output-port out))
     (write t)
     (read)))

Ryan


> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev