Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sweet-expressions: A readable format for Lisp-like languages

dwheeler.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Sweet-expressions: A readable format for Lisp-like languages

#71

Post by gruseom »

yason wrote: post #50

The new and "readable" syntax looks truly ugly compared to the S-expression counterparts. Why is it that some people dread parentheses so badly and other people just never mind and choose to spend the time working with them? The main reason I consider parentheses and S-expressions superior to other syntax is that it allows for flexible navigation in the source code. I can move forward and backward, upward and inward…

Why is it that some people dread parentheses so badly

Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together: 1. the human brain craves familiarity; 2. people love bike sheds.

(Bike shed = something anybody can have an opinion and argue about irrespective of knowledge or effort. Since their purpose is to jump into the argument, these opinions tend to be strong ones, diminishing the likelihood of any resolution. Indeed, a feature of such discussions is that they are argument for argument's sake, and thus no resolution is possible or even desirable.)

Re: Sweet-expressions: A readable format for Lisp-like languages

#72

Post by silentbicycle »

zephyrfalcon wrote: post #67
silentbicycle wrote: post #38

Earlier quoted context omitted.

Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird. My personal preference is infix without operator precedence (like APL and Smalltalk) or postfix (like Forth). All-prefix, all-postfix, or all-infix consistently make sense. Infix with arbitrary transposition due to historical "order of operation" doesn't, but it's the common convention, and minor changes to it (e.g. +. for floa…

"Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird." But that is just because you learned the conventional notation from a very young age, right? We all did, hence the name "conventional". When we learned to add and subtract, we also learned that the notation was 2+3, not (+ 2 3). That's why any other notation feels "unnatural". I do wonder if it would be possible to teach kids…

I learned arithmetic at a young age, yes (and I taught myself BASIC when I was 5-6ish). My main objection to prefix notation for arithmetic is that it's cumbersome. Mostly because if the arity of ops aren't predefined (e.g., + isn't limited to 2 arguments), parenthesis are needed for grouping.

Infix, w/ order of op:

    y^2*(6x^3 - 3x^2 + 2x - 9)
Prefix:

    (* (^ y 2) (+ (* 6 (^ x 3)) (* -3 (^ x 2)) (* 2 x) -9))
Infix, no order of op:

    y^2*((6* x^3) - (3* x^2) + (2* x) - 9)
But as long as we're talking polynomials, J wins, IMHO:

    (y^2)*+/_9 2 _3 6*(x^i.4)

Re: Sweet-expressions: A readable format for Lisp-like languages

#73

Post by waterhouse »

zephyrfalcon wrote: post #67
silentbicycle wrote: post #38

Earlier quoted context omitted.

Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird. My personal preference is infix without operator precedence (like APL and Smalltalk) or postfix (like Forth). All-prefix, all-postfix, or all-infix consistently make sense. Infix with arbitrary transposition due to historical "order of operation" doesn't, but it's the common convention, and minor changes to it (e.g. +. for floa…

"Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird." But that is just because you learned the conventional notation from a very young age, right? We all did, hence the name "conventional". When we learned to add and subtract, we also learned that the notation was 2+3, not (+ 2 3). That's why any other notation feels "unnatural". I do wonder if it would be possible to teach kids…

That is an interesting question. I see one possible argument (whose correctness I don't know enough to judge, I'm just making it up) why infix is more natural than prefix: A kid will start by seeing an object, and only once you have an object does it make sense to combine it (by addition or whatever) with another object. Also, note that a certain amount of English syntax is infix: "I went to the store", not "Went to I the store".

...However, I think that in some other languages, postfix notation is common. I think my friend who studies Spanish told me that they say the equivalent of "I her it gave" (meaning "I gave it to her"), and I think I remember Shakespearean English using postfix. ...Looking at the text of Romeo and Juliet, I see both prefix and postfix.

  Prefix: "O, where is Romeo? saw you him to-day?"
  Postfix: "The which if you with patient ears attend"
On the one hand, we could say that, since these plays were apparently rather successful, people obviously didn't have too much trouble understanding them. On the other hand, since this sort of strange permutation has been mostly dropped from common usage (so that I recognize it as strange), that may be evidence that these things are just harder to use. On the other hand, that could just be because "common usage" comes mostly from people who have been educated in schools, and schools have no reason to teach more than one method of speaking. On the other hand, Shakespeare seems only to have done that in order to make lines fit into rhyming iambic pentameter; in no way was this natural to him.

I should probably note that a lot of speech deals with object method calls more than function calls ("I.saw(Bob.win(a_game))" or, as it would probably be expressed in Arc, "(I!saw (Bob!win a-game))"; function call would be like (saw I (win Bob a-game))). And adjectives and adverbs act kind of like keyword arguments: (I!drove :to (the store) :[qualifier] fast). From that perspective, the distinction might be "object method calls" vs "function calls", rather than "infix" vs "prefix".

Does someone who knows more than I about other human languages (or English, for that matter) know about the prevalence of postfix notation (and prefix, if it so happens)?

Re: Sweet-expressions: A readable format for Lisp-like languages

#74

Post by silentbicycle »

waterhouse wrote: post #73
zephyrfalcon wrote: post #67

Earlier quoted context omitted.

"Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird." But that is just because you learned the conventional notation from a very young age, right? We all did, hence the name "conventional". When we learned to add and subtract, we also learned that the notation was 2+3, not (+ 2 3). That's why any other notation feels "unnatural". I do wonder if it would be possible to teach kids…

That is an interesting question. I see one possible argument (whose correctness I don't know enough to judge, I'm just making it up) why infix is more natural than prefix: A kid will start by seeing an object, and only once you have an object does it make sense to combine it (by addition or whatever) with another object. Also, note that a certain amount of English syntax is infix: "I went to the store", not "Went to…

Turkish and Japanese both typically end sentences with verbs, IIRC. There are probably several others; I really should just buy a copy of Comrie's _The World's Major Languages_ already.

In German (which I'm at least a little familiar with, unlike those two), auxiliary verbs stack at the end of the sentence: "I have eaten my breakfast." -> "Ich habe mein Frühstück gegessen." (lit. "I have my breakfast eaten.") It's unusual to have more than a couple, though - human languages typically don't nest very deeply.

OTOH, comparing natural languages and programming languages may not be that useful - programming language design places a high priority on avoiding ambiguity, while natural languages assume have quite a bit of it. It may be better to consider programming languages as a kind of notation for math, logic, rules, instructions, declarations, etc. Kenneth Iverson had some interesting ideas about that.

Another issue with method calls is that many things don't have a clear primary actor. In single-dispatch OOP languages, this turns into ugly workarounds (e.g. the Visitor pattern), "who owns this method?" debates, and tedious rewriting. Multimethods avoid that issue entirely.

Re: Sweet-expressions: A readable format for Lisp-like languages

#75

Post by sedachv »

derefr wrote: post #32
sedachv wrote: post #26

Earlier quoted context omitted.

"Also, you wouldn't be comparing, say, Java to APL. You'd be comparing Java to Java + "an unless statement", or APL to APL + "enforced whitespace." You want to see the relative worth of language features, not the relative worth of our current languages, which have mostly been slapped together with no concern for UX. The result of such a study would be a set of UX suggestions, of language features that comparatively i…

You ignored the most important part of what I said. > Thus, if the test-taker doesn't know English, they get the same (low) score on both tests—to the BNN, that is the same as "no new evidence." So, of course, you wouldn't test APL vs. APL+whitespace on someone who doesn't know APL, because your test results would always, predictably, be 1:1. But you wouldn't be testing APL vs. anything—because APL is a set of design…

"a random combination of language features that has no overarching design principle which users could recognize to reduce cognitive load"

Thank you for walking right into my trap.

The reason I like to use APL in arguments about programming language syntax/semantics is that it's "unusual" compared to Algol-derived languages in more than just the syntax.

Matlab/Octave are also array programming languages that in fact are very similar to APL despite having a C-like syntax. It does not make it any easier for people to figure out what Matlab programs do if they don't understand array programming. (And if you don't know linear algebra, then in practice you can't understand most typical Matlab programs at all).

You're implicitly assuming that all programming languages have similar imperative/algorithmic interpretations and differ by syntax. This is a result of a very fundamental epistemological error.

There is no such thing as "programming" that people understand. All programming languages are related to (derived from, or applied to) other domains of knowledge.

If you ignore this fact all the conclusions that you will come to will either apply only to your implicitly assumed domain (which may not fit any problems that people actually want to solve) or will be incoherent.

Re: Sweet-expressions: A readable format for Lisp-like languages

#76

Post by sedachv »

python_padawan wrote: post #22
Zak wrote: post #3

Somebody has invented a more conventional-looking syntax for Lisp every couple years since John McCarthy first suggested M-expressions. Nobody[0] has ever cared enough to use any of them. People who "get" Lisp get over any aversion to the syntax, and usually even come to appreciate it. People who can't get over the syntax never actually get Lisp. [0] For large values of nobody

"Well, all true Scotsmen like haggis." Or, for those who cannot draw the correlation: "Well, all true Lispers like parentheses." Never mind that pure functional programming is an ideal that even Lisp does not live up to. Think I'm throwing B.S. around? Try doing I/O in Lisp without side-effects. Now that we've established that Lisp is not at the top of the blub-curve, maybe we can get on with: 1. Writing functional l…

"What we need is someone who truly groks multiprocessor, multi-threaded, heterogeneous run-time environments; and from that knowledge can write a language to take advantage of such an environment."

Please Google: Starlisp, Paralations, NESL, Multilisp, Qlisp, Actors (ACT 1, ABCL), Termite, Kali

There have been only two (tuplespaces and STM) parallel programming paradigms that have not been pioneered by people who can be considered "Lispers."

Re: Sweet-expressions: A readable format for Lisp-like languages

#77

Post by sedachv »

loup-vaillant wrote: post #56
Zak wrote: post #3

Somebody has invented a more conventional-looking syntax for Lisp every couple years since John McCarthy first suggested M-expressions. Nobody[0] has ever cared enough to use any of them. People who "get" Lisp get over any aversion to the syntax, and usually even come to appreciate it. People who can't get over the syntax never actually get Lisp. [0] For large values of nobody

People who actually get Lisp understand that S-expressions and surface syntax⁰ are orthogonal. "Ubiquitous parentheses" are one way to represent them. Sweet expressions are another. There is zero Lisper on this planet that think about "Ubiquitous parentheses" as the best possible syntax. Not even the seemingly fanatics of Lisp's "regular syntax". Proof: no one in her right mind (not even you) would prefer (quote X),…

"Now why stop there? You could try and remove more parentheses by using a tab syntax, or introduce a few other irregularities, or both. There's a good chance that we could come up with something better than the currently widely accepted surface syntax."

The constraint is that the grammar of the resulting syntax has to be capable of expressing everything expressable by S-expressions, has to be unambiguous, and it has to be pretty-printable back into a canonical form. The last point itself is pretty hard to do, but if you actually look at the grammars of a lot of programming languages, very few of them aren't ambiguous!

Re: Sweet-expressions: A readable format for Lisp-like languages

#78

Post by sedachv »

silentbicycle wrote: post #66
sedachv wrote: post #18

I've worked with programs in half a dozen Lisp dialects and everyone who claims Lisp is hard to understand because of the syntax is wrong. The only reason I could work with so many dialects and so many programs is because the syntax is uniform. If you think you have an idea for how to "improve" Lisp syntax that involves an ambiguous infix grammar, please stop trolling and go write some Python.

Some people seem to have a hard time with deeply nesting languages. Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". I'm fine with heavily nested Lisp-y code, but chaining code feels very awkward to me. Self and Prolog both have well-designed, completely unambiguous grammars. People interested in syntax design (or "fixing" Lisp) would do well to loo…

"Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". "

The thing with fluent interfaces is they're identical to nested Lisp code, except they read left to right instead of right to left. I suspect writers of Hebrew and Arabic would find chaining to be more confusing than nested Lisp code for that reason.

Also worth noting is that a popular style of indenting chained fluent calls is by splitting them by lines, like:

  someObj.method(arg)
         .otherMethod(arg2)
         .om3(a4)
         .om4(a5);
That's not that different from formatting Lisp code.

Re: Sweet-expressions: A readable format for Lisp-like languages

#79

Post by bitwize »

"Ugly" s-expressions?

I find them to be quite beautiful, like matryoshka dolls. I am a bit disappointed when I have to work on code that doesn't manifest its own structure so explicity, looking like a tangle of words and punctuation down the page, like what becomes of balls of yarn after a kitten has gotten through with them.

Re: Sweet-expressions: A readable format for Lisp-like languages

#80

Post by evanrmurphy »

gruseom wrote: post #71
yason wrote: post #50

The new and "readable" syntax looks truly ugly compared to the S-expression counterparts. Why is it that some people dread parentheses so badly and other people just never mind and choose to spend the time working with them? The main reason I consider parentheses and S-expressions superior to other syntax is that it allows for flexible navigation in the source code. I can move forward and backward, upward and inward…

Why is it that some people dread parentheses so badly Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together: 1. the human brain craves familiarity; 2. people love bike sheds. (Bike shed = something anybody can have an opinion and argue about irrespective of knowledge or effort. Since their purpose is to jump into the argument, these opinions ten…

> Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together

Parentheses (and along with them s-expressions and macros) are one of the few characteristics still unique to Lisp. Most of the other features - including GC, dynamic typing, first-class functions and lexical scoping - are now shared with other programming languages as well.

Post reply on HN