[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile Summer of Code project

From: Neil Jerram
Subject: Re: Guile Summer of Code project
Date: Tue, 25 Mar 2008 21:45:05 +0000
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

"Kjetil S. Matheussen" <address@hidden> writes:

> On Tue, 25 Mar 2008, Kjetil S. Matheussen wrote:
>> Neil Jerram:
>>>  Luis Araujo <address@hidden> writes:
>>> >  Hello everyone , how are you?
>>>  Hi Luis!
>>>  Thanks for posting this proposal.  I haven't read every detail yet,
>>>  but have one initial query, and would be interested in your thoughts.
>>>  It seems like it would be a big job to write a C parser in Guile, and
>>>  it also seems that the really interesting results would flow from what
>>>  one could do with the parser output - but that the existence of the
>>>  parser on its own would not be that exciting.
>>>  Therefore I'm wondering if there isn't already a C parser -
>>>  implemented in some other language - that you could use to work first
>>>  on the interesting possible applications of having a C parser.
>>>  This is all assuming, of course, that there is a C parser available
>>>  somewhere that would generate the right kind of output, and I haven't
>>>  actually researched that.  But it seems to me that the advantages of
>>>  doing things this way round would be that
>>>  - it would bring concrete advantages to Guile more quickly
>>>  - the process of working on applications would probably make clear
>>>   whether a Guile-implemented C parser would provide extra benefits,
>>>   and would probably indicate what kind of parser interface and/or
>>>   output would be most useful and convenient.
>>>  What do you think?
>> For me it sounds like you would achieve exactly the same just
>> by combining the output of either swig[1] or gwrap[2] and
>> feed it into eval-c[3-4]. Perhaps 5-6 hours of work, probably
>> less...
>> [1]
>> [2]
>> [3]*checkout*/snd/cvs-snd/eval-c.scm
>> [4]
> Also see this mail from december:

In general terms, this - i.e. duplicating what can already be done -
is my concern too.  From a very quick googling session today, I also
came across sparse (,
and I wonder whether you/we could get more mileage from using (and
contributing to) that, instead of from creating a new implementation.

Luis, have you considered using and building upon these existing
technologies?  If you have, can you say more to justify your
particular proposed approach?  I think that will help to attract
support from GNU project members who will vote on the available


reply via email to

[Prev in Thread] Current Thread [Next in Thread]