Not to take away from the general comparisons between various Lisp flavors and between various scripting languages (an activity I engage in quite often), but your lead off line is more prescriptive than I find advisable. I don't think a blanket statement that optimizations of runtime behavior of code "should" only be done via a compiler. Some devs enjoy the work, others have varied reasons for doing performance sensitive work in a given language/environment. But at the end of day, doing optimization is a valid usage of developer effort and time if that developer judges it so.

Additionally they allow to prove a point.

For example, is writing compilers systems programming or not?

> [...] GNU/MIT Scheme is what you want to follow along with MIT publications working in Scheme (like Structure and Interpretation of Computer Programs, Structure and Interpretation of Classical Mechanics, and The Art of the Propagator).

Definitely, though I suspect if you need a language that's exactly what's written in the text, you are probably missing the point? At least for SICP, I haven't looked into the others as closely. (Part of) the point being learning wider concepts.

I almost feel like you get more out of the book, if you do the exercises in a mix of JavaScript and Python. Not because those are better languages, just the opposite: because it forces you to understand the concepts well enough to translate them.

    lift :: Vec (a->b) -> (a->Vec b)
    lift [] a = []
    lift f:fs = (f a):(lift fs $ a)

    ((fx fy fz) r)

For example, `guile-scmutils`[0] says:

> Functionality not available in the port:

> Scheme extension to allow applying vectors/structures as procedures. For example rather than

    1 ]=> (pe ((up (literal-function 'x) (literal-function 'y)) 't))
    (up (x t) (y t))

    guile> (pe ((lambda (t) (up ((literal-function 'x) t) ((literal-function 'y) t))) 't))
    (up (x t) (y t))

  (define (juxt . fns)
    (lambda args
      (map (lambda (fn) (apply fn args)) fns)))

    lift = fix ((`ap` tail) . (. head) . flip ((.) . liftM2 (:)))

It is possible to fill in basic function bodies based on their type, using ghc-justdoit (https://hackage.haskell.org/package/ghc-justdoit). That's maybe not what you meant, if you are looking for integrating pointfree into Haskell it can be added to ghci or your development environment.

    foo :: ((a -> r) -> r) -> (a -> ((b -> r) -> r)) -> ((b -> r) -> r)
    foo = (…)

      flip \a -> ($ a)
    = flip (&)
    = flip (flip ($))
    = ($)

    (??) :: Functor f => f (a -> b) -> a -> f b
    funs ?? a = fmap ($ a) funs

This is valid definition of lift along a different, less interesting but more general axis.

    lift = (??) @[]

    lift = flip $ \a -> ($a)

I can't recommend MIT Scheme for anything these days; it's just missing too many things that I feel are required for real work in Scheme, and has too many idiosyncrasies and quirks. Even using it to run a standalone program written in Scheme is a pain.

Serapeum has you covered: https://github.com/ruricolist/serapeum/blob/master/REFERENCE...

It also doesn't help that Schemes like Guile are also interactive. The domain of an interactive language and a "compiled" language are quite different.

Given the entirety of the program made available to the compiler all at once, there are high level derivations that can happen notably through flow analysis to let the compiler make better decisions. But do that in an interactive environment when the rug can be pulled out of any of the assumption the compiler made, and things get messy quite quickly.

One interesting tidbit for Java is that the developers of the compiler advocate "idiomatic" Java. Simply, write Java like Java, and don't try to trick the compiler. Let the compiler developers trick the compiler.

That's evident here in this article when they wrote the function that tests the types of the parameters. Raw Scheme, naturally, doesn't allow you to specify parameter types, not the way you can in Common Lisp, for example. And, either Guile does not have an specific extension to support this, or simply the compiler looks for this type checking pattern at the top of a function to make optimization determinations. On the one hand, it could be more succinct with a specialized facility, but on the other, this is "just Scheme".

So, in effect by checking for the type of the variable, they're implicitly declaring the type of the variable for the "sufficiently smart" compiler to make better decisions.

The counter example is the "define-inline" construct, and thus not standard Scheme (though readily replaced by a "no-op" macro if one was interested in porting the code).

Haskell's GHC does quite well with its 'ghci' interactive environment. GHC is a compiler first and foremost, and as far as I can tell, ghci works by compiling each line you give it one by one? (But even in ghci, you have to abide by the type system of Haskell, so that might help.)

The Common Lisps were always pretty good at combining compiled and interpreted parts, even in the same program. And I think OCaml also does a good job of combining the two approaches?

https://bibliography.selflanguage.org/_static/dynamic-deopti...

Plus guile comes with a more comprehensive standard library; on the other hand, chicken's package manager and available packages do make up for that.