|
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)
|
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/