I wrote:
Hm, should I try to offer mentoring:
- working on chjmodule (renaming it at that occasion)?
- working on some other module system?
I see that mentors must be listed already at the organization application. I'll release my current code quickly now (give me 24h).
Sorry, I can't make it so quick. Believe me, I really just started working again on it two days ago (it's only six days since I'm not tied up in a job anymore, too), and adapting to the newer Gambit releases is a little more complicated for me than I had wished; what I'm hitting against right now is the change in Gambit to not define standard forms like define or lambda in non-"" namespaces anymore; this is a sensible change, but I really have to build clean identifier handling in now, I don't just want to include ~~/lib/gambit#.scm because then one couldn't override any such identifiers anymore without globally affecting all code.
I'll continue hacking after this mail (I'll also analyze how Snow does things), expect me to invest half of my time of the upcoming days.
Let me advertise my planned work (in which a student could participate or take on parts) like this:
- study enough Gambit internals in the area of parsing/compilation stages, macro expander integration, repl handling, and debugger displays, symbol table handling, and possibly more, to be able to adapt and integrate any module system work cleanly.
- create a module system that's easy and practical for everyday work, meaning highly interactive, and at the same time aiming to enable optimizations which can lead to fast code without compromising code clarity (like e.g. cross module inlining, and specialization for parametrized modules).
- experiment also with the practical aspects on the filesystem side (filesystem layout, compilation caching strategies, C code compilation / some sort of make tools integration (integrate make tool calls into the module system and not vice versy!)).
- especially after the above infrastructure is well in place, study the existing approaches of modularization and syntax handling out there (Scheme48, MzScheme, Chicken's attempts at mixing syntax systems, riaxpander (http://mumble.net/~campbell/darcs/riaxpander/), R6RS, ERR5RS)
- think of every way that object oriented practices are being used to achieve modularization in OO languages and find the right counterpart for Scheme. (There will also probably always be *some* need for dynamic type dispatch (virtual method calls), be open to interface to a CLOS like OO system for this.)
- code is data, data is code: treat files that other languages would consider data (e.g. XSLT files) as modules. Also explore XML namespaceing ideas in s-expr syntax.
- those findings which are deemed important (and are not Gambit-specific, e.g. performance oriented), are meant to become portable by integration into or building on top of the Snow framework.
I would be happy if a student or other people would take part in this. So I would like to offer to be a mentor. I think we may not get done everything of the above during this summer, so if you want to participate (or also if you don't) help pick out what you think is important.
If you think the GSoC job description should be more precise than that, please tell me, so that we can come up with something better.
Christian.