Damien Mattei writes: > i just add a #; support in Scheme+ : https://github.com/damien-mattei/Scheme-PLUS-for-Guile > Scheme+ is an extension syntax to Scheme. It goes in the opposite direction of Wisp or Rhombus (based on Racket) Note that Wisp and Rhombus differ: Wisp is just Scheme that allows reducing parentheses where they can be inferred from indentation. In intentionally avoids doing anything complex, so it keeps compatibility with future improvements of Scheme. If you want to improve beyond what Wisp offers, the best way is usually to build appropriate control structures that can also be used in regular Scheme. > by keeping the same > number of parenthesis, but they are just differents : ( ), { }, [ ] > and it allow the use of infix expressions. Is your implementation of {} compatible with SRFI-105? (curly infix) Can it be used to provide proper operator precedence? (that’s currently not offered by SRFI-105 and would be quite an improvement) > Parenthesis have advantage on indentation (and inconvenient i admit). For example if you comment a single line of indented code (python for > example) that was used to define a loop you have to reindent all the body code in the loop. If you want to move a block of indented code you > then have to re-indent it specifically for the new place too. To some degree yes, though rectangle-editing in Emacs usually makes that painless. > Anyway scheme and scheme+ ,C ,C++ code are still indented for readness even if parentheses would be enough to validate the syntax. One point of wisp is that having a parenthesis as first element on almost every line makes it harder for people to understand the code as long as they have not yet trained their eyes to fade parens. Indentation is what’s easier to humans to understand at a glance, so if you want to prevent mistakes, you have to indent strictly by the parens. Wisp follows Python in the reasoning that if the parens *always* strictly define the indentation, you can just edit the indentation in the first place without the "detour" over the parens. An alternate way of getting something similar is parinfer which strictly couples parens and indentation while editing: https://shaunlebron.github.io/parinfer/ There are also cases where parentheses are clearer, even for newcomers. For these, Wisp defers to pure paren-processing inside parentheses (this also enables simple copy-pasting of regular Scheme code). Combining rainbow parens (or other ways to fade parens) with parinfer gives similar reading experience as with wisp, but only for those in specialized editors, so it doesn’t help newcomers. On the other hand, a mode like lispy provides expert users with a level of convenience during editing parethesized code which clearly outclasses editing Wisp. So these show clear reasons why Wisp is most used in the niche of newcomers: - it looks easier without specialized modes, including patches - it makes it easier to do simple changes (you don’t have to keep parentheses balanced) - it makes it *harder* to build advanced tooling which does in-place editing of the AST and simply reflows the code, because switching between styles (i.e. adding linebreaks when something is inserted in a line) requires more decisions when you use wisp. I like it that way, because it encourages contributing code to the regular Scheme codebase, and not building a separate set of Wisp modules. That reduces the risk of splitting the community. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de