search

ruricolist / serapeum

Utilities beyond Alexandria
MIT License
425 stars 42 forks source link

More alist access macros. #36

Open vale981 opened 5 years ago

vale981 commented 5 years ago

Hi, I've written some macros to make alist access nicer for nested alists. They sure need polish which I'd add if you would be interested in adding them to serapeum.

Cheers.

ruricolist commented 5 years ago

Pull requests are always welcome, though I can't promise anything.

vindarel commented 5 years ago

Hello, do you mean something similar to access? https://github.com/AccelerationNet/access/ It allows nested access: (access:accesses <obj> <elt1> <elt2> etc).

vale981 commented 5 years ago

Geez. I should have found that earlier :P.

Although "A word on performance" in the readme maybe calls for something more minimalistic.

phoe commented 2 years ago

@vale981 Have you ever managed to submit a PR? Is this issue still valid?

vale981 commented 2 years ago

@vale981 Have you ever managed to submit a PR? Is this issue still valid?

Hi, these macros are in https://github.com/tu-phys/nougat-web/blob/ed603fa61aa8e917638aafb1266d9973cbb82183/src/discourse.lisp#L64. I'm not sure if they're nice enough for general use though.

phoe commented 2 years ago

I'm not really convinced after reading the definitions for agett, aget, and agets; they can be easily fixed to avoid multiple evaluation and all, but the design makes me wondering. I would rather use Access for accessing alists like that, and if performance is a problem, then using alists already sounds like a wrong choice.

ruricolist commented 2 years ago

I can certainly understand wanting convenient accessors for nested data structures (we have one already for hash tables, as href) but it's not obvious how it would work in cases where, say, alists at different levels should use different tests.

phoe commented 2 years ago

but it's not obvious how it would work in cases where, say, alists at different levels should use different tests.

~> probably solves that one. If anything, a custom assoc~> macro might save you writing alexandria:assoc-value multiple times in a row, but I have no idea if that can be considered a feature.