This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
From: Taylor Campbell <campbell@xxxxxxxxxxxx> Subject: Re: API conflicts (Was: Re: Reasons for withdrawal) Date: Wed, 29 Oct 2003 16:39:54 -0500 > LIST= should be n-ary. I'm not sure why it isn't. (probably a typo; > there are lots of those in the document, due to the tedium in writing > it) See my mail <20031028.200305.229729887.shiro@xxxxxxxx> > A couple of problems with alists have been mentioned. Three solutions > came up on IRC: > - Create an abstract type for alists. [...] > - Add a unique token to the head of the alist. [...] > - Add a metadata _association_ to the list, with a unique token > visible only to the implementation. [...] The fundamental problem I see is that what Scheme/Lisp programmer thinks as "alist" is just a list of pairs and nothing more, no hidden structure, no magic tags; it doesn't fit well in the view of "dictionary" in srfi-44. For example, one of alist's nice properties is that you can add the pair to the head of existing alist non-destructively, effectively shadowing entries with the same key. The power of alist is in its simple and flexible structure. The alist dictionary is just one of special application of alist, and not all alists fit that view. So I suggest we define an abstract type for alist-dictionary, which happens to use alist to store data internally, but alist-dictionary itself is a different object, maybe implemented by srfi-9 record type. > It's pretty easy to avoid this conflict by either not explicitly using > SRFI 44 or explicitly using those implementations' libraries, or > having a simple SRFI 44 wrapper around hash tables of those > implementations when you do explicitly use SRFI 44. The primary point of the section is to warn users, so that they can take the strategy like you described here. There's another point, though. There are two camps in Scheme implementations regarding how to give the "fallback" value, both have their own ground. If srfi-44 gives a convincing rationale for thunk approach, and becomes widely spread, it may be possible that eventually the convention of giving fallback value converges to thunk approach. --shiro