guile-srfi-123

commit c9d5545c377aaa0c962e0eda498ab15b969ec0aa
parent 554f1a9c2a4d5ff8071d0d249e19698905857f09
Author: Taylan Ulrich Bayırlı/Kammer <taylanbayirli@gmail.com>
Date:   Sun, 16 Aug 2015 14:17:27 +0200

Elaborate rationale for lack of alist support.

Diffstat:
M
srfi-123.html
 | 
2
+-
M
srfi-123.md
 | 
17
++++++++++++-----

2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/srfi-123.html b/srfi-123.html
@@ -50,7 +50,7 @@ class="antispam">nospam</span>srfi.schemers.org</a></code>. To subscribe to the 
 (ref foo &#39;a)  ;=&gt; 0
 (set! foo &#39;b 2)  ;error: No such assignable field of record.</code></pre></li>
 </ul>
-<p>Alists are unfortunately impossible to support due to the lack of a reliable <code>alist?</code> predicate. (It's ambiguous in that every alist is also a list, and any list may coincidentally have the structure of an alist.)</p>
+<p>Alists are difficult to support due to the lack of a reliable <code>alist?</code> predicate. (It's ambiguous in that every alist is also a list, and any list may coincidentally have the structure of an alist.) It was considered to support non-integer keyed alists as a special case, but this would lead to silent code breakage when a programmer forgot about the API inconsistency and exchanged a non-integer key for an integer key in existing code. It was also considered to drop list support in favor of alist support, but that idea discarded as well because the hypothetical <code>alist-set!</code> is an exceedingly rare operation. (Prepending an entry to the front, possibly hiding another entry with the same key, is more common.)</p>
 <p>A <code>ref*</code> procedure taking an arbitrary number of <code>field</code> arguments and walking through several collections was considered, but deemed sub-optimal because it doesn't play well with collections that may have &quot;empty&quot; fields (e.g. hashtables), and usually one doesn't walk through deep structures at once, and instead binds intermediate results to a variable. Nevertheless, it is trivial to define if desired:</p>
 <pre><code>(define (ref* object field . fields)
   (if (null? fields)
diff --git a/srfi-123.md b/srfi-123.md
@@ -20,7 +20,7 @@ subscribe to the list, follow
 [these instructions](http://srfi.schemers.org/srfi-list-subscribe.html).
 You can access previous messages via the mailing list
 [archive](http://srfi-email.schemers.org/srfi-123).
-  
+
   - Received: 2015/8/14
   - Draft #1 published: 2015/8/15
 
@@ -109,10 +109,17 @@ types:
     (set! foo 'b 2)  ;error: No such assignable field of record.
     ```
 
-Alists are unfortunately impossible to support due to the lack of a
-reliable `alist?` predicate.  (It's ambiguous in that every alist is
-also a list, and any list may coincidentally have the structure of an
-alist.)
+Alists are difficult to support due to the lack of a reliable `alist?`
+predicate.  (It's ambiguous in that every alist is also a list, and
+any list may coincidentally have the structure of an alist.)  It was
+considered to support non-integer keyed alists as a special case, but
+this would lead to silent code breakage when a programmer forgot about
+the API inconsistency and exchanged a non-integer key for an integer
+key in existing code.  It was also considered to drop list support in
+favor of alist support, but that idea discarded as well because the
+hypothetical `alist-set!` is an exceedingly rare operation.
+(Prepending an entry to the front, possibly hiding another entry with
+the same key, is more common.)
 
 A `ref*` procedure taking an arbitrary number of `field` arguments and
 walking through several collections was considered, but deemed