[Haskell-cafe] on finding abstractions ...
gue.schmidt at web.de
Sun Feb 14 19:31:39 EST 2010
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.
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
More information about the Haskell-Cafe