We are hiring

Maude I/O

In my continued experiments with Maude I have been investigating its I/O system and, more generally, how to integrate Maude with other systems and extend its built-in capabilities.

Libraries are arguably Maude’s weakest point. The standard libraries are very rudimentary. Furthermore, there is no FFI, so there is no easy way to hook in third party libraries. As we shall see, this is actually less of a problem than it may seem.

One area where the shortcomings in the standard library become immediately apparent is I/O. There is no file I/O, but thankfully recent versions of Maude at least come with a socket I/O module. This turns out to be very basic, with some serious limitations – which the authors are very open about – such as bad interaction with tracing, profiling and debugging. It also has some quite severe bugs – I can make Maude crash by just running the example from the manual!

One further obstacle is the lack of an API to the lexer and pretty-printer, i.e. there is no way of turning a string into a token stream and vice versa. The closest available facility is the LOOP-MODE, which facilitates the construction of custom REPLs but only operates on stdin/stdout. This, for example, makes it impossible to hook up a Maude REPL to a socket without writing your own lexer, or, alternatively, wrapping an entire Maude process with a socket interface and communicating to it via stdin/stdout.

The latter approach is the one taken by IOP.

IOP

The InterOperability Platform (IOP) bills itself as a general tool interoperability mechanism. Thus it is not Maude specific, though it was motivated by the need to make Maude interact with GUIs, web resources, the file system and tools such as theorem provers.

IOP was a breeze to install, though, as with Maude itself, I wish there was a debian package. Also note that IOP is only available in binary form, for Linux and Mac OS X. I wonder what the motivation for that is. Perhaps the source code is in a state that is unfit for release. Or perhaps it contains IPR the authors want keep. Neither prospect is very appealing.

IOP has an interesting take on interoperability. It is based on the actor model with actors communicating over sockets and Maude being one of those actors. To an extent this addresses Maude’s lack of standard and third-party libraries. That is of course a problem common to all new programming languages. The traditional solution, short of implementing vast libraries from scratch, is to provide an FFI. That’s not what IOP does. Rather than extending Maude by linking in third party libraries, which is what an FFI would provide, one wraps the libraries in an IOP actor that is then made accessible to Maude via the IOP messaging infrastructure. To a Maude program the interaction with that actor can be made to look just like an ordinary rewrite.

Thus IOP keeps Maude free from any dependencies on the underlying implementation language/platform which would be introduced by an FFI. The approach has of course its own fair share of difficulties. Firstly there is performance – calling into a library via IOP is effectively an RPC. Secondly, wrapping a library with all the marshalling and unmarshalling code required to make it an actor is tedious. In a sense this is no different from the argument/result conversions one has to perform in an FFI. However, unlike IOP, most FFIs come with tools to generate all the necessary wrappers etc so that very little manual coding is required. Finally, managing resources, such as memory (de)allocation and file handles, in the IOP model is more challenging than in an FFI since the resources are spread across multiple operating system processes or even hosts. This requires the library wrappers to implement explicit resource
management protocols or some kind of distributed garbage collection.

Odds and Ends

IOP doesn’t solve all of Maude’s interoperability problems. There are other shortcomings of Maude that affect interaction with the outside world but also have an impact on other aspects of system development. Firstly, Maude has no support for unicode; its string, character and identifier types are all ASCII-only. This makes interaction with many modern systems cumbersome as it requires unicode strings to be represented and manipulated in some custom, non-standard way. Secondly, Maude has no support for multi-threading. This is surprising since multiset rewriting – the very foundation of Maude – really lends itself to concurrent programming. Maude’s object system actually seems tailor made for this, representing objects an messages as elements in a “soup” that, at least in theory, could even be distributed. I guess the Maude authors simply haven’t had the time or need to make the implementation multi-threaded. Perhaps the widespread transition to multi-core CPUs will prompt them into action. Maude is very well placed to take advantage of multiple cores and this could in fact become one of Maude’s key selling points.