Re: GETF Speedup?
"David McClain (as dbm at refined-audiometrics dot com)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
Function definitions in most of my code will often use &KEY and &REST argument lists. The problem I often see is that BOA arg lists become very cumbersome for more then 3-4 arguments. You have to exert effort to remember which parameter goes in what position. And often times there are conflicting BOA conventions. So using &REST along with &KEY is a very convenient thing to have. It removes the need to remember order and number of args, and you can pass all of them along, sometimes with overrides by prefixing the &rest args with your own values for some keywords. Why this is so important to me, is that I often have factory functions that produce behavior functions. And the arg lists to the factory function become a local database of state values for the resulting functional closure. These local databases are not global, but they are visible to all threads who call on the functional closure. And so they are shared values nonetheless. And many times the behavior function will want to mutate the values in this local database. The only safe and reentrant way to do this is to perform a BECOME with the same or different behavior function along with a mutated COPY of the original arg list. BECOME is a mediated mutation of just the behavior slot of a wrapper envelope for the functional closure. You can change as much or as little as you like with just one slot mutation. > On Oct 12, 2025, at 09:20, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote: > > On 12 Oct 2025, at 15:21, David McClain <[email protected]> wrote: >> >> &REST… um, sorry, I meant &KEY args, when taken along with &REST, so that I can transport all of the keyword associations in bulk. > > I'd assume (but I may be wrong) that the cases where function call uses anything like plists are really only APPLY and perhaps FUNCALL. Of course those can matter! > > --tim > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > [email protected] > http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html