External representation taylanbayirli@xxxxxx (10 Sep 2015 15:21 UTC)
Re: External representation taylanbayirli@xxxxxx (10 Sep 2015 15:22 UTC)
Re: External representation Arthur A. Gleckler (10 Sep 2015 15:24 UTC)
Re: External representation taylanbayirli@xxxxxx (10 Sep 2015 20:10 UTC)
Re: External representation Arthur A. Gleckler (10 Sep 2015 20:44 UTC)
Re: External representation taylanbayirli@xxxxxx (11 Sep 2015 07:36 UTC)
Re: External representation John Cowan (11 Sep 2015 13:04 UTC)
Re: External representation taylanbayirli@xxxxxx (11 Sep 2015 13:25 UTC)
Re: External representation Per Bothner (11 Sep 2015 14:05 UTC)
Re: External representation taylanbayirli@xxxxxx (11 Sep 2015 14:21 UTC)
Re: External representation Kevin Wortman (11 Sep 2015 19:10 UTC)
Re: External representation taylanbayirli@xxxxxx (11 Sep 2015 21:48 UTC)
Re: External representation Shiro Kawai (12 Sep 2015 02:04 UTC)
Re: External representation John Cowan (10 Sep 2015 16:30 UTC)
Re: External representation taylanbayirli@xxxxxx (10 Sep 2015 18:12 UTC)
Re: External representation John Cowan (10 Sep 2015 19:02 UTC)
Re: External representation Per Bothner (10 Sep 2015 21:25 UTC)
Re: External representation John Cowan (10 Sep 2015 21:52 UTC)

Re: External representation taylanbayirli@xxxxxx 10 Sep 2015 18:12 UTC

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