Add compiler macros to reduce materialization of intermediate collection values

[swapneils]

[I've edited the title. This interesting conversation wound up in a different place from where it started. — Scott]

I was looking through the FSet code thinking about how it could be optimized, and the first thought that came to mind was using compiler macros to remove the generic function overhead in nested FSet forms (and potentially in standalone forms as well).

• Note: Not sure how this would work from the API compatibility perspective. Does FSet currently aim to guarantee that defining new methods will immediately be reflected in existing FSet code, or is it fine to partly/fully inline FSet forms?

Aside from the API concern above, the main blocker to this was lack of info on argument types at compile time. The only means I know of to robustly solve this is the CLTL2 compatibility libraries (e.g. cl-form-types or cl-environments).

Is there any issue with adding a dependency on one or more of these libraries in the process of adding the above optimizations?

• Note: Not committing to doing this myself, I'm pretty low on bandwidth, but I think any attempt to remove the generic function overhead without removing the generic functions will require compile-time type information.