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: [EMAIL PROTECTED] [mailto:haskell-cafe- > [EMAIL PROTECTED] 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, [EMAIL PROTECTED] > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe