From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Faraz Shahbazker" Newsgroups: gmane.lisp.guile.user Subject: Re: Re: to serialize/deserialize closures; and multithreading Date: 26 Mar 2004 20:02:51 -0000 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <20040326200251.19862.qmail@webmail27.rediffmail.com> Reply-To: Faraz Shahbazker NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0609048381==" X-Trace: sea.gmane.org 1080331610 31203 80.91.224.253 (26 Mar 2004 20:06:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 26 Mar 2004 20:06:50 +0000 (UTC) Cc: nickjohnson@virginia.edu, guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Mar 26 21:06:39 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B6xbD-0000aF-00 for ; Fri, 26 Mar 2004 21:06:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B6xaC-0003dX-VC for guile-user@m.gmane.org; Fri, 26 Mar 2004 15:05:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B6xYc-00021y-RO for guile-user@gnu.org; Fri, 26 Mar 2004 15:03:59 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B6xXl-0000VB-6Z for guile-user@gnu.org; Fri, 26 Mar 2004 15:03:38 -0500 Original-Received: from [203.199.83.37] (helo=rediffmail.com) by monty-python.gnu.org with smtp (Exim 4.30) id 1B6xXd-0000RB-Od for guile-user@gnu.org; Fri, 26 Mar 2004 15:02:57 -0500 Original-Received: (qmail 19863 invoked by uid 510); 26 Mar 2004 20:02:51 -0000 Original-Received: from unknown (219.65.34.140) by rediffmail.com via HTTP; 26 mar 2004 20:02:51 -0000 Original-To: rm@fabula.de X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Mime-version: 1.0 Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:3009 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:3009 This is a multipart mime message --===============0609048381== Content-type: multipart/alternative; boundary="Next_1080331371---0-203.199.83.37-19839" This is a multipart mime message --Next_1080331371---0-203.199.83.37-19839 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A
=0A        The problem with Kali and other di= stributed Scheme
=0Aimplementations (and there are quite a few) is that = most of
=0Athem are built around the imperative style of parallel
=0A= computation -- result: things get ugly quickly for complex
=0Aprograms. = You could end-up writing C-like programs in
=0AScheme.
=0A
=0A&nbs= p;       IMHO the ideal system would be built around pure=0Afunctional style (using MultiLisp type parallel annotations
=0Alike = future/touch/pcall). This category is also known as
=0Apara-functional l= anguages. It has been explored reasonably in
=0AML/Haskell, but little w= ork of this nature has been done in
=0AScheme/Lisp so far.....
=0A=0A
=0A> Autsch, that does get rather expensive when closures/contin= uation
=0A> are used (something that does happen occasionally in func= tional
=0A> programming ;-)
=0A
=0A        = That I accept. It can be speeded up by building the
=0Atransformation in= to the compiler, something which is not possible
=0Awith guile - bigloo = perhaps would be a better choice for such work.
=0ABut it is difficult t= o leave guile for 2 reasons :
=0A
=0A1. it's got the "GNU" = in it's name
=0A2. SCM API is too good - absolutely love it. I don't thi= nk anyone
=0Acan provide a better extensibility for Scheme than what we = have here.
=0A
=0A
=0A
=0AAs an aside : for functional purists = like me, we should built
=0Afuture/touch constructs into guile - they ar= e a lot of fun.
=0ATry out these prototypes =3D>
=0A(Note : these = are not actually correct - the simple semantics fail
=0Ain the presence = of mutations/continuations. A proper implementation
=0Awould have to be = done in C using Guile-internals)
=0A
=0A        I= t basically works like delay/force except that any-thing
=0Athat is &quo= t;future"d returns a place-holder immediately and starts
=0Aconcurr= ent computation. When the value is required, you "touch"
=0Ath= e place-holder, causing a block until the computation completes.
=0A
= =0A
=0A(defmacro future (expr)
=0A  `(let ((ans (cons "#<= ;future>" (cons #f #f))))
=0A    (set-car! (cdr ans)<= BR>=0A              (begin-thread
= =0A                (set-cdr! (cdr a= ns) ((lambda () ,expr)))))
=0A    ans))
=0A
=0A(defmacr= o touch (future-val)
=0A  `(begin
=0A    (join-thread= (car (cdr ,future-val)))
=0A    (cdr (cdr ,future-val))))=0A
=0A
=0Aregards,
=0A- faraz
=0A=0A

=0A=0A=0A

=0A= =0A --Next_1080331371---0-203.199.83.37-19839 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0A The problem with Kali and other distributed Scheme=0Aimplementat= ions (and there are quite a few) is that most of=0Athem are built around th= e imperative style of parallel=0Acomputation -- result: things get ugly qui= ckly for complex=0Aprograms. You could end-up writing C-like programs in=0A= Scheme.=0A=0A IMHO the ideal system would be built around pure=0Afun= ctional style (using MultiLisp type parallel annotations=0Alike future/touc= h/pcall). This category is also known as=0Apara-functional languages. It ha= s been explored reasonably in=0AML/Haskell, but little work of this nature = has been done in=0AScheme/Lisp so far.....=0A=0A=0A> Autsch, that does get = rather expensive when closures/continuation=0A> are used (something that do= es happen occasionally in functional=0A> programming ;-)=0A=0A That = I accept. It can be speeded up by building the=0Atransformation into the co= mpiler, something which is not possible=0Awith guile - bigloo perhaps would= be a better choice for such work.=0ABut it is difficult to leave guile for= 2 reasons :=0A=0A1. it's got the "GNU" in it's name=0A2. SCM API is too go= od - absolutely love it. I don't think anyone=0Acan provide a better extens= ibility for Scheme than what we have here.=0A=0A=0A=0AAs an aside : for fun= ctional purists like me, we should built=0Afuture/touch constructs into gui= le - they are a lot of fun.=0ATry out these prototypes =3D>=0A(Note : these= are not actually correct - the simple semantics fail=0Ain the presence of = mutations/continuations. A proper implementation=0Awould have to be done in= C using Guile-internals)=0A=0A It basically works like delay/force = except that any-thing=0Athat is "future"d returns a place-holder immediatel= y and starts=0Aconcurrent computation. When the value is required, you "tou= ch"=0Athe place-holder, causing a block until the computation completes.=0A= =0A=0A(defmacro future (expr)=0A `(let ((ans (cons "#" (cons #f #f= ))))=0A (set-car! (cdr ans)=0A (begin-thread=0A = (set-cdr! (cdr ans) ((lambda () ,expr)))))=0A ans))=0A=0A(defmacr= o touch (future-val)=0A `(begin=0A (join-thread (car (cdr ,future-val)= ))=0A (cdr (cdr ,future-val))))=0A=0A=0Aregards,=0A- faraz =0A=0A=0A --Next_1080331371---0-203.199.83.37-19839-- --===============0609048381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user --===============0609048381==--