Malcolm would have to attest to how complete it is w.r.t. say, gcc's
preprocessor,
cpphs is intended to be as faithful to the CPP standard as possible,
whilst still retaining the extra flexibility we want in a non-C
environment, e.g. retaining the operator symbols //, /*, and */. If
the
I tried to devise a C preprocessor, but then I figured out that I
could write something like that:
---
#define A(arg) A_start (arg) A_end
#define A_start this is A_start definition.
#define A_end this is A_end definition.
A (
#undef A_start
#define A_start A_end
)
On 30 March 2010 18:55, Serguey Zefirov sergu...@gmail.com wrote:
Other than that, C preprocessor looks simple.
Ah no - apparently anything but simple.
You might want to see Jean-Marie Favre's (very readable, amusing)
papers on subject. Much of the behaviour of CPP is not defined and
often
(sorry for the dupe aaron! forgot to add haskell-cafe to senders list!)
Perhaps the best course of action would be to try and extend cpphs to
do things like this? From the looks of the interface, it can already
do some of these things e.g. do not strip comments from a file:
I'd be very much interested in working on this library for GSoC. I'm
currently working on an idea for another project, but I'm not certain
how widely beneficial it would be. The preprocessor and
pretty-printing projects sound especially intriguing.
On Tue, Mar 30, 2010 at 1:30 PM, Aaron Tomb
Yes, that would definitely be one productive way forward. One concern
is that Language.C is BSD-licensed (and it would be nice to keep it
that way), and cpphs is LGPL. However, if cpphs remained a separate
program, producing C + extra stuff as output, and the Language.C
parser understood
On 19:54 Tue 30 Mar , Stephen Tetley wrote:
On 30 March 2010 18:55, Serguey Zefirov sergu...@gmail.com wrote:
Other than that, C preprocessor looks simple.
Ah no - apparently anything but simple.
I would describe it as simple but somewhat annoying. This means that
guessing at its
That's very good to hear!
When it comes to preprocessing and exact printing, I think that there
are various stages of completeness that we could support.
1) Add support for parsing comments to the Language.C parser. Keep
using an external pre-processor but tell it to leave comments in
On Tue, Mar 30, 2010 at 7:30 PM, Aaron Tomb at...@galois.com wrote:
Hello,
I'm wondering whether there's anyone on the list with an interest in doing
additional work on the Language.C library for the Summer of Code. There are
a few enhancements that I'd be very interested seeing, and I'd love
On Mar 30, 2010, at 3:16 PM, Tom Hawkins wrote:
On Tue, Mar 30, 2010 at 7:30 PM, Aaron Tomb at...@galois.com wrote:
Hello,
I'm wondering whether there's anyone on the list with an interest
in doing
additional work on the Language.C library for the Summer of Code.
There are
a few
On Tue, Mar 30, 2010 at 5:14 PM, Aaron Tomb at...@galois.com wrote:
That's very good to hear!
When it comes to preprocessing and exact printing, I think that there are
various stages of completeness that we could support.
1) Add support for parsing comments to the Language.C parser. Keep
Stephen Tetley wrote:
Much of the behaviour of CPP is not defined and
often inaccurately described, certainly it wouldn't appear to make an
ideal one summer, student project.
But to give Language.C integrated support for preprocessing, one needn't
implement CPP. They only need to implement the
12 matches
Mail list logo
