> 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