Wisp: Whitespace to Lisp
draketo.de
draketo.de
Well, back to old.reddit.
.. if the page demands that you use the app on mobile (and I find this site's layout far superior).
Part 2 is spent wailing in misery that not all languages use the clearly superior S-expression syntax
Part 3 is spent making a macro to write your favourite language as S-expressions, from a lisp environment.
Finally, part 4 is accepting that we can't have nice things.
(((((((((((((((((((((( In Stereo, Where Available )))))))))))))))))))))))))))
had prior experience/trauma with Lisp.
And one of you fuckers is going to tell me that there are more closing parens than open ones. I did that on purpose, and you've fallen into my trap.
That, or I have a plugin running in the background for years without me noticing.
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.
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.
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).
[1]: https://srfi.schemers.org/srfi-110/srfi-110.html
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 :)
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.
https://en.wikipedia.org/wiki/LISP_2
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".
https://en.wikipedia.org/wiki/CGOL
Fast forwarding to modern times, in addition to Wisp and the SRFI, there are also David Wheeler's Sweet Expressions and other things of that ilk.
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 :)
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.«
That said, you can probably make dinner structural editing work roughly the same. Might benefit from highlighting to indicate current scope.
Many parts of structural editing (but not all) become simple indentation shifting with indentation-sensitive languages.
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.)
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.
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.
define : proc
display (string-append "foo"
"bar" (format #f "foo~a" 2)
) ; is valid wisp
(empty lines added to prevent hn from stripping newlines)
Python, except with braces instead of whitespace. (Syntactically significant whitespace kills me.)
Or a tool which makes reading easier by adding parens where they would otherwise be implied.
I have a very little experience writing Python, but PS and P. are extremely similar.
Also, I think it's a pretty sane comparison language for Python - except with more structure * ducks *.
There's Hy lang, which is python powered lisp. It'll be good to get some extra attention.
https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
"Indentation to Lisp" would be more accurate.
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.
IMHO the IDE is the place to smooth over syntax you don't like.