3 ms·
> Lisps in general are much more static than a language like Ruby What? You mean running code directly off of data structures like in Lisp interpreters, using
by lispm 11y ago
> Lisps in general are much more static than a language like Ruby
What?
You mean running code directly off of data structures like in Lisp interpreters, using late binding, dynamic CLOS dispatch with method combinations, a full blown meta-object protocol, etc. is more static than Ruby?
Okay...
- pron 11y agoHe means, I think, that method dispatch (i.e. function resolution) in Lisps is less dynamic than in Ruby/JS, where you resolve the call target by searching for the method name in a map -- at least as an abstraction -- belonging to the target object at runtime (or Ruby's method_missing). I am not familiar with all Lisps, but their method polymorphism is usually much more structured.
- lispm 11y agoActually CLOS (Common Lisp Object System) is more dynamic than Ruby. Every CLOS method is part of a generic function. Each generic function is a collection of methods. At runtime the applicable methods are collected, based on the runtime class graph of the arguments to dispatch over, and an effective method is assembled by a per generic function method combination. Method selection is also depending on more than one argument (the target object), but on multiple arguments. Various parts of that are implemented by a meta-object protocol in CLOS implementations, which make it possible to change the behavior of the object system at runtime in various ways.
- chrisseaton 11y ago> running code directly off of data structures I specifically addressed this. You may need to re-compile if you see a new code data structure instance, but when you've compiled the fact it came from a data structure isn't interesting. All JIT compilers have code as data - they have an IR. > late binding This is no more troublesome than it is in Ruby. > dynamic CLOS dispatch with method combination But these are optional features that you sometimes use. In Ruby all operations, method calls and most control structures use the strongest form of dynamic dispatch available in the language. > full blown MOP So does Ruby. So I can't say Lisp is any more dynamic for the compiler than Ruby. A sibling of yours mentioned a trace extension but said people don't expect it to be fast so nobody is bothering. In the implementation of Ruby I work on, we've even made set_trace_func as fast as we can.
- lispm 11y ago> All JIT compilers have code as data - they have an IR. Lisp interpreters run mutable source code, not IR. > > dynamic CLOS dispatch with method combination > But these are optional features that you sometimes use. In Ruby all operations, method calls and most control structures If you look at actual Lisp systems it's not optional. IO, Error handling, tools, ... all use CLOS. > use the strongest form of dynamic dispatch available in the language. CLOS uses a more dynamic form of dispatch. > So I can't say Lisp is any more dynamic for the compiler than Ruby. Using a compiler or interpreter makes no difference for CLOS.
- chrisseaton 11y agoWell I'm not an expert in compiling Lisp and I guess you're not an expert in compiling Ruby, so we're probably not going to come to an agreement on this.
- tokenrove 11y ago> A sibling of yours mentioned a trace extension but said people don't expect it to be fast so nobody is bothering. That's a bit of a misrepresentation of what I said. I don't know about TRACE in particular (which is not an extension but a core part of the language), but the sbcl developers in particular have been very attentive to the performance of development tools like that. (And, probably, the commercial vendors, as well.)