Alexander Solla wrote:
After all, the source is always structured in more-or-less the same
way. Fragments of text with opaque -- unless/until you understand
them -- combinators "join" two distinct concepts/types into functions.
A chain of functions (potentially at various levels of abstraction)
is a computation. You "use" these things by finding a chain of types
(Start -> A), (A -> B), (B -> C), ... (N -> Goal) and composing,
filling in additional details as necessary. Building that chain means
doing depth first searches on a tree/graph of possibilities, and
usually isn't so much fun. The library developer is in the best
position to do exactly that, having already done it while constructing
the library.
In Haskell even learning to use a library has an algebraic structure. ;^)
Actually, I was thinking just this afternoon... If you're writing in an
OO language, you can use UML to produce diagrams that give you a kind of
at-a-glance overview of the saliant parts of something. (Depending on
how much detail you choose to include in the diagram.) I wander if
anybody has a standardised notation that might be applicable to FP in
general or Haskell specifically...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
