Re: Replace data constructors via meta programming

One possible solution here is to define a fold function that captures
the relationship between constructors and functions to substitute
instead (please see the Logic.hs attachment). But it may be a bit
error-prone to use because the relationship is captured implicitly by
corresponding argument of the 'foldProposition' function.

Re: Replace data constructors via meta programming

Here's a quick demo of the finally-tagless style for this kind of
problem. It is an alternative to defining a data type to represent the
syntax, with a fold function (or "catamorphism") to deconstruct it.

Note that although you can't redefine constructors, you can rebind
variables like "not", "(&&)"... The idea is that users can construct
terms using these functions abstractly, and to evaluate those terms is
to provide a definition of those functions.

We represent PropSyntax with a record instead of a type class in order
to define implementations that depend on other values, such as
boolSyntax depending on a map. It may be possible to use type classes at
the same time to make it easier to construct propositions; for simple
definitions, using RecordWildCards seems sufficiently discreet.

Then use Control.Monad.Free from the package 'free'. It also has a template Haskell part. The function you want is called 'iter' there, and applying a context of type var -> Bool is simply fmap. Note that a Map from var to Bool does not always yield a total reduction, since your formula might contain variables that are not in the Map.

If feasible, remove If and Iff from the Prop type and make them binary functions on type Proposition var instead. That reduces the boilerplate further.
-- Olaf
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafeOnly members subscribed via the mailman list are allowed to post.

Re: Replace data constructors via meta programming

The type-foo looks very cool and I will have to dig more into the different options.

Generating a catamorphism using the library of the same name works like a charm and integrates well with my existing code—once I managed to get it to install (thank you Stack LTS!) it just worked out of the box and let me write a one-line evaluator and a one-line pretty-printer. Woohoo!

Unfortunately It's not really viable to use this "for real" at the moment because it requires such an old version of GHC.

Something I miss is the clear correspondence between data constructors and "substitutions" (like in my `magic` example), since they become entirely positional, leading to potentially brittle code (imagine reordering the data constructors). I think some of the other solutions might be better in this respect.

It's a shame that the catamorphism package doesn't work for a more up-to-date version of GHC, because I think I would use this quite often.

I suppose the fold that Sergey proposed is essentially what the catamorphism package generates. Although I want to avoid having to write functions by hand when really the computer should be doing them for me, I think I will use this for now as it integrates nicely with my existing code and leads to quite idiomatic Haskell.

I will definitely check out the other suggestions as well though, thank you again.

The type-foo looks very cool and I will have to dig more into the different options.

Generating a catamorphism using the library of the same name works like a charm and integrates well with my existing code—once I managed to get it to install (thank you Stack LTS!) it just worked out of the box and let me write a one-line evaluator and a one-line pretty-printer. Woohoo!

Unfortunately It's not really viable to use this "for real" at the moment because it requires such an old version of GHC.

Something I miss is the clear correspondence between data constructors and "substitutions" (like in my `magic` example), since they become entirely positional, leading to potentially brittle code (imagine reordering the data constructors). I think some of the other solutions might be better in this respect.

It's a shame that the catamorphism package doesn't work for a more up-to-date version of GHC, because I think I would use this quite often.

I suppose the fold that Sergey proposed is essentially what the catamorphism package generates. Although I want to avoid having to write functions by hand when really the computer should be doing them for me, I think I will use this for now as it integrates nicely with my existing code and leads to quite idiomatic Haskell.

I will definitely check out the other suggestions as well though, thank you again.

Re: Replace data constructors via meta programming

This actually leads me to another question: what are the tradeoffs between implementing this via Template Haskell as in the case of this package vs the `deriving` mechanism as for the foldable instance?

The type-foo looks very cool and I will have to dig more into the different options.

Generating a catamorphism using the library of the same name works like a charm and integrates well with my existing code—once I managed to get it to install (thank you Stack LTS!) it just worked out of the box and let me write a one-line evaluator and a one-line pretty-printer. Woohoo!

Unfortunately It's not really viable to use this "for real" at the moment because it requires such an old version of GHC.

Something I miss is the clear correspondence between data constructors and "substitutions" (like in my `magic` example), since they become entirely positional, leading to potentially brittle code (imagine reordering the data constructors). I think some of the other solutions might be better in this respect.

It's a shame that the catamorphism package doesn't work for a more up-to-date version of GHC, because I think I would use this quite often.

I suppose the fold that Sergey proposed is essentially what the catamorphism package generates. Although I want to avoid having to write functions by hand when really the computer should be doing them for me, I think I will use this for now as it integrates nicely with my existing code and leads to quite idiomatic Haskell.

I will definitely check out the other suggestions as well though, thank you again.