From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Lexical binding bug in org-list.el? Date: Sat, 07 Nov 2015 21:30:58 +0000 Message-ID: <87a8qpts31.fsf@gmail.com> References: <87wptuua9n.fsf@gmail.com> <87ziyq7j8t.fsf@nicolasgoaziou.fr> <87r3k2t46z.fsf@gmail.com> <87twox92nx.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvB4i-0007AE-IN for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 16:31:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvB4f-0008Qc-AN for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 16:31:04 -0500 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:34294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvB4f-0008QU-1h for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 16:31:01 -0500 Received: by wikq8 with SMTP id q8so48861308wik.1 for ; Sat, 07 Nov 2015 13:31:00 -0800 (PST) In-Reply-To: <87twox92nx.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: emacs-org list Hi Nicolas, 2015ko azaroak 7an, Nicolas Goaziou-ek idatzi zuen: >=20 > Aaron Ecay writes: >=20 >> On a broader scope, this is just one part of org that is written in this >> style (one large let that defines many functions which call each other; >> the body of the let is just a call into one of these functions). This >> isn=E2=80=99t idiomatic elisp (at least, I=E2=80=99ve never seen it outs= ide org), and it >> seems suboptimal for at least two reasons: >> 1. The interface between the functions isn=E2=80=99t well-defined =E2=80= =93 they could >> exchange information via arguments and/or by modifying variables >> introduced by their containing let. >=20 > They are mutually recursive functions. I don't think that is > un-idiomatic in the Lisp world. I don't think why the reason above would > make them sub-optimal, too. I guess it=E2=80=99s a scheme-ism. . Grepping for it in emacs sources, I see 4 uses in vc-* libraries, 1 in octave, and 1 in emacs-lisp mode. cl-labels is also implemented in terms of letrec. Org has 16 uses so far, all of them introduced since the lexical binding change (or in any case since the last merge with emacs). I=E2=80=99m not saying we shouldn=E2=80=99t use it just because it=E2=80=99= s rare, or a scheme-ism. Just satisfying my own curiosity out loud. :) >=20 >> 2. It=E2=80=99s impossible to unit test the small let-bound functions. >=20 > Why would you want to unit test them? They are an implementation detail. > Only `org-list-parse-list' should be tested here. I don=E2=80=99t think we should unit-test only public API functions. Indee= d, I find it easier to write unit tests for small functions, since I don=E2=80= =99t have to construct a lot of extra context to exercise all the corner cases. >=20 >> In view of this, do you think it would be desirable in the long term to >> refactor code like this into top-level functions? >=20 > No, I don't. I see no reason to pollute name space with these very > specific functions. I=E2=80=99m not sure I get it =E2=80=93 interned symbols are cheap, and wit= h the new-ish double-dash convention for private functions users/downstream developers can be pretty sure they don=E2=80=99t need to worry about them. If it=E2=80=99s for us as org devs, I think the benefits outweigh the drawb= ack of having the extra function names to sift through in code completion popups (which is the only one I can think of). But opinions can differ, and maybe I haven=E2=80=99t considered all the potential negatives. [...] > My take on the problem at hand is >=20 > - change `org-list-parse-list' to provide a simpler output and update > Babel should to use that new output. >=20 > - re-implement `org-list-to-subtree' using directly Elements, or even > string massaging. OK, these both sound do-able. >=20 > - start a poll on the ML to guess the potential user base for radio > lists. Depending on the results, we might either deprecate the whole > thing, as you suggest, or implement in a more powerful and clean > way. Note that first item implies `org-list-to-generic' should be > updated to handle new output for `org-list-parse-list'. Given that no one=E2=80=99s ever asked for better radio lists despite us advertising the feature and its unflattering comparison with more powerful radio tables, I doubt there will be any interest. But it=E2=80=99s worth asking. Should one of us start a new thread to ask this question? --=20 Aaron Ecay