3 ms·

You can serialize closures (and continuations) in Common Lisp using Common Cold. The serialized representation of a closure contains a tag instead of the actua

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

TeMPOraL 5y ago
> 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.
- bluefox 5y ago
  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.
kagevf 5y ago
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?
- bluefox 5y ago
  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.
  - kagevf 5y ago
    You're right, it was: http://web.archive.org/web/20081120155011/http://www.discontinuity.info/~pkhuong/common-cold/handler.lisp http://web.archive.org/web/20081120155011/http://www.discont...
  - WalterGR 5y ago
    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/ 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 https://www.google.com/search?q=site%3Aalu.org
    - bluefox 5y ago
      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.

TeMPOraL 5y ago

> 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.

bluefox 5y ago
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.

kagevf 5y ago

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?

bluefox 5y ago
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.
- kagevf 5y ago
  You're right, it was: http://web.archive.org/web/20081120155011/http://www.discontinuity.info/~pkhuong/common-cold/handler.lisp http://web.archive.org/web/20081120155011/http://www.discont...
- WalterGR 5y ago
  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/ 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 https://www.google.com/search?q=site%3Aalu.org
  - bluefox 5y ago
    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.