- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Mon, 28 Apr 2003 16:31:27 +0100
- To: Graham Klyne <gk@ninebynine.org>, Dan Connolly <connolly@w3.org>
- Cc: www-archive <www-archive@w3.org>
At 11:25 28/04/2003 +0100, Graham Klyne wrote: >[Brian, I assume you're forwarding significant RDFcore messages to me >while I'm sorting out my mailing list subscription - thanks.] Trying to - i've set up a filter to pass them on to you - let me know when you want me to turn it off. Re haskell - by an odd coincidence I bought the book recently and have been quietly having a play. Brian >At 05:40 28/04/2003 +0100, Brian McBride wrote: >>On Sun, 2003-04-27 at 21:58, Dan Connolly wrote: >>>Graham's mention of haskell reminds me that I'd >>>like to survey the landscape of formal-hacking >>>tools again, I think. > >FWIW, my choice of Haskell is based on the following: > >- in my SWAD-E work on access control, I found that cwm rules handling >wouldn't let me do some of the kinds of complex manipulations I wanted to >try. Part of my conclusion from this experience was that it isn't yet >clear how much expressive power is needed in an off-the-shelf tool like >cwm. (Euler could probably do the complicated bits, but I don't see how >to use it as an inference-scripting tool.) > >- Being a general purpose programming language, Haskell would >(theoretically, and I now believe practically) allow me to do anything >that could be coded in Python/Java/etc. > >- Being a *pure* functional language, Haskell would permit/encourage a >greater degree of direct correspondence with formal specification than >with an imperative language. (cf. my URI parser based fairly directly on >Roy's new URI draft.) For example, among other things, I feel that I'd >like to experiment with Haskell to implement RDF style datatypes in >something approaching a formal framework -- with some 3experience, I may >be able to define some higher order functions for "defining" >datatypes. My initial work on URIs, an N3 parser (and maybe even a full >RDF/XML parser based directly on the new RDF syntax spec -- it's not my >own top priority but if anyone likes the idea enough to support the >work...) is toolmaking so I can get back to exploring the application ideas. > > From my current vantage, having been working with Haskell about 20% over > the past couple of months: > >- there's a fairly steep learning curve compared with learning a more >conventional programming language. I'm still a long way from fluent in >making effective use of higher order functions, though occasionally some >beautifully elegant solutions just fall into my lap. > >- the use of Monads for capturing state-transformation processes in a >functional programming environment is very powerful, is fairly easy to use >if someone else has defined the Monad-based data types, but takes some >work to really grasp what's going on. > >- Haskell is ultimately a programming language, and I don't think it's a >substitute for a formal proof-checking system like Larch. What I do think >it has great potential for is building testable implementations based >closely on formal specifications. Debugging, I find, is more like getting >a proof right than typical program debugging: normal imperative language >debugging techniques like tracing/breakpoints/debug-writes don't seem to >help much; rather, I find myself creating additional test cases to test >intermediate functions (rather, I suppose, like making complex proofs from >proofs of smaller lemmas). > >In summary, I see Haskell as being a potentially powerful "scripting >language for the semantic web". For processes of any complexity, I'm less >convinced about its utility as a replacement for Larch for semantic web >theorem-checking (BICBW -- I've still lots to learn about using Haskell). > >#g > > >------------------- >Graham Klyne ><GK@NineByNine.org> >PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
Received on Monday, 28 April 2003 11:31:10 UTC