There's a benefit to being able to *parse* a language using a context-free grammar. This allows text editors to perform highlighting, auto-completion, etc without having to track identifiers (which isn't always possible; editors have to be able to work with incomplete code).
That is certainly true - it is not easy for an editor to use different syntax highlighting for C functions and variables, for example. Context-free, or close to context-free, makes this a lot easier. It also makes compilation easier and faster (which was one of the goals of "go"). However, I'd prefer the editor to have to work harder rather than me - I would parse the difference between "public foo" and "private foo" faster than the difference between "Foo" and "foo". I can always buy a faster computer, and a better parser only needs to be written once, but it's hard to upgrade the human brain...
is go so badly broken that it doesn't use the "#line" preprocessor directive to enable source level debugging? or are you making shit up?
If you check the doc's, they mention that the GCC frontend generates C code, which is all you get for debugging.
--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
I haven't read the docs, so I'll take your word for it. But if that's the case, then it is not a gcc frontend - it's a pre-processor generating C as an intermediary language. That's fair enough - there are several compiler tools that do that, and it's a quick way to make a fairly portable tool. But the terminology they have used on the website is at best misleading.
Of course not. It's a nice symmetry. Previously one could only get confused about the order the parameters. Now scope for confusion about the order of results has been added.
Sylvia.
On Nov 19, 9:13=A0am, David Brown
I disagree with your use of the term "pre-processor" it can still be a full compiler that generates C code. A pre-processor doesn't do type checking, semantics, etc. very important for embedded code.
Do you have a suggestion for a better term? You are certainly correct that the compile-go-to-C program has more compiler features than the traditional C pre-processor, but less than a traditional compiler.
How much of the original structure is retained in the C code?
GHC's C output isn't noticeably higher-level than its assembler output, so I'd call it a compiler whether it's generating C or assembler.
OTOH, if the Go compiler's C code preserves much of the structure of its input (along the lines of CFront or f2c), I'd call it a translator.
No idea.
That sounds reasonable enough to me. Since I can't answer your question, however, I can't tell which is the most appropriate. Maybe if I keep quiet, someone who has actually tried the software can give us an answer!
's
came across: A "source-to-source compiler" is a type of compiler that takes a high level language as its input and outputs a high level language.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.