3 ms·

I strongly disagree that Lisp-style s-exprs are the solution to this problem. They preclude future-proofing language tools. If feature X is currently describe

I strongly disagree that Lisp-style s-exprs are the solution to this problem. They preclude future-proofing language tools. If feature X is currently described as a n-tuple, and I want to enhance it, I must now either create a new tag (which breaks tools) or increase its arity (which necessarily centralizes language development). A solution to this would be to represent nodes as key-value sets. There is precedent for this: XML and CSS both work this way.

gruseom 13y ago
I agree that key-value sets (hashmaps, associative arrays, whatever one calls them) are even more convenient for programming than lists are. A pet idea is to create a Lisp that takes the hashmap as its native representation. (My cofounder is working on it!) However, it would be beyond tedious to have to assign every code element an explicit key, so in practice one wants to generalize s-exprs into what one might call t-exprs ("table expressions") in a way analogous to how Lua lets tables have a special integer-indexed array portion. Semantically, everything is a table (hashmap); notationally, most forms look just like s-exprs. But now they can be augmented with arbitrary key-value pairs. I don't feel future-proofing is as big a deal as you do, but I do think that certain programs and (especially) tools would be easier to write in a hashmap-based Lisp, where the programmer and/or tool could attach whatever metadata they wanted to any section of code. There are potentially some order-of-magnitude wins there, I think. Production Lisps usually tack on various kinds of magic metadata anyway (e.g. symbol-plists, docstrings, Common Lisp's declare, Clojure's metadata). The above idea would unify all of those by promoting the underlying generic construct to first-class status.

3 ms·

I strongly disagree that Lisp-style s-exprs are the solution to this problem. They preclude future-proofing language tools. If feature X is currently describe

by colanderman 13y ago

gruseom 13y ago
I agree that key-value sets (hashmaps, associative arrays, whatever one calls them) are even more convenient for programming than lists are. A pet idea is to create a Lisp that takes the hashmap as its native representation. (My cofounder is working on it!) However, it would be beyond tedious to have to assign every code element an explicit key, so in practice one wants to generalize s-exprs into what one might call t-exprs ("table expressions") in a way analogous to how Lua lets tables have a special integer-indexed array portion. Semantically, everything is a table (hashmap); notationally, most forms look just like s-exprs. But now they can be augmented with arbitrary key-value pairs. I don't feel future-proofing is as big a deal as you do, but I do think that certain programs and (especially) tools would be easier to write in a hashmap-based Lisp, where the programmer and/or tool could attach whatever metadata they wanted to any section of code. There are potentially some order-of-magnitude wins there, I think. Production Lisps usually tack on various kinds of magic metadata anyway (e.g. symbol-plists, docstrings, Common Lisp's declare, Clojure's metadata). The above idea would unify all of those by promoting the underlying generic construct to first-class status.