This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: another nit.


On 6 Jul 2000, Michael Livshin wrote:

> > > why do assq-ref and friends return #f when the key is not found, in
> > > stead of #<unspecified>? This makes it kind of hard to distinguish
> > > between an alist not containing KEY and  (KEY . #f)
> > 
> > Actually, it would be best to throw an error if the key is not
> > found.
> 
> no.  it would introduce a Guile-specific aspect into an otherwise
> portable specification.
> 
> also, even if we assume that exceptions are standartized, it's not
> reasonable to expect them to have reasonable performance.

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.

IMO it's unclean to allow the ambiguity that the same return value can
have two different meanings.  This ambiguity can only be avoided by saying
that it is an error to pass a key that is not in the alist.  Returning any
other object is ambiguous.  Even my suggestion to have an unique tag to be
returned if the key is not found is ambiguous:  You can simply use this
tag to construct another alist, where it would be a valid return
value.  Your suggestion for assq-bind is probably the best solution, but
it does not answer the question, how assq-ref should react if the key can
not be found.

Thus, again the question:  How should assq-ref react if the key can not be
found?  Are there good arguments against saying that it is an error if the
key can not be found?  Another possibility would be to extend the
definition of assq-ref to take an optional third argument that determines
a default value.  But, even if this last suggestion was accepted, I would
still prefer that an error was signalled if the key is not found _and_ no
default is provided.  (In other words:  I am against saying that #f is the
default for the default :-)

Best regards
Dirk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]