In article <··············@eho.eaglets.com>, ···@goems.com wrote:
> Right now I have the following (I omit `unwind-protect', `let' etc):
>
> (defmacro with-zzz ((&rest options) &body body)
> `(progn (zzz-options ,@options) ,@body))
You could write a DEF... macro that hides the options, e.g.
(defconstant more-options-names '(opt1 opt2 opt3 opt4 opt5 opt6 opt7 opt8
opt9 opt10))
(defmacro with-zzz-options (&body body)
`(progn (zzz-options opt0 ,@more-options-names) ,@body))
(defmacro defzzzfun (name args
(&optional (opt0default nil o0dfltp))
&body body)
`(defun ,name (,@args &key
,(if o0dfltp `(opt0 ,opt0default) `opt0)
,@more-options-names
;; More options?
)
. ,body))
> (defun zzz-options (opt0 opt1 opt2 ... opt10)
> "called only from `with-zzz'"
> ...)
(defzzzfun zzz-options () ()
"called only from `with-zzz'"
)
> (defun foo (arg0 arg1 &keys (opt0 foo-default) opt1 opt2 ... opt10)
> [possibly modify opt0...5, but never opt6...10]
> (with-zzz (opt0 opt1 opt2 ... opt10)
> ....))
(defzzzfun foo (arg0 arg1) (foo-default)
(with-zzz-options
))
etc.
> (defun bar (arg0 arg1 &keys (opt0 bar-default) opt1 opt2 ... opt10)
> [possibly modify opt0...5, but never opt6...10]
> (with-zzz (opt0 opt1 opt2 ... opt10)
> ....))
>
> (defun baz (arg0 arg1 &keys (opt0 baz-default) opt1 opt2 ... opt10)
> [possibly modify opt0...5, but never opt6...10]
> (with-zzz (opt0 opt1 opt2 ... opt10)
> ....))
>
> what I don't like is that whenever I want to add a new option, I have to
> modify `zzz-options' as well as `foo', `bar' and `baz'. I know of
> &allow-other-keys (and I use it in other places).
>
> Any suggestions?
>
> [This is actually for `gnuplot' interface for CL, if anyone wants, I can
> post or e-mail it, it works pretty nicely with CLISP, CMUCL and ACL.]
In article <····················@x063.bit-net.com>, ···@flavors.com (David
D. Smith) wrote:
> In article <··············@eho.eaglets.com>, ···@goems.com wrote:
>
> > Right now I have the following (I omit `unwind-protect', `let' etc):
> >
> > (defmacro with-zzz ((&rest options) &body body)
> > `(progn (zzz-options ,@options) ,@body))
>
> You could write a DEF... macro that hides the options, e.g.
>
> (defconstant more-options-names '(opt1 opt2 opt3 opt4 opt5 opt6 opt7 opt8
> opt9 opt10))
>
> (defmacro with-zzz-options (&body body)
> `(progn (zzz-options opt0 ,@more-options-names) ,@body))
>
> (defmacro defzzzfun (name args
> (&optional (opt0default nil o0dfltp))
> &body body)
> `(defun ,name (,@args &key
> ,(if o0dfltp `(opt0 ,opt0default) `opt0)
> ,@more-options-names
> ;; More options?
> )
> . ,body))
...
P.S. This is an example. This is ONLY an example. Had this been a real
piece of code, you would have been instructed in how to survive it.
d
···@flavors.com (David D. Smith) writes:
> > You could write a DEF... macro that hides the options, e.g.
> >
...
> > (defmacro defzzzfun (name args
> > (&optional (opt0default nil o0dfltp))
> > &body body)
> > `(defun ,name (,@args &key
> > ,(if o0dfltp `(opt0 ,opt0default) `opt0)
> > ,@more-options-names
> > ;; More options?
> > )
> > . ,body))
This is a possibility, of course. And not to be neglected. One
negative of it is, though, that all the code that touches the
dataflow has to be recompiled to accomodate new options. The
&allow-other-keys pass-through style is more resilient, requiring only
those options that are affected by the change to be recompiled.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@flavors.com (David D. Smith) writes:
>
> > > You could write a DEF... macro that hides the options, e.g.
> > >
> ...
> > > (defmacro defzzzfun (name args
> > > (&optional (opt0default nil o0dfltp))
> > > &body body)
> > > `(defun ,name (,@args &key
> > > ,(if o0dfltp `(opt0 ,opt0default) `opt0)
> > > ,@more-options-names
> > > ;; More options?
> > > )
> > > . ,body))
>
> This is a possibility, of course. And not to be neglected. One
> negative of it is, though, that all the code that touches the
> dataflow has to be recompiled to accomodate new options. The
> &allow-other-keys pass-through style is more resilient, requiring only
> those options that are affected by the change to be recompiled.
Personally I think it is very important that later the
allowed options (keywords args for example) are recoverable in
the development environment.
I preferrably want to know for each macro and each function which
args are allowed and which not. Also wrong args should
be detected at the point where they are introduced.
Ideally this should all be detected by the compiler and
not at runtime.
Stuff where the keywords are processed as lists and filtered
and given to subfunctions which are doing the same
generated by macros that are also freely processing
arglists - this is a maintenance nightmare.
--
http://www.lavielle.com/~joswig