lookup-def

On Sun, 04 Jul 2004 16:17:40, Terrence Brannon wrote, regarding
SXML-to-HTML-ext.scm issues:

> 1/ this file has 2 functions of general utility: lookup-def and
> signif-tail. I think these belong in util.scm not here because they
> have general usefulness... I added a default warn? option to
> lookup-def.


To which I replied:

<blockquote>
As to lookup-def, I agree about its utility. I seem to be writing
something like that in almost every other file of my code. Alas, all
those lookup-def are slightly different. For example, the associative
list to look up in can be specified either as 
        ((key . value) ...)
or as
        ((key value) ...)
the former is more common, in my experience. Yet the lookup-def in
SXML-to-HTML-ext.scm uses the latter for obvious reasons. Also, what
to do when the key is not found and there is no default? Sometimes I
want to abort the execution because it just can't continue. Sometimes
I wish to print a warning message and return #f. Sometimes I just wish
to return #f. How to specify the default value or the lack of it is
also not clear. Sometimes #f as 'no default' is OK. Sometimes I make
the default argument optional. Sometimes specifying the default as a
thunk is beneficial (cf. SRFI-44). 

So, while lookup-def is certainly a useful function, what is the best
interface for it remains totally unclear to me....
</blockquote>

I have checked all of my Scheme code for lookup-def and related
assq-def, assv-def and assoc-def. The latter three are defined in
myenv*.scm files. I have found that I never used assv-def; I used
assoc-def only on two occasions. Almost all the time keys are
symbols. The procedures lookup-def and assq-def are quite
frequent. The former is, unfortunately, defined and redefined in lots
of places, sometimes with slightly different
interfaces. Standardization is indeed in order. It seems that the
following interface is a good compromise.

It is tempting to call the proposed form just `lookup'. However, the
latter is such a common name. The present name `lookup-def' appears to
be rare enough. Other suggestions are also welcome.

The proposed `lookup-def' is a special form rather than a regular
procedure. Its first two arguments are evaluated exactly once. The
default-value argument, if given, is evaluated only if the desired key
is not found. I have not seen any need to pass `lookup-def' as an
argument to other functions. If the latter is desired, it is not
difficult to accomplish by explicitly wrapping `lookup-def' into a
lambda form.


; Look up a value associated with a symbolic key in alist 
; ((key value) ...) or ((key . value) ...)
; and return the associated value.
; If the association has the form
;   (key . value) where value is not a pair --> return value
;   (key   value)                           --> return value
;   (key value1 value2 value3 ...) -> return (value1 value2 value3 ...)
; that is, the procedure tries to do the right thing for
; both kinds of associative lists. 
;
; We use a pseudo-keyword argument warn: as a modifier.
; This is not really a keyword argument (although it may be,
; if the Scheme system turns out DSSSL-compatible)
; 
; (lookup-def key alist)  -- lookup the key in the alist and return the
;                        associated value. Raise an error if the key is not
;                        found.
; (lookup-def key alist default-exp)
;                     -- lookup the key in the alist and return the associated
;                        value. If the the key is not found, evaluate
;                        the default-exp and return its result.
; (lookup-def key alist warn: default-exp)
;                     -- the same as above. In addition, write a warning
;                        (using cerr above) if the key is not found.


The proposed lookup-def is not exactly compatible with lookup-def that
is currently defined in SXML-to-HTML-ext.scm. So, some changes to
various stylesheets might be needed. This is a pain, but seems
necessary. I'd also like to drop assq-def, assv-def, and assoc-def
from myenv*.scm files. Comments are very appreciated.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php