Hacker News Reader

Comment by znpy | Hacker News Reader

One might argue that this guy actually wrote a transpiler and not a true compiler as the target language is D and not assembly or machine language.

I don't want to diminish the work this guy has done, but one of the biggest challenges, unless you want to take credit for someone else's work, is to do all the various kind of optimization that a mature compiler would do, at various levels.

So yeah, that's cool, but I was expecting more given the use of the word "compiling".

View on HN

I think the use of the word is fine. Whilst "compile" is often used to refer to programs whose target language is assembly/machine code, it generally refers to any translation from one computer language to another [0].

A "transpiler" is therefore a specific type of compiler.

[0] http://www.compilers.net/paedia/compiler/index.htm

Yeah, that is what I was taught as well. From one abstract machine to another.

If we think about it javac would not be a compiler otherwise :-)

The reason I'm comfortable calling BSDScheme in particular a compiler is because ultimately you get a small binary you can bring to another machine without a runtime. Javac may get you bytecode, but you're still dependent on a JVM. This is the most useful distinction for most users, not if it compiles straight to assembly or not.

In the case of JSC, a binary is produced currently but it must be launched by a Node app. So it doesn't exactly meet my criteria. But being able to produce embedded V8 code will not be significantly more difficult for these examples. (Recreating Node's stdlib would of course be difficult but that's separate.) I'm hoping to have a Node-independent target soon.

The majority of comercial JDKs also compile to native code.

You always need something on which to run your program. If you compile your program on openbsd, then you need another openbsd machine to run it, you can't run it on windows. How is something like the jvm different from an os?

I depend on the JVM in my mind traslates to "my target is the JVM"

You are "dependent" if you want on the RunTime (rt.jar). The way it was explained to me, and the model which I sticking to in my mind is:

Abstract Machine/language + RunTime = Level of the onions of a computer.

Assembly/CPU + libc Bytecode/JVM + rt.jar

The language manipulates the resources provided by the machine (registers, stack-machine etc etc).

My recollections are fading though - but I found this model to be good enough to explain me well how a computer works.

I still think it would have been much clearer had the title stated that transpilation was its mechanism.

I don’t know D enough to know whether GC is enabled in this project, which is a major weakness in many dynamic languages that one might imagine aot compilation could eliminate.

Just going off of Wikipedia[1], "A source-to-source compiler translates between programming languages that operate at approximately the same level of abstraction", so at least by that definition, you probably shouldn't call it a "transpiler" if you're compiling from dynamic-typed code to static-typed code.

I view "transpiler" as a recent informal term to be a little more precise/honest when describing compilers targeting JS, but not one that people should feel obligated to use in place of the more generic term "compiler".

[1] https://en.wikipedia.org/wiki/Source-to-source_compiler

I consider the term "compiler" to be very generic, and to cover a wide spectrum of tools ranging from those which compile from one high-level programming language to a slightly lower-level language (e.g. TypeScript), right down those which produce machine code (e.g. GCC/Clang+LLVM). In fact several major compilers (such as GHC and the first C++ compiler, cfront) started out by using C as their backend.

"Transpiler", which is arguably somewhat of a buzzword, typically refers to compilers where the source and target language are either the same, or at a very similar level of abstraction; I agree with n4r9 in considering them a particular type of compiler. Even so, the implementation described in the article compiles from a high-level language, JavaScript, to a considerably lower-level language, C++; so even if we exclude transpilers from our definition of what constitutes a true compiler I still think it's a valid term to apply in this case.

And the first C compilers actually generated Assembly, they weren't capable of generating .o files directly.

In gcc, the compiler proper still generates assembly instead of machine code. It then calls the system assembler (which is usually from gnu binutils) to generate machine code.

I don't remember much argument about the term "compiler" when compilation to C started appearing. That goes back at least as far as Scheme->C [1] and f2c [2]. (f2c was "just" a re-targeting of the first Fortran 77 implementation to a C backend.)

1. http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-89-1.pdf

2. http://www.netlib.org/f2c/

Reply on news.ycombinator.com