unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Noah Lavine <noah.b.lavine@gmail.com>
To: "Diogo F. S. Ramos" <diogofsr@gmail.com>
Cc: guile-devel@gnu.org
Subject: Re: GSoC 2011
Date: Thu, 31 Mar 2011 00:09:22 -0400	[thread overview]
Message-ID: <AANLkTik7ac6uyhR76yyrvHm1h=Oy9a3_BaNzgQEaSna=@mail.gmail.com> (raw)
In-Reply-To: <87lizwvu0v.fsf@gmail.com>

> 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	other threads:[~2011-03-31  4:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-28  4:51 GSoC 2011 Diogo F. S. Ramos
2011-03-31  3:29 ` Noah Lavine
2011-03-31  3:38   ` Diogo F. S. Ramos
2011-03-31  4:09     ` Noah Lavine [this message]
2011-03-31 13:39       ` Diogo F. S. Ramos
2011-03-31 10:18 ` Andy Wingo
2011-03-31 14:31   ` Diogo F. S. Ramos
2011-04-04  3:28     ` Noah Lavine
2011-04-04 14:19       ` Diogo F. S. Ramos
2011-04-05 10:57         ` Andreas Rottmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTik7ac6uyhR76yyrvHm1h=Oy9a3_BaNzgQEaSna=@mail.gmail.com' \
    --to=noah.b.lavine@gmail.com \
    --cc=diogofsr@gmail.com \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).