Steel Bank Common Lisp

Lars Brinkhoff <lars@...> writes:
> Is this the preferred way to muffle the style warning mentioned in the
> subject line?
> (locally (declare (sb-ext:muffle-conditions style-warning))
>          (defun foo (&optional x &key y) (+ x y)))

If not, what is?

Lars Brinkhoff <lars@...> writes:

> Lars Brinkhoff <lars@...> writes:
>> Is this the preferred way to muffle the style warning mentioned in the
>> subject line?
>> (locally (declare (sb-ext:muffle-conditions style-warning))
>>          (defun foo (&optional x &key y) (+ x y)))
>
> If not, what is?

Well, my preferred way would be not to have &optional and &key in the
same lambda list.  Failing that, your form is what I would suggest.

If you are worried about style-warning being too coarse a class to
muffle, even for just the lambda list (because you can get your
style-warnings for the body back by doing
  (locally
    (declare (muffle-conditions style-warning))
    (defun foo (&optional x &key y) ; bletch
      (declare (unmuffle-conditions style-warning))
      (+ x y)))

Cheers,

Christophe

Christophe Rhodes <csr21@...> writes:
>> Lars Brinkhoff <lars@...> writes:
>>> Is this the preferred way to muffle the style warning mentioned in the
>>> subject line?
>>> (locally (declare (sb-ext:muffle-conditions style-warning))
>>>          (defun foo (&optional x &key y) (+ x y)))
>
> Well, my preferred way would be not to have &optional and &key in the
> same lambda list.

Agreed, but sometimes there's no choise.  (Like, when you're
implementing read-from-string as specified by ANSI CL.)

> Failing that, your form is what I would suggest.

Thanks.

Christophe Rhodes <csr21@...> writes:

> Lars Brinkhoff <lars@...> writes:
>
>> Lars Brinkhoff <lars@...> writes:
>>> Is this the preferred way to muffle the style warning mentioned in the
>>> subject line?
>>> (locally (declare (sb-ext:muffle-conditions style-warning))
>>>          (defun foo (&optional x &key y) (+ x y)))
>>
>> If not, what is?
>
> Well, my preferred way would be not to have &optional and &key in the
> same lambda list.  Failing that, your form is what I would suggest.
>
> If you are worried about style-warning being too coarse a class to
> muffle, even for just the lambda list (because you can get your
> style-warnings for the body back by doing
>   (locally
>     (declare (muffle-conditions style-warning))
>     (defun foo (&optional x &key y) ; bletch
>       (declare (unmuffle-conditions style-warning))
>       (+ x y)))

Whoops.  There was an end to this sentence planned when I started
writing it...

If you are worried about style-warning being too coarse a class to
muffle, then thoughts on a sensible hierarchy of style-warning
conditions that can be documented and exported from an extension
package are appreciated.

Cheers,

Christophe

Christophe Rhodes <csr21@...> writes:
> If you are worried about style-warning being too coarse a class to
> muffle, then thoughts on a sensible hierarchy of style-warning
> conditions that can be documented and exported from an extension
> package are appreciated.

I'm sorry, but I don't have any suggestions.  In almost every case, it
would be better to code around this particular style warning, so I
couldn't justify putting it in any particular place in such a hierarchy.