For the record, uiop has a general (but not extensible) accessor called access-at. lisp-interface-library has an extensible interface function lookup — and yes, it works both on alist and on plist (if you supply an appropriate interface object).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The shipwreck survivor's law: after a catastrophe, only the few survivors erect votive shrines to thank deities for having saved them. The many casualties don't erect anti-shrines to spit their contempt at the same deities that failed to save them. On Thu, Feb 4, 2016 at 2:25 PM, Steve Haflich <shafl...@gmail.com> wrote: > <silly_question> > Does it work for plists? For alists? > </silly_question> > > Can the user write methods to add his own structures/classes/constructs to > the set understood by REF? > > More seriously, this function seems to me to be an over generalization, > distorting CL style. Built into the numerous built-in ways of supporting > data in CL are assumptions about the efficiency and scaling of the various > kinds. Although efficiency might not matter for particular low-bandwidth > operations, in other places it will certainly matter. That's obvious. But > even more important is that use of an over-generalized reference operator > makes the code harder to read and understand. If I see an aref, I know I'm > looking at an array, understand something about the expected performance, > and know what to look for elsewhere in a huge module to examine where this > array is constructed and modified. > > For me, traditional CL operators have a nice, time-tested balance between > generality and specificity.