| Part of the problem is that raw Scheme is spectacularly underspecified. 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). |
https://bibliography.selflanguage.org/_static/dynamic-deopti...