From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Concurrent MVars for Guile Date: Wed, 15 Jan 2014 19:47:44 -0500 Message-ID: <87zjmwrbv3.fsf@netris.org> References: <87fvtn1wv8.fsf@tines.lan> <87wqmjmrl8.fsf@gnu.org> <87d2o7ryku.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389833418 12732 80.91.229.3 (16 Jan 2014 00:50:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 00:50:18 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jan 16 01:50:24 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W3bA7-0007y7-Vi for guile-devel@m.gmane.org; Thu, 16 Jan 2014 01:50:24 +0100 Original-Received: from localhost ([::1]:57885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3bA7-0000fz-Jp for guile-devel@m.gmane.org; Wed, 15 Jan 2014 19:50:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3b9y-0000ft-9e for guile-devel@gnu.org; Wed, 15 Jan 2014 19:50:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3b9s-00075B-V0 for guile-devel@gnu.org; Wed, 15 Jan 2014 19:50:14 -0500 Original-Received: from world.peace.net ([96.39.62.75]:50956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3b9s-00074v-RM; Wed, 15 Jan 2014 19:50:08 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W3b9l-000607-Hl; Wed, 15 Jan 2014 19:50:01 -0500 In-Reply-To: <87d2o7ryku.fsf@pobox.com> (Andy Wingo's message of "Tue, 17 Sep 2013 22:18:57 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16807 Archived-At: Hi! Reviving an old thread... Andy Wingo writes: > On Sat 14 Sep 2013 15:59, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> It looks like a useful tool to me. > > FWIW I totally agree! > >> I don=E2=80=99t like the name =E2=80=9Cmvar=E2=80=9D (=E2=80=9Cmonadic v= ariable=E2=80=9D, I guess). Perhaps >> =E2=80=9Csynchronized box=E2=80=9D, or =E2=80=9Ctransactional variable= =E2=80=9D, or...? The downside of >> choosing another name is that people familiar with the concept won=E2=80= =99t >> recognize it first-hand. > > I guess I can see this. I prefer "box" to "variable" fwiw. How about > "tbox"? (The T for threadsafe or transactional or something; perhaps > this is a bad idea.) My preference would be to keep the "mvars" name, however imperfect, simply because many people in the neighboring Haskell community already know them as "mvars". There are many different ways that one can design threadsafe and/or transactional boxes. In the future, we might very well support some slightly different mechanism that could just as easily be called tboxes, and then we will have to invent yet another name. Given that these mvars have identical semantics to the ones in Haskell, I think it's probably best to just reuse the name that already exists. However, I don't feel strongly. If you and Ludovic can agree on a name, I'll rename them. Mainly I just want to get this module, or something like it, into stable-2.0 relatively soon. What do you think? Mark