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

[Brian, I assume you're forwarding significant RDFcore messages to me while 
I'm sorting out my mailing list subscription - thanks.]

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 10:05:53 UTC