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

https://www.cs.utah.edu/plt/publications/gpce12-rf.pdf

by goranmoomin • 7 years ago

71 61 7 years ago

cs.utah.edu

jhvkjhk• 7 years ago

It looks like javascript syntax.

classified2• 7 years ago

And a Lamborghini looks like a soapbox cart.

dang2• 7 years 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

pacaro2• 7 years 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

masukomi3• 7 years 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_.

classified2• 7 years ago

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

ken2• 7 years 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

lidHanteyk• 7 years 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.

AriaMinaei• 7 years ago

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

saagarjha• 7 years ago

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

wtetzner4• 7 years 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• 7 years ago

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

masukomi3• 7 years 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.

smabie2• 7 years 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.

masukomi3• 7 years 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. ;)

smabie2• 7 years ago

https://beautifulracket.com/appendix/thoughts-on-rhombus.htm...

knubie• 7 years ago

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

spdegabrielle• 7 years ago

Smalltalk?

pgtan2• 7 years 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!

wtetzner4• 7 years ago

Honu's real trick is supporting Racket's syntax-case in an infix syntax.

drcode• 7 years 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"

soegaard• 7 years ago

This needs an upvote.

Rerarom• 7 years 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.

milhnl2• 7 years ago

Can you elaborate or maybe link to a resource that explains this? This seems to be missing piece of the puzzle for me.

pgtan2• 7 years ago

Yes, LOGO already has all the list evaluating like the real Lisp.

? run `[print ,[sum 2 3]]

But also a very sophisticated way to define functions with many default and within even optional parameters without the need of parentheses. From UCBLogo info:

This version of Logo allows variable numbers of inputs to a procedure. After the procedure name come four kinds of things, in this order:

            1.   0 or more REQUIRED inputs    :FOO :FROBOZZ                                    

            2.   0 or more OPTIONAL inputs    [:BAZ 87] [:THINGO 5+9]                          

            3.   0 or 1 REST input            [:GARPLY]                                        

            4.   0 or 1 DEFAULT number        5

pmoriarty• 7 years 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.

pjmlp2• 7 years 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.

ken2• 7 years 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.

Riverheart• 7 years ago

I don't think people already on the lisp boat are the target audience of these things.

cuspycode• 7 years ago

Agreed. And the phenomenon is not exactly new. I played around with CGOL about 35 years ago, and although I was already a fan of s-expression syntax, I still thought CGOL was great for certain applications. It's cool to see Vaughan Pratt (who designed CGOL in 1973) in the bibliography of this article.

S-expression syntax seems to be very divisive. Every time I have introduced that syntax into various projects (since it's such an easy and clear solution for domain-specific languages) for the past couple of decades, I have met resistance because so many people are repelled by all those parentheses.

wtetzner4• 7 years ago

The title of the Hacker News post ("Honu: Lisp with Algol Syntax") is misleading. The real title of the paper is "Honu: Syntactic Extension for Algebraic Notation through Enforestation". It's a paper showing how to implement syntax-case in a language with infix notation.

dang2• 7 years ago

We've changed the title from "Honu: Lisp with Algol Syntax", in accordance with the site guidelines.

https://news.ycombinator.com/newsguidelines.html

hencq• 7 years ago

I would agree, I love the structure s-expressions bring, especially using smartparens in Emacs. At the same time I really enjoy some of the deviations from pure s-expressions that Clojure has made (like hash literals, using vectors for function arguments, using position instead of parentheses in binding forms). This suggests to me that there might be a sweet spot between Algol and s-expressions.

I'm quite interested to see where the whole Racket 2 thing goes in that regard. For example, the examples here all look quite clean to me: https://github.com/mflatt/rhombus-brainstorming/blob/shrubbe...

tombert• 7 years ago

I feel like Clojure's deviation from S expression still somewhat follows the spirit of Lisp at least; the first-class hashes and vectors still correspond to native data structures and as a result, the syntax reflects that. In some ways, I feel like Clojure's embrace of this almost follows the Lisp formula better than something like, for example, Chicken Scheme, which by default does scheme-style hashes that don't correspond directly to syntax.

jlarocco• 7 years ago

I've also grown to love s-expressions, but even Common Lisp deviates from pure s-expressions in places ( #( ... ) array syntax, for example), and the mechanism is customizable via reader macros.

Some examples:

https://gist.github.com/chaitanyagupta/9324402

https://lisp-lang.org/wiki/article/reader-macros

yiyus• 7 years ago

They may be depressing and frustrating, but I think they are necessary. They answer a "what-if" that most people learning Lisp will ask themselves at some point.

Eg: I was never into the Lisp usage of parents until I saw some of the alternatives (I still prefer M-expressions though, but that's just personal taste).

jonathanstrange• 7 years ago

The funny thing is that I'd even prefer s-expressions for a "static" language with tons of compile-time zero-cost abstractions. Having to remember less syntax allows me to focus on the semantics, which is what matters to me.

brudgers• 7 years ago

Co-author Mathew Flatt is part of Racket's core team. Racket is a language development platform. Honu is written in Racket.

https://github.com/racket/honu/tree/master

Honu isn't a Lisp replacement. It's an academic research product.

nikofeyn• 7 years ago

i think it's more than just an academic research product. all of these efforts and more are the core racket team looking into replacing racket's syntax, in particular its parenthetical syntax. they have explicitly stated that they want to and will do so.

so honu isn't a lisp replacement, but it is one evolution and inspiration for getting rid of the lispy syntax of racket.

xj92• 7 years ago

you don't remember M-expressions?

S-expressions were originally intended only for data to be manipulated by M-expressions, but the first implementation of Lisp was an interpreter of S-expression encodings of M-expressions, and Lisp programmers soon became accustomed to using S-expressions for both code and data.

— https://en.wikipedia.org/wiki/S-expression#Use_in_Lisp

now, i won't say that i don't enjoy S-expressions, because i do. i do think there is some value in creating ..less intimidating front-ends to lisp-fam languages. one of the things that i love about racket is their focus on alternative syntax. i love that. everyone knows that lisp is capable of creating new syntax, but most of the time that ability is not used to its fullest extent. some standardization is needed, but it would be really cool to have a way to create compilers for arbitrary languages using advanced syntax macros. especially if the lisp representation is callable from other lisp programs AND other languages. JVM and BEAM have this, why not lisp?

personally i'm very interested in creating an elm compiler using chicken scheme. it is a little bit outside of the C-like comfort zone, but it is made to be very beginner friendly which i appreciate.

setholopolus• 7 years ago

it would be really cool to have a way to create compilers for arbitrary languages using advanced syntax macros. especially if the lisp representation is callable from other lisp programs AND other languages

You are perfectly describing Racket here.

zozbot234• 7 years ago

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

gliese1337• 7 years ago

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

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

Related Stories