> Your CPU doesn’t know or care what functions are [...]<p>Well, most architectures do not use plain jumps with implicit arguments for function calls, but have explicit call/ret or branch-with-link instructions. Even those that used jumps had branch hints. The reason is that the microarchitecture must know about call/ret pairs to be able to predict the return path as the generic dynamic predictor is just not good enough for such a common path.<p>Reduced prediction performance compared normal calls is actually a concern for some coroutine and async code.<p>> in C we don’t have any dynamic lookup inside functions—every dynamic jump comes from an explicit conditional statement<p>function pointers.
> Well, most architectures do not use plain jumps with implicit arguments for function calls, but have explicit call/ret or branch-with-link instructions.<p>Anyone who wants to go deeper on this would be well served doing some reading on "return oriented programming" and shadow stacks / control flow integrity. I got turned onto this by a few LWN articles that talk about the subject (<a href="https://lwn.net/Articles/940403/" rel="nofollow">https://lwn.net/Articles/940403/</a> among others).<p>It turns out that "jump to this pointer" is actually a dangerous construct, and it's not something you get much high-level exposure to since functions as an abstraction are so unleaky.
> Your CPU doesn’t know or care what functions are<p>This has already been commented on by a couple of people, but yes, your CPU absolutely does care a lot about functions. At the very least, call/ret matching is important for branch prediction, but the big arches nowadays have shadow stacks and CFI checks that require you to use call/rets as regular functions. x86 has a more thoroughly built-in notion of functions, since they have a (since mostly-defunct) infrastructure for doing task switching via regular-ish call instructions.<p>> The toString method that gets called depends on the type of the receiver object. This isn’t determined at compile time, but instead a lookup that happens at runtime. The compiler effectively generates a switch statement that looks at the result of getClass and then calls the right method. It’s smarter than that for performance I’m sure, but conceptually that’s what it’s doing.<p>No, it's conceptually doing the exact opposite. Class objects have a vtable pointer, a pointer to a list of functions, and the compiler is reading the vtable and calling the n'th function via function pointer. The difference is quite important: vtables are an inherently open system (anyone can define their own vtable, if they're sufficiently crazy), but switches are inherently closed (the complete set of possible targets has to be known at compile-time). Not that I've written it up anywhere, but I've come to think of the closed nature of switch statements as fundamentally anathema to the ideals of object-oriented programming.
> To start with, you need to remember that functions don’t exist. They’re made up. They’re a social construct.<p><a href="https://www.felixcloutier.com/x86/call" rel="nofollow">https://www.felixcloutier.com/x86/call</a><p>Sufficiently large distances of abstraction from the concrete, underlying mechanics are indistinguishable from religion and superstitious belief. Expect LLMs to widen this gap in understanding.<p>We are not far away from the tech priests of the Adeptus Mechanicus.
> Sufficiently large distances of abstraction from the concrete, underlying mechanics are indistinguishable from religion and superstitious belief.<p>Hell, you can apply this to all culture. Humans are not very rational or observant beings, despite how much some of us insist to the contrary. Basically any abstraction is a) going to be taken at face value, or on an assumption that the world is inherently structural, and b) the assumption is essentially guaranteed to either be inaccurate or tautological.<p>"Religion" was invented about 500 years ago to distinguish from the secularists, but the distance between them these days is mostly one of chosen ritual and the direction in which arrogance is spewed. After all, the church that persecuted Galileo was hardly any more irrational than the states we entrust <i>nuclear weapons</i> to is today.
> If you want to read more, I’d recommend starting with the Effekt and Koka language tours<p>Instead of exploring a research language that nobody uses you could try a mature effects system for a semi-popular language. I think Zio is great and runs on the JVM and ScalaJS. <a href="https://zio.dev/" rel="nofollow">https://zio.dev/</a>
This article would benefit from an introduction that lays out the structure of what is to come. I'm expecting an article on effect systems, but it jumps straight into a chunky section on the implementation of function calls. I'm immediately wondering why this is here, and what is has to do with effect systems.<p>Also, this is a very operational description: how it works. It's also possible to give a denotational description: what it means. Having both is very useful. I find that people tend to start with the operational and then move to the denotational.
> having to add IO effects to all functions<p>Sound like Haskell, and its Monads. I think it does end up being very similar in the end.<p>Would you compare effects and monads?
I came here to ask the same question; did somebody just reinvent monads?<p>Also note that much of Haskell now uses MonadIO, so you are no longer constrained to IO or having to manually lift IO into your monad, so long as your monad instances MonadIO. This makes code reuse across libraries trivial. I say this because their div() example says that it can only be called from an Exception effect context, which is like old-school IO-everywhere Haskell. It seems to me like they're going to run into the function colour problem.