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

[Alexander Solla]

On Fri, Apr 4, 2014 at 10:02 AM, Robert Vollmert <rvollmert-lists at gmx.net>wrote:

>
> On Mar 15, 2014, at 0:36 , Robert Vollmert <rvollmert-lists at gmx.net>
> wrote:
> > My problem is how I should deal with these intermediate types that vary
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140404/ff0f1f42/attachment.html>