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.
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