Talk:Source-to-source compiler

CoffeeScript?

Would coffee qualify as source-to-source compiler? It takes CoffeeScript as input and compiles it into JavaScript. It's intended to be a refinement of JavaScript, but it provides more than just a different syntax or shorthand notation. What about HAML, which is _only_ a shorthand, or SASS, which is an abstract form of CSS? None of these is really useful without conversion (though there seems to be an interpreter for CoffeScript in development), but they all differ significantly from their "target" language. -- 78.35.98.218 (talk) 13:48, 30 October 2010 (UTC)

Indeed, I think they qualify as source-to-source compilers, until they become a full flown language once they have their own interpreter/compiler that does not translate to another language (like CofeeScript will become). Another source-to-source compiler example is Lisaac's compiler which translate Lisaac code into C code. JnRouvignac (talk) 10:48, 1 November 2010 (UTC)

Delete article

Hi! Since the terms “source-to-source compiler” and “transpiler” are neither well-defined (does the target language has to be similar or at the same level or only kinda more highlevel than assembly? What is about immediate languages? LLVM? C? C--? And what is special about it, compilation is always “trans” and “source-to-source” – source language → target language) nor distinguishable. I propose to delete both of them and mention such stuff (like compilers for porting to a new version or specific target languages) in the compiler-article mentioning that those terms are not well-defined. Opinions? --Chricho ∀ (talk) 14:51, 19 August 2011 (UTC)

I agree with your suggestion. Both articles look of low quality and keeping the info you suggest is really what matters here. JnRouvignac (talk) 02:28, 24 August 2011 (UTC)

I also agree. "Transpiler" is not even an actual term of the art. The correct and only term is "compiler." Ohmantics (talk) 00:27, 18 March 2015 (UTC)

Hello! Well, actually that isn't the case, "compiler" isn't the only term around no matter how widely it is used. "Translator" is also a correct term, and in my opinion we should see how to combine Translator (computing) and Source-to-source compiler articles into a single article. — Dsimic (talk | contribs) 04:12, 20 March 2015 (UTC)

I think these should just be subsections in the compiler article and "Translator (computer science)" and "Source-to-source compiler" should redirect to that section in the compiler article. AadaamS (talk) 06:09, 20 March 2015 (UTC)

The Compiler article is already quite lengthy, so merging more content into it would be against WP:SIZESPLIT. — Dsimic (talk | contribs) 06:50, 20 March 2015 (UTC)

While the terms "source-to-source compiler" and "transpiler" are indeed not well defined, they are not useless either. When they are assumed to refer to compilers that translate from one high level language into another, a similar problem occurs, as the term 'high level language' isn't well defined either. There used to be talk of genrations (1st = machine code, 2nd = assembly, 3nd = imperative, 4th = declarative, 5th = AI based, self learning. While at generation 5 these terms were so frequently abused in marketing that they lost all value, I think the term "source-to-source compiler" is intuitively quite clear even though it isn't formally well defined. With the reference from 'transpiler' and a link from 'compiler' people will be able to find it. As for the term 'transpiler': due to the fact that most browsers only understand JavaScript natively (be it asm.js or anything like it), this term is becoming more common. In general this field is so dynamic that inevitably new terms emerge. I think in a medium like Wikipedia we should avoid marketing slang and hypes, but given the popularity of source to source compilation, we're not dealing with a hype here. Indeed the amount of info is too large to be joined with Translator (computing) because of WP:SIZESPLIT. Still people may look for information on source-to-source compilation and should be able to find it. So I think this article should be improved rather than deleted. Jacdeh (talk) 07:13, 12 August 2016 (UTC)

Agreed. The term "transpiler" is certainly one I absorbed from somewhere, and as a professional programmer, I recognize the general category of "transpiler" as what is described in this article. Wikipedia is often useful as an expanded definition of terms. This article is useful in describing the concept for those who hear that term. 50.39.240.234 (talk) 23:37, 19 October 2023 (UTC)

I share skepticism of the term; I think it comes from ignorant enthusiasm. "Compiler" and "Translator" cover it. Perhaps determining original use of the term would help settle the debate? I could not find mention of first use in the article. User:gstover 2019-12-09T07:07:31-0800 —Preceding undated comment added 15:09, 9 December 2019 (UTC)

I share your scepticism too, it seems a marketing term. However thinking more about it, it may be a legitimate new kind of translator, the interesting thing would be if it is about deriving paradigm-to-paradigm translators. Please read my comment below and my comment to the other comments.

But, do not precipitate to erase it. It is quite superficial but may be a really different kind of translator if transpilers map source code in different paradigms. Doing more research that could be de case. We need to review the term in research papers to know if it is really different. If that is the case, write in this entry what is new, why, what problem solves and who is working on it.

-- (unsigned) 2021-05-22T19:14:32 by IP 201.137.190.180

YACC and LEX

YACC (Yet Another Compiler-Compiler) and LEX both date to the early 1970s and would seem to be in this category. If you agree, that would be quite a bit earlier than the 1981 example said to be "one of the earliest examples..." — Preceding unsigned comment added by 2601:646:9300:5230:CCAC:B31F:393E:F59 (talk) 01:59, 30 January 2019 (UTC)

No, YACC is something different. Compiler-compilers take a formal description of a programming language as input (typically as text file) and create the source code (or at least significant parts of it) of a compiler. Executing the resulting compiler, it translates source code written in the freshly defined programming language into whatever target format the compiler is supposed to output (typically executable code).

--Matthiaspaul (talk) 12:55, 18 January 2020 (UTC)

"Recursive transcompiling"

Wikipedia has another article that describes something called "recursive transcompiling," though I can't find any mentions of this phrase outside Wikipedia. Should the "Recursive transcompiling" article be merged into this article? Jarble (talk) 16:06, 12 April 2019 (UTC)

The whole "Recursive transcompiling" section has no relevant sources, and in general the concept of "Recursive" does not make sense here. In order to be recursive is has to be theoretically infinite, ie linked lists and binary trees are both recursive data structures because they are potentially infinite (the halting problem). 2A00:23C5:D294:5900:7CD6:4F1A:793:A322 (talk) 11:01, 1 September 2020 (UTC)

The halting problem is about undecidability of program to stop with an answer of loop forever.

Processing inductive types like binary trees or lists is decidable. They have a finite number of constructors and the programs can test each one. Oh the other side there are dual structures that you can grow infinitely, for example streams, defined co-inductively, in that case you may prove if the program will reach a result if you can stablish a some convergence criteria. It is more likely that you can't decide if the program will stop when you are doing a brute force search with an infinite search tree (is a structure but the key here is the strategy to do a brute force) and you can keep searching some answer that will never be find, and you can't decide if you need more time to eventually find an answer or that no answer exists or can't be found with that method. (there is no convergence criterium).

--(unsigned) 2021-05-22T18:41:13‎ by IP 201.137.190.180

Compilers are never expected to loop forever in the compilation process. Source code is always expected to be executed in a machine and the compilation has to always finish. 2A00:23C5:D294:5900:7CD6:4F1A:793:A322 (talk) 11:01, 1 September 2020 (UTC)

What I understood from the article, is that cycling from $A\to B\to C\to \ldots \to A'$ and probably $A'\to B'\to C'\to \ldots \to A'$ shows that all the programs are equivalent with no information loss if $A=A'$ or there is some information loss if $A'\to \ldots \to A'$ is never reached. In the later case that would mean that some transpilers are wrong if each language is Turing complete.

Is it possible to automatically derive transpilers, taken as paradigm-to-paradigm translators? (see comment below)

I had not thinked about it, until I learned about transpiler today, I am not sure what is it about, as I expressed in my below comment, but it can be an interesting subject to study.

I hope that my comments give to the transpiler experts a guide in how to improve the article covering this points.

--(unsigned) 2021-05-22T18:41:13‎ by IP 201.137.190.180

Source is a Misnomer

Source-to-Source is a misnomer.  Transpilers do not output source, despite that they output (potentially) human readable text.

Text input is also not guaranteed to be source, it could also be generated output.

"Source" is the thing you need to place under "source code control" because it is "original" and thus, cannot be reproduced mechanically.

So, the better term here is text-to-text compiler.

— Preceding unsigned comment added by 98.234.74.137 (talk)

"Source-to-source compiler" is the correct name. A source-to-source compiler translates the source code of one programming to another. Its input is source code, and its output is source code. Jarble (talk) 17:55, 29 November 2019 (UTC)

Did you even both reading what he said before posting this reply? It certainly doesn't seem like it. — Preceding unsigned comment added by 82.6.177.154 (talk) 03:27, 9 December 2019 (UTC)

Source-to-Source is the correct name, see below 2A00:23C5:D294:5900:7CD6:4F1A:793:A322 (talk) 10:44, 1 September 2020 (UTC)

I agree that "source" could mean many things and what we actually mean here is source code in a text file (compared to a binary file). However, Wikipedia does not invent new terms but uses what is established. While the term "source-to-source compiler" is not used by everyone, "text-to-text compiler" is not used at all in any WP:RS. So we can't use it.

--Matthiaspaul (talk) 12:55, 18 January 2020 (UTC)

Compiler literature is very specific about the term Source-to-Source. The name is explicit in the Aho book (Page 3, second edition: "A compiler that translates a high-level language into another high-level language is called a source-to-source translator."). The Cooper book gives a more specific definition (Page 3, second edition: "Some compilers produce output programs in the same language as their input; we call these “source-to-source” translators."). In any case, Source-to-Source is the correct name. 2A00:23C5:D294:5900:7CD6:4F1A:793:A322 (talk) 10:44, 1 September 2020 (UTC)

The Aho book, use the term to contrast with other kinds like optimizing compilers. As such that kind is not a very interesting subject, although it is necessary to implement new languages.

Today it seems to be a lot interest in javascript-to-any and from any-to-javascript translators, preserving human legibility (if any) during translation. That is what makes the difference, to me that means paradigm-to-paradigm translation, a more interesting challenge.

I suspect that there is some serious research ongoing in that direction, but hackers and newbies had just a superficial view on the subject and are writing "transpilers" and articles with no depth insight on the process, as frequent happens, not reviewing the theory.

So I give the benefit of doubt before recommending to erase this article. I prefer to mark it to do more research in the subject to improve it, before deciding if it is, as it seems, just a marketing term.

-- (unsigned) 2021-05-22T19:45:33 by IP 201.137.190.180

Wikipedia does not publish original research

An article from a German magazine about a "transpiler" from the 80's is hardly a reference to the popularity of the transpiler term. Classical literature about compilers (ie Aho and Cooper) does not mention transpilers in any way, even though the concept has been applied many times in the past (ie, C++'s Cfront). 2A00:23C5:D294:5900:7CD6:4F1A:793:A322 (talk) 10:30, 1 September 2020 (UTC)

I had a similar thought, however thinking more about it, as I found a lot of links about transpilers searching for a jscript2c converter, I noticed that the subject is becoming more popular and that it may be a legitimate new subject if it refers to a paradigm-to-paradigm translator see my comments below .. is a paradigm-to-paradigm translator? and my comment within a couple of comments above mine.

if that is the case, it is possible that there are more references about it. Other wise just a new marketing term for an old concept. This term is new to me, but I give it the benefit of doubt. It can be a really interesting new subject deserving an entry in Wikipedia. Not a research discussion entry but a mention on an ongoing research about these more often mentioned transpilers and why they deserve attention, if that is the case. Just do not precipitate to erase this topic because it just tackles the subject superficially. Which may be the case.

-- (unsigned) 2021-05-22T18:55:52 by IP 201.137.190.180

Searching actual journals, rather than random German Amiga magazine articles, yields relatively few results. Even if one widens the net to magazines, the evidence for "transpiler" as an established name for anything is pretty thin. I found this 2016 article which defines "transpilation" as "just a fancy way of saying the compilation of similar languages", which doesn't really make a lot of sense by itself, but I suppose it really means to compile one language and produce output in a similar language, with the transformation of ECMAScript 6 into ECMAScript 5 being given as an example. Meanwhile, according to this substantially older article "transpiler" is actually the name of a software product involving the INMOS Transputer: "transpiler" being a combination of "transputer" and "compiler". Personally, I see "transpiler" used a bit as some kind of derogatory term to suggest that a compiler somehow isn't a real compiler. For instance, this project claims that two actual compilers (Nuitka and Shedskin) are "transpilers", yet the operations performed by both of them involve targeting a lower-level language and introducing code to support the higher-level source language: precisely what an actual compiler does. Finally, if there is actual research about some kind of "paradigm-to-paradigm translator", maybe it could be dug up and referenced so that this page isn't conducting some kind of original investigation. --PaulBoddie (talk) 21:54, 19 September 2021 (UTC)

The references regarding the term "transpiler" were not added to somehow document some popularity or to encourage the usage of this term, but simply to fulfill our goal as an encyclopedia to document what is/was without any bias.

There has been some speculation that "transpiler" would be a new term, therefore, I added those refs to track it down in history and document the defining early usage. In fact, the three earliest sources using this term I could find are given as references: An Amiga BASIC-to-C source-to-source compiler by the German company ARC in 1988, an Occam-to-"parallel"-Occam source-to-source-compiler by the Swiss company CTS in 1989, and the claim of the British company Sector 7 Software, who, among other stuff, developed another BASIC-to-C source-to-source compiler for DEC VMS and (incorrectly) claimed they would have been the first to use the term in 1991 (and temporarily even managed to trademark it). There might be other early sources using the term (if you know any, please add them), but this narrows down the timeframe when the term must have been coined and used to somewhen in the late-1980s/very early 1990s. So, it is definitely not a new term, and it has always been used for source-to-source compilers.

Still, I consider the term to be somewhat jargon'ish and while we have to properly document that it exists, and for what and since when, we should better use the terms "transcompiler" or "source-to-source compiler" in the article prose.

--Matthiaspaul (talk) 21:07, 6 January 2022 (UTC)

Is transpiler a new marketing name for an old kind of translator or a really new kind of paradigm-to-paradigm translator?

A source code to source code translator is not a new concept. Ratfor, a rational Fortran was an structured and embellished Fortran translated into Fortran IV by means of a preprocessors. I knew other similar preprocessors.

Interpreters, compilers, preprocessors and the so called transpilers, are all different kinds of translators. More over, any application program translates the input data into some information, i.e. an application program interprets data in some meaningful way.

Normally higher level programming languages are compiled into machine code, in the process the program is optimized. Those compilers are correctly called optimizer-compilers.

Interpreters translate and evaluate the source code. Lisp and Basic were one of the old ones. Lisp interpreters were written in Lisp, That was not exclusive of Lisp, many other languages either interpreted or compiled were described and implemented in the same language.

The so called transpilers, translate source code from one language into another programming language, That is not new. As mentioned above RatFor translates an extended Fortran (structured) into Fortran IV. That is something similar.

It is relatively easy to translate similar languages, Fortran to C, Pascal to C, Cobol to Pascal, C++ to C. To write a Lisp compiler or interpreter in C, the basic building blocks of that language are implemented in C and used to incrementally write the Lisp interpreter/compiler in Lisp. The basic instructions of the Lisp family are the cons, car, cdr, null, eq, cond. and lambda expressions.

The same minimal set can used to implement a Lisp to C translator. The C object code from a Lisp source written with such basis, is actual C code compilable by any standard compiler into machine code. However such C code may be human readable and very similar to the original Lisp source program. If a C programmer writes a program to do the same thing that the Lisp program does, the program would be different. It could use arrays instead of lists, loops instead of recursion, the Lisp programmer may use higher order functions while the C programmer could not even use function pointers.

It is not clear to me if the real aim of transpilers, is to transliterate one language into another or translate from one paradigm, functional in our example, to other, the imperative. That "idioms" mapping could be the basis for a really new kind of translators called "transpiler". The term "transpiler" is new to me, not the different kind of translators, maybe those of you with experience with transpilers, can clarify this point. If I am right, source-to-source translator is a wrong description for a transpiler, That could be called paradigm-to-paradigm translator or something alike. — Preceding [elias]unsigned comment added by 201.137.190.180 (talk) 14:05, 22 May 2021 (UTC)

Take a look to this link with an example of java-to-haskell translation: https://jarble.github.io/transpiler change the source language to c, and you will see the correct translation with the correct scope. That page has links to other projects with a similar aim. Although this is new to me that site points to what I think is the idea behind what is called transpilers. Maybe that is a legitimate new kind of translator. -- (unsigned) 2021-05-22T20:50:49‎ by IP 201.137.190.180

The short answer is: No.

Transpiler is just a "fancy" (IMHO jargon'ish) way to say "transcompiler", and this is used as a synonym to source-to-source compiler by most (there might be nuanced differences between "translators", "compilers" and "transcompilers", but that's a different topic). Regarding "transpiler", see my answer in the other thread regarding early use of the term in the late 1980s/early 1990s, so, it is also not a new term, but it is little used (except for, perhaps, in the past decade, however, this might also be the result of Wikipedia using this term in the prose - which I have changed now to use the more established term transcompiler instead).

As you point out correctly there are different types of transcompilers, possibly including new types for which new names might emerge over time. It is the goal of Wikipedia to document "what is" in a suitable structured and accessible way, but in doing so it is not our business to coin new terms ourselves - in fact we should try hard to avoid this because it creates circular definitions. So, we have to list the term transpiler and even give examples of its usage, and discussing the origin of the term might be even interesting and encyclopedically relevant, but the term is not used broadly enough to warrant its usage in our own prose when other synonyms (like transcompiler) are available to describe the same.

Perhaps as an example, one of the references to document the usage of the term "transpiler" is about an Occam transcompiler for automatic parallelization and from reading only that article (which even connects the term transpiler to transputer), one might come to the conclusion transpiler would be a specific term for this kind of precompiler, however, when reading it in the context of the other two references it becomes clear that the term just refers to the more general source-to-source compiler meaning and the choice to use this (rather than the more conventionally sounding term transcompiler from the pool of available terms) in conjunction with transputers was just motivated for linguistic or even marketing reasons. Does this make transpiler a term used specifically for parallelizing transcompilers? No, certainly not, it is still only a synonym for transcompilers in general.

--Matthiaspaul (talk) 13:45, 9 January 2022 (UTC)