3 ms·

The T in AST means that any straightforward textual representation is going to come out isomorphic to Lisp. But if you try something non-straightforward, then p

by gruseom 13y ago

The T in AST means that any straightforward textual representation is going to come out isomorphic to Lisp. But if you try something non-straightforward, then programmers will have to do the mapping between text and AST in their heads, which defeats the purpose. Thus what you're asking for reduces to either (a) a mainstream Lisp, or (b) a language whose programs naturally translate into something other than a tree. (a) is a can of rather boring worms, but (b) seems like it could use more attention. The only thing I know of in that space (maybe) are stack languages.

TheLoneWolfling 13y ago
(b) Dataflow programming? And the entire point of storing the "source" on-disk as an AST is to not have the programmer directly edit the file. Use an editor set up to handle it. Sort of like JSON. Yes, you can read and edit it manually, but it's primarily meant for something else.
- gruseom 13y ago
  In most dataflow languages (e.g. Lucid) the source text is still parsed into a tree; it's the order of execution at runtime that is unusual. That is, dataflow languages are tree-based lexically, but not temporally. A counterexample would be interesting. Is there one? Edit: it feels like if one found a textual notation that matched the dataflow graph in the way that s-exprs match ASTs, that could lead to a Lisp of dataflow languages. I have no idea what that would look like or whether it would be tractable for building real-world systems, but it would be an interesting experiment.
colanderman 13y ago
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.

by gruseom 13y ago

TheLoneWolfling 13y ago

(b) Dataflow programming? And the entire point of storing the "source" on-disk as an AST is to not have the programmer directly edit the file. Use an editor set up to handle it. Sort of like JSON. Yes, you can read and edit it manually, but it's primarily meant for something else.

gruseom 13y ago
In most dataflow languages (e.g. Lucid) the source text is still parsed into a tree; it's the order of execution at runtime that is unusual. That is, dataflow languages are tree-based lexically, but not temporally. A counterexample would be interesting. Is there one? Edit: it feels like if one found a textual notation that matched the dataflow graph in the way that s-exprs match ASTs, that could lead to a Lisp of dataflow languages. I have no idea what that would look like or whether it would be tractable for building real-world systems, but it would be an interesting experiment.

colanderman 13y ago

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.