John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> I think it would be very useful to specify external representation
>> (reader syntax) for hash tables, but I want to make sure I'm not adding
>> anything unreasonable to the spec.  External representation is a big
>> deal since it changes the lexical syntax.
>
> I think it's very important, if you are going to add lexical syntax,
> to comply with SRFI-108.  It doesn't have a lot of coverage yet beyond
> Kawa, but it is the first mechanism for extending Scheme lexical syntax
> (always excepting Racket) that doesn't suffer from phasing problems.
> Its downside is that it doesn't work like you expect in data files read
> with `read`, but how common are those these days?

Files, network streams, database entries, ... anything from which you
want to acquire Scheme data structures without 'eval', which is a lot.

If 'read' doesn't understand it, it's not external representation, just
a fancy macro.

> If you decide to do that, then all you have to do is pick a set of tags
> like your `hash`, `hashq`, and `hashv` and explain the meaning of the
> identifiers `$construct$:hash` etc. (which can be procedures or macros).
> That way you don't need a separate SRFI, and people with SRFI-108 can
> just use:
>
>> &hashq{(key . value) ...}  ; eq? based
>> &hashv{(key . value) ...}  ; eqv? based
>> &hash{(key . value) ...}  ; equal-hash & equal? based
>
> etc.

I'd need to think harder to be able to give a credible critique, but
from a short skim, I don't like SRFI-108.  I would be very shocked if it
were standardized in an RnRS and/or if the external representation of a
type in an RnRS were explained in terms of it.

Taylan