On May 25, 2006, at 2:25 PM, Jason Dagit wrote:
On 5/25/06, Joel Reymont <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
