About closure creation
After reading this article about readable closures, I check that:
Since closures are byte-code function objects, they print readably.
You can capture an environment in a closure, serialize it, read it
back in, and evaluate it. That’s pretty cool! This means closures can
be transmitted to other Emacs instances in a multi-processing setup
(i.e. Elnode, Async)
So since we can do that, we can also write closures?
Should this be a real possibility and will have a real use?
Writing a normal closure
ELISP> (setq counter (let ((x 0)) (lambda () (cl-incf x))))
(closure
((x . 0)
t)
nil
(cl-incf x))
ELISP> (funcall counter)
1 (#o1, #x1, ?C-a)
ELISP> counter
(closure
((x . 1)
t)
nil
(cl-incf x))
Writing a literal closure:
ELISP> (setq even-counter '(closure ((x . 0) t) nil (cl-incf x 2)))
(closure
((x . 0)
t)
nil
(cl-incf x 2))
ELISP> (funcall even-counter)
2 (#o2, #x2, ?C-b)
ELISP> even-counter)
*** IELM error *** More than one sexp in input
ELISP> even-counter
(closure
((x . 2)
t)
nil
(cl-incf x 2))
So they both work, and are the same type, since they don't will have non-readable types (i.e buffer) inside they will work equally. further more they are the same type:
ELISP> (type-of even-counter)
cons
ELISP> (type-of counter)
cons
But I couldn't find any constructor for building a closure.
So I suppose that his is one of the cases of homoiconicity of lisp.
To Sum up:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of
cons?
elisp lexical-scoping dynamic-scoping lexical-binding closures
edited Dec 13 at 14:40
sds
3,671826
asked Dec 13 at 14:31
anquegi
298214
add a comment |
After reading this article about readable closures, I check that:
Since closures are byte-code function objects, they print readably.
You can capture an environment in a closure, serialize it, read it
back in, and evaluate it. That’s pretty cool! This means closures can
be transmitted to other Emacs instances in a multi-processing setup
(i.e. Elnode, Async)
So since we can do that, we can also write closures?
Should this be a real possibility and will have a real use?
Writing a normal closure
ELISP> (setq counter (let ((x 0)) (lambda () (cl-incf x))))
(closure
((x . 0)
t)
nil
(cl-incf x))
ELISP> (funcall counter)
1 (#o1, #x1, ?C-a)
ELISP> counter
(closure
((x . 1)
t)
nil
(cl-incf x))
Writing a literal closure:
ELISP> (setq even-counter '(closure ((x . 0) t) nil (cl-incf x 2)))
(closure
((x . 0)
t)
nil
(cl-incf x 2))
ELISP> (funcall even-counter)
2 (#o2, #x2, ?C-b)
ELISP> even-counter)
*** IELM error *** More than one sexp in input
ELISP> even-counter
(closure
((x . 2)
t)
nil
(cl-incf x 2))
So they both work, and are the same type, since they don't will have non-readable types (i.e buffer) inside they will work equally. further more they are the same type:
ELISP> (type-of even-counter)
cons
ELISP> (type-of counter)
cons
But I couldn't find any constructor for building a closure.
So I suppose that his is one of the cases of homoiconicity of lisp.
To Sum up:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of
cons?
elisp lexical-scoping dynamic-scoping lexical-binding closures
edited Dec 13 at 14:40
sds
3,671826
asked Dec 13 at 14:31
anquegi
298214
add a comment |
After reading this article about readable closures, I check that:
Since closures are byte-code function objects, they print readably.
You can capture an environment in a closure, serialize it, read it
back in, and evaluate it. That’s pretty cool! This means closures can
be transmitted to other Emacs instances in a multi-processing setup
(i.e. Elnode, Async)
So since we can do that, we can also write closures?
Should this be a real possibility and will have a real use?
Writing a normal closure
ELISP> (setq counter (let ((x 0)) (lambda () (cl-incf x))))
(closure
((x . 0)
t)
nil
(cl-incf x))
ELISP> (funcall counter)
1 (#o1, #x1, ?C-a)
ELISP> counter
(closure
((x . 1)
t)
nil
(cl-incf x))
Writing a literal closure:
ELISP> (setq even-counter '(closure ((x . 0) t) nil (cl-incf x 2)))
(closure
((x . 0)
t)
nil
(cl-incf x 2))
ELISP> (funcall even-counter)
2 (#o2, #x2, ?C-b)
ELISP> even-counter)
*** IELM error *** More than one sexp in input
ELISP> even-counter
(closure
((x . 2)
t)
nil
(cl-incf x 2))
So they both work, and are the same type, since they don't will have non-readable types (i.e buffer) inside they will work equally. further more they are the same type:
ELISP> (type-of even-counter)
cons
ELISP> (type-of counter)
cons
But I couldn't find any constructor for building a closure.
So I suppose that his is one of the cases of homoiconicity of lisp.
To Sum up:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of
cons?
elisp lexical-scoping dynamic-scoping lexical-binding closures
edited Dec 13 at 14:40
sds
3,671826
asked Dec 13 at 14:31
anquegi
298214
After reading this article about readable closures, I check that:
Since closures are byte-code function objects, they print readably.
You can capture an environment in a closure, serialize it, read it
back in, and evaluate it. That’s pretty cool! This means closures can
be transmitted to other Emacs instances in a multi-processing setup
(i.e. Elnode, Async)
So since we can do that, we can also write closures?
Should this be a real possibility and will have a real use?
Writing a normal closure
ELISP> (setq counter (let ((x 0)) (lambda () (cl-incf x))))
(closure
((x . 0)
t)
nil
(cl-incf x))
ELISP> (funcall counter)
1 (#o1, #x1, ?C-a)
ELISP> counter
(closure
((x . 1)
t)
nil
(cl-incf x))
Writing a literal closure:
ELISP> (setq even-counter '(closure ((x . 0) t) nil (cl-incf x 2)))
(closure
((x . 0)
t)
nil
(cl-incf x 2))
ELISP> (funcall even-counter)
2 (#o2, #x2, ?C-b)
ELISP> even-counter)
*** IELM error *** More than one sexp in input
ELISP> even-counter
(closure
((x . 2)
t)
nil
(cl-incf x 2))
So they both work, and are the same type, since they don't will have non-readable types (i.e buffer) inside they will work equally. further more they are the same type:
ELISP> (type-of even-counter)
cons
ELISP> (type-of counter)
cons
But I couldn't find any constructor for building a closure.
So I suppose that his is one of the cases of homoiconicity of lisp.
To Sum up:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of
cons?
elisp lexical-scoping dynamic-scoping lexical-binding closures
elisp lexical-scoping dynamic-scoping lexical-binding closures
edited Dec 13 at 14:40
sds
3,671826
asked Dec 13 at 14:31
anquegi
298214
edited Dec 13 at 14:40
sds
3,671826
asked Dec 13 at 14:31
anquegi
298214
edited Dec 13 at 14:40
sds
3,671826
edited Dec 13 at 14:40
sds
3,671826
edited Dec 13 at 14:40
sds
3,671826
3,671826
asked Dec 13 at 14:31
anquegi
298214
asked Dec 13 at 14:31
anquegi
298214
asked Dec 13 at 14:31
anquegi
298214
298214
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You asked:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of cons?
All three questions are answered with the following quote of the elisp manual:
However, the fact that the internal structure of a closure is exposed to
the rest of the Lisp world is considered an internal implementation
detail. For this reason, we recommend against directly examining or
altering the structure of closure objects.
So you should not rely on the structure of closure objects and the answer to your first and second question is: `No´.
About your third question: cons is also a real type.
I think you actually ask why (type-of counter) does not return something closure specific but cons. The above quote also answers that question. Closures are currently represented by lists. Therefore type-of cannot differentiate between closure and a list with the symbol closure as first element.
edited Dec 15 at 2:42
Drew
46.8k462104
answered Dec 13 at 16:24
Tobias
12.6k1832
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "583"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2femacs.stackexchange.com%2fquestions%2f46581%2fabout-closure-creation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You asked:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of cons?
All three questions are answered with the following quote of the elisp manual:
However, the fact that the internal structure of a closure is exposed to
the rest of the Lisp world is considered an internal implementation
detail. For this reason, we recommend against directly examining or
altering the structure of closure objects.
So you should not rely on the structure of closure objects and the answer to your first and second question is: `No´.
About your third question: cons is also a real type.
I think you actually ask why (type-of counter) does not return something closure specific but cons. The above quote also answers that question. Closures are currently represented by lists. Therefore type-of cannot differentiate between closure and a list with the symbol closure as first element.
edited Dec 15 at 2:42
Drew
46.8k462104
answered Dec 13 at 16:24
Tobias
12.6k1832
add a comment |
You asked:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of cons?
All three questions are answered with the following quote of the elisp manual:
However, the fact that the internal structure of a closure is exposed to
the rest of the Lisp world is considered an internal implementation
detail. For this reason, we recommend against directly examining or
altering the structure of closure objects.
So you should not rely on the structure of closure objects and the answer to your first and second question is: `No´.
About your third question: cons is also a real type.
I think you actually ask why (type-of counter) does not return something closure specific but cons. The above quote also answers that question. Closures are currently represented by lists. Therefore type-of cannot differentiate between closure and a list with the symbol closure as first element.
edited Dec 15 at 2:42
Drew
46.8k462104
answered Dec 13 at 16:24
Tobias
12.6k1832
add a comment |
You asked:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of cons?
All three questions are answered with the following quote of the elisp manual:
However, the fact that the internal structure of a closure is exposed to
the rest of the Lisp world is considered an internal implementation
detail. For this reason, we recommend against directly examining or
altering the structure of closure objects.
So you should not rely on the structure of closure objects and the answer to your first and second question is: `No´.
About your third question: cons is also a real type.
I think you actually ask why (type-of counter) does not return something closure specific but cons. The above quote also answers that question. Closures are currently represented by lists. Therefore type-of cannot differentiate between closure and a list with the symbol closure as first element.
edited Dec 15 at 2:42
Drew
46.8k462104
answered Dec 13 at 16:24
Tobias
12.6k1832
You asked:
- Will be useful to write/build literal closures?
- Should it be a good practice? any example?
- Why the closure is not a real type instead of cons?
All three questions are answered with the following quote of the elisp manual:
However, the fact that the internal structure of a closure is exposed to
the rest of the Lisp world is considered an internal implementation
detail. For this reason, we recommend against directly examining or
altering the structure of closure objects.
So you should not rely on the structure of closure objects and the answer to your first and second question is: `No´.
About your third question: cons is also a real type.
I think you actually ask why (type-of counter) does not return something closure specific but cons. The above quote also answers that question. Closures are currently represented by lists. Therefore type-of cannot differentiate between closure and a list with the symbol closure as first element.
edited Dec 15 at 2:42
Drew
46.8k462104
answered Dec 13 at 16:24
Tobias
12.6k1832
edited Dec 15 at 2:42
Drew
46.8k462104
edited Dec 15 at 2:42
Drew
46.8k462104
edited Dec 15 at 2:42
Drew
46.8k462104
46.8k462104
answered Dec 13 at 16:24
Tobias
12.6k1832
answered Dec 13 at 16:24
Tobias
12.6k1832
answered Dec 13 at 16:24
Tobias
12.6k1832
12.6k1832
add a comment |
add a comment |
Thanks for contributing an answer to Emacs Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2femacs.stackexchange.com%2fquestions%2f46581%2fabout-closure-creation%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
