3 ms·

> Common Lisp's worst feature is that it feels like just about everything imaginable has a catch. You've put into words something I've struggled with saying fo

> Common Lisp's worst feature is that it feels like just about everything imaginable has a catch. You've put into words something I've struggled with saying for a while, and the exact reason I could never really enjoy working with Common Lisp. The example I always return to is the lack of pervasive use of CLOS throughout the standard. Something like generic-cl[0] feels like it should be a baseline part of the language. As it is, it's a great library. But people are hesitant to even use it, because the result of making everything generic is a loss in performance! Of course, [0] talks about optimizations they've done. I don't know how it compares to using the methods in the standard as opposed to the lib. Regardless, these libs only help when writing code, not reading it. Though don't get me wrong, that's a big deal! It's very helpful! But you wish everyone would play by those rules. [0] https://github.com/alex-gutev/generic-cl https://github.com/alex-gutev/generic-cl

vindarel 6y ago
If you want to regain performance, add-in type declarations, cl-generic will inline its functions: https://github.com/alex-gutev/generic-cl/#optimization https://github.com/alex-gutev/generic-cl/#optimization
- dTal 6y ago
  Perhaps one could write a type-inference macro. That would leave you with something like Julia, broadly speaking.
- admax88q 6y ago
  If I knew the types beforehand at compile time then I don't really _need_ the generic functions per say. Is there a CLOS implementation with inline caches for generic method dispatch?
  - reikonomusha 6y ago
    Do you mean something like this? https://github.com/guicho271828/inlined-generic-function https://github.com/guicho271828/inlined-generic-function Even if you know all the types, you still have polymorphism that can’t be efficiently monomorphized without an exponential space penalty.
    - admax88q 6y ago
      I don't think that's what I was looking for. That talks about dispatching generic functions at compile time. > you still have polymorphism that can’t be efficiently monomorphized without an exponential space penalty. Wouldn't it be linear at each call site only by the number of types that actually reach that call site? Plus you don't have to cache _all_ types at the call site, only the most frequent ones. In Java and JS for instance, dynamic dispatch is JITed away at hot spots, and can be un-jitted later to reclaim space if the spot is no longer hot. I generally don't care if a dynamic dispatch is slow if I'm only calling it a few times, but in a tight loop I want it to be inlined as much as possible.
  - fiddlerwoaroof 6y ago
    Almost all of them have something like that: Robert Strandh has a technique that looks promising[1] and is being implemented as a library, I believe. CLOS’s customization hooks allow you to switch out the implementation of “generic function” on a case-by-case basis which can be used to implement this sort of optimization. [1]: http://metamodular.com/SICL/generic-dispatch.pdf http://metamodular.com/SICL/generic-dispatch.pdf
Jtsummers 6y ago
This seems like a consequence of the language never getting another standard. If it did, and given the way Common Lisp systems work, I think there could've been something like cl2 and cl2-user packages which could've pushed more towards that generic style that CLOS promotes, and maybe eliminated some of the elements that were redundant or didn't quite fit with everything else (is it `(function sequence index)` or `(function index sequence)`?). Those conflicts make sense given the history of the language (it was created to help connect several branches of the lisp family). And the older standard would've been easily preserved in the cl and cl-user packages. But the language is essentially frozen in the existing standard, and can only be extended by community consensus right now.

vindarel 6y ago

If you want to regain performance, add-in type declarations, cl-generic will inline its functions: https://github.com/alex-gutev/generic-cl/#optimization https://github.com/alex-gutev/generic-cl/#optimization

dTal 6y ago
Perhaps one could write a type-inference macro. That would leave you with something like Julia, broadly speaking.
admax88q 6y ago
If I knew the types beforehand at compile time then I don't really _need_ the generic functions per say. Is there a CLOS implementation with inline caches for generic method dispatch?
- reikonomusha 6y ago
  Do you mean something like this? https://github.com/guicho271828/inlined-generic-function https://github.com/guicho271828/inlined-generic-function Even if you know all the types, you still have polymorphism that can’t be efficiently monomorphized without an exponential space penalty.
  - admax88q 6y ago
    I don't think that's what I was looking for. That talks about dispatching generic functions at compile time. > you still have polymorphism that can’t be efficiently monomorphized without an exponential space penalty. Wouldn't it be linear at each call site only by the number of types that actually reach that call site? Plus you don't have to cache _all_ types at the call site, only the most frequent ones. In Java and JS for instance, dynamic dispatch is JITed away at hot spots, and can be un-jitted later to reclaim space if the spot is no longer hot. I generally don't care if a dynamic dispatch is slow if I'm only calling it a few times, but in a tight loop I want it to be inlined as much as possible.
- fiddlerwoaroof 6y ago
  Almost all of them have something like that: Robert Strandh has a technique that looks promising[1] and is being implemented as a library, I believe. CLOS’s customization hooks allow you to switch out the implementation of “generic function” on a case-by-case basis which can be used to implement this sort of optimization. [1]: http://metamodular.com/SICL/generic-dispatch.pdf http://metamodular.com/SICL/generic-dispatch.pdf

Jtsummers 6y ago

This seems like a consequence of the language never getting another standard. If it did, and given the way Common Lisp systems work, I think there could've been something like cl2 and cl2-user packages which could've pushed more towards that generic style that CLOS promotes, and maybe eliminated some of the elements that were redundant or didn't quite fit with everything else (is it `(function sequence index)` or `(function index sequence)`?). Those conflicts make sense given the history of the language (it was created to help connect several branches of the lisp family). And the older standard would've been easily preserved in the cl and cl-user packages. But the language is essentially frozen in the existing standard, and can only be extended by community consensus right now.