9 ms·

Honu: Syntactic Extension for Algebraic Notation (2012) [pdf]

71 points by pcr910303 7y ago

jhvkjhk 7y ago
It looks like javascript syntax.
- classified 7y ago
  And a Lamborghini looks like a soapbox cart.
  - dang 7y ago
    Could you please stop posting unsubstantive comments to Hacker News? You've been doing it quite a bit and we're trying for something a bit better than that here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- pacaro 7y ago
  This is a reasonable observation, JavaScript uses a syntax derived from Algol, via C, with some language features derived from Scheme. I understand some of the upthread scepticism of the role that this may play in racket moving forward, but while people may have reservations about some of the Wut features in JavaScript, it has undeniably been a very successful language
  - masukomi 7y ago
    it's been a successful language because the web is effing amazing and it's literally your only choice if you want any functionality in a web page. If the original Scheme-like plan for JS had of been used then you'd be saying exactly the same thing about a Scheme. JS didn't succeed because it was "good" in _any_ way. It succeeded because it was not horrendous and it was/is _the only choice_.
    - pacaro 7y ago
      I mostly agree with you. I think however that it was "the only choice" because it was good enough. It's worth remembering that there was a non trivial time period in which there was a single dominant browser platform which supported alternatives: VBScript was supported through IE10, and is still available in IE11; ActiveX could be used to allow just about any scripting language. Even now it's fairly straightforward to have JavaScript be the output of a toolchain, but not necessarily the input
classified 7y ago
After seeing this, I know why I prefer Lisp with its conventional non-syntax over this mess.
- ken 7y ago
  You're not the first. Peter Norvig wrote: > Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this: >>> parse("2 + 2") ['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison', ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term', ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor', ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']] > This was rather a disapointment to me. The Lisp parse of the equivalent expression is (+ 2 2). It seems that only a real expert would want to manipulate Python parse trees, whereas Lisp parse trees are simple for anyone to use. Honu appears to have a ton of complexity just to be able to support writing "a+b". [1]: https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
  - lidHanteyk 7y ago
    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.
AriaMinaei 7y ago
Haven’t taken a deep look, but the first examples look surprisingly clean.
saagarjha 7y ago
Related (by not mentioned?): https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression
- wtetzner 7y ago
  It's not mentioned because the paper isn't actually about Lisp with Algol Syntax. It's about how to add syntax-case to a language with Algol Syntax.
dwheeler 7y ago
If you're interested, I suggest looking at "readable Lisp". Details here: https://readable.sourceforge.io/ https://readable.sourceforge.io/
- masukomi 7y ago
  i think you may have just broken sourceforge with this link... > SourceForge project websites are currently experiencing abnormally high levels of traffic. Our support staff has been notified. Please check back in a few minutes. We thank you for your patience.
smabie 7y ago
Fortunately or unfortunately, it seems like Racket is going to move to this new syntax, as Matthew Flatt is a core contributor to Racket. I’ll hold judgment until I see it, but I’m skeptical, to say the least.
- masukomi 7y ago
  got any links about this? I'm not sure what the right search incantation is. Too much talk in Racket about new / experimental syntax. ;)
  - smabie 7y ago
    https://beautifulracket.com/appendix/thoughts-on-rhombus.html https://beautifulracket.com/appendix/thoughts-on-rhombus.htm...
knubie 7y ago
After using Clojure for awhile, I think the only syntax I would prefer it is Ruby’s.
- spdegabrielle 7y ago
  Smalltalk?
pgtan 7y ago
LOGO is already Lisp without parentheses and with infix notation. Recently, doing exercises in LOGO with my kid,he asked: can we put some parentheses around the functions for better clearness? I said: my son, you just discovered Lisp!
- wtetzner 7y ago
  Honu's real trick is supporting Racket's syntax-case in an infix syntax.
  - drcode 7y ago
    I like the folks involved with Honu and new language initiatives are always great, but to me this reads as "Honu's real trick is supporting something I don't want, using something I don't want"
    - wtetzner 7y ago
      Well, given that it's meant to be language research, I think there's a ton of value in it. We already have a bunch of popular existing languages with infix syntax, and Honu shows how a powerful hygienic macro system can be applied to those. You may not want a powerful macro system in those languages, but I personally think it would far preferable to the existing mess of annotations and build-system hacks to generate code.
  - soegaard 7y ago
    This needs an upvote.
- Rerarom 7y ago
  Lisp parentheses are not just for grouping. In Lisp, x is not the same as (x). That confused me a lot at first because it's rarely explicitly stated.
  - milhnl 7y ago
    Can you elaborate or maybe link to a resource that explains this? This seems to be missing piece of the puzzle for me.
pmoriarty 7y ago
As a lover of Lisp, I find these sorts of initiatives really depressing and frustrating. They seem to come up over and over again, where someone has the bright idea to make Lisp less Lisp-like, often by getting rid of all the parenthesis and making the language more Algol-like. But parenthesis are, for me, one of the greatest things about Lisp. They make understanding, reasoning about, editing, and manipulating the code really easy, and add a consistency to the language which I really appreciate when compared to mismash of arbitrary, inconsistent delimiters in other languages. This leads me to adopt a "you'll have to pry my parenthesis from my cold, dead fingers" attitude when I see suggestions like these. Please, just keep Lisp Lisp.
- pjmlp 7y ago
  Dunno, I feel that both Dylan and Julia are somehow good enough approaches. Dylan failed because Apple losed interest, if they had Swift like motivation back then, it might have turned out differently. Julia, lets see how it goes.
  - ken 7y ago
    This sounds like an admission that the only way a programming language survives is when a corporation decides we should use it. Given what I’ve seen in the past 25 years, I’m not sure you’re wrong.
    - taeric 7y ago
      I think I repeat basically this every time the topic comes up. Marketing works to build a market for products, but is expensive. Yes, there are grass roots marketing that gets some languages adopted. They seem to be the exceptions proving the rule. So much of the technical chase for getting a successful language feels jarring compared to the momentum of languages that are succeeding.
    - pjmlp 7y ago
      Because programming languages are just software products like anything else, where the customer base are the developers. So you need an use case to keep your product on the market (programming language). Corporations are the ones with deep enough pockets to push those use cases, even if initally they don't caught on. For example, if Dart was a FOSS project it would have died by now, instead Google can keep throwing money at Flutter until Dart actually picks up.
zozbot234 7y ago
How does this compare to Scheme sweet-expressions https://srfi.schemers.org/srfi-110/ https://srfi.schemers.org/srfi-110/ and curly-infix https://srfi.schemers.org/srfi-105/ https://srfi.schemers.org/srfi-105/ ?
gliese1337 7y ago
This reminds me rather a lot of Magpie: https://journal.stuffwithstuff.com/2011/02/13/extending-syntax-from-within-a-language/ https://journal.stuffwithstuff.com/2011/02/13/extending-synt...

71 points by pcr910303 7y ago

jhvkjhk 7y ago

It looks like javascript syntax.

classified 7y ago
And a Lamborghini looks like a soapbox cart.
- dang 7y ago
  Could you please stop posting unsubstantive comments to Hacker News? You've been doing it quite a bit and we're trying for something a bit better than that here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
pacaro 7y ago
This is a reasonable observation, JavaScript uses a syntax derived from Algol, via C, with some language features derived from Scheme. I understand some of the upthread scepticism of the role that this may play in racket moving forward, but while people may have reservations about some of the Wut features in JavaScript, it has undeniably been a very successful language
- masukomi 7y ago
  it's been a successful language because the web is effing amazing and it's literally your only choice if you want any functionality in a web page. If the original Scheme-like plan for JS had of been used then you'd be saying exactly the same thing about a Scheme. JS didn't succeed because it was "good" in _any_ way. It succeeded because it was not horrendous and it was/is _the only choice_.
  - pacaro 7y ago
    I mostly agree with you. I think however that it was "the only choice" because it was good enough. It's worth remembering that there was a non trivial time period in which there was a single dominant browser platform which supported alternatives: VBScript was supported through IE10, and is still available in IE11; ActiveX could be used to allow just about any scripting language. Even now it's fairly straightforward to have JavaScript be the output of a toolchain, but not necessarily the input

classified 7y ago

After seeing this, I know why I prefer Lisp with its conventional non-syntax over this mess.

ken 7y ago
You're not the first. Peter Norvig wrote: > Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this: >>> parse("2 + 2") ['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison', ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term', ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor', ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']] > This was rather a disapointment to me. The Lisp parse of the equivalent expression is (+ 2 2). It seems that only a real expert would want to manipulate Python parse trees, whereas Lisp parse trees are simple for anyone to use. Honu appears to have a ton of complexity just to be able to support writing "a+b". [1]: https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
- lidHanteyk 7y ago
  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.

AriaMinaei 7y ago

Haven’t taken a deep look, but the first examples look surprisingly clean.

saagarjha 7y ago

Related (by not mentioned?): https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression

wtetzner 7y ago
It's not mentioned because the paper isn't actually about Lisp with Algol Syntax. It's about how to add syntax-case to a language with Algol Syntax.

dwheeler 7y ago

If you're interested, I suggest looking at "readable Lisp". Details here: https://readable.sourceforge.io/ https://readable.sourceforge.io/

masukomi 7y ago
i think you may have just broken sourceforge with this link... > SourceForge project websites are currently experiencing abnormally high levels of traffic. Our support staff has been notified. Please check back in a few minutes. We thank you for your patience.

smabie 7y ago

Fortunately or unfortunately, it seems like Racket is going to move to this new syntax, as Matthew Flatt is a core contributor to Racket. I’ll hold judgment until I see it, but I’m skeptical, to say the least.

masukomi 7y ago
got any links about this? I'm not sure what the right search incantation is. Too much talk in Racket about new / experimental syntax. ;)
- smabie 7y ago
  https://beautifulracket.com/appendix/thoughts-on-rhombus.html https://beautifulracket.com/appendix/thoughts-on-rhombus.htm...

knubie 7y ago

After using Clojure for awhile, I think the only syntax I would prefer it is Ruby’s.

spdegabrielle 7y ago
Smalltalk?

pgtan 7y ago

LOGO is already Lisp without parentheses and with infix notation. Recently, doing exercises in LOGO with my kid,he asked: can we put some parentheses around the functions for better clearness? I said: my son, you just discovered Lisp!

wtetzner 7y ago
Honu's real trick is supporting Racket's syntax-case in an infix syntax.
- drcode 7y ago
  I like the folks involved with Honu and new language initiatives are always great, but to me this reads as "Honu's real trick is supporting something I don't want, using something I don't want"
  - wtetzner 7y ago
    Well, given that it's meant to be language research, I think there's a ton of value in it. We already have a bunch of popular existing languages with infix syntax, and Honu shows how a powerful hygienic macro system can be applied to those. You may not want a powerful macro system in those languages, but I personally think it would far preferable to the existing mess of annotations and build-system hacks to generate code.
- soegaard 7y ago
  This needs an upvote.
Rerarom 7y ago
Lisp parentheses are not just for grouping. In Lisp, x is not the same as (x). That confused me a lot at first because it's rarely explicitly stated.
- milhnl 7y ago
  Can you elaborate or maybe link to a resource that explains this? This seems to be missing piece of the puzzle for me.

pmoriarty 7y ago

As a lover of Lisp, I find these sorts of initiatives really depressing and frustrating. They seem to come up over and over again, where someone has the bright idea to make Lisp less Lisp-like, often by getting rid of all the parenthesis and making the language more Algol-like. But parenthesis are, for me, one of the greatest things about Lisp. They make understanding, reasoning about, editing, and manipulating the code really easy, and add a consistency to the language which I really appreciate when compared to mismash of arbitrary, inconsistent delimiters in other languages. This leads me to adopt a "you'll have to pry my parenthesis from my cold, dead fingers" attitude when I see suggestions like these. Please, just keep Lisp Lisp.

pjmlp 7y ago
Dunno, I feel that both Dylan and Julia are somehow good enough approaches. Dylan failed because Apple losed interest, if they had Swift like motivation back then, it might have turned out differently. Julia, lets see how it goes.
- ken 7y ago
  This sounds like an admission that the only way a programming language survives is when a corporation decides we should use it. Given what I’ve seen in the past 25 years, I’m not sure you’re wrong.
  - taeric 7y ago
    I think I repeat basically this every time the topic comes up. Marketing works to build a market for products, but is expensive. Yes, there are grass roots marketing that gets some languages adopted. They seem to be the exceptions proving the rule. So much of the technical chase for getting a successful language feels jarring compared to the momentum of languages that are succeeding.
  - pjmlp 7y ago
    Because programming languages are just software products like anything else, where the customer base are the developers. So you need an use case to keep your product on the market (programming language). Corporations are the ones with deep enough pockets to push those use cases, even if initally they don't caught on. For example, if Dart was a FOSS project it would have died by now, instead Google can keep throwing money at Flutter until Dart actually picks up.

zozbot234 7y ago

How does this compare to Scheme sweet-expressions https://srfi.schemers.org/srfi-110/ https://srfi.schemers.org/srfi-110/ and curly-infix https://srfi.schemers.org/srfi-105/ https://srfi.schemers.org/srfi-105/ ?

gliese1337 7y ago

This reminds me rather a lot of Magpie: https://journal.stuffwithstuff.com/2011/02/13/extending-syntax-from-within-a-language/ https://journal.stuffwithstuff.com/2011/02/13/extending-synt...