Someone on twitter shared a link to https://github.com/forest-lang/forest-compiler, which sounds really interesting. There's also a great conversation in the Issues here: https://github.com/forest-lang/forest-compiler/issues/2

You can't fully decouple syntax from semantics in a programming language. It wouldn't actually be possible to start with a program written in idiomatic Haskell, flip a switch, and view it in idiomatic Common Lisp.

@Doug Moen Forest's goal is to allow multiple different syntaxes for the same PL and not to allow programs to be displayed as they were written in an entirely different PL. It's "Haskell-like syntax", not "Haskell syntax and semantics" (even though that'd be cool too). I agree that certain parts of the syntax (e.g. reserved keywords) need to be taken care for, but this shouldn't be too hard using some form of escaping. Escaping is ubiquitous in string literals. Another example would be Rust's raw identifiers that allow using any name as an identifier. If syntaxes support this kind of escaping, you already get better backwards-compatibility for free. Introducing a new keyword in your syntax would cause programs using the keyword as an identifier to be displayed differently, but it wouldn't break any code.

@Felix Kohlgrüber I see that Forest has this goal, but currently they only support one syntax (Haskell), and there's nothing in the github repo that shows how they will support an automatic two-way mapping between Haskell curried functions and Javascript or Ruby function call syntax. We are contemplating a multi-syntax projectional editor for Curv, so this is a topic that interests me.

It is impractical, i would go so far as to say a doomed effort, to try and convert one language to another across a wide range of languages. There are concepts in one language that don't exist in another. In my Beads language i have physical units of measurement built in, so you can say 3 m + 3 feet + 3 inches. How would you remap that? You would have to build basically the entire arithmetic runtime of Beads in some other language. And syntactically you can't just add suffixes in other languages, you would have to emulate it via function calls. Another feature isn't even syntactical, it is semantic, that would be impossible to express, namely the deductive nature of drawing code, where whatever state variables used, if those variables change, the runtime redraws the affected draw block without having to manually schedule a refresh. this is a huge effort saving, automatic feature, that eliminates a whole category of under- and over-refresh bugs that are so common in graphical interactive software. This is not shown in the ENBF grammar of the Beads language; it an implied feature performed by the runtime. Languages aren't just their syntax; all the modern ones come with very fancy runtimes, that do all sorts of clever things. There is zero chance that you can implement Erlang in Python; not because Erlang does some computational trick that Python cannot, rather, Erlang has a very customized runtime system that creates a stack and heap for each of the hundreds of thousands of threads you create, which makes garbage collection easy because the heap is so tiny. When you get to a problem that needs the massive thread count of Erlang/Elixir, there is nothing else on the planet that is built that way. Only within a set of "dumb" languages, which have negligible runtime features can one map one language to another. I can think of dozens of counter-examples from pairs of languages that would be a nightmare to convert. I have had to convert plenty of code in my day, and sometimes it is a challenge.

Is sure to be janky, but can pretty useful. http://www.swig.org/ (Yes, SWIG only wraps C, but still.)