Hi David, Readers on this list will not be surprised to hear me saying that, of course, type classes perfectly make sense for your scenario. You may have a look at some posts on "extensible interpreters": - http://compilers.iecc.com/comparch/article/04-12-111 - http://www.haskell.org/pipermail/haskell/2005-February/015346.html There are at least two ways of making the type "[Step] -> String" work with a setup that replaces Step by a type class. One is: use an existential type; another is: use HLists. (There is a third one: use Typeable.) I'll send you some draft material in a separate email that I don't want to share publicly yet. In this draft, your scenario is actually illustrated in a broader context. And then I should mention that you may also want to have a look at Hinze's and Loeh's open data types. I seem to remember that they provide actual tool support (sort of preprocessing) so that this works with Haskell today. HTH Ralf
-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of David House Sent: Sunday, May 21, 2006 5:50 AM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Writing an extensible interpreter
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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe