Re: GETF Speedup?

Ahh, yes! You are correct - so long as the property lists are just arguments to a function. 

But if the function you call with the keyword args (or dictionary) is just a factory function, and what functional closure it produces has multiple clauses found by pattern matching on incoming messages, then every message produces a function entry of sorts, and each different entry point only needs to refer to a few dictionary entries.

You end up doing GETF on just the dictionary entries you care about. And more likely, you supplant one or more of them with fresh data, or remove one or more of them, before calling BECOME to update the internal database. 

So you wouldn’t want to scan for every keyword possible in the dictionary, which is what happens when you spell out all the keywords with their default values.

And for long lived, evolving, functional closures you need to be concerned about the stale garbage at the tail of the property list, if all you do for supplanting is to prefix the dictionary with updated keyword associations.

> On Oct 13, 2025, at 02:36, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
> 
> I think that's a common approach.  Certainly I do this a lot and keyword args in CL are clearly designed by people who thought about this
> 
> But even in cases where something needs to snarf argument values from a list and can't do something smarter at compile time, you wouldn't use GETF.  You'd walk down the list once looking for all the keywords rather than repeatedly probing it.  You need what is essentially a supplied-p parameter for each argument which you use to skip duplicates, and you need to be careful about types and when defaults get evaluated.  This is what DSM does, anyway.
> 
> I wrote a naïve GETF version which is about 2/3 the speed empirically and could surely be made quicker: GETF isn't doing any magic that I can see.  Walking down lists is just very quick.
> 
> --tim
> 
>> On 13 Oct 2025, at 01:58, David McClain <[email protected]> wrote:
>> 
>> 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
> 
> _______________________________________________
> 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