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

21–30 of 36 posts

Re: Swift's Abstract Syntax Tree

#21

Post by dang »

stormbrew wrote: post #18
dang wrote: post #9

Earlier quoted context omitted.

Boy do I know how you feel. So many things that used to seem interesting and deep to me (often involving syntax or parsing or data formats) now feel like busywork and noise. Or like I'm visiting a land where everyone wears extra layers of heavy, stiff clothing and speaks in long circumlocutions. I feel claustrophobic and can't wait to get back to Sexp-land where I can breathe. Some of it's just habit, of course, but…

Of course, the sentiment in this reply could probably have been expressed with far less text and/or syntax (probably in less than a tweet even). IMO people prefer to communicate with some nuance and some degree of redundant expression. Terseness is itself even a kind of nuance when you're allowed to not use it. Drives for widespread purity in language never seem to pan out, in either human human communication or huma…

Well, let me see. Conversation isn't code, natural language isn't programming language, I don't think I care about "purity in language", and I'm pretty sure I can make a case for everything in my comment needing to be there.

I do agree that people often desire to make things more complicated than they need to.

Re: Swift's Abstract Syntax Tree

#22

Post by stormbrew »

dang wrote: post #21
stormbrew wrote: post #18

Earlier quoted context omitted.

Of course, the sentiment in this reply could probably have been expressed with far less text and/or syntax (probably in less than a tweet even). IMO people prefer to communicate with some nuance and some degree of redundant expression. Terseness is itself even a kind of nuance when you're allowed to not use it. Drives for widespread purity in language never seem to pan out, in either human human communication or huma…

Well, let me see. Conversation isn't code, natural language isn't programming language, I don't think I care about "purity in language", and I'm pretty sure I can make a case for everything in my comment needing to be there. I do agree that people often desire to make things more complicated than they need to.

Explain in more detail why code isn't conversation? You are communicating a set of expectations about what a computer should do to both the computer and other humans who either read it or interact with it.

Re: Swift's Abstract Syntax Tree

#23

Post by dang »

stormbrew wrote: post #22
dang wrote: post #21

Earlier quoted context omitted.

Well, let me see. Conversation isn't code, natural language isn't programming language, I don't think I care about "purity in language", and I'm pretty sure I can make a case for everything in my comment needing to be there. I do agree that people often desire to make things more complicated than they need to.

Explain in more detail why code isn't conversation? You are communicating a set of expectations about what a computer should do to both the computer and other humans who either read it or interact with it.

What I said is that conversation isn't code. Not a commutative statement!

That is, you seemed to be arguing that there was redundancy in my comment, similar to what I called busywork and noise in code. An interesting point, but my comment was conversation—not code—so it struck me as a non sequitur.

Your comment hints at an insight into why we make code overcomplicated. But the superfluous complexity I'm talking about rarely strikes me as nuance, i.e. valuable enhancement for humans. It's mostly boilerplate to satisfy machines. It's no accident that "Programs must be written for people to read, and only incidentally for machines to execute" is a line that came out of the Lisp mentality.

Re: Swift's Abstract Syntax Tree

#24

Post by yjgyhj »

yjgyhj wrote: post #15
Kinnard wrote: post #10

Earlier quoted context omitted.

Hmmm, I am learning a lisp now I've been reluctant to dive in but this makes me all the more willing

It's simpler than it seems, and how strange people make it out to be held me off for a long time. There are cons cells. A cons cell is basically an untyped tuple. The syntax for a cons cell containing a number look like this: (1 nil) (where nil is the zero byte (I think, please correct me if I'm wrong)). You can nest them, like this: (1 (2 (3 nil))). Because nobody can be bothered to type those parens, the part of th…

BONUS FUN:

If you want to play around with lisp interactively, I reccomend checking out the program Emacs. It's a little lisp interpreter written in C, that comes with a text editor and such. Download it and run it. When you write some lisp code into the editor, place your cursor after the expression and hit Ctrl-x Ctrl-e. That is read, eval and apply what the expression, and display the result in the bottom of them window.

Here is a screenshot of me doing that with this code (apply (quote +) (quote (1 2))) ;; http://i.imgur.com/SrhMxS8.png

Play around with that - it's fun enough for an evening.

Some other fun code to run is this

    (reduce '+ '(1 2 3 4))

    (defun say-hello (&optional name) ;; a wild lambda appeared!
      (if (stringp name)
          (concat "hello " name)
        "I'm a lonely program"))
    (say-hello "Martin")
    (say-hello)

Re: Swift's Abstract Syntax Tree

#25

Post by yjgyhj »

stormbrew wrote: post #18
dang wrote: post #9

Earlier quoted context omitted.

Boy do I know how you feel. So many things that used to seem interesting and deep to me (often involving syntax or parsing or data formats) now feel like busywork and noise. Or like I'm visiting a land where everyone wears extra layers of heavy, stiff clothing and speaks in long circumlocutions. I feel claustrophobic and can't wait to get back to Sexp-land where I can breathe. Some of it's just habit, of course, but…

Of course, the sentiment in this reply could probably have been expressed with far less text and/or syntax (probably in less than a tweet even). IMO people prefer to communicate with some nuance and some degree of redundant expression. Terseness is itself even a kind of nuance when you're allowed to not use it. Drives for widespread purity in language never seem to pan out, in either human human communication or huma…

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.

Re: Swift's Abstract Syntax Tree

#26

Post by mkehrt »

yjgyhj wrote: post #25
stormbrew wrote: post #18

Earlier quoted context omitted.

Of course, the sentiment in this reply could probably have been expressed with far less text and/or syntax (probably in less than a tweet even). IMO people prefer to communicate with some nuance and some degree of redundant expression. Terseness is itself even a kind of nuance when you're allowed to not use it. Drives for widespread purity in language never seem to pan out, in either human human communication or huma…

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.

Re: Swift's Abstract Syntax Tree

#27

Post by [deleted] »

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.

[deleted]

Re: Swift's Abstract Syntax Tree

#28

Post by PeCaN »

adamnemecek wrote: post #3
Kinnard wrote: post #2

That looks like lisp?

Programming in lisp is basically manipulating the ast.

Not just "basically", that actually is the so-called ‘Zen of Lisp’. With something like paredit, your editing isn't text editing so much as manipulating the AST in a very literal sense. Then you can write macros to do that for you, since programmers are lazy and Lisp programmers are particularly so.

Re: Swift's Abstract Syntax Tree

#29

Post by outworlder »

lispm wrote: post #11
Kinnard wrote: post #2

That looks like lisp?

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 related somehow. The notation is a bit off, but it's nothing a few macros wouldn't solve.

[1] http://lemonodor.com/archives/2007/10/sexprs_in_leopard.html

Re: Swift's Abstract Syntax Tree

#30

Post by chriswarbo »

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 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!).

Post reply on HN