Python Front-end to GCC

[Steven D'Aprano]

On Tue, 22 Oct 2013 08:04:21 -0700, Mark Janssen wrote:


>>>> A language specification in BNF is just syntax. It doesn't say
>>>> anything about semantics. So how could this be used to produce
>>>> executable C code for a program? BNF is used to produce parsers. But
>>>> a parser isn't sufficient.
>>>
>>> A C program is just syntax also.  How does the compiler generate
>>> executable machine code?  Extrapolate into a Python front-end to C.
> 
> [Dave Angel responds:]
>> Did you even read the paragraph you quoted above?  The BNF
>> specification does NOT completely describe a language, it only defines
>> its syntax.
> 
> [Steven D'Aprano responds:]
>> Like every other language, C programs are certainly not *just* syntax.
>> Here is some syntax:
>>
>> &foo bar^ :=
> 
> Now, I don't know where y'all were taught Computer Science, 

Melbourne University Computer Science Department. How about you?


> but BNF
> specifies not only syntax (which would be the *tokens* of a language),
> but also its *grammar*;  how syntax relates to linguistic categories
> like keywords, and tokens relate to each other.

I'm not about to get into a debate about the difference between syntax 
and grammar as they apply to computer languages, because it doesn't 
matter. Neither syntax nor grammar tell you what something *means*, the 
semantics of the code. The parser knows that (say) "x ^% y" is legal and 
(say) "x y ^%" is not, but it doesn't know what machine code to generate 
when it sees "x ^% y". That's not the job of the parser.

I expect that some compilers -- ancient ones, or lousy ones, or simple 
ones -- have a single routine that do all the parsing, lexing, code 
generation, linking, optimizing, etc., rather than separate routines that 
do the parsing, the code generation, and so on. But even those compilers 
cannot just take a description of the syntax and intuit what it means.

Syntax isn't enough. At some point, the compiler needs to know that "^" 
means to generate code to dereference pointers (like in Pascal), or 
perhaps it's bitwise or (like in C), or maybe even exponentiation (like 
in VisualBasic), or perhaps it's something completely different.


> Dave is claiming that BNF only defines the syntax of a language, but
> then Stephen goes on to supply some syntax that a BNF specification of
> the language would not allow (even though Steven calls it "syntax" which
> is what BNF in Dave's claim parses).

I think you have misunderstood me. I gave an example of some invented 
syntax that your hypothetical language might choose to use. Here it is 
again:

&foo bar^ :=

Since I didn't provide the BNF specification for that syntax, you aren't 
in a position to say it is illegal. You should assume that it is legal 
syntax. If you really insist, I'll waste my time and yours and generate a 
BNF specification that allows that as valid syntax, or you could just 
accept that it's legal for this imaginary language.

Your task is to describe what the code does, and hence what machine code 
your hypothetical compiler will generate, when it sees that line of code.

You should be asking "How the hell can I tell what that does?" Exactly. 
That's the point. Neither can the compiler, not from syntax alone.


-- 
Steven