Re: [Haskell-cafe] Haskell RPC

On May 25, 2006, at 2:25 PM, Jason Dagit wrote:

On 5/25/06, Joel Reymont wrote:

...

This is an example from my test harness:

(define-test remote-basic (def-remote-class remote (server) ()) (def-remote-method sum :sync ((self remote) (a fixnum) (b integer)) (declare (ignorable ip port)) (+ a b seqnum)) (let* ((port (+ 1000 (random 50000))) (server (make-instance 'remote :port port)) (client (make-instance 'remote-proxy :host (host-address) :port port))) (assert-equal '(6) (sum client 1 2 :seqnum 3)) (stop server) (stop client) ))

I won't comment on the difference between haskell and lisp (both languages I respect), but I will say that you should add a macro or high order function (depneding on lisp vs. haskell) that is something like "(with-client (c args-list) body)", that way you can simplify the creation/cleanup of clients. Same idea as with-open-file. You can do the same with server.

As for your actual question, there is a deriving(Read), but I don't remember what extensions are needed.

None. 'deriving' for Read and Show are both Haskell 98. It won't work for functions though. Haskell functions, unlike in lisp/scheme, are "opaque". If all you want to do is send data around, then you can surely use Read/Show, or some of the more efficient workalikes from DrIFT (http://repetae.net/~john/computer/haskell/DrIFT/). Joel Raymont:

I think I can send Haskell code over the wire to be read on the other side just like I do with Lisp. The part that baffles me is being able to provide an interface that lets one easily define remote classes and methods.

I totally hate Template Haskell because I find it incomprehensible and I'm not going to compare it to Lisp macros. Is there a way to do it without TH?

If you want to deliver source code to be executed elsewhere, you can use hs-plugins or the GHC API (in GHC HEAD branch). Check out the lambdabot for inspiration (http://haskell.org/haskellwiki/ Lambdabot). Or you could maybe do something interesting here with YHC bytecode. If you instead want to go the XML-RPC route there's HaXR (http://www.haskell.org/haxr/). I can understand the sentiment about TH, but it's probably the only way to get a similar interface to the lisp one, short of preprocessing/code generation. Beyond that, I'd say there are a few too many free variables in the problem description. What would be the design goals and non-goals for such an RPC mechanism? What problems prompted the original lisp implementation? What about fault tolerance, reliability, security? etc. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG