Btw if you like this kind of thing, you will love Caterwaul JS. My best frowning faces are made reading that language.
http://spencertipping.com/ / http://caterwauljs.org/doc/caterwaul-by-example.pdf
Btw if you like this kind of thing, you will love Caterwaul JS. My best frowning faces are made reading that language.
http://spencertipping.com/ / http://caterwauljs.org/doc/caterwaul-by-example.pdf
But on the web, you obviously can't tolerate true unsafe back doors. This project gives you something that is "unsafe" in that you can read or write to parts of the allocated "heap" buffer that you aren't supposed to, but it's not possible for that to violate JavaScript's safety. And the compiler is generating extremely optimizable code, so it JITs very, very well.
On top of that, the fact that it's all implemented on top of a simple API (typed arrays) means that you could compile in a safe mode that does extra checks, or even trap all memory traffic and build valgrind-like diagnostic tools. It's starting out as a virtualized abstract machine, which means it's easy to hook into and provide great development tools.
I probably wouldn't reach for this kind of dialect for most purposes. But for very performance-sensitive kernels, it's got promise. But it's an experiment, so we'll see!
There would always be the option of running the code out into a raw VM host using NaCL or Xax style container (I know Mozilla dont see these approaches as necessarily compatible with the open web). But to take an approach like boot to gecko to the next level and being compatible with low power usage, I dream of running near native code - inline SSE/Neon with a fallback to generic code.
I'm also thinking how the vm/language could self extend in the field. How the SIMD extensions (or any feature) could be introduced a-posteriori or independent from browser release cycle.