Emacs Lisp Readable Closures (2013)

Re:Emacs Lisp Readable Closures (2013) by bluefox on Friday October 15, 2021 @06:16AM (#28876163)

You can serialize closures (and continuations) in Common Lisp using Common Cold. The serialized representation of a closure contains a tag instead of the actual code, but the forms are also available in case you need to serialize them as well.

  CL-USER> (write-to-string
            (let ((y 4))
              (common-cold:slambda (x)
                (* x y))))
  "#.(S:F '1 '(4))"
  CL-USER> (funcall (read-from-string *) 3) ;; * here means reference to the last returned value
  12

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by TeMPOraL on Friday October 15, 2021 @07:16AM (#28876556)

> The serialized representation of a closure contains a tag instead of the actual code

Was going to ask about that.

For readers unfamiliar with Common Lisp, the output is essentially equivalent to

  "(eval '(s:f '1 '(4)))"

because #. is a reader macro that means "instead of returning the s-expression, return the result of evaluating it". I.e. it's a way to run arbitrary Lisp code at parsing stage. This is not something you want to see in a serialization format.

Ignoring the security implications[0], the result seems to rely on the runtime state of the Lisp image (I assume that '1 bit is a key to the actual code of the function) - so you won't be able to persist it and load after program restart, or send it to another instance of the program.

[0] - We're talking serializing code here anyway, so adding arbitrary code execution to paring changes nothing.

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by bluefox on Friday October 15, 2021 @07:50AM (#28876751)

Like I said, the mapping from tags to forms is available and you can serialize that as well, if you wish. Using a tag is useful, as it makes for a compact serialization when creating many closures of the same function. With regards to security, you would want to attach an authentication tag that you can verify prior to deserialization. Common Cold comes with an example of a Hunchentoot handler that compresses and encrypts the serialized continuation representations.

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by kagevf on Friday October 15, 2021 @12:21PM (#28879501)

Thank you for sharing this!

I tried looking for this on QL and github but couldn't find it ... do you know if the common cold source code is still available somewhere?

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by bluefox on Friday October 15, 2021 @01:11PM (#28880183)

I believe you can find it via archive.org, but you should probably ask Paul Khoung (pvk.ca) to push it to GitHub or something.

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by WalterGR on Friday October 15, 2021 @11:51PM (#28885410)

It’s such a shame that the Common Lisp community has to rely on archive.org so much. I remember working with others to recover (IIRC) https://wiki.alu.org/ from archive.org after... something.

In fact, it loks like it’s inaccessible now, at least in my browser. Google does have some pages indexed though: https://www.google.com/search?q=site%3Aalu.org

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by bluefox on Saturday October 16, 2021 @08:42AM (#28887458)

Yes, it is unfortunate. Information loss on the internet is not limited to CL, however, and many of my bookmarks became stale over the years. When I encounter a "treasure trove" of information, I make sure to archive it on my machine (and ultimately on backup hardware). Sometimes I put it up on sites like GitHub.

[ Parent | on HN ]

Re:Emacs Lisp Readable Closures (2013) by kagevf on Friday October 15, 2021 @01:59PM (#28880842)

You're right, it was: http://web.archive.org/web/20081120155011/http://www.discont...

[ Parent | on HN ]