3 ms·
> Why would you want to do that in Common Lisp? This isn't a matter of this language or that language. Are you going to deliberately use a less efficient algor
by catnaroek 11y ago
> Why would you want to do that in Common Lisp?
This isn't a matter of this language or that language. Are you going to deliberately use a less efficient algorithm or a more convoluted design, just to please your language of choice? No idea about you, but, when a programming language doesn't let me express what I want, I don't force myself to want something else - I switch languages.
> To be honest, I think folks imagine the wrong things when looking at CLOS. They think it's Lisp foray into statically-typed OOP like C++. But it isn't. Lisp stays dynamically typed.
I never said CLOS is Lisp's take on static typing. I'm just offering an example of a use case for which CLOS isn't as powerful as other existing alternatives.
> The task you're proposing is nonsensical "in CLOS". It's just not Lisp-y :-)
This doesn't make sense. What I'm asking for is fundamental if you want generic programming to work: generic algorithms must be specializable for performance reasons, while still providing a uniform interface to users.
- eliben 11y agoYou can implement this in Lisp. The dispatch will be at runtime, not compile time. I don't think CLOS supports this use case, but the rest of Lisp certainly does. The issue will be speed, as I mentioned before.
- catnaroek 11y ago> You can implement this in Lisp. The dispatch will be at runtime, not compile time. That would be fine with me, but... > I don't think CLOS supports this use case, but the rest of Lisp certainly does. How exactly? Manually branching on the type of an object is ugly and non-extensible, and thus the antithesis of good modular design. Or are you proposing creating a whole new object system, in parallel to CLOS, but which supports this one additional feature? My copy of AMOP suggests that the design of CLOS is intended to avoid this kind of scenario: “The metaobject protocol approach (...) is based on the idea that one can and should "open languages up," allowing users to adjust the design and implementation to suit their particular needs.” (p. 1) “Rather than supplying the user with a fixed, single point in the space of all language designs and implementations, we would instead support a region of possible designs within that overall space. (...) Users are free to move to whatever point in that region best matches their particular requirements.” (p. 5-6)