Re: GSoC 2011

["Diogo F. S. Ramos" <diogofsr@gmail.com>]

Noah Lavine <noah.b.lavine@gmail.com> writes:

>> 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.

I really appreciate it.

> 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.

About the second thing: It's something I read people talking about in
the IRC channel.

> 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.

I agree. But sometimes what one is first excited with is not what is
best for the project at the moment. That's why I insist on figuring out
where people think the time is best spent on.

And it is not like there is only one cool thing to work on, like you
demonstrated with all the cool ideas. :)

> 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?

All of them are interesting to me actually, but I have some reservations
with (4). It seems to me that it requires a deep understanding of scheme
and guile and I think that maybe I'm not up to the task right now. Not
that this gap couldn't be filled, but it's something to consider.

The (3) is the one which hit closest to home. I'm a Emacs user for some
years now and I remember dreaming about the idea of emacs running on
guile, even though I didn't know guile at the time. I would love to help
with that dream, but I suppose it will require some collaboration with
the emacs developers. I'm sometimes at #emacs and AFAICT elisp is still
evolving.

From the list of 5 ideas, I guess I like (1), (3) and (5) the most. I'm
probably more comfortable with (1) and (3) but maybe it's just my
ignorance talking.

-- 
Diogo F. S. Ramos