How an Optimizing Compiler Works
lihaoyi.com
lihaoyi.com
,opt expression
And it prints the source code after a first basic pass of the expander and optimizer. It does constant folding, inlining, dead code elimination and partial evaluation (and some other things). Being able to inspect what guile does helps a lot with macro writing, and is just a generally handy tool.It beats reading assembly (which is also available) any day of the week.
This is why optimisations aren't usually source-to-source - they need to include in the output extra information that isn't normally representable in source code. Another reason is that compiling to a lower-level representation gives you more power - when I partially evaluate I gain extra information such as that an add operator will not overflow, and I want to include that valuable information in my output even if there is no no-overflow add operator in the source language.
Those syntax objects are also the basis of the hygienic macro systems in many schemes (at least ones using syntax-case) so that macros also benefit from that information.
The lisp source representation is already an AST, so these kinds of transformations are trivial.
In the particular case of ackermann(2, 2) you should be able to do it with a moderate number of inlinings, but I don't think compilers often bother to inline more than one level of a recursive function.
[1] Of course you can force compile-time evaluation of code in some languages, like with Lisp macros or C++ templates. But that's not what's happening here.
It starts at 0 and keeps multiplying itself with integers, which should always result in 0.
EDIT: My bad, it is explained after the code snippet, but not immediately after so I didn't catch it at first.
> multiplied does not: it starts off 0, and every time it is multiplied via multiplied = multiplied * count it remains 0.
The article then goes on to use that fact for some optimizations.
Are there any JVM engineers that could confirm or deny this happening (in the real world)?
When I used HTTPS, the page loaded fine, but then reloaded itself using HTTP, but didn't loop after that.
OP, you may want to look into figuring out why your page reloads using HTTP after loading just fine with HTTPS.
<script>if (window.location.protocol == "https:")
window.location.href = "http:" + window.location.href.substring(window.location.protocol.length);
</script>Especially since the page loads just fine. It's not like it's relying on accessing some 3rd party resource that's only accessible via HTTP.