[Haskell-cafe] Writing an extensible interpreter
dmhouse at gmail.com
Sun May 21 08:50:26 EDT 2006
I'm in the process of writing an interpreter for the self-modifying
automaton languages SMATINY , designed by ihope (whose name some of
you may recognise from IRC). The current effort is online , but
it's at a rather early stage and there's a few modifications I'd like
to make to it.
To begin with, extensibility is key. Such tiny languages are designed
to be easily extendable, and I'd like my interpreter to follow suit.
At the moment, adding a new command is as follows:
1) Add a new constructor for the Step type to represent your command.
2) Write a Parsec parser for your command in Smatiny.hs.
3) Add said parser to the 'inputs' list in Smatiny.hs.
4) Write a 'handler' for your command; a function in State that will
take the appropriate action.
This is a bit of an ordeal; I'd like new commands to be addable
without touching Smatiny.hs, which will form the base of the
One solution I was thinking about was to write a new module for each
command that exports a "parser" and "handler" function. A bit of
metacode would read the Commands directory then import qualified all
the modules it finds in there. Subsequently, it would call
parseSmatiny (the parser; in Smatiny.hs) with all the parsers it found
as an argument, then send the output of this into runSmatiny (the
interpreter; also in Smatiny.hs).
However, the remaining issue is step 1): how would the metacode handle
additional constructors to the Step ADT? Type classes won't work here:
the intepreter has a type of [Step] -> String. With type classes this
would have a type of something like Step a => [a] -> String, but by
the homogeneity of lists you'd only be able to have one type of step
in your program.
Thanks in advance for your input. Let me know if I didn't explain
something too well; I have a tendancy toward brevity :)
-David House, dmhouse at gmail.com
More information about the Haskell-Cafe