3 ms·

First, it's been nearly two decades since Norvig's examination, and Python grew the `ast` module in the stdlib, which improves things greatly: >>> ast.dump

First, it's been nearly two decades since Norvig's examination, and Python grew the `ast` module in the stdlib, which improves things greatly: >>> ast.dump(ast.parse('2 + 2')) 'Module(body=[Expr(value=BinOp(left=Num(n=2), op=Add(), right=Num(n=2)))])' Not perfect but much improved. There are two reasons why Python ASTs are richer than Lisp/Scheme ASTs. First, Python simply has a richer syntax and semantics. (Too rich IMO!) Second, Python ASTs contain extra annotations, like line information, which are indispensable for production-quality code transformation; I assume that production-quality Lisp parsers do the same thing one way or another. Honu does indeed have a lot of complexity, but I don't think that it's bad; I think that it's table stakes for offsides-indentation layouts. By merely having its primary goal as a goal, Honu must be complex.

mumblemumble 7y ago
> Python simply has a richer syntax and semantics. (Too rich IMO!) This is the core of the issue. If there were a Zen of Lisp, it might just be two lines extracted from the Zen of Python: Simple is better than complex. Complex is better than complicated. The reason why s-expressions are so great is because that simplicity makes metaprogramming manageable. I'm curious about how the new Racket syntax works out, but also mildly skeptical. . . I fear that a "lisp" where the ASTs don't look exactly like the text I see in the editor is a lisp that has had its soul amputated.
- ddragon 7y ago
  Indeed some of the lisp soul would be amputated in those languages, but that's usually done as a deliberate design and not as an unfortunate restriction. Sort-of-homoiconic languages (as in featuring a direct mapping between it's surface syntax and homoiconic representation, and support for manipulating the surface directly through quote/unquote) like Julia and Elixir (plus Nim, D, Rust, Scala and other languages with powerful macros) don't want macros to be your first thought when facing an issue, nor the second or third thought. In most Lisp your custom syntax is as first class as any standard syntax, which could lead to maintenance problems when every developer in the group could easily end up making his own poorly documented language to solve (even if perhaps optimally) a part of the problem. But in those other languages there is a first class way of doing something (a standard way of looping, standard way of conditional tests...), and macros are either discouraged or have to be annotated every time it's called to warn the user that the syntax ahead is not conventional. And macros are really there for the last resource when the surface syntax is really not expressive enough for the problem, and by then they'll be worth even when dealing with the AST in a much less convenient way.
- DonaldPShimoda 7y ago
  > I'm curious about how the new Racket syntax works out, but also mildly skeptical. . . I fear that a "lisp" where the ASTs don't look exactly like the text I see in the editor is a lisp that has had its soul amputated. FWIW I talked to Matthias Felleisen about this to some degree this past summer. I asked whether he felt homoiconicity is important, and he essentially said that no, it wasn't particularly important so long as whatever system you arrive at has a sufficiently well-considered design. (Though he couldn't/wouldn't tell me which aspects of syntax he felt are important to designing a metaprogramming system as complete as Racket's.) It's also worth noting that Racket's syntax is not changing. Matthew has said that he regrets calling his proposed project "Racket 2" because he never really intended it to subsume Racket, but rather to be a sister-project. The new name is Rhombus, and his proposed syntax uses what he calls "shrubbery notation" [0]. [0] https://github.com/mflatt/rhombus-brainstorming/blob/shrubbery/shrubbery/0000-shrubbery.md https://github.com/mflatt/rhombus-brainstorming/blob/shrubbe...

mumblemumble 7y ago

> Python simply has a richer syntax and semantics. (Too rich IMO!) This is the core of the issue. If there were a Zen of Lisp, it might just be two lines extracted from the Zen of Python: Simple is better than complex. Complex is better than complicated. The reason why s-expressions are so great is because that simplicity makes metaprogramming manageable. I'm curious about how the new Racket syntax works out, but also mildly skeptical. . . I fear that a "lisp" where the ASTs don't look exactly like the text I see in the editor is a lisp that has had its soul amputated.

ddragon 7y ago
Indeed some of the lisp soul would be amputated in those languages, but that's usually done as a deliberate design and not as an unfortunate restriction. Sort-of-homoiconic languages (as in featuring a direct mapping between it's surface syntax and homoiconic representation, and support for manipulating the surface directly through quote/unquote) like Julia and Elixir (plus Nim, D, Rust, Scala and other languages with powerful macros) don't want macros to be your first thought when facing an issue, nor the second or third thought. In most Lisp your custom syntax is as first class as any standard syntax, which could lead to maintenance problems when every developer in the group could easily end up making his own poorly documented language to solve (even if perhaps optimally) a part of the problem. But in those other languages there is a first class way of doing something (a standard way of looping, standard way of conditional tests...), and macros are either discouraged or have to be annotated every time it's called to warn the user that the syntax ahead is not conventional. And macros are really there for the last resource when the surface syntax is really not expressive enough for the problem, and by then they'll be worth even when dealing with the AST in a much less convenient way.
DonaldPShimoda 7y ago
> I'm curious about how the new Racket syntax works out, but also mildly skeptical. . . I fear that a "lisp" where the ASTs don't look exactly like the text I see in the editor is a lisp that has had its soul amputated. FWIW I talked to Matthias Felleisen about this to some degree this past summer. I asked whether he felt homoiconicity is important, and he essentially said that no, it wasn't particularly important so long as whatever system you arrive at has a sufficiently well-considered design. (Though he couldn't/wouldn't tell me which aspects of syntax he felt are important to designing a metaprogramming system as complete as Racket's.) It's also worth noting that Racket's syntax is not changing. Matthew has said that he regrets calling his proposed project "Racket 2" because he never really intended it to subsume Racket, but rather to be a sister-project. The new name is Rhombus, and his proposed syntax uses what he calls "shrubbery notation" [0]. [0] https://github.com/mflatt/rhombus-brainstorming/blob/shrubbery/shrubbery/0000-shrubbery.md https://github.com/mflatt/rhombus-brainstorming/blob/shrubbe...