Recent Features
| |||||||||||||
Facebook's "HipHop" PHP translatorFacebook's "HipHop" PHP translatorPosted Feb 2, 2010 22:01 UTC (Tue) by xorbe (subscriber, #3165)In reply to: Facebook's "HipHop" PHP translator by ncm Parent article: Facebook's "HipHop" PHP translator
> There's no difference between ...
> The only difference ...
Anyways, most people consider a compiler to generate something a bit lower level than C++, and would consider "source code transformation" to be more informative about its true nature.
(Log in to post comments)
Facebook's "HipHop" PHP translator Posted Feb 2, 2010 22:19 UTC (Tue) by ccshan (guest, #2723) [Link]
Your quotes are out of context; please read what you quoted again. There's no difference between a compiler and a source-code transformer. There are differences between a compiler/source-code-transformer that uses less direct routes and one that uses more direct routes. A compiler can use less or more direct routes just as a source-code transformer can use less or more direct routes, because, after all, there is no difference between a compiler and a source-code transformer.
Separately, you suggested that a compiler is considered "to generate something a bit lower level than C++". According to this definition, and assuming that assembly code is "lower level than C++", you would call a preprocessor for assembly code (such as HLA "the High-Level Assembler" perhaps) a compiler, right? After all, it generates assembly code.
Facebook's "HipHop" PHP translator Posted Feb 3, 2010 4:41 UTC (Wed) by xorbe (subscriber, #3165) [Link]
What? Yeah so technically the terms are interchangeable, but I'd use compiler, source transform, and preprocessor as others would expect within a too change.
PHP code -> source code transform -> g++ compiler
That's how 99.9% would talk about it.
PHP code -> compiler -> compiler
That's you confusing the 99.9%! That's it, I'm referring to all input/output programs as transmogrification binaries!
A compiler's a compiler, no matter how small Posted Feb 3, 2010 7:11 UTC (Wed) by ncm (subscriber, #165) [Link] 99.9% of statistics are made up on the spot.Regardless, a program that takes source code and gives you a binary executable is a compiler. If it happens to use G++ inside none of the user's business. So, 99.9% of people who have the faintest idea what a compiler is (i.e., 0.1% of normal people) would call it a compiler, because that's what it is. Be proud, you're in the remaining 0.001% of the population who call cars "four-wheeled self-propelled vehicles" and hamburgers "layered bovine handmeals" or something.
A compiler's a compiler, no matter how small Posted Feb 3, 2010 10:25 UTC (Wed) by dgm (subscriber, #49227) [Link]
Close, but no cookie. A program that takes source code and gives you an executable binary is usually a compiler+assembler+linker, or at least a compiler+linker.
There's more than opcodes in an executable file.
A compiler's a compiler, no matter how small Posted Feb 3, 2010 19:55 UTC (Wed) by ncm (subscriber, #165) [Link]
Gcc produces binary executables. Gcc uses gas and gold underneath, and that's none of my business. Gcc is a compiler.
Enjoy your layered bovine handmeals.
Compiling is not translating Posted Feb 4, 2010 22:15 UTC (Thu) by man_ls (subscriber, #15091) [Link] The difference is important. I am currently trying to write a program to translate Java code to Python code, and no sane mind would call that a compiler. Even if it generates code and then tries to run it. I don't know if "code transformer" is a good description, but "compiler" is not it. I prefer calling the process "translation" myself.My mother makes hamburgers with 50% beef, 50% pork. They are delicious. You may choose to call them something else than "hamburgers" and I will not be offended.
Compiling is not translating Posted Feb 4, 2010 23:19 UTC (Thu) by nix (subscriber, #2304) [Link]
Indeed. Compilers are a special kind of translator, not vice versa. (GCC
is a translator: so is your Java->Python transformer.)
Compiling is not translating Posted Feb 4, 2010 23:22 UTC (Thu) by ccshan (guest, #2723) [Link]
> Compilers are a special kind of translator
So, which special kind is that?
Compiling is not translating Posted Feb 4, 2010 23:53 UTC (Thu) by nix (subscriber, #2304) [Link]
A translator which targets something which can be executed, typically.
Things are blurred somewhat when one considers compilers that yield various forms of bytecode which are then interpreted by something else.
Translators can yield all sorts of output: e.g. IDL 'compilers' which in
Compiling is not translating Posted Feb 5, 2010 1:44 UTC (Fri) by ccshan (guest, #2723) [Link]
I don't see what you mean by "execute". For example, I'm not sure why you think DVI is not executable but PostScript is. Maybe you mean that DVI is not Turing-complete but PostScript is, but lots of things are compiled to finite-state machines (if only large ones).
And C++ header files *are* Turing-complete, if we ignore implementation limits on template instantiation (just as we ignore physical-computer limits on memory use).
Compiling is not translating Posted Feb 5, 2010 9:36 UTC (Fri) by anselm (subscriber, #2796) [Link] TeX is no more or less of a compiler than the Sun Java »compiler« is. Both create machine code for a »virtual« processor that is then executed by a specialised interpreter. Read sections 583-591 of »TeX: The Program« by Donald E. Knuth.
Compiling is not translating Posted Feb 5, 2010 15:44 UTC (Fri) by marcH (subscriber, #57642) [Link] A translator which targets something which can be executed, typically. Things are blurred somewhat when one considers compilers that yield various forms of bytecode which are then interpreted by something else.The "executable" road will never reach any satisfying definition. It will always be "blurred somewhat". You might have a bit more success with "high-level vs low-level", as found in Wikipedia. Maybe.
Compiling is not translating Posted Feb 5, 2010 17:13 UTC (Fri) by man_ls (subscriber, #15091) [Link] It is not so blurred; since modern processors have a native mode of execution there is an absolute: a native executable format. Even if internally they translate the instruction set to microcode, that layer is inaccessible from the outside. So there is at least one public native executable format per processor, although there can be more (for instance x86 and x86_64). "Compiling" is going from a human-readable file to this executable format. Merriam-Webster has a clear definition:2 : a computer program that translates an entire set of instructions written in a higher-level symbolic language (as C) into machine language before the instructions can be executedFrom there up files are not literally executable. However judging by the similarity to a processor instruction set people can create virtual machines, bytecode languages and the like. So moving from human-readable files to machine-readable files can be called "compiling" by generalization. Still there is no blurring: going from human-readable to human-readable I would call "translating", and from machine-readable to machine-readable I would call "emulation".
Compiling is not translating Posted Feb 5, 2010 17:41 UTC (Fri) by ccshan (guest, #2723) [Link]
The two blurry parts of your definition of "compile" are what is human-readable and what is machine-readable. If whether a layer is "inaccessible from the outside" is relevant as you suggested, then would a translator from PHP to C++ become a compiler as soon as someone builds a sealed box that takes C++ code as input and runs it (or even type-checks it)? If whether a language is "similar" to a processor instruction set is relevant as you suggested, then is JVM bytecode really all that similar to a processor instruction set and all that dissimilar to C++ code? (Compare: LISP machine.) Also, humans can understand machine code.
Compiling is not translating Posted Feb 5, 2010 18:07 UTC (Fri) by man_ls (subscriber, #15091) [Link] I don't agree with the last part: humans can maybe understand machine code, but not read it in the usual sense. Just as there is usually no ambiguity between text files and binary files.As to the rest, I'm fine with it: as far as something can be said to be human-readable and something else can be said to be machine-readable, "compiling" is converting between the two. A PHP -> C++ translator, combined with a C++ compiler, yields a PHP compiler.
Compiling is not translating Posted Feb 5, 2010 18:14 UTC (Fri) by ccshan (guest, #2723) [Link]
> humans can maybe understand machine code, but not read it in the usual sense. Just as there is usually no ambiguity between text files and binary files.
So, which usual sense is that?
> as far as something can be said to be human-readable and something else can be said to be machine-readable, "compiling" is converting between the two
Continuing with the obvious Posted Feb 5, 2010 18:45 UTC (Fri) by man_ls (subscriber, #15091) [Link] Text files are strings of values that map to letters and symbols. ASCII for instance is restricted to 0-9, A-Z, a-z, some punctuation marks and a few other symbols; Unicode is quite wider but still maps code points to printable symbols. Binary files are streams of bytes with no such intent.For "machine-readable" I obviously mean "readable to execute". While "human-readable" is "readable to understand". Again, the intent is what counts. And before you continue pointing out silly flaws: unlambda or brainf*ck are not really made to be readable, but are still meant to be understood by people.
Continuing with the obvious Posted Feb 6, 2010 0:47 UTC (Sat) by marcH (subscriber, #57642) [Link]
> Text files are strings of values that map to letters and symbols. [...] Binary files are streams of bytes with no such intent.
Sorry but the text/binary boundary does not work any better. It's just a uninteresting and irrelevant matter of representation and encoding. You can store very high-level languages in binary and very low-level languages in ASCII.
Consider assembly for instance. It is text. So following your logic "gcc" is a just a "translator" and "as" is a compiler?
Text and assembly Posted Feb 6, 2010 10:57 UTC (Sat) by man_ls (subscriber, #15091) [Link] Let me answer both of you at the same time since you make similar arguments. Text encodings are not just a trivial matter of representation, any more than the alphabet is just a trivial matter of drawing pretty lines. Text encodings are the essence of symbolic representation with computers. The level of the language is not really relevant.Consider assembly for instance.Assembly language is not an instance; it is a special case of a language designed to mimic machine instructions and still be understandable by humans. To the extent that "return" is as much a symbol as "0x4e75", you are right that both things are equivalent; but assembly is not a real language so much as a mere transposition of opcodes. In fact, it is so much a boundary case that a special term has been invented for the conversion between assembly and machine code, also called "assembly" -- and this process is so distinct that it gives its name to the language itself, "assembly language". Aren't words fun?
Text and assembly Posted Feb 6, 2010 22:22 UTC (Sat) by ccshan (guest, #2723) [Link]
You have not answered any question, even explicit questions about your supposedly non-blurry distinction between compilers and mere translators, nor dispelled any concern, even explicit concerns about your distinction between compilers and mere translators being blurry. Questions to answer are signaled by the question-mark (?) punctuation.
Text and assembly Posted Feb 7, 2010 0:26 UTC (Sun) by man_ls (subscriber, #15091) [Link] I'm sorry that you feel that way, but I have tried to clarify (not answer) what I felt were the important questions (implicit or explicit) in the discussion. The rest has no interest for me, and I would probably be the wrong person to answer them. I did learn something in the discussion and the issue of compiling vs translating vs mere assembling is now clearer for me, so thanks for that.
Continuing with the obvious Posted Feb 6, 2010 0:47 UTC (Sat) by ccshan (guest, #2723) [Link]
> Binary files are streams of bytes with no such intent.
I assume that by "such intent" you mean intent to be "readable to understand". But do you mean a file as a sequence of bytes or a file as displayed by, say, the Linux console to the human retina? If the former (which is the text/binary distinction that file(1) tries to make), then a text file (such as 116 104 105 115) is no more intended to be "readable to understand" than a binary file. If the latter, then isn't README.gz a text file? In any case, I don't see an answer to the question "humans can maybe understand machine code, but not read it in *which* sense".
> For "machine-readable" I obviously mean "readable to execute". While "human-readable" is "readable to understand". Again, the intent is what counts.
Isn't the PDP-11 machine language intended to be "readable to understand"? If someone were to design a programming language to be "readable to understand", but that language ended up isomorphic to another language designed to be "readable to execute", then would translators that produce this/these language(s) be compilers? (It has happened.) Is an assembly-language preprocessor a compiler but cpp a mere translator?
Given that all programming languages are intended to be "readable to execute", no distinction has been made between translators and compilers. A PHP->C++ translator is a PHP->C++ compiler.
|
|||||||||||||