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.229729887xxxxxx@lava.net>

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