In investigating the use of LP in Haskell I came across this example: <http://www.ninebynine.org/Software/HaskellDL/DLExploration.lhs>
This is interesting from a few perspectives. First, it shows a working example of a literate haskell (LHS) file. I notice that the LHS style is very similar to what you'd find in a math textbook (if you skip printing the > signs and used a different print font). Thus the code appears to be surrounded by context explanations, just as equations are surrounded in a math textbook. Second, it appears that LHS files do not have chunks. At least I could not find an example of chunking. I'm not a haskell programmer but I suspect that there is a requirement for code placement order in haskell. Do the "module" and "import" statments have to come first? If so, chunking would be useful because you could move these away to the very end and explain them in the implementation details. Third, this is interesting as a knowledge representation program, something that will be important to the crystal work later. He mentions the ideas of Satisfiability, Subsumption, Equivalence, and Disjointness. All of these can be expressed as subsumption, which is the basis of the work I knew at IBM (KREP, KROPS). Although I authored a language (KROPS) that depended on knowledge representation I doubt I could have decoded his haskell implementation without the documentation. Fourth, he has included test cases along with their explanations. Fifth, from the couple dozen other examples of LHS I've seen there are people who have built "native latex" tools (ala Cliff's ASDF work for lisp). See <http://www.jantar.org/lambdaTeX>. (He apparently wrote the whole tool in TeX. Amazing.) You can see the result at <http://www.jantar.org/lambdaTeX/Example.pdf> There is also a lhs2TeX (i.e. "noweave") program at <http://www.informatik.uni-bonn.de/~loeh/lhs2tex> and an emacs mode at <http://www.fh-wedel.de/~di/html/unix/.emacs.herbert> As someone who is "skilled in the art" (like a mathematician can be skilled in the art of reading and understanding math books) I can read and follow the knowledge representation code even though I don't read or write haskell. In fact, I find that I can "read" the haskell code once I've read the explanations, although I'm not able to parse it for things like syntax errors. I've heard the comment that haskell code is somewhat similar to spad code which leads me to put this pamphlet "on the shelf" so I can refer to it when the crystal work begins. A spad version of this work would be very interesting. We could begin to talk about what Axiom "knows" and it can infer things, as you'd expect from a knowledged-based system. >From this I can conclude that the literate form of the haskell work is much more valuable than raw code. This recent paper by Martin Grabm\"uller ``Monad Transformers Step by Step'' <http://uebb.cs.tu-berlin.de/~magr/pub/Transformers.lhs> (source) <http://uebb.cs.tu-berlin.de/~magr/pub/Transformers.pdf> (pdf) is a beautifully done example of a paper using literate latex with executable haskell code embedded. It seems clear that this paper could easily be "drag-and-dropped" onto a running sytem. This is the kind of thing we can do in Axiom, especially using Cliff's asdf/cl-web work. Given all of this existing work in the haskell community (google shows literate haskell 456k hits, 529k for literate lisp, 2.24M for literate C) I don't see that Axiom is breaking any new ground. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer