(Unlike the other pages, this is written in first-person perspective by Christian, as he's organizing this.)
This is about the formation of a group that regularly meets to work on a project, a compiler for the programming language Scheme. The ultimate goal is for the result to be worthwhile for us to use, although the primary aim is to learn how to do this. Scheme is a good choice because although in some ways it's a simple language to implement, in other ways it's also an interesting (demanding) one, and it's a general and clean language usable for real work if one wishes to use the result. Also, it will be a good basis on which to later implement type systems, should we wish to do a followup project.
I'm hoping to satisfy participants with a somewhat wide experience spectrum. I'm not looking for contributors for this project because I'm thinking that this will get it done faster, but because I'm hoping to learn from you just as I'm hoping that you'll learn something. And enjoy ourselves while doing it. I'm limited in the amount of help I can provide by the time and attention I can invest before it interferes with working with the rest of the group. I'm asking for everybody to be courteous and helping out where they see fit and communicating in a way that all involved can understand.
You should not mistake this for a course or classes because:
I'm doing this the first time, and I don't know whether it will work the way I expect. Perhaps there are more people interested than I can take care of, or perhaps thoughts and needs of the various participants are farther off than I can bring in tune. I'll try to lead, but this is also a group effort, perhaps the group as a whole can make it work in ways that I'm not anticipating. Or perhaps we'll have to reconsider the situation if things aren't working and do changes (including possibly shrinking the group).
This will be more learning by doing than being teached, even though I'll be able to guide most of the time. Unlike solving exercises, we'll try to do real work towards the product goal as much as we can, hence we'll want to parallelize the development, thus usually only one or two persons are going to work on the same task. We'll meet regularly to report progress, exchange results, and get help and feedback.
(There are some Exercises but these are just meant to get you thinking about something, and may be helpful for discussion. They are generally optional, although I might ask for some of them to be solved for some particular meeting when I'm anticipating that they will help making the next problem that needs tackling clear.)
not everything is planned or prepared to the detail; there are still parts that I haven't thought through in detail and hence where the devil will lie and require creative action for solution. (While I have read about how to implement programming languages, visited a course on programming language implementation in the past, analyzed some existing implementations and have been using Scheme extensively so I do know what an implementation needs, I haven't written a complete one myself yet.)
We may even realize that we have to tackle parts of the project differently than planned here. And I may not realize this by myself, so don't hesitate to point out issues.
Not everyone will have the same level or kind of experience. If you don't understand something or don't know how to approach something, please ask. We'll then try to find a good solution, like me or someone else explaining, pairing up for work, or similar. I may ask you to do some reading if I see this can fill the gap (combined with support over email/IRC).
If you feel that you could help someone in such a situation, please consider taking initiative. You haven't properly understood a topic yourself unless you've teached it to someone else, so this may benefit you, too.
Participation is free except if there are costs for location or infrastructure that need to be shared (currently not expected).
In the search for a term to describe this format, "workshop" came to my mind. I think of a workshop as a location where one can actively and efficiently work on a (common) object, and where tools or knowledge are available. I do see the term being used for events with a predefined program (talks or poster presentations) with passive participation, though, so perhaps I should use a different term? (Also, these events are usually not free.)
This is for people who are already familiar with Scheme or another Lisp, or have experience with functional programming from another environment. You should either have worked through the SICP course materials, chapters 1-2, or should check whether you're able to solve the exercises there. If in doubt, I suggest you contact me or us early on if possible (before the start of the stage of the project for which you want to contribute), then we can find out what knowledge you're missing if any and suggest preparatory studying before the start of the work (I'll try to support you with it) if necessary.
Consider joining the London SICP Study Group (see below) if that could be beneficial for you.
Don't hesitate to contact me to see whether I think you'll fit. You can also subscribe to the bottoms-public mailing list to stay current about our planning before deciding to join.
The workshop will consist of meetings and activity between the meetings. The meetings will be used for:
report on progress, problems, results from the work between the meetings.
work together to solve problems if necessary
resolving problems merging code
explaining the next steps to be taken, discussing them, dividing work into tasks and distribute them to the participants (individuals or perhaps pairs (or subgroups)).
possibly small presentations about papers or other projects that help understanding of an area of the project on which we have limited understanding ourselves (see also Questions and Reading).
possibly do individual work if time permits
Between workshop meetings, participants will work individually on their choosen task (coding, perhaps reading), possibly using email or IRC for communication.
There are multiple relatively independent stages and hence possible points in time when participants can join:
implement S3C if we want to use that to implement the VM. This includes getting familiar with C if not already, getting to know Scheme more intimately, writing a simple compiler/translator (top-down instead of bottom-up), writing rules-based tests and possibly testing framework. More advanced than part 3.
implement the VM (VML). This includes learning S3C or whichever other language we're using as implementation language, plus writing rules-based tests (or dealing with an advanced type system (and possibly proof assistant)). S3C should make it easy to contribute, the language is pretty simple and the safe implementation will point out errors dynamically (i.e. easy to understand). Advanced debugging techniques are only used when needed and can be explained when situations that require them turn up. Writing tests smartly will require some clear thinking, but doesn't require special knowledge. Rust or ATS may require quite a steep investment first before knowing enough to write the VM (and contributors adding complex types in an attempt at encoding security requirements might make things more difficult for the others to understand).
write a language on top of VML, by growing it towards Scheme step by step. This should be easy to follow or teach as the steps are mostly incremental.
It will be best if you participate during the whole time of a stage, as otherwise you'll not be up to date about what we're doing and will need help to catch up. If you'd like to join (or rejoin after missing several meetings) after the start of a stage, ask and we'll see what we can do. If you can't come for a meeting, please give note about what the others should know about the project part that you're working on, and afterwards read and ask about what we've been doing. If you often can't come for a meeting, you may need to find someone else to work in a pair.
Currently planned are meetings of 2.5 hours (6:30 pm - 9 pm) every fortnight, plus a personal investment of about the same amount of time between the meetings (perhaps a bit more for those who can and would like to work on more involved parts).
It's difficult to say how long it will take us to reach the goals. Due to the bottom-up approach, part 3 is going to be slower than projects using existing programming languages to bootstrap from. We're also aiming for something a bit more complete than many toy implementations aspire to, thus the effort can't be compared. Also, it will depend on how effective we will be as a group (will we be faster or slower than a single person working on the project alone?), and how much attention to detail we give and how much time we spend reflecting. I may be tempted or happy to follow sidetracks too if I find them interesting, and if it doesn't mean that others are disappointed for boredom or because it's not what they expected...
I suspect that implementing S3C and writing the VM will together probably take about 4 months when following this schedule (with me likely investing additional time). If that's too long (i.e. the parallel SICP studying takes less time than that), we may be able to hurry up a bit or it could be shortened down much by implementing the VM in plain Scheme instead, or even radically so by using Scheme's objects for guest language objects instead of writing our own memory allocator; that would of course eliminate some of the aims and learning opportunities, too.
For the rest (part 3 above, writing the actual language on top of the VM), when I'm looking at the steps in Languages, I can see getting through it in about 10 meeting/working periods (i.e. about 5 months) if things are going smoothly and work can progress in parallel. Estimates are always a mix between generous time allocations and underestimating the amount of detail required to get things done, though. Probably all in all this amount of time is rather too optimistic than pessimistic. But this is also quite a bit flexible: in case we loose our energy before reaching the end, since we're going to implement it in steps / layers, we could stop or participants could leave before reaching the full goals and will still have something interesting running. Of course we could also decide at some point that the bottom-up approach is too time-consuming and relent, and use an existing Scheme environment to run new code before our own system supports it. That would betray the name of the project and be somewhat of a pity, though. In case we're too quick, there will be lots of additional challenges and work to improve the system.
Let's discuss the plans at a first meeting, and then see how it goes and re-evaluate from time to time (every other month).
An idea may be to invest a weekend or a couple and go camping with laptops (and batteries [and 230 V inverter] provided by Christian for offline power outside the campsite) or rent a cabin?
There are plans to continue having SICP study sessions, and we'll try to make it so that when reaching the SICP chapters about compilers we'll be ready to start stage 3 as listed above.
During stages 1 and 2, we'll have to see whether the participants of this workshop also want to follow SICP. One possible arrangement might be to have weekly meetings at the same time for both groups, one week the workshop group will work on the project while part of the SICP group will read the new SICP chapters together?, and the other week everyone will do the SICP exercises together. Or perhaps we can get enough room to have SICP and workshop meetings at different times. It might not be possible to get room in the same location or on the same day every time, we may have to be flexible.