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)

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)

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).

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).

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.

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)

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.

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 unsigned comment added by 201.137.190.180 (talk) 14:05, 22 May 2021 (UTC)