Hi all. I'm in the process of writing an interpreter for the self-modifying automaton languages SMATINY [1], designed by ihope (whose name some of you may recognise from IRC). The current effort is online [2], 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 interpreter. 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 :) [1]: http://esoteric.voxelperfect.net/wiki/SMATINY [2]: http://esoteric.voxelperfect.net/files/smatiny/impl/smatiny.tar.gz -- -David House, dmhouse@gmail.com