Let's say I'm writing a macro which accepts declarations like do. Let's say argument a to the macro may or may not be a declaration. Is this the right way to check ?
(if (and (consp a) (eq (car a) 'declare)) ; It's a declaration ; It isn't )
-- A mouse is a device used to point at the xterm you want to type in. A.S.R.
On 2009-12-02 22:02:48 +0000, Spiros Bousbouras <spi...@gmail.com> said:
> Let's say I'm writing a macro which accepts declarations like do. Let's > say argument a to the macro may or may not be a declaration. Is this > the right way to check ?
> (if (and (consp a) (eq (car a) 'declare)) > ; It's a declaration > ; It isn't )
I think so. Remember you can have lots of declarations so you have to walk down the body of the macro until you get to something that is not DECLARE form.
Spiros Bousbouras <spi...@gmail.com> writes: > Let's say I'm writing a macro which accepts declarations like do. Let's > say argument a to the macro may or may not be a declaration. Is this > the right way to check ?
> (if (and (consp a) (eq (car a) 'declare)) > ; It's a declaration > ; It isn't )
Of course. That's what macros do, they process code, and declarations are code.
On Dec 3, 12:11 am, Tim Bradshaw <t...@cley.com> wrote:
> On 2009-12-02 22:02:48 +0000, Spiros Bousbouras <spi...@gmail.com> said:
> > Let's say I'm writing a macro which accepts declarations like do. Let's > > say argument a to the macro may or may not be a declaration. Is this > > the right way to check ?
> > (if (and (consp a) (eq (car a) 'declare)) > > ; It's a declaration > > ; It isn't )
> I think so. Remember you can have lots of declarations so you have to > walk down the body of the macro until you get to something that is not > DECLARE form.
It's to bad that PARSE-BODY isn't in the spec. Not the least because every implementation seems to have such a function, although not all export it as interface.
Spiros Bousbouras wrote: > Let's say I'm writing a macro which accepts declarations like do. Let's > say argument a to the macro may or may not be a declaration. Is this > the right way to check ?
> (if (and (consp a) (eq (car a) 'declare)) > ; It's a declaration > ; It isn't )
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).
Yes, declarations can be a bitch to deal with in your own macros. But they are not as bad as inner defines in Scheme... :-P
On Dec 2, 11:02 pm, Spiros Bousbouras <spi...@gmail.com> wrote:
> Let's say I'm writing a macro which accepts declarations like do. Let's > say argument a to the macro may or may not be a declaration. Is this > the right way to check ?
There's a library by Tobias C. Rittweiler. I have not used it yet but its functionality seems quite extensive. It has "declaration- env.affected-variables" for example:
Pascal Costanza <p...@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:
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
On Thu, 03 Dec 2009 09:11:39 -0800, Thomas A. Russ wrote: > Pascal Costanza <p...@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:
> 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)
> 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.
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
>> 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.
> 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)) ;-)
p...@informatimago.com (Pascal J. Bourguignon) writes:
> > Tamas K Papp <tkp...@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
