This optimization is sacrificing the precision a lot, moreover I am not sure that is what happens actually, because if that were the case this kind of syntax is just misleading and causes more harm than good.
I think the approach with the paper is correct, the aim of the paper is not to prove that this can be implemented efficiently, however it proves that it is possible, a preliminary step that proves mathematically that the idea makes sense, as this seems a topic that is both very complex and doesn’t have a lot of practical information in the wild.
This approach also works in full favor of the developer, just by saying “we want this experience for our developers” and not by going from a performant implementation backwards. I think in the development world there two opposing philosophies:
- Make the language highly optimized, by introducing a lot of syntactic complexity. People seem to praise languages like Rust a lot these days, however in the field that I work, mainly development of applications for businesses and end-users, this language offers some tradeoffs I am not interested in, the development time and complexity is much more important to me than that performance gain.
- Tailor the language to be developer friendly, witch seems the direction that elixir and erlang took, a simple example would be how constrained is the message passing between processes and mailboxes, that makes them easy to reason about in more complex applications for humans, but there is a clear performance penalty.
