> If any of the RWO authors are reading this, I'd love an expanded version (or another book) with more advanced features of the language -- GADTs, a deeper treatment of the functor/module system, covariant/contravariant types, Camlp4 and/or the extension points mechanism, etc.
I'm actually meeting our editor (Andy Oram) in a couple of weeks at OSCON to discuss just this. We deliberately stayed away from newer features (e.g. GADTs) that we didn't feel had enough of an outing in production codebases, but with the release of OCaml 4.02 due in a few months this is a good time to do a refresh and fix that. What aspects of the module system would you like to see more of?
> I'm actually meeting our editor (Andy Oram) in a couple of weeks at OSCON to discuss just this.
Great to hear that!
> What aspects of the module system would you like to see more of?
The book is actually comprehensive in this respect, but the module system is just a lot to digest. I'm not actually an expert, so I really don't know what could/should be done, only that sometimes it takes me a while to figure out "best practices", or what's required by the compiler, or the semantic implications of some of the more unfamiliar syntax. For example, recently I saw:
module Client : module type of Client.Make(IO)
which differs from the "module type of" usage discussed in the book. The OCaml module system is extremely rich, with a learning curve to match. I don't really feel that I know how to exploit the system to its fullest just yet. Maybe a section on common patterns or best practices would be helpful.
On a side note, thanks for all your effort, not just on the book but also in keeping the OCaml community vibrant. I wouldn't be nearly as interested without all the work that's going on now.
Thanks, that's all very useful feedback. There have been several significant improvements to the module system in 4.02 (including generative functors and module aliases [1] in signatures), so I agree that there's quite a bit more to write about. We have a very short section on common patterns that could perhaps be expanded into a chapter.
RWO does an excellent job in introducing OCaml's main features in a simple and pragmatic way. It really does show the strength of the language and demonstrates the building blocks one can use to write high quality software.
One aspect that I think could be explored deeper is how to architecture complex applications with the language. How the module system can be used to build abstractions and protocols for not-trivial systems? For example how one could build a database with it, or even an operating system? I'm in the process of learning OCaml and what is really difficult for me is to understand what are the most idiomatic and efficient ways of modelling application domains. Although there are many open-source projects one can learn from (like JaneStreet's libraries, Nymote sub-projects, etc), the concepts and practices they use are sometimes hard to understand just reading the source.
I was just about to suggest looking at projects like Mirage/Irmin et al but since you mention Nymote, I assume you've already found your way to them.
If it helps, we have a series of blog posts about some of the recent library releases on the Mirage blog [1], some of which go into the design of those libraries. Perhaps they'd be useful?
Thank you! I'm impressed with the serie of blog posts the Mirage team posted lately – really informative and inspiring. I think this kind of system design articles are really valuable to actually learn how to use the language in the wild.
Another good example of a very good software design reading I've fuond is the OCamlgraph's paper[1], which demonstrates the strength of the ML's module system in a not trivial situation.
I'm actually meeting our editor (Andy Oram) in a couple of weeks at OSCON to discuss just this. We deliberately stayed away from newer features (e.g. GADTs) that we didn't feel had enough of an outing in production codebases, but with the release of OCaml 4.02 due in a few months this is a good time to do a refresh and fix that. What aspects of the module system would you like to see more of?