guile-devel
[Top][All Lists]
Advanced

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

Re: GSoC 2011


From: Noah Lavine
Subject: Re: GSoC 2011
Date: Thu, 31 Mar 2011 00:09:22 -0400

> Not since the e-mail. I'm still waiting for feedback.

I will tell you what I think, then, but keep in mind that many people
on this list know a lot more than I do.

The first idea is something I think Guile people are very interested
in, and you could expect to do significant work, possibly having a
working version done, over a summer. I don't know anything about the
second one.

I will also offer a few more suggestions below simply as things for
you to think about, but it would be best if you worked on a project
that you personally were excited about, because you will have a better
time and you will work better like that.

3. More work on Elisp. There's been a plan for approximately 100 years
(ish) to port Emacs to Guile. At the end of last summer, we had an
Elisp frontend that contained everything we would need except for the
Emacs C code. That's probably changed now, because Emacs is merging a
lexical binding branch, but it shouldn't be terribly hard to add
support for that to Guile as well. A good project would be adding
lexbind support to Guile's Elisp frontend, then getting as much of the
Emacs C code as you can ported before the summer ends.

4. A static analyzer. This project has been purely in my own head so
far. I had been planning to write an email to the list talking about
it at some point, but now this chance has come up, so here's an
incomplete introduction: we should have a static analyzing system. It
should be set up so the user can ask it to check specific things, or
perhaps so that the user can define new analyses easily. For instance,
here are some things a user would want to check that a standard
compiler might not realize needed checking:
   - that a specific mutex is always acquired before a certain data
structure is modified
   - that a given function throws one of a certain set of errors
   - that a given function always returns or throws an error
(impossible in general, but very much doable in specific cases)
   - that a given function returns one of a certain set of Scheme types
Bonus points: the analyzer should support both Scheme and C, and the
initial use of it should be checking that Guile itself will always
work as expected. I have some thoughts on how to implement this
without insane amounts of complexity, which I can mention if you are
interested.

5. A JIT compiler. This has actually been my project for quite a
while, and it has been moving pretty slowly. It would move a lot
faster if someone were working on it full time. You would be coming in
partway through this project, but there would still be plenty of
things to figure out, and of course you could always change some of
the earlier decisions I made if they turn out to be bad.

What do you think? Is there a project that seems interesting to you?

Noah



reply via email to

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