From: Eric Schulte <schulte.eric@gmail.com>
To: Thorsten <quintfall@googlemail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Elisp programming style
Date: Fri, 28 Oct 2011 08:35:37 -0600 [thread overview]
Message-ID: <87fwiduqti.fsf@gmail.com> (raw)
In-Reply-To: <86obx1qkcc.fsf@googlemail.com> (Thorsten's message of "Fri, 28 Oct 2011 16:09:07 +0200")
>
> The problem can be described easily:
>
> problem-specific helper-funcions (some redundancy avoided)
> ,-----------------------------------------------------------
> | (defun main-function (args)
> | (let ((var (assoc :key1 args))) ; extracting var once
> | ...
> | (helper-function1 ...) ; inside let using var
> | (helper-function2 ...) ; inside let using var
> | ))
> |
> | (defun helper-function1 ()
> | ...
> | )
> |
> | (defun helper-function2 ()
> | ...
> | )
> `-----------------------------------------------------------
>
> vs
>
> standalone helper-functions (but redundancy)
> ,-------------------------------------------------------------
> | (defun main-function (args)
> | (let ((value (assoc :key1 args)) ; extracting var 1st time
> | ...
> | )
> | (helper-function1 ...) ; outside let
> | (helper-function2 ...) ; outside let
> | )
> |
> | (defun helper-function1 (args)
> | (let ((var (assoc :key1 args))) ; extracting var 2nd time
> | ...
> | ))
> |
> | (defun helper-function2 (args)
> | (let ((var (assoc :key1 args))) ; extracting var 3rd time
> | ...
> | ))
> `-------------------------------------------------------------
>
Hmmm, this looks suspiciously like the case in some Babel functions :)
in which we originally has instances of the first style and then had to
manually transition to the second. IMO the first is very poor form, the
variables are technically "free variables" when defined in the helper,
and just through undocumented variable capture does the execution work
out correctly, this can lead to unpleasant bugs.
The means the helper may only be used when variables of certain names
are in scope.
If you do want to use a helper which uses variables in scope which
aren't passed as arguments (again just my opinion) you should defined
the helper function using `flet' *inside* of the main function and the
scope of the variables.
>
>
>> In general, if the helper function is only used in a single place and
>> isn't likely to be more generally useful, there might be no reason for
>> it to be a standalone function at all (other than modular programming,
>> which is always a good idea IMO).
>>
>> OTOH, if the helper function _is_ standalone and used in multiple
>> places, then there is no "redundancy", so I'm really not sure what you
>> mean.
>
> Is there a policy? Lets say, an org-library author thinks his helper
> functions will be of no use for nobody else and designs them
> non-standalone. A few years later somebody wants to write a similar
> library and trys to reuse some of the old helper functions, to no avail.
>
> Would that be considered bad style from the original author, or is that
> up to personal choice and not considered a problem?
>
I don't believe we have an official canon of such rules, but personally
I would consider this to be bad style. If the helper function is only
used in one main function then it should be defined using flet, if it is
used across multiple functions then the in-scope variables should be
passed as explicit arguments (preferably with names other than those
which it has in scope so you can be sure you are actually using the
arguments).
Finally, I believe the emacs-lisp compiler would complain about such
free variables.
Hope this helps, Best -- Eric
>
> cheers
--
Eric Schulte
http://cs.unm.edu/~eschulte/
next prev parent reply other threads:[~2011-10-28 14:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 18:03 Elisp programming style Thorsten
2011-10-28 10:17 ` Štěpán Němec
2011-10-28 14:09 ` Thorsten
2011-10-28 14:31 ` Nick Dokos
2011-10-28 15:59 ` Thorsten
2011-10-29 2:13 ` Eric Abrahamsen
2011-10-28 14:34 ` Tassilo Horn
2011-10-28 14:40 ` Eric Schulte
2011-10-28 16:04 ` Thorsten
2011-10-28 14:35 ` Eric Schulte [this message]
2011-10-28 15:52 ` Thorsten
2011-10-28 17:43 ` Tom Prince
2011-10-28 18:05 ` Thorsten
2011-10-29 7:43 ` Tassilo Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fwiduqti.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=quintfall@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).