[Ecls-list] dev. proposal : parsing *.d files with lisp?

[Sean Champ]

Hello;

:: How this proposal started ::

I had problems with building ecls -- gcc complained about an 'implicit
function declration', and the build failed.

--
g++ -c -I../h -I/mnt/hda1/src/ecls/ecls/src/c -I/mnt/hda1/src/ecls/ecls/src/h  -O3 -fstrict-aliasing -Dlinux -o main.o main.c
/mnt/hda1/src/ecls/ecls/src/c/main.d: In function `union lispunion * quit(int, ...)':
/mnt/hda1/src/ecls/ecls/src/c/main.d:160: implicit declaration of function `int FEwrong_num_arguments(...)'
--

When I was  investigating why this happened, I found out what dpp is, and what
those *.d files under src/c/ are for.

<skipping some explanation>

To try to get gcc to not complain as such, I decided to try to manually code
an error.h for dpp, for which dpp would automatically emit:

#include "error.h"

But, after a while of manually transcribing things from error.d, re-writing
them as preprocessor declarations[1] for error.h, i realized that it may be
helpful if we would simply generate header files from the "raw" *.d file
sources, at the same time as when we make the plain c output.


:: The Proposal ::

Because I'm quite less than a novice with C, i thought that we[2] could simply
build something like 'dpp', but use Common LISP for it. 


Here's one attempt at a prototyping a the "dpp emulator" function:


(defun dpp::parse-file (source &key output header)
 (declare (type (or stream pathname string) output header))
 ...)

 ;; default values for OUTPUT and HEADER would be file-names based on SOURCE




Thus, we could get nice little header files, with all the functions from
SOURCE having been given, each, their own preprocessor declarations.



:: Drawbacks ::

After this, we'd need a LISP to build a LISP -- to build ECL, namely

 - I'm sure the simple parsing function could be made fully portable.

 - I doubt that this build requriement would be much of a problem. 

 - We could make a "non-developer" source distribution of ecls[3], which would
  have all the *.d files already processed, so that the user would not need
  our little LISP DPP::PARSE-FILE



:: Segue out ::


Does my choppy explanation make sense? Does this sound like a good idea?
If so, I'll start working on it today.  Seiously. I like ECL. It seems like
just what the doctor ordered, so to speak.





Good day
--
sean
schamp at users.sourceforge.net





--------------------------------------------------

Footnotes: 
[1]  I'm new to C. I'm not sure if the things in header files are called
     "preprocessor declarations" or not, really. Not wanting to confuse.

[2]  I'll nominate myself for this, gladly

[3]  ...and this, too. It could be automated with some build-scripts that
     would be run on the SourceForge shells,  hypothetically; it seems that
     the Galeon project does something like this, already.