> Common Lisp's evaluation semantics are a language of it's own practically at this point and are very far removed form most languages.
Huh? What do you mean? The separate function namespace? Evaluation rules in CL, strictly speaking, are very simple.
* Symbols evaluate to variable values, lists evaluate to function/macro/special operator calls, and everything else evaluates to itself.
* The first element of a list is either a symbol that names a function/macro/special operator, or a lambda form that denotes an anonymous function.
* If we're calling a function, evaluate all argument forms and apply the function to them; if we're calling a macro, pass all argument forms as-is into the macroexpansion function; if we're calling a special operator, it's up to the implementation to make sense of this.
What's this "a language of its own" that you mean?
Ok; One thing that makes this not obvious is that common lisp is a huge language, and scheme is a small one. And since common lisp is multiparadigm, you can work with it in ways that are very much not not like scheme. But you can also use a subset with a very similar paradigm.
Some of it is philosophical I suppose. Fundamentally they are both lisps. Both opinionated about what that means, but they are lisps.
The fundamental objects in the language are congruent. I find them quite similar for REPL driven exploratory design, in a way that python never quite gets. Although there is a deep schism on macro hygiene, they both have deeply integrated macros. They both allow for clean functional approaches and deep recursion in practice. Both get low level enough to get decent performance from the language itself (unlike python).
I guess what I'm saying is I can write CL code that feels very scheme like in approach and also is comfortable in the language. The same is not close to true of python.
> They both allow for clean functional approaches and deep recursion in practice.
Please tell me what kind of functional approaches Common Lisp and Scheme allow that Python doesn't.
Scheme is the only one o the three that has t.c.e. as a language feature, of course.
> Both get low level enough to get decent performance from the language itself (unlike python).
Scheme is far, far more performant than C.L. and that's due to language design choices.
> I guess what I'm saying is I can write CL code that feels very scheme like in approach and also is comfortable in the language. The same is not close to true of python.
I think you might simply not know how to or believe that it feels more Scheme like simply because it's written in a similar syntax.
Even JavaScript started as a Scheme dialect that later was given alternative syntax, mind you.
There is however one big thing: and that is that Python lacks true block scope, which both Scheme and Common Lisp have, but on the flip-side Common Lisp has dynamic variables, and different cells for functions and values. as well as `setf`.
> Scheme is the only one o the three that has t.c.e. as a language feature, of course.
Though Common Lisp implementations have been providing it for decades. 't.c.e.' is an optimization feature of various Common Lisp compilers.
> Scheme is far, far more performant than C.L. and that's due to language design choices.
That's not the case.
Actually Common Lisp has a lot of language features which make it performant: stack allocation hints, type hints, inline declarations, compilation semantics, implementation specific feature limits, etc. One of the design goals of Common Lisp was to support optimizing compilers on various platforms.
I've mostly been staying out of this thread because I really don't know what the point of this discussion is, but:
> Scheme is far, far more performant than C.L. and that's due to language design choices.
That's nonsensical. You're comparing language specs for performance, and not implementations here. Both can achieve high levels of efficiency from their code, depending on the implementation decisions taken by the particular compiler/interpreter you're electing to use, as well as which data structures and mechanisms you elect to use from each language.
> Scheme is far, far more performant than C.L. and that's due to language design choices.
Even if that claim is empirically pretty dubious it's idiosyncratic at best to compare putative design impacts of specifications (rather than implementations) between CL and scheme ... when python is in your mix.
I suspect this isn't going anywhere useful so I'm out.
