Re: Parsing partial sentences

George Neuner <>
Fri, 21 Apr 2017 07:41:10 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: Parsing partial sentences (Martin Ward) (2017-04-11)
Re: Parsing partial sentences (Hans-Peter Diettrich) (2017-04-11)
Re: Parsing partial sentences (Martin Ward) (2017-04-11)
Re: Parsing partial sentences (George Neuner) (2017-04-11)
Re: Parsing partial sentences (Hans-Peter Diettrich) (2017-04-12)
Re: Parsing partial sentences (Hans-Peter Diettrich) (2017-04-20)
Re: Parsing partial sentences (George Neuner) (2017-04-21)
Re: Parsing partial sentences (Walter Banks) (2017-04-27)
Re: Parsing partial sentences (Kaz Kylheku) (2017-04-27)
Re: Parsing partial sentences (Hans-Peter Diettrich) (2017-04-28)
Re: Parsing partial sentences (2017-04-28)
Re: Parsing partial sentences (Marco van de Voort) (2017-04-29)
Re: Parsing partial sentences (Kaz Kylheku) (2017-04-30)
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers
Date: Fri, 21 Apr 2017 07:41:10 -0400
Organization: A noiseless patient Spider
References: <> 17-04-011 17-04-021
Injection-Info:; posting-host=""; logging-data="89198"; mail-complaints-to=""
Keywords: parse
Posted-Date: 23 Apr 2017 12:54:05 EDT

On Thu, 20 Apr 2017 16:14:43 +0200, Hans-Peter Diettrich
<> wrote:

>After thinking more about macro expansion, interpretation of the macro
>text should occur only when a macro is actually used, so that all
>referenced identifiers (other macros, parameters, variables, functions)
>are known to the parser/compiler. At that point the returned
>non-terminal from the expanded macro can be used immediately to
>determine a possible macro conversion.
>Some attributes should be added to the parse tree, so that it will be
>possible to determine the macro name for every token, if it results from
>a macro expansion, and the kind, type and scope of all used identifiers.
>As long as only literal constants occur in the parse tree, the macro can
>be converted into a named constant[1]. If identifiers occur as well,
>more checks are required to reject e.g. identifiers of non-global scope,
>before the macro can be converted into a function[2].

So far, so good. Actually converting "function" macros into functions
[where possible] should lead to improved maintenance.

However, in the past I have run into some bizarre macro systems where
some macros create data structures for other macros to manipulate.

I'm just guessing as I don't have an example handy - but considering
such entwined macros independently, I could see manipulation macros
being rejected by your translator for appearing to reference
"identifiers of non-global scope".

>If all tests are passed, the macro equivalent can be constructed and
>stored, for later use. If such an equivalent has already been stored,
>the new construct has to be compared with that first construct, to sort
>out possible variations due to macro redefinition or varying macro
>argument types. It may be possible to handle varying argument types by a
>transformation into generic functions, or by type expansion.
>Provisions also are required (and already implemented) to prevent
>duplicate parsing of properly guarded header files, which otherwise
>could confuse the automatism about preceding expansions of macros.
>Did I miss something?

Some actual things done with C macros.,-tips,-and-idioms

> Martin Ward said:
>> However, in practice it depends on the purpose of your C to Pascal
>> convertor. If it is to be a general purpose tool which has to be
>> able to handle any C source code that anyone throws at it,
>> then you are stuck.
>See above, my convertor only accepts valid C code. In so far the user
>can throw any valid C source file at it. It's only required that the
>original compiler and its libraries are made known to the convertor, so
>that all compiler-predefined macros are known, and all #included header
>files are available for parsing.

Seemingly non-sensical macros can lead to valid C code. In one
stackoverflow example they led to valid Java.

>> An intermediate approach might be to keep all the macros
>> which look straightforward and fall back on expanding macros
>> which do weird things with the syntax.
>That's the current implementation, which does not yet handle translated
>#defines at all.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.