4 ms·

Through things like this library, which, combined with a Sufficiently Smart Compiler (SBCL qualifies as one for this purpose), produces C++-like static dispatch

by gecko 10y ago

Through things like this library, which, combined with a Sufficiently Smart Compiler (SBCL qualifies as one for this purpose), produces C++-like static dispatch for cases such as the one you're proposing. https://github.com/guicho271828/inlined-generic-function https://github.com/guicho271828/inlined-generic-function

catnaroek 10y ago
It's not only about speed, it's also about deeply specializing templates.
- eliben 10y ago
  But templates are about speed. Clojure-type dispatch can be easily implemented in CLOS (all of CLOS is just a set of Lisp macros and functions), and it's fully general. You can "deeply specialize" to your heart's content, the only issue being speed. As another comment mentioned, some compilers are smart enough to see through things that are known at compile time, or perhaps even JIT-specialze at runtime, but it's all about speed.
  - catnaroek 10y ago
    It's not only about speed. It's about dispatching on types that themselves are template instantiations. As an exercise, write a CLOS generic function that takes a list, and prints its elements forwards if the elements are ints, but prints them backwards if they are strings. You aren't allowed to use anything other than CLOS multimethods for type dispatch. In C++ this is super simple.
    - eliben 10y ago
      Why would you want to do that in Common Lisp? 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. The task you're proposing is nonsensical "in CLOS". It's just not Lisp-y :-) I think this discussion has gotten fairly far from the main point by now. There's no real use trying to twist one language to achieve every feature of another.
      - catnaroek 10y 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 10y ago
        You 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 10y 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)
    - lispm 10y ago
      C++ : Static. Compile-time method selection. But not dynamic. CLOS: Dynamic dispatch is possible, given extensions like predicate dispatch. ftp://publications.ai.mit.edu/ai-publications/2001/AITR-2001-006.pdf
      - catnaroek 10y ago
        No amount of runtime predicate dispatch is going to tell you if a particular occurrence of `nil` is intended to be used as a list of ints or as a list of strings, because runtime checks can't “see into the object's future”. On the other hand, a type checker can easily infer this, in some languages.
        lispm 10y ago
        Type checker = static.
  - GregBuchholz 10y ago
    >Clojure-type dispatch can be easily implemented in CLOS Can be implemented in CLOS or Common Lisp? Are you thinking of something using the metaobject protocol? Catnaroek's challenge is interesting, and would seem on the surface to not be possible with CLOS.

by gecko 10y ago

catnaroek 10y ago

It's not only about speed, it's also about deeply specializing templates.

eliben 10y ago
But templates are about speed. Clojure-type dispatch can be easily implemented in CLOS (all of CLOS is just a set of Lisp macros and functions), and it's fully general. You can "deeply specialize" to your heart's content, the only issue being speed. As another comment mentioned, some compilers are smart enough to see through things that are known at compile time, or perhaps even JIT-specialze at runtime, but it's all about speed.
- catnaroek 10y ago
  It's not only about speed. It's about dispatching on types that themselves are template instantiations. As an exercise, write a CLOS generic function that takes a list, and prints its elements forwards if the elements are ints, but prints them backwards if they are strings. You aren't allowed to use anything other than CLOS multimethods for type dispatch. In C++ this is super simple.
  - eliben 10y ago
    Why would you want to do that in Common Lisp? 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. The task you're proposing is nonsensical "in CLOS". It's just not Lisp-y :-) I think this discussion has gotten fairly far from the main point by now. There's no real use trying to twist one language to achieve every feature of another.
    - catnaroek 10y 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 10y ago
        You 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 10y 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)
  - lispm 10y ago
    C++ : Static. Compile-time method selection. But not dynamic. CLOS: Dynamic dispatch is possible, given extensions like predicate dispatch. ftp://publications.ai.mit.edu/ai-publications/2001/AITR-2001-006.pdf
    - catnaroek 10y ago
      No amount of runtime predicate dispatch is going to tell you if a particular occurrence of `nil` is intended to be used as a list of ints or as a list of strings, because runtime checks can't “see into the object's future”. On the other hand, a type checker can easily infer this, in some languages.
      - lispm 10y ago
        Type checker = static.
- GregBuchholz 10y ago
  >Clojure-type dispatch can be easily implemented in CLOS Can be implemented in CLOS or Common Lisp? Are you thinking of something using the metaobject protocol? Catnaroek's challenge is interesting, and would seem on the surface to not be possible with CLOS.