Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)

[Dr. Arne Babenhauserheide]

Damien Mattei <damien.mattei@gmail.com> 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

signature.asc
Description: PGP signature