Hacker News Reader

Comment by TheLoneWolfling | Hacker News Reader

I wish that a mainstream language would come about that uses a proper encoded AST as "source code", thus making the point moot, as people could display format as they wish. unfortunately, this has not come about thus far.

However, it's still (almost) a moot point to me. I almost never code in 80 characters (generally closer to 130ish. Fits two windows nicely side-by-side on my screen.), but if something requires it I have my IDE set up to reformat it when I am done.

View on HN

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.

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.

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.

(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.

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.

Reply on news.ycombinator.com