help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : How to create a higher order function?


From: Marcin Borkowski
Subject: Re: [External] : How to create a higher order function?
Date: Fri, 24 Sep 2021 11:04:08 +0200
User-agent: mu4e 1.1.0; emacs 28.0.50

On 2021-09-21, at 17:49, Drew Adams <drew.adams@oracle.com> wrote:

>> My question is: which of (B) and (C) is better?  (C) is definitely
>> simpler, and with lexical scope becoming the default (perhaps at some
>> point in time in the future) or the recommended (even now, I guess)
>> setting, is probably the way to go.  But maybe (B) is better under some
>> circumstances?  Is it faster?  (I don't think so, and my simple
>> benchmarks were inconclusive.)  Is it more memory-efficient?  (Could
>> be.)  Does it have any other advantage?
>
> (C) is definitely better, in general.
>
> (That's really the takeaway answer.)
>
> The lexical environment, i.e., the one where
> the function is defined, is the environment you
> generally want for the function - it's, well,
> the environment that _defines_ the function.
>
> Generally speaking that's the only proper
> environment for defining the function.  Of
> course, this is Lisp, and nothing says you're
> obliged to use the "proper", static, definition
> of anything.
> ___
>
> Two counter cases to (C), of sorts:
>
> 1. If you specifically want to allow other code
> to be able to _change the behavior_ of the
> function by simply providing an arbitrary
> runtime value for some variable, then you might
> want to dynamically bind that variable.
>
> 2. If a free variable in the function body is
> never used _as a variable_, so that only its
> _value_ at the point of the function definition
> is needed, then you can do what you did, which
> is to just substitute the value for the var.
>
> This means there's no carrying around that var
> binding in the closure, no need to look up its
> value, etc.  But see next: that generally
> doesn't mean a benefit in performance - the
> contrary.
>
> Wrt #2: Be aware that, at least with current
> Elisp and its byte-compiler, #2 essentially
> _loses_ the function definition at the point
> where it's defined.  Instead, it substitutes
> a _list_, a constructed lambda form, for the
> function.  It's only later, in some other
> context/environment, that that list can get
> interpreted as a function.
>
> Among other things, this means that that
> representation of a function can't be compiled
> as a function.  It can only be interpreted
> (any number of times, in any contexts).
>
> It can't in any way be treated or understood
> by Emacs as a _function_ - it's just a list
> with a lambda form, until it's eval'd.  Put
> differently, it's just a _mention_ till it's
> explicitly _used_.  It's a template function
> definition, to be filled in and interpreted
> as a function wherever and whenever.
>
> On the other hand, for better and worse, it
> can be treated as a list (it is one).  IOW,
> instead of a function, you have essentially
> the _name_, a representation, of a function.
> If you want to do things to or with such a
> representation, you can.  But this is rare.
> ___
>
> Wrt the advantages and uses of dynamic binding
> in the context of _Emacs_ - i.e., the reason
> why Emacs has, and should continue to have,
> dynamic binding (along with lexical binding),
> see RMS's arguments here:
>
> https://www.gnu.org/software/emacs/emacs-paper.html#SEC17
>
> https://www.gnu.org/software/emacs/emacs-paper.html#SEC18

Yes, I am aware of that, thanks!

> Those arguments are as valid today (& tomorrow)
> as they were when written in 1981.
>
> Wrt the uses and behavior of dynamic & lexical
> binding in _Lisp_ (not particular to Emacs), I
> recommend reading the relevant parts of "Common
> Lisp The Language".
>
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html
>
> Here's my SO post on reading that section in
> relation to Emacs:
>
> https://stackoverflow.com/a/7135315/729907

Thanks, I'll look into those, too!

Best,

-- 
Marcin Borkowski
http://mbork.pl



reply via email to

[Prev in Thread] Current Thread [Next in Thread]