[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Closures - do you understand them well?
From: |
Emanuel Berg |
Subject: |
Re: Closures - do you understand them well? |
Date: |
Thu, 02 Mar 2023 19:50:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Michael Heerdegen wrote:
> Maybe I should mention oclosures where you can access
> variables with accessor functions "from the outside".
> But this is also a high-level thing, the internal structure
> of oclosures is not important and an implementation like for
> "normal" function values.
Here is the abstract:
While folklore teaches us that closures and objects are two
sides of the same coin, they remain quite different in
practice, most notably because closures are opaque, the only
supported operation being to call them.
In this article we discuss a few cases where we need
functions to be less opaque, and propose to satisfy this
need by extending our beloved 𝜆 so as to expose as sorts of
record fields some of the variables it captures. These open
closures are close relatives of CLOS’s funcallable objects
as well as of the function objects of traditional
object-oriented languages like Java, except that they are
functions made to behave like objects rather than the
reverse. We present the design and implementation of such
a feature in the context of Emacs Lisp. [1]
There is a list of use case, they seem to have a lot to do
with really specific situations and fringe cases were one
would previous hack one's way thru it each time, and not rely
on ideomatic, clean code, so now with oclosures that's
much easier.
Good, but if so it's maybe nothing indispensible for the Joe
Emacs Hacker, whereas the top-level lexical let-closures are
one or two small steps forward with the three use cases I have
identified (no/less global varaibles, share variables between
functions, preserved variable values between function calls).
But I'm all for the esoteric stuff as well so it's all good.
[1] https://www.iro.umontreal.ca/~monnier/oclosure.pdf
--
underground experts united
https://dataswamp.org/~incal