technology from back to front

Maude I/O

In my [continued
experiments](/blog/2006/06/05/language-design-in-maude) 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
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
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.


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.


two × 1 =

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us