Re: Fwd: Re: Another Comment on Owl Ref {was: Re: Denotation of owl:Class)

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