-1

If we had a universal interpreter for all available features of programming languages we could use a specializer to generate compilers for all languages. We could simply use any language as source (or input) and any platform as target (output).

We could all write in our favorite programming language to add features to that universal interpreter because the base Abstract Syntax Tree (used by the universal interpreter) could be a target of our favorite programming language. On top of that, you could view the 'source code' of the universal interpreter in any language because the 'source code' of that universal interpreter is actually an AST.

Despite programmers having these sort of ideas for more than 40 years most of us still seem to think that we need to choose a specific textual representation and appropriate interpreter (or specialized interpreter called compiler).

I don't get why that is. There are so much programmers around and most programmers are really passionate about their ability to create. I don't understand why we fight about different programming languages, to me they seem like a different view on the same AST.

Why are we all not using the same base as a library from which we can pick language features?

EECOLOR
  • 214
  • 7
    Well that's not the case. If you choose the AST to be assembly for an architecture then pretty much every language does indeed target the same base. If you're wondering why have different languages at all: well there are certain language features that are just not compatible. You can't have general recursion and termination, it's just not possible. Different languages are necessarily different chunks of some Platonic language of computation because it's contradictory to glom everything together into one thing. – daniel gratzer Feb 16 '15 at 21:46
  • @jozefg So we should mark the compatibility of different features with each other. – EECOLOR Feb 16 '15 at 21:49
  • 3
    yes. this idea is called Lisp. Nobody who's sane thinks this is a good idea – AK_ Feb 16 '15 at 21:49
  • 4
    One common target and infrastructure for different languages? We already have this, see for example http://en.wikipedia.org/wiki/List_of_CLI_languages and http://en.wikipedia.org/wiki/List_of_JVM_languages... and don't forget LLVM http://en.wikipedia.org/wiki/LLVM – Doc Brown Feb 16 '15 at 21:52
  • @AK_ you seem to validate my question by bringing up a language instead of an example of what I tried to describe. – EECOLOR Feb 16 '15 at 21:52
  • @DocBrown so that's one part of the puzzle. Now we need the part that's in between the text (source files) and the targets. – EECOLOR Feb 16 '15 at 21:53
  • 1
    Have you actually tried implementing (or even just thought in detail about how to implement) any of that? The longer I think about it, the more problems I find. I've only been at it for two minutes and I already have so much material that beating it into the shape of a good answer takes far more time than I'm willing to invest. –  Feb 16 '15 at 21:56
  • 1
    Lisp is not a programming language. its THE programming language. and to rephrase Greenspan: any sufficiently complicated program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. – AK_ Feb 16 '15 at 21:57
  • 2
    Syntax matters. I don't want to program in ASTs. And a "universal interpreter" won't be able to fit the runtime needs of every language. For instance, garbage collectors for functional languages have very different assumptions from those in imperative languages. And what about purity and laziness? Haskell relies on these and the runtime system is built for them. How do you reconcile those needs with languages that are neither pure nor lazy? – Doval Feb 16 '15 at 21:58
  • 2
    @EECOLOR re marking features - what about the features by prohibition? Agda do guarantee to large extent the correctness of program (corrects states and termination) - if you allow it to interact arbitrarily with PHP you loose such guarantees without needed to check anything. In similar way NULL-less languages have 'fun' interacting with languages that do have a billion dollar mistake in design (see Scala and JVM). (In addition to Doc Brown examples LLVM seems to be close to arbitrary input/arbitrary output). – Maja Piechotka Feb 16 '15 at 21:59
  • If you're essentially writing your own language as you go along, how on Earth do you ever expect anyone else to maintain the code? Or even yourself, after a span of time long enough to forget why you thought feature A was such a great idea, when it's obvious crud to you now. – jamesqf Feb 17 '15 at 07:12
  • 1
    How does this differ from the Intentional Domain Workbench, JetBrains MPS, Eclipse Xtext, Spoofax, Monticore, MetaEdit+, Metarepository, Whole Platform, Rascal, Melanee, Gemoc Studio or any of the other Language Workbenches? – Jörg W Mittag Feb 17 '15 at 12:27

1 Answers1

18

You seem to think that programming languages differ only in their syntax. This is not the case. Languages can have vastly incompatible semantics as well. For example:

  • A functional language that uses lazy evaluation and an imperative language that allows side effects are difficult to combine.
  • A language that allows pointer arithmetic and a language that guarantees memory safety are difficult to reconcile.
  • A program involving infinite loops cannot necessarily be expressed in a language such as Coq.
  • A language that allows dynamic dispatch (i.e. OOP) is incompatible with a language that is completely statically typed.
  • Some languages don't offer dynamic memory allocation.
  • A program using closures does not have a straightforward representation in a language without garbage collection.

The list of incompatibilities goes on and on.

There are a couple of program representations that are common for different languages. These are called machine code or byte code. While they are functionally equivalent to the original program, most of the structure of the program is lost.

The .NET common language runtime is an interesting example of an intermediate-level language platform that supports a variety of different languages, both imperative and object-oriented (e.g. C#) and functional (e.g. F#). While programs cannot be transformed from one language to the other – slight feature mismatches exist –, different parts of the same project can be written using different languages. Due to the common feature-rich runtime, their interop facilities are practically effortless.

amon
  • 134,135
  • There is a finite set of these semtantics (in programming languages now) right? Couldn't we create an interpreter that deals with this? – EECOLOR Feb 16 '15 at 22:11
  • 1
    @EECOLOR There trivially are a finite number of programming languages. But no, realistically, there is far too much diversity in languages for a single AST, a single IR, or a single interpreter. –  Feb 16 '15 at 22:18
  • 5
    @EECOLOR Yes, common interpreters are possible – your computer's CPU is one example. But getting a usable, high-level representation that is similar to the source representation of the program back from the common interpreter's representation is not generally possible. This becomes easier when the executable representation closely mirrors the high-level source language. But that always means this executable representation moves further away from other languages, which then do not map cleanly to that executable representation. – amon Feb 16 '15 at 22:22