3 ms·
Seeing this "dump AST" option for Swift is truly refreshing. I've come to the opinion that when sending data in or out of software, it should always preserve a
by chriswarbo 11y ago
Seeing this "dump AST" option for Swift is truly refreshing.
I've come to the opinion that when sending data in or out of software, it should always preserve as much structure as possible in an easily parseable form accessible to off-the-shelf parsers; e.g. s-expressions, JSON or, if it can't be avoided, XML. Even thrown-together debugging messages. Basically I should be able to reconstruct all of the structure in basically any programming language with something like one module import and a function call (or equivalent); I shouldn't have to define my own parsing rules, no matter how simple their author thinks they are.
Not only this, but any format which, for some reason, cannot be represented in this way, e.g. programs in languages which consciously avoid s-expressoins, should pass through a layer which does convert to a structured form, and this form should be obtainable, e.g. by setting an environment variable or a commandline flag. That's why I commend this "dump AST" flag.
It's basically the opposite of the many "Lisp-on-top-of-X" approaches. Instead of being able to write s-exprs which translate to some underlying language, like Swift, I should be able to translate any Swift into s-exprs to be manipulated. Why? Because there will always be strictly less code written in a Lispy language than there will be for the underlying platform as a whole. For example, there will always be less code written in Clojure than code written for the JVM.
The benefits of s-expressions (and accessible AST structures in general) is that they can be inspected, transformed, manipulated, pulled apart, recombined, etc. This is of some use when programming, e.g. having macros manipulate our Clojure ASTs, but not a huge amount; after all, we could write our code in a different way which didn't need the macros (we could even, in principle, write it in Java!).
In contrast, being able to manipulate code which isn't ours is much more useful; since we don't have the option of writing it a different way (since we didn't write it at all!).
- westoncb 11y agoInteresting. I've been thinking about an alternate way of structuring programming tools that's along these lines. I've written about it here: http://westoncb.blogspot.com/2015/06/how-to-make-view-independent-program.html http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...
- chriswarbo 11y agoVery interesting, especially tracing a path through the grammar; I saw "path" and was expecting something more unwieldy like an infinite trie of all valid programs. Whilst I agree that the visual and on-disk representations of programs are too tightly-coupled, there are many structure-based IDE experiments out there, but few see much adoption due to the immense momentum of existing infrastructure, and the subtlety of integrating nicely with things like version control. It's a less drastic change to make existing language compilers/interpreters more modular, so that we can use them for things like parsing, type-checking, optimisation, etc. in a "standalone" way, without having to reinvent everything from scratch each time we want to do something the implementors didn't consider.
- westoncb 11y agoHey Chris, thanks for checking it out. The way I see it, the fact that our programming tools operate on huge character sequences is historical accident. Rather than coming up with a particular editor, I'm trying to think of what a more 'correct' structure for representing programs in general would be, as a replacement for character sequences. Of course this is essentially suggesting a paradigm shift, and as you say (approximately), the current paradigm has lots of momentum. It feels like this might be closer to describing planetary orbits with the more natural ellipses rather than circles—but maybe I'm just suggesting triangles or something :)
- westoncb 11y agoAlso, probably the most subtle thing I do in there is change what it is that the grammar is actually describing, so that the 'grammar' I talk about paths through is actually talking about higher level things than grammars ordinarily are.