Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #162962

Re: Preprocessor <-> compiler

From Bart <bc@freeuk.com>
Newsgroups comp.lang.c
Subject Re: Preprocessor <-> compiler
Date 2021-10-03 17:24 +0100
Organization A noiseless patient Spider
Message-ID <sjclfk$e3c$1@dont-email.me> (permalink)
References <68d48f9f-4268-47e4-8728-a158cbf9c2ccn@googlegroups.com>

Show all headers | View raw


On 03/10/2021 14:47, Thiago Adams wrote:
> I have implemented the preprocessor 'on demand' in my c compiler
> front end and I was kind of regretting it because the code become
> much more complex compared with preprocess in everything in
> advance and separately.
> 
> I was planning to change it to simplify the code but I realized that
> this makes it possible the integration with the compiler.
> 
> My parser asks 'give me the next token’ for a preprocessor state machine
> and it returns only tokens already preprocessed.
> 
> For instance:
> 
> void F() {
> char ch =
> #if 0
>     'a'
> #else
>     'b'
> #endif
>   ;
> }
> after '=' the parser pulls the next token and the preprocessor move
> its internal state consuming preprocessor tokens until it finds 'b' returning it’.
> 
> It asks again and the preprocessor returns ';' changing it internal state
> after consuming (but not returning) #endif.
> 
> The internal state (#include, #ifdefs, #endif) are kept in stacks.
> Macro expansion is on demand as well.
> 
> This preprocessor state machine has an advantage.
> 
> It still happens before the compiler phase but it has the compiler
> context and could access it.
> 
> That means that #if could ask anything for the compiler like sizeof
> of the variable on scope, or if a variable/function exists etc.
> 
> Considering this.. I was wondering if the C language could change its
> concepts to allow this in the future.
> 
> When we read code, we don't do the preprocessor "separated" in
> your mind we do it "on demand" as well.
> 
> The invention of _Static_assert for instance would not be necessary
> 
> Instead of
> 
> _Static_assert( sizeof(x) == sizeof(int), "must be sizeof int");
> 
> we could just write:
> 
> #if   sizeof(x) != sizeof(int)

This requires that the lexer knows about symbol tables, scopes and user 
types, and that operations such as building those types and user types 
and the name resolution required to figure out which x is intended, are 
all done while parsing.

In other words, that part needs to be single pass, which puts a 
constraint on the compiler.

Also, what happens when someone /only/ wants to do a preprocessing pass? 
Then 'sizeof(x)' is meaningless.

Would you have to remove that ability from the language? I think more 
than a few compilers depend on a third party preprocessors, and various 
language processing tools may depend on it too.

So it's an unlikely retrofit for C.

For a new language though, or one which eventually transpiles to C, you 
can define it as you like.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 06:47 -0700
  Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 08:38 -0700
  Re: Preprocessor <-> compiler Bart <bc@freeuk.com> - 2021-10-03 17:24 +0100
    Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 10:55 -0700
      Re: Preprocessor <-> compiler Bart <bc@freeuk.com> - 2021-10-03 19:41 +0100
        Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 12:16 -0700
          Re: Preprocessor <-> compiler Bart <bc@freeuk.com> - 2021-10-03 20:28 +0100
            Re: Preprocessor <-> compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 14:12 -0700
  Re: Preprocessor <-> compiler Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-10-06 08:41 -0700
    Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 10:56 -0700

csiph-web