Our great sponsors
-
> M-expressions ("never implemented")
There were a bunch of approaches and even implemented languages.
https://github.com/shaunlebron/history-of-lisp-parens/blob/m...
-
I dunno, my Lisp code comes back in pretty frequently, but I'm defining new functions, using CLOS, making use of let* or other nifty macros (uiop:nest is occasionally useful), and refactoring when a function gets too large. But compared to horrors I've frequently seen in JavaLand (especially in older code when the more modern practice of extract function refactoring was less common, more laborious, and not really automated), tons of Lisp code I come across from others has been pretty sane as far as indentation and spacing goes.
It seems like a problem mostly handled by style, just because you can easily represent the whole expanded AST in one function definition doesn't mean you should. And sure there are plenty of (in my opinion) not so great examples out there, like it's rather unfortunate that this is the first example for the cl-sdl2 project: https://github.com/lispgames/cl-sdl2/blob/main/examples/basi... (Though on another metric, the longest line is only 96 characters; most of my lines happen to be under 80 but I don't hold myself to that limit, my screen and editor windows support wide lines by default, like >200 characters wide.) The huge nest of with-macros further impedes runtime redefinition and modification, because now sure you can change code and redefine the function, but your game loop isn't going to see any of that on further iterations. At least the other renderer.lisp example is moving in a better direction splitting the game loop up into several draw functions, and you see those have a normal pattern of going out and then back in.
Urbit docs for its language Hoon once called the phenomenon something like "attacking the right margin". I recalled this fosdem paper describing it more https://archive.fosdem.org/2018/schedule/event/urbit/attachm... especially in 6.3.2:
> There are two common syntactic problems in functional languages: closing terminator piles (eg, right parens in Lisp) and indentation creep. A complex function will have a deep AST; if every child node in that AST is indented past its parent, any interesting code tends to creep toward the right margin. To solve terminator piles, there are two forms of every Hoon twig: “tall” and “flat”, ie, multiline and single-line. Tall twigs can contain flat twigs, but not vice versa, mimicking the look of “statements” and “expressions” in an imperative language. Flat form is enclosed by parentheses and separated by a single space; tall form is separated by multiple spaces or a newline, and (in most cases) not enclosed at all. ...
> Right-margin creep is prevented by backstep indentation; where a classical
-
SonarQube
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
-
?., which reverses q and r.
Hoon code is rather interesting to look at, especially the rune vs keyword syntax (random file: https://github.com/urbit/urbit/blob/master/pkg/arvo/lib/aqua...) but I don't think it's worth the effort.
-
