Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift's Abstract Syntax Tree

ankit.im

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Swift's Abstract Syntax Tree

#31

Post by westoncb »

chriswarbo wrote: post #30
yjgyhj wrote: post #4

After learning lisp, I just feel like every other language is a weird set of macros. Looking at this AST confirms that. Wish I could live the rest of my life in Sexp-land.

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 ba…

Interesting. 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-indepe...

Re: Swift's Abstract Syntax Tree

#32

Post by chriswarbo »

westoncb wrote: post #31
chriswarbo wrote: post #30

Earlier quoted context omitted.

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 ba…

Interesting. 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-indepe...

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

Re: Swift's Abstract Syntax Tree

#33

Post by westoncb »

chriswarbo wrote: post #32
westoncb wrote: post #31

Earlier quoted context omitted.

Interesting. 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-indepe...

Very 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…

Hey 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 :)

Re: Swift's Abstract Syntax Tree

#34

Post by westoncb »

chriswarbo wrote: post #32
westoncb wrote: post #31

Earlier quoted context omitted.

Interesting. 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-indepe...

Very 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…

Also, 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.

Re: Swift's Abstract Syntax Tree

#35

Post by JBReefer »

mkehrt wrote: post #26
yjgyhj wrote: post #25

Earlier quoted context omitted.

Look then at human languages - two of the giants are English and Spanish. Both pretty simple. Definitely they both are the most spoken as second language. They would not have that position if it was not for their simplicity, compared to other languages. Mandarin is an outlier in that comparison - but also not popular as a second language.

English and Spanish hold their positions as popular languages based on the fact they were both spoken in world spanning empires in the past, not because they are particularly simple. English, in particular, is known for being difficult to learn--it uses phones that very rare ("th" and the English "r"), it has a bizarrely large vocabulary, and, somewhat separately, its spelling is nonsensical.

Your are correct about the cause of dominance, but Spanish is absolutely the most simple language in large use.

Re: Swift's Abstract Syntax Tree

#36

Post by lispm »

outworlder wrote: post #29
lispm wrote: post #11

Earlier quoted context omitted.

No, it looks like some kind of s-expression version of the Swift AST. It could have been in XML format or something else. Lists seem to be popular for it - somehow. Not everything which uses a notation similar to s-expressions has anything to do Lisp.

True, but it could be turned into executable Lisp code without much effort. As could a XML format version of it. Besides, square brackets is the most common representation of lists. It's difficult to find round brackets denoting lists outside of Lisp and dialets. I doubt that's a coincidence. Given that Apple already uses Scheme in its sandbox implementation [1], it wouldn't be too outlandish to assume those are rela…

> True, but it could be turned into executable Lisp code without much effort

Unlikely.

> Given that Apple already uses Scheme in its sandbox implementation [1], it wouldn't be too outlandish to assume those are related somehow. The notation is a bit off, but it's nothing a few macros wouldn't solve.

They both use parentheses. They are related. Somehow.

Post reply on HN