Checking for declarations in macros
in [Lisp]
|
Prev: emacs manual problem
Next: 3 questions about arrays
From: Thomas A. Russ on 3 Dec 2009 12:11 Pascal Costanza <pc(a)p-cos.net> writes: > Here is a function for parsing method bodies (probably also good for > function bodies) that I implemented for Closer to MOP. > > (defun parse-method-body (body error-form) > (loop with documentation = nil > for (car . cdr) = body then cdr > while (or (and cdr (stringp car)) > (and (consp car) (eq (car car) 'declare))) > if (stringp car) > do (setq documentation > (if (null documentation) car > (error "Too many documentation strings in ~S." > error-form))) > else append (cdr car) into declarations > finally (return (values documentation > declarations > (cons car cdr))))) > > What's important to keep in mind when writing such code is: > > + There are potentially many declarations. > + There is potentially one documentation string in between the declarations. > + If a potential documentation string is not followed by any other code, > it's actually not a documentation string, but the method/function body > (so the body returns a constant string). Actually, I'm not sure that it really is an ERROR to have multiple strings in the beginning of the method body. It seems to me that one should at most issue a WARNING for that situation. After all, the following code would be legal Common Lisp: (defmethod odd-method (self) "This method has some extra stuff" (print self) "This string is really odd, since it isn't returned or processed" :done) and it seems to me that the following should also be legal: (defmethod odd-method (self) "This method has some extra stuff" "This string is really odd, since it isn't returned or processed" (print self) :done) which is similar to (defmethod odd-method (self) "This method has some extra stuff" 'unused-symbol (print self) :done) The second string would just be ignored, since it evaluates to itself and then isn't used. But it hardly seems like it would be a situation that should signal an ERROR. It also seems that there is an ambiguity in the parsing rules (based on the grammar in the Hyperspec) for a situation where you only have a string in the DEFUN/DEFMETHOD form: defun function-name lambda-list [[declaration* | documentation]] form* It seems that one could choose to parse the string as being the documentation string and there being no FORMs in the body, or one could parse it as being no documentation string and a single FORM in the body. -- Thomas A. Russ, USC/Information Sciences Institute
From: Tamas K Papp on 3 Dec 2009 14:36 On Thu, 03 Dec 2009 09:11:39 -0800, Thomas A. Russ wrote: > Pascal Costanza <pc(a)p-cos.net> writes: > >> Here is a function for parsing method bodies (probably also good for >> function bodies) that I implemented for Closer to MOP. >> >> (defun parse-method-body (body error-form) >> (loop with documentation = nil >> for (car . cdr) = body then cdr >> while (or (and cdr (stringp car)) >> (and (consp car) (eq (car car) 'declare))) >> if (stringp car) >> do (setq documentation >> (if (null documentation) car >> (error "Too many documentation strings in ~S." >> error-form))) >> else append (cdr car) into declarations finally (return >> (values documentation >> declarations >> (cons car cdr))))) >> >> What's important to keep in mind when writing such code is: >> >> + There are potentially many declarations. + There is potentially one >> documentation string in between the declarations. + If a potential >> documentation string is not followed by any other code, it's actually >> not a documentation string, but the method/function body (so the body >> returns a constant string). > > Actually, I'm not sure that it really is an ERROR to have multiple > strings in the beginning of the method body. It seems to me that one > should at most issue a WARNING for that situation. > > After all, the following code would be legal Common Lisp: > > (defmethod odd-method (self) > "This method has some extra stuff" > (print self) > "This string is really odd, since it isn't returned or processed" > :done) > > and it seems to me that the following should also be legal: > > (defmethod odd-method (self) > "This method has some extra stuff" > "This string is really odd, since it isn't returned or processed" > (print self) > :done) > > which is similar to > > (defmethod odd-method (self) > "This method has some extra stuff" > 'unused-symbol > (print self) > :done) > > The second string would just be ignored, since it evaluates to itself > and then isn't used. But it hardly seems like it would be a situation > that should signal an ERROR. > > It also seems that there is an ambiguity in the parsing rules (based on > the grammar in the Hyperspec) for a situation where you only have a > string in the DEFUN/DEFMETHOD form: > > defun function-name lambda-list [[declaration* | documentation]] form* > > It seems that one could choose to parse the string as being the > documentation string and there being no FORMs in the body, or one could > parse it as being no documentation string and a single FORM in the body. 3.4.11 Syntactic Interaction of Documentation Strings and Declarations In a number of situations, a documentation string can appear amidst a series of declare expressions prior to a series of forms. In that case, if a string S appears where a documentation string is permissible and is not followed by either a declare expression or a form then S is taken to be a form; otherwise, S is taken as a documentation string. The consequences are unspecified if more than one such documentation string is present. So: (defun foo () "foo") ; value (defun bar () "foo" ; docstring "bar") ; value (defun baz () "foo" ; docstring "bar" ; unspecified (eg duplicate doc string error in SBCL) "baz") ; value ;;; this is fine, as 'unused-symbol is NOT a string, but a symbol (defmethod odd-method (self) "This method has some extra stuff" 'unused-symbol (print self) :done) ;;; this is "unspecified" (defmethod odd-method (self) "This method has some extra stuff" "unused-symbol" (print self) :done) Tamas
From: Thomas A. Russ on 4 Dec 2009 12:43 Tamas K Papp <tkpapp(a)gmail.com> writes: > On Thu, 03 Dec 2009 09:11:39 -0800, Thomas A. Russ wrote: > > > > Actually, I'm not sure that it really is an ERROR to have multiple > > strings in the beginning of the method body. It seems to me that one > > should at most issue a WARNING for that situation. .... > > It also seems that there is an ambiguity in the parsing rules (based on > > the grammar in the Hyperspec) for a situation where you only have a > > string in the DEFUN/DEFMETHOD form: > > 3.4.11 Syntactic Interaction of Documentation Strings and Declarations > > In a number of situations, a documentation string can appear amidst a > series of declare expressions prior to a series of forms. > > In that case, if a string S appears where a documentation string is > permissible and is not followed by either a declare expression or a > form then S is taken to be a form; otherwise, S is taken as a > documentation string. The consequences are unspecified if more than > one such documentation string is present. Ah. Didn't find that part of the Spec. It's good to see that it is taken care of. > (defun baz () > "foo" ; docstring > "bar" ; unspecified (eg duplicate doc string error in SBCL) > "baz") ; value OK. So this is officially unspecified. I, personally, would still favor a WARNING rather than an ERROR, but since the Specification says the consequences are unspecified, an implementation is allowed to do anything it wants. -- Thomas A. Russ, USC/Information Sciences Institute
From: Pascal J. Bourguignon on 4 Dec 2009 15:54 tar(a)sevak.isi.edu (Thomas A. Russ) writes: > Tamas K Papp <tkpapp(a)gmail.com> writes: > >> On Thu, 03 Dec 2009 09:11:39 -0800, Thomas A. Russ wrote: >> > >> > Actually, I'm not sure that it really is an ERROR to have multiple >> > strings in the beginning of the method body. It seems to me that one >> > should at most issue a WARNING for that situation. > > ... > >> > It also seems that there is an ambiguity in the parsing rules (based on >> > the grammar in the Hyperspec) for a situation where you only have a >> > string in the DEFUN/DEFMETHOD form: >> >> 3.4.11 Syntactic Interaction of Documentation Strings and Declarations >> >> In a number of situations, a documentation string can appear amidst a >> series of declare expressions prior to a series of forms. >> >> In that case, if a string S appears where a documentation string is >> permissible and is not followed by either a declare expression or a >> form then S is taken to be a form; otherwise, S is taken as a >> documentation string. The consequences are unspecified if more than >> one such documentation string is present. > > Ah. Didn't find that part of the Spec. It's good to see that it is > taken care of. > >> (defun baz () >> "foo" ; docstring >> "bar" ; unspecified (eg duplicate doc string error in SBCL) >> "baz") ; value > > OK. So this is officially unspecified. > > I, personally, would still favor a WARNING rather than an ERROR, but > since the Specification says the consequences are unspecified, an > implementation is allowed to do anything it wants. AFAIK, it is not unspecified. It is valid. You can have self evaluating atoms anywhere in the body of a function. (defun f () 1 "2" 3.0 :\4 5) (f) --> 5 (defun g () 1 (do-something) 2 (do-next-thing) "Notice that this can be used to insert comments in PROGN et al." 3 (do-list-thing) :finally (compute-result)) ;-) -- __Pascal Bourguignon__
From: Thomas A. Russ on 4 Dec 2009 17:09
pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > > Tamas K Papp <tkpapp(a)gmail.com> writes: > >> 3.4.11 Syntactic Interaction of Documentation Strings and Declarations > >> > >> In a number of situations, a documentation string can appear amidst a > >> series of declare expressions prior to a series of forms. > >> > >> In that case, if a string S appears where a documentation string is > >> permissible and is not followed by either a declare expression or a > >> form then S is taken to be a form; otherwise, S is taken as a > >> documentation string. The consequences are unspecified if more than > >> one such documentation string is present. > > AFAIK, it is not unspecified. It is valid. You can have self > evaluating atoms anywhere in the body of a function. Well, that is what I initially thought, too, until Tamas Papp brought the part of the Specification to my attention where is specifically says "The consequences are unspecified if more than on such documentation string is present." Thinking a bit more about it, I'm thinking that one reasonable interpretation of the intent is that the specification writers didn't want to specify if the first or the second string ended up as the documentation string for the function. I find an error there a bit harsh, which is why I prefer a warning. -- Thomas A. Russ, USC/Information Sciences Institute |