Hacker News Reader

Comment by joshmarlow | Hacker News Reader

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?

View on HN

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.

You can configure (read) to be safe for this purpose.

It’s not a hack.

Yes, there's a specific standard special variable controlling it, *read-eval*.

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.

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.

Good points. I sometimes see it as “easy and clean json” rather than code as data.

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.

Probably this?

“Concurrency Oriented Programming in Termite Scheme”: http://scheme2006.cs.uchicago.edu/09-germain.pdf

Implemented in Gambit Scheme: https://github.com/FredericHamel/termite-scheme

Erlang also has this capability built in. You can do all kinds of weird stuff with it, it’s great.

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

Reply on news.ycombinator.com