This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: another nit.
- To: Jonathan Bartlett <johnnyb at wolfram dot com>
- Subject: Re: another nit.
- From: hjstein at bfr dot co dot il (Harvey J. Stein)
- Date: 06 Jul 2000 10:46:30 -0400
- Cc: Michael Livshin <mlivshin at bigfoot dot com>, Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>, Han-Wen Nienhuys <hanwen at cs dot uu dot nl>, Guile Mailing List <guile at sourceware dot cygnus dot com>
- References: <Pine.LNX.4.10.10007060409520.4726-100000@scully.wolfram.com>
Jonathan Bartlett <johnnyb@wolfram.com> writes:
> What does vector-ref return when someone accesses it beyond a valid
> index? Whatever this behavior is, should also be the behavior of
> assq-ref.
I thought of that, but I don't think it's the appropriate analogy. An
array has a predetermined starting & ending index, so the set of
"keys" (the indices) is known in advance. In an alist, the
keys are arbitrary and vary when insertions are done. Alists should
have the same interface as hashtables (and other dictionaries), not as
vectors. A more appropriate analogy btw vectors and alists not having
a particular key would be referencing an index in a vector before that
element has been set to something.
In fact, it's *extremely* desireable for these fcns to have the same
interface because then one can easily replace alists by hash tables
when necessary. Even better would be a set of dictionary fcns using
GOOPS which act appropriately both on alists & hash table objects.
As for making assq-ref's return value unspecified when the key doesn't
exist, it could be reasonable, but I think it's a bad idea. The
return value being unspecified means not that it's always
#<unspecified> but that it could be anything. It could just as easily
be nil or #f or 3 or the last item in the list or ...
--
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il