Christina O'Donnell 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