Re: [Haskell-cafe] design problem, "varying intermediate types"

On Fri, Apr 4, 2014 at 10:02 AM, Robert Vollmert wrote:

...

My problem is how I should deal with these intermediate types that vary

On Mar 15, 2014, at 0:36 , Robert Vollmert wrote: based on the input. My current approach below has parsing and printing functions, and then one big function that strings the matching parsers and printers together.

Just wanted to report that I've solved this well enough for now. The basic approach looks like:

type Parsers a b = ... type Printers a b = ...

type Handler c = forall a b. Parsers a b -> Printers a b -> c

compose :: Tag -> Handler c -> c compose Tag1 h = h parsers1 printers1 compose Tag2 h = h parsers2 printers2 ...

(where type parameters a b differ for the different tags)

Then I can define different handlers for different ways of stringing together parsers and printers.

I'd still love to know if this is the "right" way to do this... Or if what I'm doing has a name?

Cheers Rob

It seems to me that you might benefit from a "compiler" approach. In such a design, you parse the input text, turn it into an abstract syntax tree, and then interpret the tree (typically in terms of some monad, but not necessarily). The "intermediate" data type is definitely tricky to get down. If you are having trouble expressing it in a way that fits your other design constraints, you might want to look into stuff like "data types a la carte" or the "syntactic" package. But really, standard Haskell data types are pretty good at this kind of thing. You shouldn't need data types a la carte unless you're trying to make a "pluggable" F-algebra. (That is, a data type that you can "extend" by importing a library)