Lisp functions are not math functions. Lisp functions are pieces of interpreted or compiled Lisp code and AFAIK there is no way to compare the math semantics of Lisp function objects other than to write a set of tests and compare the results.
Also note that (equalp next1 next2) does not compare two
SYMBOL-FUNCTIONs (the function objects), instead it compares the
SYMBOL-VALUEs (the variable values) of the symbols NEXT1 and NEXT2. To compare the function objects of the symbols NEXT1 and NEXT2 you need to write:
- Code: Select all
(equalp #'next1 #'next2) => NIL
This also results NIL because
EQUALP compares two different
SYMBOL-FUNCTION objects, bound to two different Lisp symbols, NEXT1 and NEXT2.
In ANSI-CL, there is
FUNCTION-LAMBDA-EXPRESSION, returning the textual definition of a Lisp function object as a list, but only if this information is available at all. With high
OPTIMIZE settings a Lisp compiler is free to strip out this information from compiled Lisp function objects, in which case
FUNCTION-LAMBDA-EXPRESSION just simply returns NIL.
Here is what happens with SBCL 1.0.59 (and default
OPTIMIZE settings):
- Code: Select all
CL-USER> (defun next1 (x) (+ x 1))
NEXT1
CL-USER> (defun next2 (y) (+ y 1))
NEXT2
CL-USER> (function-lambda-expression #'next1)
(SB-INT:NAMED-LAMBDA NEXT1
(X)
(BLOCK NEXT1 (+ X 1)))
NIL
NEXT1
CL-USER> (function-lambda-expression #'next2)
(SB-INT:NAMED-LAMBDA NEXT2
(Y)
(BLOCK NEXT2 (+ Y 1)))
NIL
NEXT2
You see that even if
FUNCTION-LAMBDA-EXPRESSION returns useful results, you still need to write some code to find out if the math semantics of the textual function definitions are equal or not. In Lisp, such a program is called a "code walker" (ask Google about it).
- edgar