Not the name of a function
ccc31807
your head against a brick wall for no good reason. I'm working through
chapter 21 of Wilensky's 'CommonLISPCRAFT' and have spend most of the
day trying to find the source of the error. The error message is:
-+ Errors (1)
`-- Not the name of a function: (NOT (CONTAINED-IN PATTERN-VAR ITEM
BINDINGS))
-+ Style Warnings (1)
`-- variable CHAR is not used.
Misspelled or missing IGNORE declaration?
I have pasted the code below. I've tried out all the usual tricks,
including commenting out sections and then uncommenting line by line,
but I can't understand why the debuggers things that CONTAINED-IN
isn't a function when I damn will know that it is.
Thanks, CC.
;Chapter 21, CommonLISPCRAFT, Wilensky
(set-macro-character #\?
#'(lambda (stream char)
(list '*var* (read stream t nil t))))
(defun match (pattern1 pattern2)
(match-with-bindings pattern1 pattern2 nil))
(defun match-with-bindings (pattern1 pattern2 bindings)
(cond
((pattern-var-p pattern1) (variable-match pattern1 pattern2
bindings))
((pattern-var-p pattern2) (variable-match pattern2 pattern1
bindings))
((atom pattern1) (if (eq pattern1 pattern2)
(values t bindings)))
((atom pattern2) nil)
(t (multiple-value-bind (flag carbindings)
(match-with-bindings (car pattern1) (car pattern2)
bindings)
(and flag
(match-with-bindings (cdr pattern1) (cdr pattern2)
carbindings))))))
(defun variable-match (pattern-var item bindings)
(format t "This is contained-in ~a ~a ~a~%" pattern-var item
bindings)
(if (equal pattern-var item) (values t bindings)
(let ((var-binding (get-binding pattern-var bindings)))
(cond
((var-binding (match-with-bindings var-binding item
bindings))
((not (contained-in pattern-var item bindings))
(values t (add-binding pattern-var item bindings))))))))
(defun contained-in (pattern-var item bindings)
(format t "This is contained-in ~a ~a ~a~%" pattern-var item
bindings)
(cond ((atom item) nil)
((pattern-var-p item) (or (equal pattern-var item)
(contained-in pattern-var (get-
binding item bindings) (bindings)))
(t (or (contained-in pattern-var (car item) bindings)
(contained-in pattern-var (cdr item) bindings))))))
(defun add-binding (pattern-var item bindings)
(cons (list pattern-var item) bindings))
(defun pattern-var-p (item)
(and
(listp item)
(eq '*var* (car item))))
(defun get-binding (pattern-var bindings)
(cadr (assoc pattern-var bindings :test #'equal)))
vippstar
> I'm sorry, guys, but CL is difficult enough without having to bash
> your head against a brick wall for no good reason. I'm working through
> chapter 21 of Wilensky's 'CommonLISPCRAFT' and have spend most of the
> day trying to find the source of the error. The error message is:
>
> -+ Errors (1)
> `-- Not the name of a function: (NOT (CONTAINED-IN PATTERN-VAR ITEM
> BINDINGS))
> -+ Style Warnings (1)
> `-- variable CHAR is not used.
> Misspelled or missing IGNORE declaration?
>
> I have pasted the code below.
> (defun variable-match (pattern-var item bindings)
> (format t "This is contained-in ~a ~a ~a~%" pattern-var item
> bindings)
> (if (equal pattern-var item) (values t bindings)
> (let ((var-binding (get-binding pattern-var bindings)))
> (cond
> ((var-binding (match-with-bindings var-binding item
> bindings))
> ((not (contained-in pattern-var item bindings))
> (values t (add-binding pattern-var item bindings))))))))
(cond
((expr)
((not (contained-in ...)) (expr)))
Somewhat obvious, ((not (contained-in ...)) ...) can't be correct -
because (not (contained-in ...)) is not a function name.
Pascal Costanza
> I'm sorry, guys, but CL is difficult enough without having to bash
> your head against a brick wall for no good reason. I'm working through
> chapter 21 of Wilensky's 'CommonLISPCRAFT' and have spend most of the
> day trying to find the source of the error. The error message is:
>
> -+ Errors (1)
> `-- Not the name of a function: (NOT (CONTAINED-IN PATTERN-VAR ITEM
> BINDINGS))
> -+ Style Warnings (1)
> `-- variable CHAR is not used.
> Misspelled or missing IGNORE declaration?
>
> I have pasted the code below. I've tried out all the usual tricks,
> including commenting out sections and then uncommenting line by line,
> but I can't understand why the debuggers things that CONTAINED-IN
> isn't a function when I damn will know that it is.
One of your 'cond forms has too many parentheses.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Kenneth Tilton
You meant:
(defun variable-match (pattern-var item bindings)
(format t "This is contained-in ~a ~a ~a~%" pattern-var item
bindings)
(if (equal pattern-var item) (values t bindings)
(let ((var-binding (get-binding pattern-var bindings)))
(cond
(var-binding (match-with-bindings var-binding item
bindings))
((not (contained-in pattern-var item bindings))
(values t (add-binding pattern-var item bindings)))))))
The error meant it found:
(not (contained-in pattern-var item bindings))
... in the function (first) position of a form, so you should just look
at that form and figure out why it is not what you intended, the first
element in a cond clause.
That happened because you balanced parens without reindenting or without
staring at the reindentation to see if you achieved the balancing by
adding right parens at the wrong place.
One trick I use is to start at the end of the problematic form and
eyeball the balanced parens as I work out to make the sure the right one
is balancing.
kt
--
http://thelaughingstockatpngs.com/
http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
ccc31807
> One of your 'cond forms has too many parentheses.
Thank you very much for suggesting this. I successfully corrected the
error after carefully comparing the code in the book with what I
copied. Actually, two of them had too many sets of parens.
I won't complain about the parentheses, because I understand that they
are part of the discipline of the language.
I will complain about the error message issued by the debugger. At
least the Perl debugger suggests possible sources of the error, and it
seems to me that a message 'Not the name of a function' could have
suggested causes for the error.
CC
ccc31807
> That happened because you balanced parens without reindenting or without
> staring at the reindentation to see if you achieved the balancing by
> adding right parens at the wrong place.
I see what you mean, but this is part of the ART of writing in a
particular language, not part of the syntax or grammar. Unfortunately,
I'm totally alone in my study of CL, so I don't get the benefit of
seasoned hands passing along the wisdom of the ages.
> One trick I use is to start at the end of the problematic form and
> eyeball the balanced parens as I work out to make the sure the right one
> is balancing.
A trick that will no doubt become easier after much practice, but
which seems a little magical to someone who hasn't quite grasped the
concept of balanced parens. Yes, I know that the parens should match,
but in this case all the parens matched -- there was just too many of
them. Picking the 'right one' is a skill that one must develop.
Thanks for your advice, and giving me a tip on what to do.
CC.
Pascal J. Bourguignon
To get better newbie error message, you would have to use something
like Harald Weitz's PHENARETE system.
http://portal.acm.org/citation.cfm?id=802950
http://portal.acm.org/citation.cfm?id=1411798.1411808
http://www.ai.univ-paris8.fr/~hw/bvlispExample.pdf
Unfortunately it has not been converted to deal with Common Lisp.
Perhaps you could have fun doing that?
--
__Pascal Bourguignon__
Pascal J. Bourguignon
> On Nov 19, 4:25�pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> That happened because you balanced parens without reindenting or without
>> staring at the reindentation to see if you achieved the balancing by
>> adding right parens at the wrong place.
>
> I see what you mean, but this is part of the ART of writing in a
> particular language, not part of the syntax or grammar. Unfortunately,
> I'm totally alone in my study of CL, so I don't get the benefit of
> seasoned hands passing along the wisdom of the ages.
And what are the Internet, news:comp.lang.lisp and
irc://irc.freenode.org/#lisp for?
--
__Pascal Bourguignon__
Kenneth Tilton
> On Nov 19, 4:25 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
>> That happened because you balanced parens without reindenting or without
>> staring at the reindentation to see if you achieved the balancing by
>> adding right parens at the wrong place.
>
> I see what you mean, but this is part of the ART of writing in a
> particular language, not part of the syntax or grammar.
Sure. I did not mean that as criticism, I meant to make clear how it
arose so you'd have a leg up next time. Happens to me too, just throwing
parens at the end.
> Unfortunately,
> I'm totally alone in my study of CL, so I don't get the benefit of
> seasoned hands passing along the wisdom of the ages.
You will if you continue posting here. That was my intent.
>
>> One trick I use is to start at the end of the problematic form and
>> eyeball the balanced parens as I work out to make the sure the right one
>> is balancing.
>
> A trick that will no doubt become easier after much practice, but
> which seems a little magical to someone who hasn't quite grasped the
> concept of balanced parens. Yes, I know that the parens should match,
> but in this case all the parens matched -- there was just too many of
> them. Picking the 'right one' is a skill that one must develop.
Actually, if you did what I suggested the mistake often jumps out pretty
spectacularly. eg (but your case, I did not go back to check), you'll
get just outside the cond form and see the opening "(let.." balanced far
far away from where you expected.
In your case, had you re-indented (control-shift-P in my setup) you
might have noticed your cond clauses not aligning.
>
> Thanks for your advice, and giving me a tip on what to do.
>
you be welcome.
Elsewhere you complained about the error message, which steered you
directly to the mistake you coded. (I am not aware of any mind-reading
compilers that could then work back to the underlying mistake balancing
parens to form a mostly legal form. If you are complaining about that,
you have never programmed in C/C++ and prolly just about any other
language.
:)
Alberto Riva
>
> I will complain about the error message issued by the debugger. At
> least the Perl debugger suggests possible sources of the error, and it
> seems to me that a message 'Not the name of a function' could have
> suggested causes for the error.
But that's what it was telling you, it's just a matter of rearranging
the word order a little bit:
> -+ Errors (1)
> `-- Not the name of a function: (NOT (CONTAINED-IN PATTERN-VAR ITEM
> BINDINGS))
In other words: "The form (NOT (CONTAINED-IN-PATTERN-VAR ITEM BINDINGS))
is not the name of a function".
Alberto
Kaz Kylheku
You have a point there. There is an ambiguity in the code, and the machine is
diagnosing it in a way which assumes that you are a Lisp expert.
Compound forms /can/ in fact be be function names. For instance
(defstruct balloon (color))
(let ((b (balloon)))
((setf balloon-color) :blue b))
So (setf balloon-color) is the compound name of a setter function.
Another example of a compound functio nname is the lambda expressions:
((lambda (x y) (+ x y)) 4 2) -> 6
You wrote:
(cond
((var-binding (match-with-bindings var-binding item
bindings))
((not (contained-in pattern-var item bindings))
(values t (add-binding pattern-var item bindings)))))
This looks like a COND with just one cond pair, consisting of the forms.
(var-binding (match-with-bindings var-binding item bindings))
and
((not (contained-in pattern-var item bindings))
(values t (add-binding pattern-var item bindings)))
If the first expression yields true, the second one is evaluted.
And the second one looks very much like a call to some function
named (not (contained-in ... )). It also does look like
what it is, namely an extra nesting level around a form intended to be
evaluated. The situation is ambiguous.
The diagnostic is a guess which could go wrong either way. If the diagnostic
said ``your form ((not ....)) seems to have too much nesting'', then it would
be unhelpful in a situation where you really did misspell a functon name ((sef
balloon-color) ...).
But there is a case to be made for ``newbie mode'' in the system whereby the
the machine's diagnostic interprets the ambiguous situation in a way which is
likely for the newbie. (Or, possibly, prints more than one possible cause for
the situation, too).
This problem shows up in other languages.
struct foo {
} /* missing semicolon */
int main(void)
{
}
Your C compiler will probably spit out a message along the lines of ``too many
type specifiers in a declaration'' rather than ``you missed a semicolon after a
struct''.
Pascal J. Bourguignon
> On 2009-11-20, ccc31807 <cart...@gmail.com> wrote:
>> On Nov 19, 2:12�pm, Pascal Costanza <p...@p-cos.net> wrote:
>>> One of your 'cond forms has too many parentheses.
>>
>> Thank you very much for suggesting this. I successfully corrected the
>> error after carefully comparing the code in the book with what I
>> copied. Actually, two of them had too many sets of parens.
>>
>> I won't complain about the parentheses, because I understand that they
>> are part of the discipline of the language.
>>
>> I will complain about the error message issued by the debugger. At
>> least the Perl debugger suggests possible sources of the error, and it
>> seems to me that a message 'Not the name of a function' could have
>> suggested causes for the error.
>
> You have a point there. There is an ambiguity in the code, and the machine is
> diagnosing it in a way which assumes that you are a Lisp expert.
>
> Compound forms /can/ in fact be be function names. For instance
>
> (defstruct balloon (color))
>
> (let ((b (balloon)))
> ((setf balloon-color) :blue b))
But this is not a valid conformant form (even if clisp accepts it).
S/USER[1]> (defstruct balloon (color))
BALLOON
S/CL-USER[2]> (let ((b (make-balloon)))
((setf balloon-color) :blue b))
; in: LAMBDA NIL
; ((SETF BALLOON-COLOR) :BLUE B)
;
; caught ERROR:
; illegal function call
; (LET ((B (MAKE-BALLOON)))
; ((SETF BALLOON-COLOR) :BLUE B))
;
; caught STYLE-WARNING:
; The variable B is defined but never used.
;
; compilation unit finished
; caught 1 ERROR condition
; caught 1 STYLE-WARNING condition
debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR: Execution of a form compiled with errors.
Form:
((SETF BALLOON-COLOR) BLUE B)
Compile-time error:
illegal function call
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
((LAMBDA NIL))
source: (LET ((B (MAKE-BALLOON))) ((SETF BALLOON-COLOR) :BLUE B))
0]
> So (setf balloon-color) is the compound name of a setter function.
Yes, but it is irrelevant to what names are allowed in function calls.
> If the first expression yields true, the second one is evaluted.
> And the second one looks very much like a call to some function
> named (not (contained-in ... )). It also does look like
> what it is, namely an extra nesting level around a form intended to be
> evaluated. The situation is ambiguous.
Not in Common Lisp.
> But there is a case to be made for ``newbie mode'' in the system whereby the
> the machine's diagnostic interprets the ambiguous situation in a way which is
> likely for the newbie. (Or, possibly, prints more than one possible cause for
> the situation, too).
Yes, we can use additionnal heuristics to give better error messages.
But is it worth it in a generic compiler?
My opinion is that it would be good to develop an ecosystem of
analysis tools, including such a newbie adviser mode, but more
sophisticated static global analysis tools.
--
__Pascal Bourguignon__
George Neuner
Bourguignon) wrote:
>Kaz Kylheku <kkyl...@gmail.com> writes:
>
>> But there is a case to be made for ``newbie mode'' in the system whereby the
>> the machine's diagnostic interprets the ambiguous situation in a way which is
>> likely for the newbie. (Or, possibly, prints more than one possible cause for
>> the situation, too).
>
>Yes, we can use additionnal heuristics to give better error messages.
>But is it worth it in a generic compiler?
Yes.
>My opinion is that it would be good to develop an ecosystem of
>analysis tools, including such a newbie adviser mode, but more
>sophisticated static global analysis tools.
Such sophisticated analysis tool(s) are 2/3 of a compiler anyway - all
that's missing is code generation. While tool making might provide a
few jobs in a poor economy, I don't think it is the best use of
resources. I think it makes more sense that compilers - which have to
do much of the same work anyway - try to provide the best possible
static error detection and warning in the first place.
YMMV,
George