64 ms·

I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across t

I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?

g9550684 2mo ago
in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.
- groundzeros2015 2mo ago
  You can configure (read) to be safe for this purpose. It’s not a hack.
  - pfdietz 2mo ago
    Yes, there's a specific standard special variable controlling it, *read-eval*.
    - groundzeros2015 2mo ago
      You can also configure a read table to disable any other data structure features you want. inb4 DoS attack. That is a universal parsing problem and should be solved by configuring OS limits for your process.
      - pfdietz 2mo ago
        I'm of two minds about read tables. Yes, it's nice we have control over it. This is a lisp thing, where features that are used to implement standard things (like the standard reader) are exposed so the user can play with them also. But code written with custom read tables has some problems. Different code with different read tables may not be composable. If I have two packages that use incompatible read tables I can't import them into a third package and expect to be able to use their readtables there. Also, it makes treating code as an object to be inspected, modified, and written out again difficult. This is similar to the problem of code rewriting systems on preprocessed languages like C or C++. A different branch of Lisp put everything into S expressions. Interlisp, for example, had comments in the code as forms, so the code could be editted as S-expressions. But that was dropped from Common Lisp, which took the surface syntax more from Maclisp.
        groundzeros2015 2mo ago
        Good points. I sometimes see it as “easy and clean json” rather than code as data.
reddit_clone 2mo ago
Not sexps, but better. Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely.. Boggles my mind even today.
- mechanicum 2mo ago
  Probably this? “Concurrency Oriented Programming in Termite Scheme”: http://scheme2006.cs.uchicago.edu/09-germain.pdf http://scheme2006.cs.uchicago.edu/09-germain.pdf Implemented in Gambit Scheme: https://github.com/FredericHamel/termite-scheme https://github.com/FredericHamel/termite-scheme
- asa400 2mo ago
  Erlang also has this capability built in. You can do all kinds of weird stuff with it, it’s great.
- dmux 2mo ago
  Tcl has a library called "comm" [0] that lets you expose an interpreter over a socket and since everything in Tcl has a string representation, there's no need for a serialization/deserialization step. [0] https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/comm/comm.md#synopsis https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tclli...

g9550684 2mo ago

in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.

groundzeros2015 2mo ago
You can configure (read) to be safe for this purpose. It’s not a hack.
- pfdietz 2mo ago
  Yes, there's a specific standard special variable controlling it, *read-eval*.
  - groundzeros2015 2mo ago
    You can also configure a read table to disable any other data structure features you want. inb4 DoS attack. That is a universal parsing problem and should be solved by configuring OS limits for your process.
    - pfdietz 2mo ago
      I'm of two minds about read tables. Yes, it's nice we have control over it. This is a lisp thing, where features that are used to implement standard things (like the standard reader) are exposed so the user can play with them also. But code written with custom read tables has some problems. Different code with different read tables may not be composable. If I have two packages that use incompatible read tables I can't import them into a third package and expect to be able to use their readtables there. Also, it makes treating code as an object to be inspected, modified, and written out again difficult. This is similar to the problem of code rewriting systems on preprocessed languages like C or C++. A different branch of Lisp put everything into S expressions. Interlisp, for example, had comments in the code as forms, so the code could be editted as S-expressions. But that was dropped from Common Lisp, which took the surface syntax more from Maclisp.
      - groundzeros2015 2mo ago
        Good points. I sometimes see it as “easy and clean json” rather than code as data.

reddit_clone 2mo ago

Not sexps, but better. Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely.. Boggles my mind even today.

mechanicum 2mo ago
Probably this? “Concurrency Oriented Programming in Termite Scheme”: http://scheme2006.cs.uchicago.edu/09-germain.pdf http://scheme2006.cs.uchicago.edu/09-germain.pdf Implemented in Gambit Scheme: https://github.com/FredericHamel/termite-scheme https://github.com/FredericHamel/termite-scheme
asa400 2mo ago
Erlang also has this capability built in. You can do all kinds of weird stuff with it, it’s great.
dmux 2mo ago
Tcl has a library called "comm" [0] that lets you expose an interpreter over a socket and since everything in Tcl has a string representation, there's no need for a serialization/deserialization step. [0] https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/comm/comm.md#synopsis https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tclli...