https://www.sciencedirect.com/science/article/pii/016764239190036W
Of course I could not follow all the rigurous logic, but the central idea is, if you remove all the syntactic sugar from a language, you start repeating patterns of boilerplate.
Hope this helps,
Daniel
Thank you for sharing that. I gave it a quick reading and, as you pointed out, it isn't exactly the kind of thing you read while having breakfast.
... typing schemes, type checking, stack and heap usage, how do you implement generic types, how do you resolve method lookup in an inheritance tree, /snip/ in a wide variety of programming languages.
Those things you usually learn by example. The implementation will differ from one language to another but, the essence, is pretty much the same regardless of language.
exception handling, concurrency, etc, in a wide variety of programming languages.
Those two are a completely different ballgames because exception handling for instance, can be implemented in quite a few different ways. A language's syntax will hide the differences in the implementation but, the implementation will have many subtle (and sometimes, not so subtle) consequences. An example of that is, exception handling in Windows, it is completely different in 64bit than it is in 32bit. The 32bit implementation uses the stack which means that exception handlers are vulnerable to stack corruption. The table based system used in Win64 is impervious to stack corruption but requires the compiler to build, what in some cases, are extremely large tables (chrome_child.dll has almost one million entries in the exception handling table.)
Concurrency, that is something that, I personally believe has no place in a language. Concurrency, and the facilities to make it happen are, IMO, an OS's concern. A programming language should not try to be an OS, anymore than an OS should try to be a programming language.
Language design is a very interesting never ending subject. I'll check out Ghezzi's book, you got me interested in it.
Thank you for sharing, Daniel.