fast-generic-functions

>For example, it cannot specialize an element type for lists. Yes, but that would be a CL violation (or an extension to provide via something else than DEFTYPE), since DEFTYPE's body can't be infinitely recursive; cf https://www.lispworks.com/documentation/HyperSpec/Body/m_def... >if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python. Indeed, but 1) it is used by the compiler itself while cpython currently ignores annotations and 2) runtime and buildtime typing use the same semantics and syntax, so you don't need band-aids like https://github.com/agronholm/typeguard But yeah, CL's type system is lacking in many places. In order of practical advantages and difficulty to add (maybe): recursive DEFTYPE, typed HASH-TABLEs (I mean the keys and values), static

> Thing is that you need a complex JIT like Julia's or stuff like https://github.com/marcoheisig/fast-generic-functions to offset the cost of constant dynamic dispatch. Julia is always the odd one out, when talking about dynamic vs. static dispatch, because its JIT compiler acts more like an Ahead-of-Time compiler in many regards. In the best case, types are statically decidable and Julia's compiler just produces a static dispatch and native code like e.g. a C compiler would. In the worst case, there are a big (or unlimited) number of type candidates. The grey area in between, where there are a limited number of type candidates, is interesting. As far as I understand, Julia does something similar to the link you provided. Based on some heuristics it will compile instances for a "sealed" number of candidates and fallback to a fully dynamic

Common Lisp doesn't use (expensive) CLOS dispatch in the core language, e.g. to add two numbers or find the right equality operator. That's one known pain point due to CLOS having been "bolted-on" rather than part of the language which makes the divide between internal (using typecase and similar) and external (generic functions) dispatch pretty ugly; and gave use the eql/equal/equalp/etc... hell. Thing is that you need a complex JIT like Julia's or stuff like https://github.com/marcoheisig/fast-generic-functions to offset the cost of constant dynamic dispatch. I actually had such a conversation on that comparison earlier this year: https://lwn.net/Articles/1032617/

> I'm sadly not very well versed with this alternative to OOP. But something tells me that a more "basic" and less dynamic scheme like that is probably best for performance reasons, since you'd either need a Julia-like JIT or a granular "dynamism knob" like https://github.com/marcoheisig/fast-generic-functions to truly amortize the cost of CLOS-like dispatch and polymorphism; though magic can be done, as the "Fast generic dispatch for Common Lisp" paper shows. You know, for someone who isn't "well versed" with it, you certainly nailed exactly why I chose it. Also, simplicity. The "as easy as Python" is only possible if I remove complecting [1] things like inheritance. > Huh! If this includes types deduced by compiler inference and not just user declarations (since Yao seems gradually typed, to my eyes), that'd be pretty impressive. It doe

> However, Yao will not have inheritance; instead, it will be more like Go: composition over inheritance. And interfaces. So I could be wrong, but without inheritance, I'm not sure the entire complexity of the CLOS is needed. Do correct me, though. I'm sadly not very well versed with this alternative to OOP. But something tells me that a more "basic" and less dynamic scheme like that is probably best for performance reasons, since you'd either need a Julia-like JIT or a granular "dynamism knob" like https://github.com/marcoheisig/fast-generic-functions to truly amortize the cost of CLOS-like dispatch and polymorphism; though magic can be done, as the "Fast generic dispatch for Common Lisp" paper shows. > if those are just for giving info to macros, Yao already has that Huh! If this includes types deduced by compiler inference and not just

(Talking about CL) Isn't gradual typing with a typed standard library enough? Because that's kind of what SBCL provides. Anyway, some other reasons: * Baby ducks who can't get over the parentheses (which quickly become invisible to the eye, you read Lisp via its indentation). * Baby ducks who can't get over too weird/big differences from C/C++/C#/Java/etc... like CL's compilation model. * ML typing being /the/ fad these days. * Low-level fetishism. I know a lot about this, since I've had my own C weenie phase (you know, the kind to spit on GC by principle) as a young university student, before turning smug lisp weenie ten years later; Tcl was actually my gateway drug into useful homoiconicity. * Some hard technical limitations: * No user accessible parametric deftype. * No recursive deftype (so no typed lists/trees). * Gimped hash

> SBCL has two interpreters, IIRC. You can configure SBCL to use an interpreter. SBCL's original "interpreter" is %simple-eval, which just calls the compiler. SB!EVAL was added sometime around 2008, but as you point out it is not used unless you set evaluator-mode to something other than :compile. The default code path goes through %simple-eval and the compiler. I have been using SBCL since before SB!EVAL was added, and I have never used the interpreter. > ECL has three ways to run code: an interpreter, a byte code engine and a Lisp-to-C compiler The confusing thing about ECL is that someone decided to call their bytecode VM an "interpreter." ECL has no interpreter - eval_nontrivial_form just calls the bytecode compiler. All that is irrelevant to the fact that ECL uses GCC as a JIT. > In theory one could use a JIT to compile the byte code