
Honu: Syntactic Extension for Algebraic Notation (2012) [pdf] - pcr910303
https://www.cs.utah.edu/plt/publications/gpce12-rf.pdf
======
pmoriarty
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.

~~~
hencq
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...](https://github.com/mflatt/rhombus-
brainstorming/blob/shrubbery/shrubbery/0000-shrubbery.md)

~~~
tombert
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.

------
zozbot234
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/) ?

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

~~~
ken
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
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
> 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.

~~~
DonaldPShimoda
> 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/shrubbe...](https://github.com/mflatt/rhombus-
brainstorming/blob/shrubbery/shrubbery/0000-shrubbery.md)

------
dwheeler
If you're interested, I suggest looking at "readable Lisp". Details here:
[https://readable.sourceforge.io/](https://readable.sourceforge.io/)

~~~
masukomi
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
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
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
[https://beautifulracket.com/appendix/thoughts-on-
rhombus.htm...](https://beautifulracket.com/appendix/thoughts-on-rhombus.html)

------
pgtan
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!

~~~
Rerarom
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
Can you elaborate or maybe link to a resource that explains this? This seems
to be missing piece of the puzzle for me.

~~~
nickloewen
When you put parentheses around an atom, lisp sees that as a function call.

Say `x` is a function which adds one to a number.

Say `y` is an atom which is not a function—perhaps a list: `(list 1 2 3)`.

If you write just `x`, no parens, you point to the function without executing
it. If you do this at your interpreter it will tell you that the value of `x`
is “function something something.”

This is important because it’s what makes it possible to pass functions as
arguments, and write things like `(map x y)`. Here `x` is not evaluated in
place; it’s called later by the `map` function, once for each element of the
list, resulting in `(list 2 3 4)`.

Now if you put parentheses around `x`, lisp will try to execute it on the
spot. `(x 1)` is what other languages would call `x(1)`, and will return `2`.

You have to be a little careful about this because it means that if you put
parens around `y`, which isn’t a function, you’ll get an error. This is why
lisp has the ‘quote’ operator, which means “take the next atom as literal data
and don’t try to execute it.” So `(quote (1 2 3))` will return `(1 2 3)`. This
can also be written `’(1 2 3)`—which is nice, because this is effectively
equivalent to `(list 1 2 3)`, and could have saved me some typing when I
defined `y` earlier.

e: typo ; also, sorry for the ugly syntax, I forgot there was no inline code
formatting on HN

~~~
dreamcompiler
Hold up. X in the above is a symbol. Symbols _may_ be bound to a function or
they may not. But x here is always a symbol.

When you write (x) in the Lisp REPL, Lisp will assume you intend to call a
function bound to x because x appears first in the list. If you instead wrote
(y x), Lisp would never assume x was a function. If the first thing in a list
is _not_ bound to a function, Lisp will throw an error.

When you write '(x) [note leading quotation mark], Lisp will simply construct
a list that contains the symbol x as its only element.

In my explanation above, I didn't make the distinction about the quotation
mark because I assumed the questioner was asking about data structures. Lisp
will print "the list containing x" without the quotation mark. But if that's
what you mean when you type it, you have to explicitly type the quotation
mark.

~~~
nickloewen
Yes, this is a good clarification!

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

~~~
spdegabrielle
Smalltalk?

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

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

~~~
wtetzner
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.

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

------
jhvkjhk
It looks like javascript syntax.

~~~
pacaro
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
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
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

