Re: another nit.

[Michael Livshin <mlivshin at bigfoot dot com>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> I don't see what should be unportable about the phrase "It is an error if 
> the key can not be found in the alist."  You're right that user code
> should not use guile's error catching mechanism to figure out whether a
> key can be found in an alist, but that's a different issue.  And, to come
> back to the original suggestion to use #<unspecified>:  The existence of
> an #<unspecified> object is also guile-specific.

(if #f #f) will yield you the `unspecified' object in any Scheme.

> IMO it's unclean to allow the ambiguity that the same return value can
> have two different meanings.

well, tough.  in Scheme, you can produce an instance of any imaginable
category (I think).  I see you point: if so, then the cleanest
solution is to throw an exception, but that's just methodologically
bad, since the case when a key is not in an alist isn't exceptional.

I think `assq' is good enough.  millions^Wthousands^Wlots of Lisp
users that live with the convention of returning #f (or nil) when a
key does not exist don't seem to mind much.

[ aside: it really should be nice if people would look at least at the 
  Common Lisp spec before they start inventing API's.  this doesn't
  only concern us Guilers, BTW. ]

> Are there good arguments against saying that it is an error if the
> key can not be found?

is there any good argument in support of that?  the alist API is
generic, it doesn't concern itself with program logic.

> Another possibility would be to extend the definition of assq-ref to
> take an optional third argument that determines a default value.

yep, I like this -- and this is exactly what CL's `gethash' does.

-- 
Think of C++ as an object-oriented assembly language.