Roll your own minilanguages with mini-interpreters (1989)

> A "monad" is just a type with a sequence operation. The heart of it is just that we aim to do "1 then 2 then 3", etc.

Isn't that an Applicative Functor? Monads also have join / bind.

Yeah for some reason this explanation which should be simple just blows my mind. I’m probably too experienced in imperative languages. It took me a long time to grok plain old monads. And when you get those GHC compiler errors from heavily stacked up types I find it very hard to work out what went wrong. For practical purposes I prefer OO even though it might be more limited in some regards.

At this point rather a lot more weight is being put on the DSL than a mere minilanguage, so I'd embed a language interpreter for something existing. I've used Tcl for this in the past.

But when you say "users", that indicates a different use case anyway. The minilanguage is basically source compression or code generation, it's for the developers.

> your users are asking you to change the syntax und use lisp-like evaluation/expressions

Nobody ever wants that except Lisp users, and if you're surrounded by angry lisp users you should just give them what they want and embed a lisp. Or even just write one, Scheme is small enough.

But as far as I can tell, "free monads" are a lot of machinery to re-implement imperative stateful programming when you could have just used a language that wasn't Haskell in the first place.

> But this interpreter does almost nothing. It draws mazes and prints text, and it only works in 80-char terminals.

That is part of the point, though: An interpreter does not need to be complex. Adding "instructions" that does more complicated things does not need to complicate the interpreter much.

Nor does the implementation language make much difference here - fundamentally the interpreter is only the part up to the definition of SubProg. Everything else is just implementation of specific instructions.

Don't get hung up on the use of assembler here - unless you need blazing speed from the interpreter itself, it's trivial to do in pretty much any language.

Conceptually, the interpreter is basically just a table of instructions, a bytecode buffer, and a loop that keeps fetching the next instruction, looks it up in the table, and calls it. The "SubProg" instruction could reasonable be considered part of the generic aspect of the interpreter, but the rest are the domain specific bits, no different

You can abstract out the instructions easily enough. E.g. here's a trivially dumb interpreter written in Ruby where the instructions are separate from the interpreter, that works conceptually not much differently to the linked assembler:

    class Interpreter
      attr_accessor :pc

      def initialize program, instructions
        @program = program
        @instructions = instructions
        @pc = 0
      end
  
      def getnext
        n = @program[@pc]
        @pc+=1
        return n
      end

      def run
        while i = getnext
          @instructions[i].call(self)
        end
      end
    end

    # We could make this an array and insist on numeric instructions,
    # but that's an implementation detail - the interpreter doesn't even need to know
    # if you pass it a hash or an array.

    instructions = {
      :myarg => ->(interp) { puts "My argument is #{interp.getnext}" },
      :helloworld => ->(interp) { puts "Hello World" }
    }

    program = [:myarg, 42, :helloworld, :myarg, 3]

    Interpreter.new(program, instructions).run

Because the program counter is settable, "SubProg" can just as easily be implemented externally to the interpreter, btw.. Adding variables would really just be a matter of exposing another array or hash in the interpreter so that you could add instructions to read/write them.

The point is to not have abstraction power. The goal is to make the DSL be a direct expression of the intended thought, which usually means cutting it down to the point where it's reduced almost everything to preset categories. At that point, you don't need much of a language to build it in, so it ends up porting well to all of them.