Lispy vs. Pseudo-English Syntax (1984) | Hacker News Reader

Lispy vs. Pseudo-English Syntax (1984)

ml.cddddr.org

26 pointsdjha-skin16 comments

Five years after this, the Lisp iterate package [1] was published. Some find it to be an excellent compromise, having readable pseudo-English syntax which is also Lispy and being, as a result, easily extensible.

It still has a few rough edges but I've never found one I couldn't work around.

[1] https://iterate.common-lisp.dev/

I had no idea iterate was so old; I think I was using lisp for over a decade (having started around the turn of the millennium) before I ever stumbled upon it.

The reductive take on why LOOP is liked in this post really speaks to the ability of LISP crowds to eat themselves. Holy crap at the amount of condescension that can be felt. To quote, "It seems to me that the principal advantages of the LOOP syntax are that some people are used to it already and that some small number of people think that it is cute."

Cute? I think it is rather expressive and does a good job fencing off areas of the code that are likely to be expensive. Is it required? Of course not, but the downsides listed in this post are... no different than claiming something as "cute."

I can almost buy that reading non-LOOP is faster. The problem, of course, is that for a lot of places reading the LOOP /should/ be done slower. That or taken as a bit of a given in the larger code.

This is one of the things I loved about the FORMAT macro. Quoting https://gigamonkeys.com/book/a-few-format-recipes.html, "[moving to expressions] is not too bad, but anyone reading this code has to mentally parse it just to figure out that all it's doing is printing the contents of list to standard output. On the other hand, you can tell at a glance that the following expression is printing list, in some form, to standard output"

That is, yes, it can take more effort to figure out what the loop is doing. But often that is something that is going to take more effort anyway.

So, rather than build on familiarity of some in the crowd; the new folks shoulder their way to the table and tell everyone that what they are familiar with is bad. And they should feel childish for liking cute things... Congrats for killing your crowd.

timonoko|3 years ago|parent|on: Lisp and Haskell (2015)

Common Lisp could evolve into totally parenthesis-free language. By expanding the "powerfull and versatile" Loop-macro into full powerfullness and versatileness. Unfortunately two parenthessis needed, but you can redefine the language having those by default around every file.

After having grokked Lisp, I think that parentheses provide a more elegant solution to the problem of parameter separation. Compare:

myfunction(a, b, c)

with

(myfunction a b c)

Parentheses allow you to leave out the commas between arguments. I like that a lot.

ML-family languages are similar: ‘myfunction a b c’. It definitely is nice.

The consequence of having the AST be explicit is profound.

> Parentheses allow you to leave out the commas between arguments.

You compared the wrong things. The parentheses associated with myfunction aren't doing that.

The reason Lisp is better at passing arguments to functions is that it requires you to add parentheses to every function call. The C-style syntax in your first example is trying to let you do this:

    myfunction(a, a+b, c)

In Lisp, you'd do this:

    (myfunction a (+ a b) c)

C has "saved" you the work of putting parentheses around (a+b) at the cost of making you add commas to everything. Here that's a wash because you needed two commas. But C really did save you three spaces that are necessary in the Lisp. (They separate a from myfunction and + from a/b.)

You could save two spaces while getting the same benefit of losing the commas if you went with

    myfunction(a +(a b) c)

> C has "saved" you the work of putting parentheses around (a+b) at the cost of making you add commas to everything.

Not only that but also at the cost of putting a comma which is spelled + between all the terms of a addition:

  myfunction(a(),b()+c()+d()+e()+f(),g())
 
  (myfunction(a)(+(b)(c)(d)(e)(f))(g))

could just as well be

  myfunction(a() +(b() c() d() e() f()) g())

with the condition that there is no space between the symbol and the opening parenthesis

I’m working on a syntax for an object oriented lisp-like thats basically this (the self receiver is implied)

    .myfunction(.a .b.+(.c).+(.d).+(.f) .g)

though making binary arithmetic operations singly-dispatched methods of the number class may be a mistake.

Yak-shaving away syntax always make me think of Forth. It's all a stack.

While C syntax requires commas, there's nothing about having the function name outside the parentheses that suddenly forces commas.

Theoretically:

    (myfunction a b c)

could be written as:

    myfunction(a b c)

Here's my standard response to this topic: http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html

tl;dr the parentheses are just the way s-expressions are serialised; there are many existing alternatives, e.g. based on indentation, etc.

If you're going to quote an old comment, please link to it as well: https://news.ycombinator.com/item?id=24716449.

This is the FOR macro he's talking about: http://ml.cddddr.org/cl-iteration/msg00008.html

Reply on news.ycombinator.com