On Wed, Oct 29, 2003 at 01:19:36PM -1000, Shiro Kawai wrote: > > there are lots of those in the document, due to the tedium in writing > > it) > > See my mail <20031028.200305.229729887.shiro@xxxxxxxx> Yes, I've applied those fixes, including the n-ary list=. I'll upload it in a little while. > > 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. I almost completely agree. I agree 100% with the idea of having an alist dictionary whose implementation happens to use an alist for storage. It doesn't need to be an SRFI-9 record though. It can be a list structure using one of Taylors strategies, too. Its just important to make it clear that the SRFI-44 alist dictionary is not backward compatible with Scheme association lists. > 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. I can take a swing at writing that absence thunk rationale section, but I'd appreciate any points anyone has so I don't miss any advantages. Scott
Attachment:
pgpPS7TCJk9GT.pgp
Description: PGP signature