I wished that, too, when I was first learning Lisp. Now, thirty years or so later, I like the parentheses. Lisp did something to me along the way.
Syntax has some quality that affects what it feels like to write code. Call it flavor, maybe; or feeling. Lisp feels good to me. It didn't feel good at first, but it gradually won me over.
I'm not the only one. Your perspective is valid, but most every Lisp programmer I've met shared it at some point, before Lisp changed their minds.
Part of it is that lisp's syntax is simple and regular enough for editors to automate a bunch of simple editing tasks. They indent things for you in a standard way. They can grab whole subexpressions and move them around and transpose them whole and so forth. Most other languages are so syntactically complicated that it's hard to make an editor do that very well.
Part of it is that the same simplicity and regularity make it tractable, even easy, to walk, transform, and generate code from Lisp expressions. That characteristic leads to things like this essay linked in another comment: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h...
Nowadays Lisp expressions feel to me like strings of pearls, each one containing meaning, and each one composed fractally of other pearls of meaning. They are simultaneously structurally sound and malleable. I long ago stopped wanting to get rid of the parentheses.
Some time around 1992 or so, Apple acquired a Lisp company named Coral Software and formed a team intended to invent a programming language for its research and development teams. the Advanced Technology Group and other research teams liked Lisp and Smalltalk and similar languages because of how quickly they could build working prototypes with them, but they didn't like the process of converting their successful experiments into Pascal, C, or C++ code. It was too hard, took too long, and lost too many features along the way. They wanted a new language; one that would be as flexible and congenial for experimentation as Lisp and Smalltalk, but that could also ship production code suitable for the more constrained systems that Apple customers mostly had.
The Coral group, renamed Apple Cambridge, designed a language called Ralph. It was a Lisp. More specifically, it was Scheme, but built on a runtime and type system based on a subset of CLOS, with some influence from Smalltalk and functional languages, and with system features for cleanly separating the development environment from delivered programs.
It was my favorite programming language ever. Eventually, amid some amusing shenanigans, Apple officially renamed it Dylan.
Along the way, the Dylan team heard over and over and over from non-Lispers that they wanted a non-Lispy syntax. Initially, the compiler people sort of shrugged and said, "sure, that's easy enough to do." And it is. There's been no shortage of unparenthesized syntaxes designed for Lisp in the roughly sixty years since it was introduced. None of them has ever really caught on (and that should probably tell us something about what a good idea it is, but never mind).
Dylan design meetings discussed creating a parser for an "infix syntax". The general idea was to create such a thing to mollify the non-Lispers. I even supported it. My argument was that it was a superficial matter, and if it attracted more users, it would be all to the good.
I was wrong.
I didn't appreciate just how helpful Lisp syntax is until I got hold of a Lisp that had an infix syntax. It was bulkier and more cumbersome. It was less pleasant to work with. It wasn't as easy to recognize the boundaries of expressions. Editors had a harder time working with it, so they weren't as nimble.
Of course, I could always switch back to the parenthesized syntax...until that was removed.
Okay, the surface syntax was clunkier, but it was still a Lisp underneath...until it wasn't.
The separation between development environment and delivered program got harder and faster. That evolution increasingly restricted what you could accomplish in the repl, until, finally, the repl disappeared altogether. At that point, Dylan really wasn't a Lisp anymore. My favorite Lisp had evolved into just another batch application compiler.
Moreover, it didn't work. The stated goal was to make the language more appealing to more working programmers, so that it would gain broader acceptance.
It didn't. It lost the things that made Lisp and Smalltalk programmers happy, and it didn't gain broader acceptance in the process.
I still like Ralph better than anything else, including Common Lisp, Scheme, Clojure, or Arc. But Ralph is extinct now, so I'll stick with those other Lisps until someone invents a better one.
My new favorite will probably have the parentheses.
Same here. I liked Dylan in the early days when it had parentheses, but when they went away I completely lost interest in the language. Shortly afterwards, Apple and everybody else did too.
An old argument, as you say, but as tech changes, the constraints sustaining it may fall away.
One trend in javascript is using a style checker to enforce a uniquely-defined textual representation for any given ast. To relieve increasing-novice developers of code layout worries. Which makes that textual javascript simply an ast printed representation, an un/dump format. And editing it, is semantic representational editing of an ast.
That's more purely an ast, than even a file of s-expressions would be. Where for instance, rearranging which expressions are on a line ending with a comment can be problematic. Tasteful manual textual layout of code is sacrificed for tooling and humans not having to preserve and care about layout.
Representational editing of an ast means you can use any surface syntax you'd like. Parentheses, infix, operator precedence, concatenative, COBOLish verbosity, or whatever. Any losslessly reversible transformation is fair game. Including conversion between statement-based and expression languages. Layout becomes merely an editor customization, like colorization.
Which isn't to say it's entirely isolated from culture, style, and tooling. And thus that syntax multiplicity could have community costs. But perhaps it makes the choice a less binary thing, more amenable to tuning. The constraint that a language necessarily has exactly one syntax, modulo colors and fonts, seems to be relaxing.
>More than anything else, I think it is the ability of Lisp programs
to manipulate Lisp expressions that sets Lisp apart. And so no one
who has not written a lot of macros is really in a position to compare
Lisp to other languages. When I hear people complain about Lisp's
parentheses, it sounds to my ears like someone saying: "I tried one of those bananas, which you say are so delicious. The white part was ok, but the yellow part was very tough and tasted awful."
To make this more clear, lets' look at one example of pg's code. In verbatim it looks like this:
(mac case (expr . args)
(if (no (cdr args))
(car args)
(let v (uvar)
`(let ,v ,expr
(if (= ,v ',(car args))
,(cadr args)
(case ,v ,@(cddr args)))))))
For Lisp programmer it looks like this:
mac case (expr . args)
if no (cdr args)
car args
let v (uvar)
`let ,v ,expr
if = ,v ',(car args)
,cadr args
case ,v ,(@cddr args)
Lisp code relies on indentation for readability. Lisp aware editor knows how to automatically indent the code because it has been explicitly told. Only few of the inner parenthesis convey semantic information to the programmer.
<beginExasperation> I don't understand how people who everywhere else love minimalism, refuse to give up the unnecessary parens (whitespace suffices). If the advice is not to look at them, and they are not needed, why have them at all! Every lisp program begins with a syntax error! That doesn't cause alarm bells to go off in people's heads? The commenter above says because parens-less lisp has been tried for 60 years and hasn't caught on it's evidence that it won't work. Sixty years is a blink! Binary notation is 330 years old. Indian numerals about 1,000 years old. Lisp is still in its infancy and things can be improved. </endExasperation>
Who said they aren't needed? They are the structure that supports Lisp's simplicity and consistency, which is what the good things come from. If you take them out, it gets complicated and isn't worth it.
The first good implementation I'm aware of is Egil Möller's from 2003 (https://srfi.schemers.org/srfi-49/srfi-49.html). My independently researched prediction in 2017 was that no one will ever discover a place where parens or other visible syntax is needed. That sets up an easy proof by contradiction (and I've built a database of over 10k languages so far, looking for a single scenario where you would need them, and haven't found one yet). Here are 19 demo languages covering lots of scenarios demonstrating utility without parens (https://github.com/treenotation/jtree/tree/master/langs). A glaring hole though, now that I think about it, is that I don't have a good Lisp-like Tree Language. I think a Bel Tree Language would be an excellent example project (and I'm happy to assist anyone who wants to make an attempt, and if no one has the bandwidth and it's not done by next year perhaps I'll find the time to give it a go).
> They are the structure that supports Lisp's simplicity and consistency, which is what all the good things come from.
I agree with this, but would say they are "one" structure, not "the", and that there are other options (I have one idea in tree notation, but not ruling out that there are more, perhaps better ones).
> If you take them out, it gets complicated and isn't worth it.
I agree with this, but think there is a future tipping point related to tooling. Tree Notation was quite terrible 2 years ago, but now with type checking, syntax highlighting, autocomplete, I hate to use Lisp and other languages (everything feels unfinished, because I know the syntax characters can be removed).
I think we'll hit a tipping point where the tooling for Lisp without parens is good enough that the benefits of dropping them make dropping them a no-brainer. Could I be wrong? Sure, it's a forecast/prediction. But I want to encourage people to invent new alternatives, to try everything under the sun, and not to settle that they are somehow needed. We can make it better.
> "I think we'll hit a tipping point where the tooling for Lisp without parens is good enough that the benefits of dropping them make dropping them a no-brainer."
Any such tooling tipping point would likely make the syntax of the underlying representation irrelevant. What to view the logic in tree notation? Or how about with the parens? Or the parens, but so faint you can't see them? Or collapsing aspects of the code you're not currently concerned with? What gets eventually transformed into the 1s and 0s executed by the machine, and its various representations along the way are really not the concern of the person writing at the top of that stack, at least not most of the time.
Personally I find the added vertical space by tree notation very distracting and that it breaks the scan of my reading. But that's my personal preference, and something that could be addressed with tooling. And that's the point: same thing can be said with the parens of lisp or other editing/IDE tooling.
I happen to like fine-tipped pens, while others enjoy the smoothness of thicker rollerballs. Is one better than another? Do the benefits of one make using it to the exclusion of others a no-brainer? Does my enjoyment of fine-tipped pens preclude others from developing new pen types or new writing implementations all together? Might my evangelism for fine-tipped pens turn people off from exploring the perfection that is the Uni-ball Signo UM-151 0.28mm (in blue-black ink, of course)?
To each their own. Find the medium that best helps you express your message. And that may not be the same for others. And that's okay.
This is a great, analogy thanks (and as a novice to pen culture, but an avid pen and paper user, should I get myself some Uni-ball Signo UM-151 0.28mm?'s).
> Is one better than another?
Rollerballs and fine-tipped pens are probably equivalent, on an order of magnitude scale. However, surely we can agree that both are far superior to feather or dipped pens?
I am forecasting the difference between parens free Lisp and status quo Lisp will resemble the chasm between dip pens and fountain pens.
Lots of Lispers say, "dip pens are fine! After a while you don't even notice you are dipping them." Whereas I see a future where a lot more can get done easier because we don't have to waste time dipping our pens.
On the other hand, other languages use bunch of different characters and they all have different meanings and have to be in different places depending on lots of things.
In Lisp, you just have () and they are always in the same place, meaning the same thing.
This is a good point, in that Lisp is better than the other languages. But why not go all the way, and drop the parens? If the goal of Bel is to be a "good language", with shorter programs, why oh why not also strive for shorter syntax?
I love Lisp and have gotten more good constructive feedback from the Lisp community than anywhere else (with the Haskell community being a close second), but I don't understand why there's only been a dozen or so serious attempts to do Lisp without parens (I-Expressions being the best so far, better than the subsequent Wisp, etc). There should be 1,000x attempts.
This should be the top priority of most Lisp researchers. I of course think my Tree Notation is the solution, but I could easily be wrong, and there could be a better way, but the () need to go!
> But why not go all the way, and drop the parens?
Because Lisp is not about 'parens', but that code is written in a serialized form of Lisp data and that it can be both written as externalized textual data and as actual data (by calling functions which work directly over this data).
> dozen or so serious attempts to do Lisp without parens
> This should be the top priority of most Lisp researchers.
There are many more interesting areas for progress. A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group - which has happened multiple times in the past - but it won't replace the main core Lisp languages.
Good references, thanks. I took a fresh look at CGOL and was again impressed.
> Because Lisp is not about 'parens',
Exactly, so why keep them around?
When you ditch the parens, things become easier. You no longer start your programs with a syntax error. You no longer even have syntax errors. Program concatenation is easier. Dictation of programs is easier: you speak "add 2 3" instead of "open parens add 2 3 close parens". Program synthesis is easier....
> A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group
All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.
Because Lisp source code is written in a data-structure using nested lists and nested lists are written as s-expressions with parentheses. The same Lisp code can be executed by an s-expression-based interpreter.
> When you ditch the parens
Again, the parens are not what Lisp is about, it is the nested lists as source code: internally and externally. It just happens that the lists are written with ( and ).
What you propose is essentially not just getting rid of 'parens', but dropping the source code idea based on explicit list representation.
> , things become easier.
Code generation, manipulation and transformation becomes harder.
> You no longer even have syntax errors.
How so?
> Program concatenation is easier.
How so? Lisp actually makes many forms of source code transformations easy.
> All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.
But then we no longer have the 'Lisp code is explicitly written in a list-based data structure' idea, which is very powerful and still relatively simple.
Language with syntax based on textual representations already exist many and there is a place for a programming language which works slightly differently.
It's possible to drop the explicit s-expression syntax, as has been demonstrated many times over history, but then the has a different look and feel. It becomes something different then and loses basic Lisp features or makes them considerable harder to use.
One can say 'why keep the wheels around'? We can do that, but either the car won't drive very well or one would transform it into something else: a boat, a plane, a sled, .. It would lose its 'car nature'.
> What you propose is essentially not just getting rid of 'parens', but dropping the source code idea based on explicit list representation.
No, I keep the nested list representation of data (as does I-Expressions: https://srfi.schemers.org/srfi-49/srfi-49.html), you just ditch the enclosing parens in favor of whitespace (or, to be more precise, in favor of 3 syntactic tokens: atomBreakSymbol, nodeBreakSymbol and edgeSymbol; by convention space/" ", newline/"\n", and space/" ").
>> You no longer even have syntax errors.
>How so?
See for yourself: https://jtree.treenotation.org/designer/. Try to generate a syntax error, it's impossible. For the same reason you don't have syntax errors at the binary notation. I think this is a very, very important hint that there is something important going on here that ties into something in nature (I don't know what that is but seems like there is a fancy prize to the person who can explain that in mathy terms). However, using the openParenSymbol and closeParenSymbol style of delimiters, you do have syntax errors--unbalanced parens.
>> Program concatenation is easier.
> How so?
This one is mildly easier, but comes up all the time. We have a Tree Language called Grammar for building other Tree Languages (and yes, Grammar itself has an implementation in Grammar). We have a Tree Language called Hakon that compiles to CSS. And we have one called Stump that compiles to HTML. Want to build a new language called "TreeML" that has both? Just `cat hakon.grammar > treeml.grammar; cat stump.grammar >> treeml.grammar` and you are just about done (just concat your new root node). You don't have to worry about adjusting any parens at the tails. A minor improvement, but lots of little things like that add up.
> but then the has a different look and feel. It becomes something different
This might be true. It seems you are taking the stand that Tree Notation is something different than Lisp (which I actually lean to agreeing with), while most lispers have given me the flippant response "congratulations! you've reinvented lisp/s-expressions". I think both arguments have merit. We will see where it goes and perhaps although the differences with parens S-Expressions are slight, perhaps there will always be a separate niche for parens lisp.
That's not an EXPLICIT list representation, where the nesting is notated by explicit characters.
It's also harder to use in interactive interfaces like REPLs, debuggers, etc., where Lisp lists don't need to have vertical layout.
> you do have syntax errors--unbalanced parens.
if you use a structure editor for Lisp you don't have unbalanced parentheses. In editors with support for s-expressions, unbalanced parentheses are basically not an issue.
> cat hakon.grammar
Yeah, Lisp works very differently. It does not use grammars like that. Lisp uses procedures in readtables to read s-expressions. Parsing the code is then done by the evaluator traversing the source or by the compiler traversing the source, with an integrated source code transformation phase (macro expansion).
We load a bunch of macros into Lisp and they then are available incrementally.
There are syntax-based structure editors (for example they were in Interlisp-D), but they always have limits, since macros can do arbitrary source transformations on s-expressions and those are not based on grammars.
You are really looking for a very different language experience. Lisp with s-expressions works very different from what you propose.
That's why I say: it's not about dropping parentheses, you propose to get rid of some of the core parts of Lisp (how programs are represented, parsed, etc.) and give it a different user interface. That's fine, but it is no longer Lisp like we know it.
Other syntaxes and IDEs for those have been done several times in Lisp-based language implementation. For example the Sk8 multimedia development tool from Apple had implemented something like AppleScript on top of Lisp. The multimedia applications were implemented in an AppleScript like language (actually it was kind of the first AppleScript implementation) with an IDE for that - implemented in Lisp.
The original dream of Lisp was to have algol-like M-Expressions and use s-expressions only for data inside M-expressions. But the internals of Lisp were implemented with s-expressions and M-expressions were manually translated into s-expressions. Breaking into a Lisp execution and looking into the interpreter state then revealed the s-expression representation of code to the developer.
> That's fine, but it is no longer Lisp like we know it.
I think this is fine, and now I can direct future commenters who tell me we've just "reinvented lisp" to your thread.
Really helpful links, and I am looking forward to watching that youtube video later this week when I have a moment. Thanks so much for all the information.
"why not go all the way, and drop the parens?" because no one found something that is simpler and shorter than just using parens. I-expressions are made up of invisible characters and my feeling is that not a lot of people who write lisp likes any sort of invisibility in their software.
For me, using parens is not a deal-breaker, as it's a relatively simple to use for dividing up things. Beats using invisible characters or many different characters.
At bottom something is necessary to delimit expressions. Going from () to semantic indentation is trading one delimiter for another, isn't it? Not exactly dropping the parens for free.
Break or fixed width delimiters are different than enclosing delimiters.
There's no longer any parens matching.
And not 2 things to keep track of (notice how Bel is both using parens but also following a whitespace convention for readability--that is then stripped and ignored by the compiler).
And also, your program is never in a syntactic error state--such things no longer exist. Semantic errors are still there, of course, but a whole class of errors goes puff.
Other techniques to make them less prominent is to use a text face or syntax highlighting to make them less prominent, e.g:
https://github.com/tarsius/paren-face/
It's not that Lisp has many more parens as that it's simplicity mandates only 1 block structure is used to define s-expressions (lisp's AST), whereas other languages adopt multiple syntaxes for defining their different blocks structures, e.g. () {} [] <>, lisp only uses ().
The Julia language is very lispy at its heart, giving you access to the AST and having "true" macros. The surface syntax however is akin to Python or Matlab. Granted, doing AST manipulations in Julia is more cumbersome than in Lisp, but AFAIK the language creators actually discourage the (over)use of macros, as the resulting mini-languages can make it difficult for outsiders/newcomers to understand or maintain the code.
It admittedly is, just as it is for most other people: there are very few "serious" prorgams I can name that were written in Lisp, in spite of its venerated heritage.
There's no shortage of options in the programming language field, so one would be a fool to stick with a language they don't enjoy working in.
