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/