From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 04 Oct 2015 17:48:24 +0000 Message-ID: References: <838ugdf251.fsf@gnu.org> <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@[87.69.4.28]> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <5610ED13.1010406@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bfcec4a6aa8fe05214b01f4 X-Trace: ger.gmane.org 1443980925 29553 80.91.229.3 (4 Oct 2015 17:48:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 17:48:45 +0000 (UTC) Cc: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 04 19:48:44 2015 Return-path: Envelope-to: ged-emacs-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 1ZinOr-0006mx-VX for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 19:48:42 +0200 Original-Received: from localhost ([::1]:43261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZinOr-0003un-1X for ged-emacs-devel@m.gmane.org; Sun, 04 Oct 2015 13:48:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZinOn-0003ue-BN for emacs-devel@gnu.org; Sun, 04 Oct 2015 13:48:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZinOm-00024m-0F for emacs-devel@gnu.org; Sun, 04 Oct 2015 13:48:37 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:35001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZinOk-00023n-79; Sun, 04 Oct 2015 13:48:34 -0400 Original-Received: by wicge5 with SMTP id ge5so91711847wic.0; Sun, 04 Oct 2015 10:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=DYEqp/ID16KTXZlgLF3/gRqd+mr05RrqTmda7RE3zVc=; b=mvSIDAvAv2BtDizggzMxggt3D6oOtA2LqvjntDPUft/VDMdJp3fhitU69ztFz7QUGy tWVsEcnqkBV3ITn9Q3/+QQ4OKB6XblDKsnX74eB+lHBx33m9b9nY1JoPRsOMpPj0VJ2x zO8sQW/xiy4cp8pkLZJ340t3fvRtkHExDSpvxJbY2xx6f52lnfiHkXi84MKNnAWBvthN fQpYJQa1J46S256kijV/A3z6SuQMnYRiHtjAhO+VHFWuJy1OGRjgjoVie3tTP4ipzEO/ 3B45x/ruHhde1qAnIAi4ZEm4NmX8L9RafvpXq7yDMrGF05zUfOexBmWOatSrET4H0cBj OaDQ== X-Received: by 10.194.77.77 with SMTP id q13mr30479966wjw.79.1443980913582; Sun, 04 Oct 2015 10:48:33 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190893 Archived-At: --047d7bfcec4a6aa8fe05214b01f4 Content-Type: text/plain; charset=UTF-8 Philipp Stephani schrieb am So., 4. Okt. 2015 um 11:41 Uhr: > >> > 3) How exactly do we represent catch/throw values? >> > >> > >> > I've thought about this a bit, and I think it would be simplest to add a >> > new function env->set_throw and have get_error and check_error return an >> > enum { normal, signal, throw }. One could come up with something like >> > creating a list (error-kind error-tag error-value), but it looks like >> > the module implementation would create such lists only for the module >> > code to convert them back, so it's simpler to represent the two kinds of >> > non-local exits directly in the interface. >> >> I'm fine with a list; keep in mind that we'll need to handle OOM >> somehow, so I'd suggest an opaque type. >> > > I think OOM is currently handled by doing the equivalent of > > (apply #'signal memory-signal-data) > > so it would be part of the normal signal handling. Using a list would be > possible, but then the distinction between error tag and data could be > removed from the module code. But I think the 'magic lists' idiom common in > Emacs is more of an antipattern and we should try to avoid it in the module > interface, thus the suggestion to use an enum. > > I've amended the PR with basic handling of throw. It's treated as if it were at the top level, i.e. it generates a signal with symbol 'no-catch and data (tag value). There is currently no functionality available to "throw" from module code, and probably none is needed because "throw" is generally used as a local control flow mechanism, and modules can use the control flow mechanisms available in their languages instead. --047d7bfcec4a6aa8fe05214b01f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am So., 4. Okt. 2015 um 11:41=C2=A0Uhr:

>=C2=A0 =C2=A0 =C2=A03) How exactly do we represent catch/throw values?<= br> >
>
> I've thought about this a bit, and I think it would be simplest to= add a
> new function env->set_throw and have get_error and check_error retu= rn an
> enum { normal, signal, throw }. One could come up with something like<= br> > creating a list (error-kind error-tag error-value), but it looks like<= br> > the module implementation would create such lists only for the module<= br> > code to convert them back, so it's simpler to represent the two ki= nds of
> non-local exits directly in the interface.

I'm fine with a list; keep in mind that we'll need to handle OOM somehow, so I'd suggest an opaque type.

=
I think OOM is= currently handled by doing the equivalent of=C2=A0

(apply #'signal memory-signal-data)

so it wo= uld be part of the normal signal handling. Using a list would be possible, = but then the distinction between error tag and data could be removed from t= he module code. But I think the 'magic lists' idiom common in Emacs= is more of an antipattern and we should try to avoid it in the module inte= rface, thus the suggestion to use an enum.
=C2=A0

I've amended the PR with basic handling of throw. It= 9;s treated as if it were at the top level, i.e. it generates a signal with= symbol 'no-catch and data (tag value). There is currently no functiona= lity available to "throw" from module code, and probably none is = needed because "throw" is generally used as a local control flow = mechanism, and modules can use the control flow mechanisms available in the= ir languages instead.
--047d7bfcec4a6aa8fe05214b01f4--