About closure creation

Question

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?

Answer 1

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.