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 Per Bothner 10 Sep 2015 21:24 UTC


On 09/10/2015 06:30 PM, John Cowan wrote:
> 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?
>
> 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

Note that a SRFI-108 reader translates:

   &hash{(key . value) ...}

to:

   ($construct$:hash "(key . value) ...")

I.e. The implementation of $construct$:hash has to parse (re-read)
the string literal "(key . value) ..." which is awkward.

It does allow substituting values:

   &hash{([key] / [val] (k1 . k2)}

Here k1 and k2 are literal, while key and val are expressions
evaluated at run-time.

What makes it complicated is that we don't want key or val to be
interpolated using plain string interpolation.  Special characters
such as #\( or #\" need to be escaped.  Worse, the escaping is
context-dependent - consider:  &hash{("[key]" . "[val]")}.

The shell-syntax support in Kawa does context-dependent escaping:
http://per.bothner.com/blog/2014/Kawa-shell-programming/
So it is quite possible - however, it's non-trivial.

It may be cleaner to use the escaped-expression syntax with square brackets:
&hash[expr]

SRFI-108 is flexible enought to allow:
   &hash[(key1 . val1) (key2 . val2)]
where key1 val1 key2 val2 are all expressions.

I don't know what the right answer is; just pointing out that
using the SRFI-108 mechanism requires some thought and work.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/