Well I just noticed that the boilerplate part consists of this:
Import data by selecting fields from a table, feed them into some sort
of internal data structure for later querying, times 12. All this
involves quite a bit of boilerplate.
Yeah, I guess I could abstract here a little.
Günther
Am 14.02.10 23:37, schrieb Alexander Solla:
On Feb 14, 2010, at 4:38 AM, Günther Schmidt wrote:
I've got a problem, in short my haskell code sucks. While it does
work and I do manage to use higher-orderish aspects quite extensively
to make my code more concise it still is nowhere abstract, always
concrete and thus always with lots of boilerplate.
There is a such a thing as too much higher-ordered-ness. Every time
you introduce a new higher order dispatch mechanism, you go through
many of the same steps, and produce "slightly incompatible"
interfaces. You're basically defining plumbing, which you might have
to plumb into your existing plumbing. Boilerplate city.
Instead of looking for a higher-order solution to your problem, look
for a normal form to express abstract terms that solve your problem.
The higher-order solution will become "obvious" when you have the
right normal forms (because now you know what you're quantifying
over) For example, algebraic data types are a natural encoding for
tree-like structures. They can even contain things. Monads are an
encoding for tree-like structures with an interface to the things the
nodes contain. I'm not saying you need to use monads. I'm saying you
should use them when they are the right normal form.
Unfortunately, boilerplate is kind of a fact of life in Haskell,
unless you use things like TemplateHaskell or SYB. After making all
our nice orthogonal classes and data types in sensible normal forms,
we need to join these classes and types, with functions and class
instances. Taking big types down a chain of type classes is no fun.
But at least all that complexity is kept in one sensible place.
One thing I wish GHC would do better is deal with cyclical module
dependencies more flexibly. More flexibility would mean letting us
organize our code by the normal form it embodies, as opposed to the
modules/types it uses. That makes code look a lot less
boilerplate-ish, since the "irrelevant" but important bits can all go
together.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
