4 ms·

One case the author left out was translation to "idiomatic" higher level language, which involves identifying abstractions that are intrinsically present, but w

One case the author left out was translation to "idiomatic" higher level language, which involves identifying abstractions that are intrinsically present, but where never explicitly expressed, in the original code. For example I've been working on a translator/converter from C to a memory-safe subset of C++[1]. The output is intended to be readable and maintainable as source code in its own right. So when for example, encountering a pointer in the original C source, you have to determine from context whether the author is using it as an iterator to a fixed-sized array, an iterator to a dynamically-sized array, an "owning" reference to a dynamically allocated object, or just a weak/observer reference to an object, and translate to the appropriate "higher-level" element. So in a sense it's a "decompiler" to a (higher-level) language the code was never compiled from. As a source-to-source transformer, presumably it would qualify as a "transpiler". But does that term have an connotation that the output is just an intermediate translation not intended to be maintained or used directly? [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

saltcured 9y ago
I think you are describing a source to source translator, and an awfully fancy one at that. A translator generally would be trying to map or maintain the structural idioms in the source code, allowing for human understanding or maintenance of the translated code. But to improve the coding style by detecting latent idioms seems a bit much even for most translators. I always considered a transpiler to be closer to a translator than to a compiler, but without the translator's concern for maintaining human-readable code. For me, the boundary between transpiler and compiler is in the runtimes. A transpiler would be targeting the whole runtime of a target language, i.e. one with non-trivial type systems, flow control/exception handling, and memory management/GC. The transpiler maps source language runtime concepts to target language runtime concepts in a relatively straightforward fashion. A compiler targets some lower-level abstract machine language and provides its own distinct runtime system as well. A similar boundary exists for interpreters, where a meta-interpreter does relatively high-level source-to-source conversion before delegating to a target language interpreter and its runtime. These meta-interpreters are akin to transpilers, while full blown interpreters are akin to compilers, targeting a lower level abstract machine and providing their own runtime systems.
- tom_mellior 9y ago
  > where a meta-interpreter does relatively high-level source-to-source conversion before delegating to a target language interpreter This is most emphatically not what Prolog meta-interpreters do. (Those are the ones I am most familiar with.) They do not build up new source code, they interpret given terms in "new" ways that are not built into the Prolog implementation. Systems that build new source code are called expansions or sometimes macros. I don't think the Lisp world would call such systems meta-interpreters either. There, too, you have macros that transform source code. Do you have a reference that uses the term "meta-interpreter" in the way you are describing?
  - saltcured 9y ago
    Sorry, it's been many years and I misremembered the term "meta-circular evaluator", i.e. everybody's toy implementation of an interpreter with a REPL and very simplistic (if any) changes to the source language being interpreted.
tom_mellior 9y ago
> a translator/converter from C to a memory-safe subset of C++ There you go. Both "translator" and "converter" are great names for this. No extra jargon needed. There really is way too much jargon already, and more often than not in obfuscates rather than clearing things up. Resist the temptation.
vorg 9y ago
Perhaps a "compiler" transforms to lower-level languages (which includes Javascript, C code, VM bytecode, and chip instructions), a "decompiler" will transform to higher-level languages, and a "transpiler" will compile then decompile.

saltcured 9y ago

I think you are describing a source to source translator, and an awfully fancy one at that. A translator generally would be trying to map or maintain the structural idioms in the source code, allowing for human understanding or maintenance of the translated code. But to improve the coding style by detecting latent idioms seems a bit much even for most translators. I always considered a transpiler to be closer to a translator than to a compiler, but without the translator's concern for maintaining human-readable code. For me, the boundary between transpiler and compiler is in the runtimes. A transpiler would be targeting the whole runtime of a target language, i.e. one with non-trivial type systems, flow control/exception handling, and memory management/GC. The transpiler maps source language runtime concepts to target language runtime concepts in a relatively straightforward fashion. A compiler targets some lower-level abstract machine language and provides its own distinct runtime system as well. A similar boundary exists for interpreters, where a meta-interpreter does relatively high-level source-to-source conversion before delegating to a target language interpreter and its runtime. These meta-interpreters are akin to transpilers, while full blown interpreters are akin to compilers, targeting a lower level abstract machine and providing their own runtime systems.

tom_mellior 9y ago
> where a meta-interpreter does relatively high-level source-to-source conversion before delegating to a target language interpreter This is most emphatically not what Prolog meta-interpreters do. (Those are the ones I am most familiar with.) They do not build up new source code, they interpret given terms in "new" ways that are not built into the Prolog implementation. Systems that build new source code are called expansions or sometimes macros. I don't think the Lisp world would call such systems meta-interpreters either. There, too, you have macros that transform source code. Do you have a reference that uses the term "meta-interpreter" in the way you are describing?
- saltcured 9y ago
  Sorry, it's been many years and I misremembered the term "meta-circular evaluator", i.e. everybody's toy implementation of an interpreter with a REPL and very simplistic (if any) changes to the source language being interpreted.

tom_mellior 9y ago

> a translator/converter from C to a memory-safe subset of C++ There you go. Both "translator" and "converter" are great names for this. No extra jargon needed. There really is way too much jargon already, and more often than not in obfuscates rather than clearing things up. Resist the temptation.

vorg 9y ago

Perhaps a "compiler" transforms to lower-level languages (which includes Javascript, C code, VM bytecode, and chip instructions), a "decompiler" will transform to higher-level languages, and a "transpiler" will compile then decompile.