3 ms·

Here is an exercise for you: Which of the following forms are valid Common Lisp: (defun foo (a b) (declare (fixnum a)) "foo" (declare (f

by lispm 10y ago

Here is an exercise for you: Which of the following forms are valid Common Lisp: (defun foo (a b) (declare (fixnum a)) "foo" (declare (fixnum b)) (+ a b)) (defun foo (a b) "foo" (declare (fixnum a)) (declare (fixnum b)) (+ a b)) (defun foo (a b) (declare (fixnum a)) (declare (type fixnum b)) "foo" (+ a b)) (defun foo (a b) (declare (type fixnum b)) "foo" "bar" (declare (fixnum a)) (+ a b)) (defun foo (a b) (declare (fixnum a)) (declare (type fixnum b)) "foo" "bar" (+ a b)) (defun foo (a b) (declare (fixnum a)) "foo" "bar" (+ a b))

kazinator 10y ago
I don't know, and who cares. I seem to be vaguely convinced for some reason that there may be exactly one docstring, and that, if present, it must be the first item in the body; then there can be declarations. Not sure if there can be two or more declares. I would always write (declare (fixnum a) (fixnum b)) and don't recall seeing multiple declares in other people's code. (I might be suffering from a form of amnesia which merges multiple ANSI Lisp declares into one.) This is the sort of thing I'd look into closely if I were tasked with parsing a function body (like for the sake of making some body rearranging-and-reassembling macro fully conforming with the surrounding language). I'm not going to write such code myself, and won't likely see it in other people's code. Until I see such instances, I won't bother looking at the spec to see what the exact rules are and confirm/refute whether those examples are conforming. In any case, whether or not some of the examples are correct, I can see what they are trying to say. Be they mistakes, they are still well-formed surface syntax and are readable. Things could plausibly work in some CL dialect such that they are all correct, if they aren't. A literal string near the beginning of a function, which is only evaluated for its side effect (which it doesn't have) looks suspiciously like a doc string. Either it is correctly positioned or it isn't. The (declare ...) syntax is clearly a declaration, whether or not correctly positioned. (declare ...) isn't a form. I suspect it would be undefined behavior for a program to define a function or macro called declare; not sure about that. Defined or not, it would be a incredibly bad idea. I'm a competent Lisp programmer and implementor too, and don't have to have this memorized; it's likely not an impediment to anyone else. Which kind of makes my point.
- lispm 10y ago
  > I don't know, and who cares. A Lisp programmer has to care, if he wants to write Lisp code. > I seem to be vaguely convinced for some reason that there may be exactly one docstring, and that, if present, it must be the first item in the body That's wrong. > I won't bother looking at the spec to see what the exact rules are Which confirms what I'm saying: even for seemingly trivial DEFUNs the syntax is not obvious. > Be they mistakes, they are still well-formed surface syntax and are readable. But the reader does not implement Lisp syntax. The reader just implements s-expression syntax. If the reader can read the form, then it is a valid s-expression. But not necessarily valid Lisp. (defun foo (a) a) ; valid s-expression, valid Lisp (defun (foo) a a) ; valid s-expression, not valid Lisp (defun (bar foo) (a) a) ; valid s-expression, not valid Lisp (defun (setf foo) (a) a) ; valid s-expression, valid Lisp syntax (defun foo (&key a &optional b) (list a b)) ; not valid Lisp (defun foo ($key a &optional b) (list a b)) ; valid Lisp The Lisp interpreter/compiler and the macros implement Lisp syntax. Not the reader. > it's likely not an impediment to anyone else. That you don't know the syntax of DEFUN confirms what I'm saying: the syntax is non-obvious. Explain this: * (defun foo (a b) (declare (fixnum a)) "foo" "bar" (+ a b)) debugger invoked on a SIMPLE-ERROR: duplicate doc string "bar" Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-INT:PARSE-BODY ((DECLARE (FIXNUM A)) "foo" "bar" (+ A B)) T NIL) 0]
  - kazinator 10y ago
    > That you don't know the syntax of DEFUN confirms what I'm saying. Yes, it rather confirms that you can go far in Lisp without memorizing stuff like this!!! If I don't have to know, few people do. You can bet your ass that if I had to implement an ANSI-CL conforming defun/lambda I'd get it right, of course. I don't have some "requirements don't matter" attitude; but not all requirements matter all the time to all people. I'd like to add, though, this: you can't be safe in ignorance in Common Lisp. Things you don't know can hurt you. Less than in some other languages, but they are there. You probably won't be hurt by not knowing all the possibilities for combining docstrings and declares. But if you're ignorant of some things, you may get burned. Undefined behavior situations like modifying literal tree structure, or writing a program that parses untrusted Lisp data, not knowing about the #. syntax and * read-eval* . I'm not advocating unsafe ignorance. Not knowing the full flexibility of some syntax is generally safe, though. > Explain this: Which aspect of that error scenario isn't self-explanatory; what is left to explain? From that one error, the listener has just taught us several important facts about the syntax which it accepts (which may be a superset of ANSI CL for all we know). It shows us that it accepts a docstring after a declare just fine, but that there must be at most one docstring. (At least, when the two are in that order, if we are to be strict in our guessing.) So without looking at a shred of documentation outside of that error message, I'm already better informed. The interactive nature of Lisp teaches! (Especially if the implementation is tight on error checking and has good diagnostics.) What's left unsettled from that error situation is whether or not there may be multiple declares, since that case isn't being probed.
deleted 10y ago
[deleted]

by lispm 10y ago

kazinator 10y ago

I don't know, and who cares. I seem to be vaguely convinced for some reason that there may be exactly one docstring, and that, if present, it must be the first item in the body; then there can be declarations. Not sure if there can be two or more declares. I would always write (declare (fixnum a) (fixnum b)) and don't recall seeing multiple declares in other people's code. (I might be suffering from a form of amnesia which merges multiple ANSI Lisp declares into one.) This is the sort of thing I'd look into closely if I were tasked with parsing a function body (like for the sake of making some body rearranging-and-reassembling macro fully conforming with the surrounding language). I'm not going to write such code myself, and won't likely see it in other people's code. Until I see such instances, I won't bother looking at the spec to see what the exact rules are and confirm/refute whether those examples are conforming. In any case, whether or not some of the examples are correct, I can see what they are trying to say. Be they mistakes, they are still well-formed surface syntax and are readable. Things could plausibly work in some CL dialect such that they are all correct, if they aren't. A literal string near the beginning of a function, which is only evaluated for its side effect (which it doesn't have) looks suspiciously like a doc string. Either it is correctly positioned or it isn't. The (declare ...) syntax is clearly a declaration, whether or not correctly positioned. (declare ...) isn't a form. I suspect it would be undefined behavior for a program to define a function or macro called declare; not sure about that. Defined or not, it would be a incredibly bad idea. I'm a competent Lisp programmer and implementor too, and don't have to have this memorized; it's likely not an impediment to anyone else. Which kind of makes my point.

lispm 10y ago
> I don't know, and who cares. A Lisp programmer has to care, if he wants to write Lisp code. > I seem to be vaguely convinced for some reason that there may be exactly one docstring, and that, if present, it must be the first item in the body That's wrong. > I won't bother looking at the spec to see what the exact rules are Which confirms what I'm saying: even for seemingly trivial DEFUNs the syntax is not obvious. > Be they mistakes, they are still well-formed surface syntax and are readable. But the reader does not implement Lisp syntax. The reader just implements s-expression syntax. If the reader can read the form, then it is a valid s-expression. But not necessarily valid Lisp. (defun foo (a) a) ; valid s-expression, valid Lisp (defun (foo) a a) ; valid s-expression, not valid Lisp (defun (bar foo) (a) a) ; valid s-expression, not valid Lisp (defun (setf foo) (a) a) ; valid s-expression, valid Lisp syntax (defun foo (&key a &optional b) (list a b)) ; not valid Lisp (defun foo ($key a &optional b) (list a b)) ; valid Lisp The Lisp interpreter/compiler and the macros implement Lisp syntax. Not the reader. > it's likely not an impediment to anyone else. That you don't know the syntax of DEFUN confirms what I'm saying: the syntax is non-obvious. Explain this: * (defun foo (a b) (declare (fixnum a)) "foo" "bar" (+ a b)) debugger invoked on a SIMPLE-ERROR: duplicate doc string "bar" Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-INT:PARSE-BODY ((DECLARE (FIXNUM A)) "foo" "bar" (+ A B)) T NIL) 0]
- kazinator 10y ago
  > That you don't know the syntax of DEFUN confirms what I'm saying. Yes, it rather confirms that you can go far in Lisp without memorizing stuff like this!!! If I don't have to know, few people do. You can bet your ass that if I had to implement an ANSI-CL conforming defun/lambda I'd get it right, of course. I don't have some "requirements don't matter" attitude; but not all requirements matter all the time to all people. I'd like to add, though, this: you can't be safe in ignorance in Common Lisp. Things you don't know can hurt you. Less than in some other languages, but they are there. You probably won't be hurt by not knowing all the possibilities for combining docstrings and declares. But if you're ignorant of some things, you may get burned. Undefined behavior situations like modifying literal tree structure, or writing a program that parses untrusted Lisp data, not knowing about the #. syntax and * read-eval* . I'm not advocating unsafe ignorance. Not knowing the full flexibility of some syntax is generally safe, though. > Explain this: Which aspect of that error scenario isn't self-explanatory; what is left to explain? From that one error, the listener has just taught us several important facts about the syntax which it accepts (which may be a superset of ANSI CL for all we know). It shows us that it accepts a docstring after a declare just fine, but that there must be at most one docstring. (At least, when the two are in that order, if we are to be strict in our guessing.) So without looking at a shred of documentation outside of that error message, I'm already better informed. The interactive nature of Lisp teaches! (Especially if the implementation is tight on error checking and has good diagnostics.) What's left unsettled from that error situation is whether or not there may be multiple declares, since that case isn't being probed.

deleted 10y ago

[deleted]