4 ms·

> What about a Clojure program and a Common Lisp program? Probably a byte stream. (Ironically, S-expressions have no commonly used "exterior" interchange format

> What about a Clojure program and a Common Lisp program? Probably a byte stream. (Ironically, S-expressions have no commonly used "exterior" interchange format) Probably because the details of S-expressions differ underneath the hood - a simple (foo ()) can mean a different thing on CL (where the second element is the symbol NIL) than on Scheme (where it is an empty list and not a symbol); also because Clojure introduces additional bracketing patterns, such as [] for arrays and {} for maps, which will confuse non-Clojures. And let's not talk about sexp variants of Lisp-Flavored Erlang. Also, if you squint hard enough, https://en.wikipedia.org/wiki/Canonical_S-expressions https://en.wikipedia.org/wiki/Canonical_S-expressions works. Also I have no idea if anyone ever cared enough to implement cross-language software transactional memory that would work across a process boundary, to close the gap between a Clojure process and a Lisp process. It could work in theory, but someone would need to do it - either get paid to do it, or have enough mojo of their own to write and bulletprove such a thing. And, since everyone serializes to JSON anyway, serializing to JSON is a decent enough choice for communicating across Lisps as well.

chubot 3y ago
Yeah the way I frame it is that Lisp is about "interior" composition (functions and data), not "exterior" (processes andf iles) Narrow Waists Can Be Interior or Exterior: PyObject vs. Unix Files https://www.oilshell.org/blog/2023/06/narrow-waist.html https://www.oilshell.org/blog/2023/06/narrow-waist.html However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? Well I guess Clojure/EDN is that, but nobody has produced a POLYGLOT system involving distributed Lisp. Common Lisp users probably don't use EDN very much, I gather. --- I found this POSE exterior s-expression format, but it seems to have little interest from the Lisp community: https://lobste.rs/s/lwf4jv/pose_portable_s_expressions_pose_spec https://lobste.rs/s/lwf4jv/pose_portable_s_expressions_pose_... It seems like JSON will have an "impedance mismatch" with Lisp data structures, but yeah that's the cost of interoperability
- phoe-krk 3y ago
  > However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? How about Lisp Flavored Erlang?
  - chubot 3y ago
    How does Lisp Flavored Erlang talk to Common Lisp? Probably with a byte stream. The VMs are different. I've noticed Erlang/Elixir also favor interior composition! Parsing is not idiomatic there -- they're actually BAD languages for parsing text. (Though they do have good affordances for parsing bytes) They prefer to pass around Erlang terms, which are copied inside the VM. I get that -- it's more convenient. But it's also a reason why "the rest of the world" has more code reuse -- e.g. Go talks to JavaScript talks to Python. Most projects have multiple languages. Monoglot projects become polyglot projects when they grow bigger. --- So I say - Lisp prefers its own (interior) narrow waist - Erlang prefers its own (interior) narrow waist -- even the Lisp one is second class! - The rest of the world uses the (exterior) byte stream narrow waist, but they complain about it a lot :)
- lispm 3y ago
  > not "exterior" (processes and iles) Common Lisp can read and write s-expressions from files. It can also compile source files and load files (both source and compiled). The syntax for Common Lisp is standardized. Thus a lot of data may be shipped either in text or compiled files. Several implementations can also create snapshots of the runtime memory. A few domains use CL s-expressions (or a subset of that) as language syntax or as a data syntax. Distributed Lisp applications exist, but may not use text to exchange data. For example there is a defined CORBA mapping for Common Lisp, which enabled Common Lisp software to take part in distributed software using a standard, which allows mixed language software.

chubot 3y ago

Yeah the way I frame it is that Lisp is about "interior" composition (functions and data), not "exterior" (processes andf iles) Narrow Waists Can Be Interior or Exterior: PyObject vs. Unix Files https://www.oilshell.org/blog/2023/06/narrow-waist.html https://www.oilshell.org/blog/2023/06/narrow-waist.html However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? Well I guess Clojure/EDN is that, but nobody has produced a POLYGLOT system involving distributed Lisp. Common Lisp users probably don't use EDN very much, I gather. --- I found this POSE exterior s-expression format, but it seems to have little interest from the Lisp community: https://lobste.rs/s/lwf4jv/pose_portable_s_expressions_pose_spec https://lobste.rs/s/lwf4jv/pose_portable_s_expressions_pose_... It seems like JSON will have an "impedance mismatch" with Lisp data structures, but yeah that's the cost of interoperability

phoe-krk 3y ago
> However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? How about Lisp Flavored Erlang?
- chubot 3y ago
  How does Lisp Flavored Erlang talk to Common Lisp? Probably with a byte stream. The VMs are different. I've noticed Erlang/Elixir also favor interior composition! Parsing is not idiomatic there -- they're actually BAD languages for parsing text. (Though they do have good affordances for parsing bytes) They prefer to pass around Erlang terms, which are copied inside the VM. I get that -- it's more convenient. But it's also a reason why "the rest of the world" has more code reuse -- e.g. Go talks to JavaScript talks to Python. Most projects have multiple languages. Monoglot projects become polyglot projects when they grow bigger. --- So I say - Lisp prefers its own (interior) narrow waist - Erlang prefers its own (interior) narrow waist -- even the Lisp one is second class! - The rest of the world uses the (exterior) byte stream narrow waist, but they complain about it a lot :)
lispm 3y ago
> not "exterior" (processes and iles) Common Lisp can read and write s-expressions from files. It can also compile source files and load files (both source and compiled). The syntax for Common Lisp is standardized. Thus a lot of data may be shipped either in text or compiled files. Several implementations can also create snapshots of the runtime memory. A few domains use CL s-expressions (or a subset of that) as language syntax or as a data syntax. Distributed Lisp applications exist, but may not use text to exchange data. For example there is a defined CORBA mapping for Common Lisp, which enabled Common Lisp software to take part in distributed software using a standard, which allows mixed language software.