Part of the formative process of every true Lisp programmer is at some point to spend 2 months creating a parens-free lisp dialect, and then abandoning it.
Correct me if I'm wrong but isn't that part of what Arc did? I don't recall specifics. I'm also reminded of the old PHP hack of using arrays as an ORM for queries.
Except that wisp is not abandoned. See for example dryads-wake for a practical use that provides an embedded DSL for game dialogue that reads like a typical theatre script: https://hg.sr.ht/~arnebab/dryads-wake
The fact that you included five extra closing parenthesis is a clear indication of madness - two or three would be understandable. One is just regular old tpyoing.
A cool project... but instead I suggest to everyone who uses Lisp, just set your editor's syntax highlighter to make the parentheses fade into the background color almost completely. They're still there, for correctness, structured editing, and ease of sharing with others; but they don't stand out.
Lisp also really benefits from an editor that colourizes ( ) in matching pairs. Even C benefits from colour-matching {} in my experience. I'm surprised it's not more common.
I got used to Lisp before I knew rainbow-parens were a thing. Then I tried it and found it added nothing. I'm sure it would be helpful as a learning tool though.
What I really can't recommend enough is paredit. It ensures balanced parens by always creating a close to an open. Typing a close just jumps you past the nearest close after the cursor. Along with the thing where the cursor momentarily jumps to the open paren when going past a close paren.
When I need to add another expression to a scope, I just hit close paren until I see the jump to the relevant open paren then hit enter.
I do know some older(than me) Lisp programmers who even find paredit excessive though.
Eventually, I found that when reading lisp I almost never actually look at the parens at all, only the indentation.
I was surprised with the lukewarm reception parinfer (which ties indentation with parens, in an automated way, and is compatible with paredit actions) had on the lisp world. I found it invaluable, especially for newcomers. It completely takes out parens-as-a-risk out of the question, effectively turning lisps into formally indentation-based languages, a la python (which is to some extent how everybody reads lisp).
I haven't looked at parinfer, but in general, in the Lisp community parentheses aren't really viewed as a problem to be solved. It's just a quirk of the language that requires a a few simple methods to deal with, and then it becomes completely natural, even seen as elegant. With things like BARF/SLURP-SEXP, to move expressions in and out of their parentheses, KILL-SEXP to delete a sexp to the buffer, adding a numeric prefix to open paren to wrap n expressions in parentheses, and ofc NEXT/PREV-SEXP. The language becomes a joy to edit, because everything conforms to this syntax you can do pretty much everything you want with this small handful of commands(all provided by paredit). As I mentioned in another comment, there is essentially a grieving process as a newly enlightened lisper comes to terms with the fact that other languages haven't caught on to this clearly(to the lisper) perfect and superior notation.
So probably parinfer is solving a problem that most Lisp programmers aren't looking to solve. That would be my guess anyway.
All this is not to pass judgement on your for finding it helpful, and I certainly agree that having more tools for beginners to get used to editing S-expressions is helpful.
> So probably parinfer is solving a problem that most Lisp programmers aren't looking to solve. That would be my guess anyway.
It mainly helps adoption, so in a way you are right, it’s not a problem for current users… but it is a problem for industry (as much as I deplore the reality that such a superficial familiarity bump detracts so many people).
This is a great idea. Of course, it's not new. Looks like Wisp was first described in 2013, the same year SRFI 110 [1] describing largely the same idea was also published. That SRFI helpfully includes a "related" section describing prior art and more detailed raionale / tradeoff analysis that some might find interesting.
Everybody seems to want to describe these ideas as "Python-like". I personally think the JSON / YAML distinction is a more apt comparison, since the latter is a backwards-compatible "superset" of the former, and it's also a nod to the duality of data / code in Lisp :)
Attempts to have some alernative syntax for Lisp go back to the orignal Lisp project. In addition to the abandoned M-expressions, there is a reason why the updated version of Lisp was Lisp 1.5.
There was a Lisp 2 in the 1960's: a project which added Algol-like syntax and semantics on top of Lisp, with faster numeric processing.
In the 1970's, there was CGOL, which the Wikipedia article says "may be regarded as a more successful incarnation of some of the essential ideas behind the earlier LISP 2 project".
Interesting. For the record, that SRFI is David Wheeler's Sweet Expressions :)
I feel like your use of the word "attempts" implies these ideas were unsuccessful, but I would disagree. Perhaps Lisp in general has not "succeeded" in that its original purpose (AI research) has entirely abandoned it, but I think the problem of low general-purpose adoption is overstated.
In particular, since Lisp does not play nicely with the C calling convention, it's ability to integrate into polyglot systems has always been problematic, but I have confidence that the future will be better for FFI's in general, perhaps starting with WASM, which hopes to create a "universal ecosystem" of libraries (components). In theory, any program written in Lisp, or Rust, or Javascript, could import any package from PyPI by means of a WASM component. If this becomes reality, Lisp would be much more appealing to people currently put off by the languishing ecosystem and lack of integration, and may yet even have a fighting chance of reclaiming it's AI research credentials, simply by importing numpy :)
Wisp was developed alongside SRFI-110 for a while and branched to SRFI-119[1], because SRFI-110 got more and more complex to improve edge cases while the focus of wisp is to preserve the simplicity of lisp. For more details, see the history part on the website[2].
The background of calling it Python-like is that this is the motivation behind starting Wisp:
» I love the syntax of Python, but crave the simplicity and power of Lisp.«
A description like JSON / YAML with YAML as proper superset is close, yes, since you can embed arbitrary parenthesized Scheme in SRFI-110 (readable), SRFI-119 (wisp) and SRFI-49.
I remembers, almost a decade ago, I got into an argument with someone here, who thought that significant whitespace languages were somehow SO fundamentally different, that they couldn't be translated back and forth to a bracket delimited language. (This is one of the hazards of not getting a formal education, or of not having enough curiosity to self educate at a deep enough level.)
There probably is something to the point that whitespace languages need more context to know what is going on? Moving code, in particular, is a bit more tedious with it. That said, I'm curious why anyone would think it can't be just as "mechanical."
Languages where blocks are indicated by indentation are not context-free (you have to keep the current and previous line indentation level as state). Everything about them is more tedious because you can't do structured editing.
And I know many become an indentation shift. This can be a lot more intrusive then just moving a paren. I personally find it harder to match indentation shifts. (Excepting simple one liners, of course.)
I usually do the alignment with tab: my Emacs wisp-mode knows the indentation levels in use in the file, so it’s just shift-tab to go back to the previous scope and tab to nest more deeply.
One observation I made is that wrapping an expression around several lines is often less intrusive, because I can simply insert a line before the block that uses only half the indentation.
Parinfer hits the sweet-spot for me -- you still get the benefits of the parens, but the indentation is still enforced to match, and changing either one causes the other to be updated accordingly
cool experiment, but whitespace is a terrible delineator. ironically one of the most disliked parts of lisp by newcomers, the parens, ends up becoming its greatest strength once you have grokked things.
I’m used to whitespace as a delineator thanks to python. If used judiciously it can be a great benefit.
I do admit it would be nice if it were optional so you could have more complicated expressions than you can easily write with paired brackets/braces/parentheses.
Editor fonts which replace spaces and tabs with what are essentially the appropriate periods or similar make this not a merely hypothetical or anachronistic point.
The Racket folks are trying to create a parens light language called Rhombus that allows for easily creating macros/dsls/languages like lisps normally have. Some of the ideas proposed are indentation/white space based though I think they have settled on something similar to honu recently
There are clearly quite a few other differences - but this is one of the reasons I love PHP... a completely sane approach to parenthesis quantity as well as whitespace sensitivity. (It is occasionally whitespace sensitive but only in the places you really want it to be).
Also, I think it's a pretty sane comparison language for Python - except with more structure * ducks *.
This looks like Haskell, and it is just as difficult to tell program structure here as with Haskell. I seriously have to stare at any 3 to 5 lines of Haskell for about 30 seconds before I get anything about what they're saying and I have that same feeling here. Maybe Haskell should use less dollar signs and more parentheses.
Wisp is an addictive /idea/, even if the net benefit ends up not being terribly strong. But combined with some other changes in assumptions, there might be some interesting insights. I've tinkered with this idea for a bit. https://gist.github.com/armstnp/bb2a88bcb053d2195f42c60a0cf1...
Heading this direction, things almost start to smell point-free. Functions begin to be designed to take elements likely to be recursive as their last argument. And a placeholder ('⎵') could be used to select the recursive slot otherwise.
I made Calcit http://calcit-lang.org/ it's also using indentations to implement S-Expressions. The syntax part is called Cirru http://text.cirru.org/ , just using very similar ideas.
Wisp already triggers me to think of wireless internet service providers, written information security plans, windows ink services platform, and the Wisconsin investigators of supernatural phenomenon
You should check python-on-guile. It compiles Python to (unidiomatic) Scheme. The resulting code uses delimited continuations and mutation EVERYWHERE, and still manages to beat python on all my old project Euler solutions.
LOL, I'm sure it's a personal taste thing, but to me, significant white-space is the absolute worst feature of python, and other languages that use it.
IMHO the IDE is the place to smooth over syntax you don't like.
