get,getf

[Kanef@CHARON.arc.nasa.gov (Bob Kanefsky)]

    Date: Tue, 5 Mar 91 08:24 MST
    From: paul@taos.intel.com (Paul Collier)


    While looking through some of the system code that performs backups, I
    came across the following:

	    (dolist (elt (backup-dump-get-dir-list wildpath))
	(if (dumper-prefilter elt)
	    (if (get elt :directory)
		(push (car elt) dirs)
		(push elt files))))

    According to CLtL p. 164, and the Symbolics debugger, this shouldn't
    work. GET is defined as returning a value from the property list of a
    symbol and sure enough, if I try to run this as a function unto itself,
    it blows up because elt is bound to an element of a list. Not to mention
    that the value of elt is such that it won't work as a plist. It seems
    like it should be written [with GETF...]

    My question is, why does the previous work? It obviously does, since
    I've been doing backups for years and it's never blown up.
							       
That code is in the LMFS package, which inherits symbols from the old ZetaLisp
package.  The GET function it's using is actually ZL:GET, which works
a little differently from CL:GET -- if it's given a list instead of a symbol,
it effectively does a GETF on the REST of the list:
	(zl:get '(a b c d e) 'b) => c
The Common Lisp way is a lot less confusing, I think, but the code you're
looking at probably predates Common Lisp by several years.
							       
							       I'm also
    curious as to why the original coder used 'elt' as the variable name in
    the form. It seems strange to use a function name as a variable name
    (although admittedly harmless.)

It doesn't seem strange to me; lots of people use LIST as a local variable
name, for example.  Besides, technically it isn't using a function name as a
variable name since there's no LMSF:ELT or ZL:ELT, only a CL:ELT.

--Kanef