Honestly, why would you want that? If you start using Lisp you rapidly stop focusing on the parentheses and instead focus on the code structure.

Indentation is a big guide, but can't do all the work.

Any scheme that supports t-expressions https://srfi.schemers.org/srfi-110/srfi-110.html

But that has a lot of pushback, and no scheme I've researched supported (implemented the SRFI) t-expressions out of the box. Usually it's some third party library or runtime you have to use for that.

Have played around a bit with it in GNU Guile, but in some circumstances I myself got confused :)

Clojure and Clojure-like Lisps (Janet, Hylang) use fewer parenthesis by replacing them with other pairs of characters ([], {}) for certain block structures, which is exactly what other non-Lisps do. The only difference is that Clojure still puts the opening character at the beginning of the structure instead of in the middle, like how non-Lisp languages usually do.

To be fair, there are more differences; where Clojure requires parentheses, non-Lisps often don't need them at all.

E.g. in Python indentation carries meaning. Ruby has "do/end"; but also it's possible to skip parentheses in some function calls; there are pipes too. Haskell - whatever haskell does, sometimes also pipes. There are more examples.

That being said, for me clojure parentheses were always more of a help than an inconvenience.

I actually find Clojure's syntax more confusing with all the punctuation they threw at it. Compare that, for example, with Scheme. I like the idea of keeping Lisps "pure" if that makes sense. In Lisp, the first element of a list is the operator. Okay, then how is Clojure a Lisp when it has vectors like this [1 2 3]? Unless [ is a macro that expands [1 2 3] to some real Lisp-y expression under the hood.

> I actually find Clojure's syntax more confusing with all the punctuation they threw at it.

Could you give some examples? Or "all the punctuation" you are referring just to []?

I'm not the same person you asked, but I find Clojure to be as easy to read as Scheme, but harder to write, since I need to remember what punctuation to use where.

I don't know, it makes sense to use different data structures for different purposes. (), [], {} are all different data structures (lists, vectors and maps) that are useful in different situations, so makes sense to have shorthands for them.

Maybe. What bothers me about this idea is that it doesn't scale: As soon as you need a fourth bracket type you're hosed, because there are no more on the keyboard.

With Common Lisp, you can define [ and { if you want to, but it's more common to use a reader macro character in front of an opening paren or a function name after it if you want different data structures. Those approaches scale.

It's a literal vector in the sense that '(1 2 3) is a literal list. Though unlike the quoted list it evaluates to itself, like a string or an int does.

there were some pseudo syntax made for scheme to remove some nesting

see https://srfi.schemers.org/srfi-110/srfi-110.html

not too far from https://chrisdone.com/posts/z/ posted before

ps: personally, lisp syntax has been an issue once every 4 years. with threading macros, paredit .. you spend 0.00001% of your time thinking about it.

I'm told that Elixir still closely follows the tradition of "code as data" while the syntax actually looks more like ruby. Things like "do...end" blocks are actually just syntax sugar for effectively parentheses[1].

I've also read that Julia is an acceptable Lisp [2].

1: https://news.ycombinator.com/item?id=36986769

2: https://mfiano.net/posts/2022-09-04-from-common-lisp-to-juli...

`do... end` blocks are a big no for me. You'd effectively replace single characters like (, {, [, with whole words.

Just get over it. Semantics are much more important than syntax. Every language will have some piece of syntax you won't like.

> mfiano

an answer to the post: https://gist.github.com/digikar99/24decb414ddfa15a220b27f674... (HN: https://news.ycombinator.com/item?id=32750052)

and BTW he's back to CL. https://mfiano.net/posts/2022-11-05-programming-languages-i-... (there was a few more explanations and criticism of Julia on IRC which I can't find rn)

For me, (...) are not the problem. But the thing that throws me off and confuses me when I read Lisp code is the excess use of long words. The language is too verbose for its own good. When I read Python or other languages, the space between the expressions/statements makes it much easier to follow the flow and understand what's going on. In Lisp, I often see lines stacked together with minimal room for my eyes to "rest".

As a long term (40+ year) Lisp developer I carry that forward into my other languages. Vertical whitespace is free in lisps,* as with most languages, so what I try to do us clump together an "operation" ideally so that it fits in my fovea when when I'm glancing at the code. So a quick glance tells me "this isn't what I'm looking for" or alternatively "all this goes together so read the whole thing before changing anything, but there's a good chance your change won't affect other parts of the function."

Thus: (if (< foo 0) (do-this) (do-that))

or if it's long

   (when (< foo this)
     (some-stuff)
     (more-stuff)
     ...)

Obviously one can do this in C++ by introducing a block, but it isn't as syntactically natural; a block implies that there is important RAII involved, so usually I just do it by "vertical clumping"

I find the standard c style (used by lots of languages) actually spreads the code out too much, emphasizing the curly braces rather than the code itself. (this is a local version of the OO+IDE plague that smears functionality across lots of tiny files.

This sense of locality is presumably why the gnu programming style is compact in some ways and expansive in others, different from K&R style, for example,

return-type function-name ( type1 arg1 ) {

allows the eye to see the identifiers without the syntactical markers () and {}, letting indentation and vertical whitespace to tell a story.

* except, de facto, Interlisp because it normally used a structure editor rather than a text editor.

Classic old Lisp doesn't have the problem of long words: it has mostly short words like atom, cons, car, cdr, array, ...

Then, eventually, along comes Common Lisp with symbols like multiple-value-bind and update-instance-for-redefined-class.

I made a dialect called TXR Lisp in which most of the important symbols in the standard library are deliberately quite short, to avoid this readability/writability issue.

Lisp code often avoids vertical breaks within sections in a function, because many constructs nest, and so the nesting and indentation separates them already, like:

   (while ...
     ...
     (let ...
       ...))
   (while ...

It's like point form:

   - abcde
     - efgh
     - jlk
       - mn
   - next point

Wonder if you can consider a rainbow colour parenthesis plugin as an alternative

The closest thing to what you want is Dylan, which was originally created by Apple: https://opendylan.org/

But parentheses aren't really that bad, after a while you get used to them and start seeing the actual structure behind them instead, kinda like that quote from The Matrix. Without them macros become much more complicated, especially if you want the syntax to be infix.

Dylan and Julia.

This has been discussed many times before, as shown in

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

And yet, none of these efforts caught on. It's as if people who like Lisp, like it __with__ parentheses and people who don't like Lisp, wouldn't like it even __without__ parentheses.

The diagnosis that the "problem" with Lisp was the syntax has always been wrong.

Tcl has some Lisp-y attributes with a bash-esque syntax.

well JavaScript if you're willing to buy into the idea that it's scheme in c syntax, which isn't actually that far off.

But no, genuine lisps come with parentheses (or some equivalent) because, as the name suggests, the entire point is list processing. Lisp programs are just data without (much) syntax. The more syntax you add, the less of a lisp it is.

> well JavaScript if you're willing to buy into the idea that it's scheme in c syntax, which isn't actually that far off.

It is quite far off. Just look at the version of "SICP in Javascript" (of which Julie Sussman was even one of the authors). The important points of the book are obscured by all the boilerplate and workarounds for the poor expressivity of the language.

Could it be that JS has poor expressivity for the concepts discussed in SICP, but good expressivity as a general scripting language[0]? Same thing for Python.

[0] And conversely, Scheme doesn't have good expressivity as a scripting language.

Given Lisp Machines and Interlisp-D, I would state the issue with Scheme is more related to lack of tooling.

Scheme has better expressivity (or more expressive power if you want to put it that way) but there’s a higher gain mismatch between its syntax and the things people usually script these days.

Scripting languages are tightly coupled to the language they are scripting.

Try using a syntax highlighter that reduces their contrast and you'll find it looks a lot like python.

There are, or rather were Lisps with fewer parenthese: Lisp 2, CGOL, Dylan, but I wouldn't say they were popular. It isn't too difficult to write one yourself. After you've done so, and used it for a while, you'll understand better why those earlier projects never gained traction, and learn to love (or, where appropriate, not notice) Lisp's parentheses.

If you look at the original LISP paper, it uses meta-expressions. Then towards the end is the alternate syntax with parenthesis. The Wolfram (Mathematica) language and K were both inspired by meta-expressions.

I have a macro in my personal library called BINDING-BLOCK that eliminates many (though not all) of the parens in common code idioms:

https://github.com/rongarret/ergolib/blob/master/core/bindin...

It's also helpful in preventing code from crawling off the right side of the screen.

However, like many of the sibling comments point out, if you think getting rid of the parens entirely is desirable then you have missed the point, which is that Lisp code is not text, it's a data structure, a linked list, and the textual representation of the code is just a serialization of that data structure. And the most straightforward way to serialize a linked list is with delimiters at the start and end, like so:

(1 2 3)

Logo would be the most obvious one.

I just put out a new release of TXR, which has a change that can reduce the nesting.

In pipes, you can now bind variables that are in scope of later pipeline elements.

  1> (flow "/usr/share/dict/words"  ; start with this path
       (file-get-lines)             ; get content as list of lines
       (let lines)                  ; bind lines variable to this list
       len                          ; take length of list
       rand                         ; get pseudo-random in [0, length)
       lines)                       ; index into lines
  "subdues"

Clojure has several threading macros: https://clojure.org/guides/threading_macros

These can all be defined in CL and have been.

https://quickref.common-lisp.net/arrows.html

Don't know why you are so downvoted since your question is valid:

A single sexpr with only atoms could be written without parenthesis and with a EOL.

Dylan.

But you said popular, so Javascript then. Seriously, JS is not what I'd consider a very good Lisp, but I think it is one because it allows you to build real lexical closures.

Edit: Haskell is a sort of a lisp too, and it's the only one IMHO that got rid of the parens in an intelligent way. Haskell lets you use either prefix or infix notation, and it works mostly without parentheses. Plus you can use the '$' character as a clever hack to remove parens where they would otherwise be needed. But...the price you pay for this is laziness and automatic currying, which most Lisps don't do.

If the lisp has read macros you can add it yourself.

There's: sweet-expression

https://srfi.schemers.org/srfi-110/srfi-110.html

https://sourceforge.net/p/readable/wiki/Examples/

    define fibfast(n)  ; Typical function notation
      if {n < 2}       ; Indentation, infix {...}
        n              ; Single expr = no new list
        fibup(n 2 1 0) ; Simple function calls

    define fibup(maxnum count n-1 n-2)
      if {maxnum = count}
        {n-1 + n-2}
        fibup maxnum {count + 1} {n-1 + n-2} n-1

    define factorial(n)
      if {n <= 1}
        1
        {n * factorial{n - 1}} ; f{...} => f({...})

Don't know about popularity but Scheme has a SRFI and syntax 'model called Wisp which does away with most brackets. It relies on indentation.

syntax 'mode'

Wisp:

https://www.draketo.de/proj/with-guise-and-guile/wisp-tutori...

(Along with the others already mentioned.)