This is not always possible. Consider the monomorphized output of a generic function. An operation may be dead in one instance but not generally

Idris is bootstrapped on scheme if I recall correctly

it's bootstrapped off of GHC.

it was only using ChezScheme as an optimizing compiler backend.

(i created a PR to refactor their build system to reify the bootstrap process all the way down from GHC. it basically generalized the normal build workflow of Idris2 to be able to animate the entire bootstrap chain from GHC. sadly, it was pretty much ignored, and later abandoned: https://github.com/idris-lang/Idris2/pull/1990)

From the Idris 2 documentation:

    >> Can Idris 2 compile itself?
    > Yes, Idris 2 is implemented in Idris 2. By default, it targets Chez Scheme, 
    > so you can bootstrap from the generated Scheme code, as described in Section 
    > Getting Started.

Also, check this talk:

https://www.youtube.com/watch?v=h9YAOaBWuIk

well, i wouldn't call that beeing bootstrapped.

in this case the generated scheme code is just a strange form of executable file that happens to need ChezScheme to be executed.

i.e. an ELF64 idris2 linux binary vs. an idris2.scm file that needs ChezScheme to come alive.

as for Idris2 implemented in Idris2: well, yes, that's true for the current version of Idris2. but the first version of Idris2 was written in Idris1. and the first version of Idris1 was written in Haskell.

I’m not even remotely close to knowledgeable on this subject but I assume metal eating microbes are not possible because metals are not molecular and therefore there’s nothing for them to be broken down into

Why is this being down voted? It's a question?

I get this in every day life, but it comes whenever I have to adjust the pods in my ears. But frankly I kinda expected these to pretty much suck until someone comes out with fully foam tips, at which point my problem will be completely solved as I no longer will have a need to adjust them

But importantly, they’re NOT!

sexpression based hygienic macros

I mean, not to sound rude, but of course it would be someone high up who would make that decision. It’s not like a grunt could decide to scrap a whole new fab

Yea fair. What I was trying to say was that it seemed like a decision that was less the construction/development team saying "this plan isn't workable for xyz reason and we need to reconsider our approach" and more someone high up saying "we are cancelling this and we won't say why".

I could be wrong but I’d assume what the OP is trying to say is that the leadership of these companies does not want these fabs to actually open and work. That something transpired maybe between them and govt.

This is the basis for basically every physics engine in some form of another. Collision is divided into the "broad phase" pruning step that typically uses the bounding box of an object and a "narrow phase" collision detection step that uses the more detailed collision primitives

also how raytracing works with bounding volume hierarchies

and how occlusion culling worked with BSP trees in Quake if I remember correctly as well

This is called a method based JIT, and is generally the more common approach to JIT compilation. Tracing JIT is a deliberate design choice that is quite different from method based JITs

That makes sense. Why exactly would python need a tracing JIT instead of a method one though? It seems like either could work.

(author of the blog post here) "just compile when you know the types" is not a good strategy for Python. My EuroPython talk "Myths and fairy tales about Python performance" explains many reasons why Python is VERY hard to optimize: https://lwn.net/Articles/1031707/

One big advantage of tracing JITs is that they are generally easier to write an to maintain. For the specific case of PyPy, it's actually a "meta tracing JIT": you trace the interpreter, not the underlying program, which TL;DR means that you can write the interpreter (which is "easy") and you get a JIT compiler for free. The basic assumption of a tracing JIT is that you have one or more "hot loops" in which you have one (or few) fast paths which are taken most of the time.

If the assumption holds, tracing has big advantages because you eliminate most of dynamism and you automatically inline across multiple layer of function calls, which in turns make it possible to eliminate allocation of most temporary objects. The problem is that the assumption not always holds, and that's where you start to get problems.

But methods JITs are not THE solution either. Meta has a whole team developing Cinder, which is a method JIT for Python, but they had to introduce what they call "static python", which is an opt-in sets of constraints to remove some Python dynamism to make the JIT job easier.

Finally, as soon as you call any C extension, any JIT is out of luck and must deoptimize to present a "state of the world" which is compatible with that the C extension finds.

IIRC Julia's is a particularly simple method-based JIT for a dynamically-typed language.

I'm not sure exactly how it differs from most JavaScript JITs, but I believe it just compiles each method once for each set of function argument types - for example, it doesn't try to dynamically determine the types of local variables.

I think the compiler figures that if a new method comes up, it’ll just compile that when it needs to.

CPS transforms are not the only way; if you translate the scheme to bytecode for a virtual machine, the call stack and IP can be reified.

But yes, for a compiler specifically, you need a CPS transformation