The authors touch on the hardware benefits you get from doing away with pointers, but I think you could go much, much further. Yes, you know which things are h

The authors touch on the hardware benefits you get from doing away with pointers, but I think you could go much, much further. Yes, you know which things are heap-allocated and which are stack-allocated, so you have some language-level disambiguation that way, but within a functional operation like map, reduce, fold, etc., you have perfect knowledge about which data is touched in what way, so you could potentially do something like use a compiler-managed scratchpad for it instead of a cache. The compiler would have perfect timing, bank conflict, etc. information, so it should be able to an awesome job of scheduling and use much less energy than a hardware-managed cache. Will be interesting to see how much of this kind of thing is done as we come up with ways to compile high-level languages directly down to performance- or efficiency-oriented hardware (not through C). Most modern architectures are designed to do a good job when the compiler has very little idea what the code is doing; you can save a lot of area and power if you know more.