From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 3004BBC0B for ; Sun, 28 Jan 2007 01:16:09 +0100 (CET) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0S0GEpc025109 for ; Sun, 28 Jan 2007 01:16:15 +0100 Received: from [192.168.0.104] (12-208-241-105.client.mchsi.com[12.208.241.105]) by sccmmhc91.asp.att.net (sccmmhc91) with SMTP id <20070128001607m91003jvtfe>; Sun, 28 Jan 2007 00:16:07 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) References: <60A08B0C-3C02-47D6-8987-00ECF210C982@valdosta.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <321BC7B3-8A0F-4FF9-B445-BEC5930F9BCE@valdosta.edu> Content-Transfer-Encoding: 7bit From: Jonathan Bryant Subject: Fwd: [Caml-list] CamlP4 and Threads Date: Sat, 27 Jan 2007 19:15:18 -0500 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.3) X-Miltered: at concorde with ID 45BBEB4E.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; camlp:01 threads:01 camlp:01 threads:01 pcaml:01 expr:01 syntax:01 pcaml:01 gced:01 ocaml:01 bug:01 beginner's:01 ocaml:01 bug:01 2007,:98 Forgot to cc this to the list... Begin forwarded message: > From: Jonathan Bryant > Date: January 27, 2007 6:44:32 PM EST > To: Jonathan Roewen > Subject: Re: [Caml-list] CamlP4 and Threads > > > On Jan 27, 2007, at 6:41 PM, Jonathan Roewen wrote: > >> 1) have you actually tested the code? you don't pass an initial value >> to Thread.create, so it won't ever start. > > That was a typo. I meant: > > let _ = Thread.create (fun c -> ...) c in > >> 2) to avoid the space leak, wouldn't removing the let binding fix >> this? e.g. Event.sync (Event.send c (f x y z)). Since it's >> automatically generated code, I don't see the problem with that. > > No, that doesn't fix the problem. The problem is that the thread > doesn't stop executing until the event is synchronized upon, and if > the return value is ignored it is never synchronized on and the > thread waits forever. > >> 3) the actual camlp4 thing? I don't know :-) I have toyed with camlp4 >> though, and I found it simplest when introducing new keywords in >> Pcaml.expr. camlp4 certainly doesn't seem to be for the faint of >> heart > > I'm trying to avoid keywords if at all possible. > >> ;-) >> >> Have you tried printing out the various rules, etc? There are some >> cool functions to do that, and I found it helps to understand all the >> various precendences, and what the various rules are. >> >> Jonathan >> >> On 1/28/07, Jonathan Bryant wrote: >>> I'm think I'm finally understanding CamlP4 and I'm trying to make a >>> small syntax extension using it, but I can't find the rule I need to >>> extend. I want to turn this: >>> >>> let f x y x = .... >>> let x = |f| x y z >>> >>> into this: >>> >>> let f x y z = ... >>> let x = >>> let c = Event.new_channel () in >>> let _ = Thread.create (fun c -> let x = f x y z in Event.sync >>> (Event.send c x)) in >>> Event.receive c >>> >>> but, like I said, I can't seem to find the rule I need to extend. I >>> can do it for an arbitrary expression: >>> >>> let x = |3 + 5| >>> >>> to >>> >>> let x = >>> let c = Event.new_channel () in >>> let _ = Thread.create (fun c -> let x = 3 + 5 in Event.sync >>> (Event.send c x)) in >>> Event.receive c >>> >>> just not function application. >>> >>> I've tried extending Pcaml.expr's "apply" but that doesn't seem to >>> work, and I can't see any other place to do it. >>> >>> Also, it seems that the implementation of the Event module has an >>> error: the above code causes a space leak if x is not synchronized >>> upon. In CML (the basis for the Event module), threads are GCed >>> when >>> they go out of scope, so this is not a problem. As a matter of >>> fact, >>> it is cited as the way to go about things. But since OCaml doesn't >>> GC threads, this is a problem. Does anyone know of a workaround for >>> this? And/or should it be submitted as a bug report? >>> >>> --Jonathan Bryant >>> >>> _______________________________________________ >>> Caml-list mailing list. Subscription management: >>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >>> Archives: http://caml.inria.fr >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >>> >