Melvin Smith wrote:
At 08:44 PM 1/9/2004 +0000, Harry Jackson wrote:

So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later.


I think we are going to have an alternative to C<.constant> builtin to IMCC, the best suggestion seems to be C<.define>

As far as macros, I guess we will keep them for the near future. I think its
time to create a new branch for imcc development, so lets see how
things work out. It may be that we can keep them in some form.


One thing to consider: when we put an API on top of IMCC, macros won't
translate; they are only for the text version.

Thankfully this will not affect me.


I am unable to find the email now but I remember someone mentioning breaking the pre-processor out of IMCC and into its own program, it was probably yourself. I have a few questions about this.

What are the requirements on the pre-processor. I am pretty rusty with C and decided that I would oil my joints a little so I have been playing with a toy pre-processor (Thank god for K&R). I know I should probably work with the one already there and not re-invent the wheel, I am also sure there are better ways to do it than the way I am doing it but.......... ;-)

This is as far as I have got and roughly how things are processed.

$ preprocess filename.imc

1. Ignore comments where the *#* comes before text. If there is any text before the "#" I process the line as a normal statement

    # This line will not be processed
    .pcc_call blah # This line will be processed

2. Recursively process ".include" files ie

    .include "/file/blah/blah"
     goto step 1.

3. Store macro declarations in a hash table ie

    146 .macro PQgetvalue(RES, tuple_num, count, data)
    147     P0 = global "PostgreSQL::PQgetvalue"
    148     I5 = .tuple_num
    149     I6 = .count
    150     P5 = .RES
    151     invoke
    152     .data = S5
    153 .endm

gets stored as "PQgetvalue" and a linked list holds each line up to the ".endm". This is the area I need some clarification on. How is the current pre-processor handling arguments to the macros. Do they need to be pre-processed and if so in what ways.

4. Find macro calls by name assuming they have been found in Step 3 ie

.PRINT(RES)

and replace with the macro text. Using the name "PRINT" I access the hashtable traverse the linked list of lines printing them out as I go along.

There are a few minor bugs in it which I am working on. I was just wondering what other types of things would the pre-processor need to handle.

If you managed to get this far and are still interested. I have used a seriously hacked version of the dbj2 hash to store the macros. I had a look at the one in K&R and thought I would have a look for a few others and this was the first one I found on google.

http://www.cs.yorku.ca/~oz/hash.html

Harry



Reply via email to