Re: API conflicts

[Shiro Kawai <shiro@xxxxxxxx>]

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