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

[Dr. Arne Babenhauserheide]

Christina O'Donnell <cdo@mutix.org> writes:

> On 09/01/2024 07:05, Dr. Arne Babenhauserheide wrote:
>> It’s a new year — any chance for one more look whether adding SRFI-119
>> in Guile is ok to merge?
>
> As a disclaimer, I'm a Scheme newbie, but I think my opinion may have /some/
> value.



> On its own, Wisp seems like a better syntax for tooling that looks at
> files as a list of lines, rather than as a tree of S-expressions. For
> example, the diff tool looks for changes in lines, so when adding a
> value to the end of a list it will always show 1 extra line removed
> and then added again with one less paren. For example (from a record
> definition):
>
>    (device-tree-support? bootloader-configuration-device-tree-support?
> -                         (default #t)))   ;boolean
> +                         (default #t))    ;boolean
> +  (extra-initrd          bootloader-configuration-extra-initrd
> +                         (default #f)))   ;string | #f

Looking at that may actually explain why many non-lisp-languages put
closing parens (braces: }) on their own line. Some are even starting to
do that for function arguments by allowing a comma after the last parameter.

> However it could cause some fragmentation of the community as peoples
> editors are set up for Lisp and not Wisp or vice versa. Though, I
> think that could be mostly resolved if there was a script that could
> convert Wisp to Lisp and back. Ideally such that on a large code base
> there's very few instances where Lisp -> Wisp -> Lisp produces changes
> the code even by white-space. But, I don't know whether even then
> you'd find much interest from the other maintainers.

there’s currently only a script to go from wisp to lisp (called
wisp2lisp, shipped with wisp), but not the other way round — for three
reasons:

1. that was the original implementation: just transform wisp to lisp,
   then run it as lisp.

2. the transformation from lisp to wisp is somewhat more complex. You
   need to decide whether to use inline-parentheses, a colon, or
   indentation. Though if the goal is to back-transform code transformed
   from wisp, that would be easier.

3. wisp2lisp is a contingency plan: if wisp turns out not to be right
   for you, you can simply migrate onwards to Scheme with a simple
   command. Part of this is that Wisp is not intended to take over
   Scheme. There is already so much Scheme code and Scheme tooling and
   knowledge about Scheme, and ongoing improvements in Scheme, that Wisp
   will work best by being a part of Scheme. To share them with non-Wisp
   Scheme, extract common parts, transform them to Scheme with
   wisp2lisp, and make these the canonical source. That way you get more
   tooling, better linters, compatibility to many more Scheme
   implementations, and far less required maintenance for Wisp.

The more specialized tooling wisp would get, the harder it would be to
actually work with all of Scheme and benefit from all of its
improvements, because that tooling would have to play constant catch-up
with the evolution of Scheme.

So I think the sweet spot is to keep Wisp small, lean, and simple. This
has worked well for the past decade, and it looks like the best way
forward.


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

signature.asc
Description: PGP signature