3 ms·
In theory, a programming language only has a syntax and a semantics, and everything else is an implementation detail. In practice, programming languages are des
by catnaroek 11y ago
In theory, a programming language only has a syntax and a semantics, and everything else is an implementation detail. In practice, programming languages are designed for specific use cases, and lend themselves to specific implementation strategies. For example:
(0) Type-checking C++ templates requires expanding them. However, nothing forces a C++ implementor to translate the individual template instantiations to machine code (or whatever target language is used). A C++ implementor could use a strategy similar to what is used in Java and C#, and re-instantiate every template on demand at runtime. Of course, nobody does this, because it's bad for the implementor (more work, because instantiating templates is more complex than instantiating generics, so better not do it at runtime if it's already been done at compile time), bad for the user (worse runtime performance), and good for noone (except perhaps C++ detractors).
(1) A Python implementor could use whole-program analysis to assign variables and expressions more useful static types than `AnyObject` - similar to what STALIN does for Scheme. But, again, this is bad for the implementor (more work), bad for the user (less interactivity and instant gratification, due to the constant rechecking of the whole program every time a change is made), and good for noone (except perhaps Python detractors).
Now, there exist language designs that are less biased towards a fixed implementation strategy. For example, Common Lisp, Standard ML and Haskell. But these languages are also markedly less popular, which perhaps suggests that programmers usually prefer languages that have a concrete story about what use cases their design optimizes for.
- mercurial 11y agoI'd say that it's in a large part a question of marketing. SML and Haskell are largely academic languages, even if there is now Haskell running in production at different locations. Likewise, you can hardly accuse OCaml of having the kind of marketing muscle and reach that a company like Mozilla can bring to bear (also, it's pretty old, which makes it difficult to sell as the new shiny).
- pcwalton 11y ago> A C++ implementor could use a strategy similar to what is used in Java and C#, and re-instantiate every template on demand at runtime. Are you sure? Expanding templates can affect the parsing of subsequent code, as this example illustrates: http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-3 http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-3 You pretty much have to expand them at compile time. (This sort of complexity illustrates why I prefer generics to templates, incidentally.)
- catnaroek 11y agoWhat I meant is: (0) Expand the templates at compile-time, in order to type-check the code. (1) Don't generate target language code for each specific instantiation, though. (2) Re-expand the templates (or some representation of them) at runtime. It's a very silly implementation strategy, of course. But I don't see why it's fundamentally impossible to do this - it's just undesirable. And, yes, I agree about generics being better.
- haberman 11y agoShameless plug, I wrote a blog article explaining the yosefk example above more explicitly: http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...
- the_why_of_y 11y ago(1) has actually been done a decade ago, it was called "Starkiller" http://people.csail.mit.edu/jrb/Projects/starkiller.pdf http://people.csail.mit.edu/jrb/Projects/starkiller.pdf