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 b
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
On Tue, Mar 30, 2010 at 5:14 PM, Aaron Tomb 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 using an
> ex
On Mar 30, 2010, at 3:16 PM, Tom Hawkins wrote:
On Tue, Mar 30, 2010 at 7:30 PM, Aaron Tomb 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 v
On Tue, Mar 30, 2010 at 7:30 PM, Aaron Tomb 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 be a
> ment
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 the
On 19:54 Tue 30 Mar , Stephen Tetley wrote:
> On 30 March 2010 18:55, Serguey Zefirov 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 specification wil
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 th
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 wrot
(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:
http://hackage.haskell
On 30 March 2010 18:55, Serguey Zefirov 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 inaccurately des
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
)
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 be a mentor for such a project if there's a student
interested
13 matches
Mail list logo
