Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
On Sun, Jan 21, 2024 at 12:24 AM Dr. Arne Babenhauserheide
wrote:
>
>
> > Is your implementation of {} compatible with SRFI-105? (curly infix)
> >
> > yes it is based on SRFI-105
>
> That’s very cool!
>
> While I’m doubtful about your other changes in scheme+, this is an
> improvement that I’d love to see merged into Guile.
>
it is available for many scheme, as a module, if there is a packet
manager,for racket it is quite simple to install,anyway it is 100% scheme,
so for guile it should be installed like another module, i do not know if
it could be integrated in guile.
>
> > the operator precedence are predefined in a list ordered by priority in
> the source code:
> >
> > (define infix-operators-lst
>
> How does it treat procedures which are not in that list?
>
first , operator precedence is based on this list:
https://runestone.academy/ns/books/published/fopp/Conditionals/PrecedenceofOperators.html
but i do not know what answer, which procedure are you thinking about?
the list of operator is quite exhaustive already.
If new operator was to add it is as simple as update the list.
Note that changing operator precedence is the first time i hear about it,
as far as i know, not possible in C++,Java,
searching for Python , it find that:
https://stackoverflow.com/questions/11811051/change-operator-precedence-in-python
but the true answer seems NO:
https://www.tutorialspoint.com/Can-we-change-operator-precedence-in-Python
I had two methods for operator precedence, it was done at run-time so if
you change rules it is immediately apply for the next computation.
Now i added optimization at compilation , by parsing the source file before
and all infix operator precedence is done before compilation, so it will no
more possible to change the precedence rules.
Note that in conjunction with operator overload too this is more useful but
this could be complex to manage and implement.
Not sure it is a good idea.
Best regards,
Damien
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Damien Mattei writes:
> On Sat, Jan 20, 2024 at 9:07 PM Dr. Arne Babenhauserheide
> wrote:
> Damien Mattei writes:
> > 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)
>
> yes it is based on SRFI-105
That’s very cool!
While I’m doubtful about your other changes in scheme+, this is an
improvement that I’d love to see merged into Guile.
> the operator precedence are predefined in a list ordered by priority in the
> source code:
>
> (define infix-operators-lst
How does it treat procedures which are not in that list?
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
signature.asc
Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
On Sat, Jan 20, 2024 at 9:07 PM Dr. Arne Babenhauserheide
wrote:
>
> Damien Mattei writes:
>
>
> > 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)
>
yes it is based on SRFI-105
> Can it be used to provide proper operator precedence? (that’s currently
> not offered by SRFI-105 and would be quite an improvement)
>
yes there is operator precedence , an expression like :
{{x - v * t} / (sqrt {1 - v ** 2 / c ** 2})}
is converted in this one:
(/ (- x (* v t)) (sqrt (- 1 (/ (** v 2) (** c 2)
the operator precedence are predefined in a list ordered by priority in the
source code:
(define infix-operators-lst
'(
(expt **)
(* / %)
(+ -)
(<< >>)
(& ∣)
(< > = ≠ <= >= <>)
(and)
(or)
(<- -> ← → ⇜ ⇝)
(<+ +> ⥆ ⥅)
)
)
Best regards,
Damien
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
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
signature.asc
Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
hello Christina,
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) by keeping the same number of
parenthesis, but they are just differents : ( ), { }, [ ] and it allow the
use of infix expressions. It is my idea, i think Scheme musk keep a strong
identity with parenthesis.
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.
Anyway scheme and scheme+ ,C ,C++ code are still indented for readness even
if parentheses would be enough to validate the syntax.
Regards,
Damien
On Fri, Jan 19, 2024 at 10:47 PM Christina O'Donnell wrote:
> Hi Ricardo,
>
> > #; works in Guile.
>
> Ah, that's my bad.
>
> - Christina
>
>
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
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 signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hi Ricardo, #; works in Guile. Ah, that's my bad. - Christina
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Christina O'Donnell writes: > Likewise, commenting code in scheme is a pain because code-commenting > is done by > line. R6RS comments (#;) aren't implemented in Guile to my knowledge. So > parenthesis aware commenting is left up to the editor to implement. #; works in Guile. -- Ricardo
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hi Arne, 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 Whereas in Wisp syntax, you'd simply get: device-tree-support? bootloader-configuration-device-tree-support? default #t ;boolean + extra-initrd bootloader-configuration-extra-initrd + default #f ;string | #f Likewise, commenting code in scheme is a pain because code-commenting is done by line. R6RS comments (#;) aren't implemented in Guile to my knowledge. So parenthesis aware commenting is left up to the editor to implement. I could say the same about editors like Vim and many other editors that see the world as a list of lines. 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. Kind regards, - Christina
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hi, I just got the most beautiful feedback on Wisp as a Scheme primer, so I would like to nag about inclusion of SRFI-119 into Guile again: »I tend to use [Wisp] as a Scheme primer for colleagues that are used to Python but want to explore the realms of functional programming without … having to break with known syntax and conventions … it makes Scheme way more “approachable” while not drifting too much apart. Before using Wisp as an introduction, I got occasional feedback that parens where seen as confusing/somewhat cluttery in terms of readability; Wisp looks as clean, plain and readable as Python code; which makes it relatively easy to awake interest for Scheme in folks that are accustomed to Python already.« — Wilko https://emacs.ch/@thees/111720771253976695 Inclusion in Guile would make it much easier for them to just try Wisp on any of the supported platforms, so I think this is a strong indicator that inclusion of Wisp would help spread Guile Scheme. => Is the squashed patch ok to merge? Link to the patch in the archives: https://lists.gnu.org/archive/html/guile-devel/2023-08/msg00011.html Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes: > Is adding SRFI-119 to Guile good to go? It’s a new year — any chance for one more look whether adding SRFI-119 in Guile is ok to merge? Best wishes, Arne signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
ArneBab writes: > ArneBab writes: >> I now assigned my copyright in GNU Guile to FSF > Is the patch now good to go? Clarification: I don’t actually need someone to push this (I can push). I just need the go to actually do it (rebase the branch then merge it), because I don’t want to push my own changes (especially not larger ones) without a go from a maintainer. Is adding SRFI-119 to Guile good to go? Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes: > "Dr. Arne Babenhauserheide" writes: > >> "Dr. Arne Babenhauserheide" writes: OK. I assumed you already emailed ass...@gnu.org the relevant form, right? Let us know how it goes. >> I now sent a request to be sent the papers to sign to ass...@gnu.org > I now assigned my copyright in GNU Guile to FSF Is the patch now good to go? Best wishes, Arne signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes: > "Dr. Arne Babenhauserheide" writes: >>> OK. I assumed you already emailed ass...@gnu.org the relevant form, >>> right? Let us know how it goes. > I now sent a request to be sent the papers to sign to ass...@gnu.org > using a template I also got for Emacs, so I’m sending these directly for > Emacs, ELPA, and Guile. I now assigned my copyright in GNU Guile to FSF and received the version of the copyright assigment form with two signatures, so copyright assigment for contributing Wisp to Guile is completed. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes: >> OK. I assumed you already emailed ass...@gnu.org the relevant form, >> right? Let us know how it goes. > > If I read it right, the docs > https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html > say that I need to ask someone to get the papers I can then sign. > > Can I get the papers from somewhere or does someone have to send them to > me? I now sent a request to be sent the papers to sign to ass...@gnu.org using a template I also got for Emacs, so I’m sending these directly for Emacs, ELPA, and Guile. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes:
> I’m attaching the new squashed patch again here and will add the patches
> for the review changes to a second email.
Attached are the promised patches of the additional review changes.
Thank you for your review!
From 3d9b452137911e1948586657edb1ea614d8a70c0 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 15 Aug 2023 00:43:53 +0200
Subject: [PATCH 12/21] SRFI-119 (Wisp): Fix: capitalize Wisp
* doc/ref/srfi-modules.texi (srfi-119): capitalize Wisp
---
doc/ref/srfi-modules.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 5b82f8070..0ffc01252 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -5686,7 +5686,7 @@ define : factorial n @result{} (define (factorial n)
* n : factorial @{n - 1@} @result{}(* n (factorial @{n - 1@}
@end example
-To execute a file with wisp code, select the language and filename
+To execute a file with Wisp code, select the language and filename
extension @code{.w} vie @code{guile --language=wisp -x .w}.
In files using Wisp, @xref{SRFI-105} (Curly Infix) is always activated.
--
2.41.0
From d8585c6380cbdba2ad0f6c56aaf6637826cd5b93 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 15 Aug 2023 00:46:53 +0200
Subject: [PATCH 13/21] SRFI-119 (Wisp): Fix: capitalize Scheme
* modules/language/wisp.scm (comments): capitalize Scheme
---
module/language/wisp.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/module/language/wisp.scm b/module/language/wisp.scm
index b4e885eec..f3127c9d3 100644
--- a/module/language/wisp.scm
+++ b/module/language/wisp.scm
@@ -21,7 +21,7 @@
;;; Commentary:
;; Scheme-only implementation of a wisp-preprocessor which output a
-;; scheme code tree to feed to a scheme interpreter instead of a
+;; Scheme code tree to feed to a Scheme interpreter instead of a
;; preprocessed file.
;; Limitations:
--
2.41.0
From 44344fa738cb51b034bb03791a6e1ee828390a42 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 15 Aug 2023 00:56:07 +0200
Subject: [PATCH 14/21] SRFI-119 (Wisp): Fix: capitalize Wisp
* modules/language/wisp/spec.scm (define-language): capitalize Wisp
---
module/language/wisp/spec.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/module/language/wisp/spec.scm b/module/language/wisp/spec.scm
index 1efd3e8b2..5f8feca9a 100644
--- a/module/language/wisp/spec.scm
+++ b/module/language/wisp/spec.scm
@@ -57,7 +57,7 @@
#:compilers `((tree-il . ,compile-tree-il))
#:decompilers `((tree-il . ,decompile-tree-il))
#:evaluator (lambda (x module) (primitive-eval x))
- #:printer write ; TODO: backtransform to wisp? Use source-properties?
+ #:printer write ; TODO: backtransform to Wisp? Use source-properties?
#:make-default-environment
(lambda ()
;; Ideally we'd duplicate the whole module hierarchy so that `set!',
--
2.41.0
From 16967e979262f7f3d86e194295a1a3f5a7f68cd0 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Fri, 18 Aug 2023 19:06:23 +0200
Subject: [PATCH 15/21] SRFI-119 (Wisp): cleanup char-list cond
* module/language/wisp.scm (match-charlist-to-repr): use helper and re-indent
---
module/language/wisp.scm | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/module/language/wisp.scm b/module/language/wisp.scm
index f3127c9d3..3ac128df2 100644
--- a/module/language/wisp.scm
+++ b/module/language/wisp.scm
@@ -97,30 +97,22 @@
;; TODO: wrap the reader to return the repr of the syntax reader
;; additions
-(define (match-charlist-to-repr charlist)
- (let
- ((chlist (reverse charlist)))
+(define (equal-rest? chars . args)
+ (equal? chars args))
+
+(define (match-charlist-to-repr char-list)
+ (let ((chars (reverse char-list)))
(cond
- ((equal? chlist (list #\.))
- repr-dot)
- ((equal? chlist (list #\'))
- repr-quote)
- ((equal? chlist (list #\,))
- repr-unquote)
- ((equal? chlist (list #\`))
- repr-quasiquote)
- ((equal? chlist (list #\, #\@))
- repr-unquote-splicing)
- ((equal? chlist (list #\# #\'))
- repr-syntax)
- ((equal? chlist (list #\# #\,))
- repr-unsyntax)
- ((equal? chlist (list #\# #\`))
- repr-quasisyntax)
- ((equal? chlist (list #\# #\, #\@))
- repr-unsyntax-splicing)
- (else
- #f
+ ((equal-rest? chars #\.) repr-dot)
+ ((equal-rest? chars #\') repr-quote)
+ ((equal-rest? chars #\,) repr-unquote)
+ ((equal-rest? chars #\`) repr-quasiquote)
+ ((equal-rest? chars #\, #\@) repr-unquote-splicing)
+ ((equal-rest? chars #\# #\') repr-syntax)
+ ((equal-rest? chars #\# #\,) repr-unsyntax)
+ ((equal-rest? chars #\# #\`) repr-quasisyntax)
+ ((equal-rest? chars #\# #\, #\@) repr-unsyntax-splicing)
+ (else #f
(define (wisp-read port)
"wrap read to
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hello Ludo, Ludovic Courtès writes: > OK. I assumed you already emailed ass...@gnu.org the relevant form, > right? Let us know how it goes. If I read it right, the docs https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html say that I need to ask someone to get the papers I can then sign. Can I get the papers from somewhere or does someone have to send them to me? >> A change I did not do: >> >> - [ ] +Use record-types for the lines+. Reason: I decided not to do >> this because it currently needs to propagate the source properties >> when retrieving the code, so this is not a good match for a record >> type (it may become one with an annotated reader, but I’d like to >> shift that to a later change: > > What about having a ‘location’ field in that record type? Would that > work for you? Or, alternatively, add source properties just on the > relevant part of the list. I did part of the refactoring to a record type but it became less clear to read than working on the list, because the special cases to handle increased, so I reverted the change. It really didn’t get cleaner. car and cdr are mostly used in the variable length code-part of the line. > As I wrote back in June, source properties are not ideal and explicitly > storing location info, as is done in syntax objects, is preferable: > > https://lists.gnu.org/archive/html/guile-devel/2023-06/msg8.html Once I get that sorted out, that would be the moment I’d switch to records (then they would need no added special casing), but I would prefer to take your offer to do that change in a followup patch. > Some comments: > >> From 5857f8b961562d1ad2ae201401d5343233422eff Mon Sep 17 00:00:00 2001 >> From: Arne Babenhauserheide >> Date: Fri, 3 Feb 2023 22:20:04 +0100 >> Subject: [PATCH] Add language/wisp, wisp tests, and srfi-119 documentation >> >> * doc/ref/srfi-modules.texi (srfi-119): add node >> * module/language/wisp.scm: New file. >> * module/language/wisp/spec.scm: New file. >> * test-suite/tests/srfi-119.test: New file. >> * am/bootstrap.am (SOURCES): add language/wisp.scm and language/wisp/spec.scm >> * test-suite/Makefile.am (SCM_TESTS): add tests/srfi-119.test > > [...] > >> +(define wisp-uuid "e749c73d-c826-47e2-a798-c16c13cb89dd") >> +;; define an intermediate dot replacement with UUID to avoid clashes. >> +(define repr-dot ; . >> + (string->symbol (string-append "REPR-DOT-" wisp-uuid))) > > As I wrote in June, please remove those UUIDs and use uninterned symbols > instead (which cannot be serialized but can be compared with ‘eq?’, > which is all we need.) I already tried this when Maxime suggested it, but it did not work. I no longer remember in which part of the code it broke, but it broke, so I reverted to using the uuids. >> +(define (match-charlist-to-repr charlist) >> + (let >> + ((chlist (reverse charlist))) >> +(cond >> + ((equal? chlist (list #\.)) >> + repr-dot) >> + ((equal? chlist (list #\')) >> + repr-quote) > > This would probably be more readable with ‘match’ instead of ‘cond’. Match was too clever here. But changed formatting already gets close, and a helper ges further: (define (equal-rest? chars . args) (equal? chars args)) (define (match-charlist-to-repr char-list) (let ((chars (reverse char-list))) (cond ((equal-rest? chars #\.) repr-dot) ((equal-rest? chars #\') repr-quote) ((equal-rest? chars #\,) repr-unquote) ((equal-rest? chars #\`) repr-quasiquote) ((equal-rest? chars #\, #\@) repr-unquote-splicing) ((equal-rest? chars #\# #\') repr-syntax) ((equal-rest? chars #\# #\,) repr-unsyntax) ((equal-rest? chars #\# #\`) repr-quasisyntax) ((equal-rest? chars #\# #\, #\@) repr-unsyntax-splicing) (else #f > Also, as mentioned regarding the naming convention, please write > ‘char-list’ or ‘chars’ rather than ‘chlist’. Fixed — thank you! >> +(define (wisp-read port) >> + "wrap read to catch list prefixes." > ^ > Capital letter. Also maybe mention PORT and the return value. Good point — the return value is pretty important here. New doc: "Wrap read to catch list prefixes: read one or several chars from PORT and return read symbols or replacement-symbols as representation for special forms." >> + (cond >> + ((or (< prefix-maxlen (length peeked)) (eof-object? (peek-char >> port)) (equal? #\space (peek-char port)) (equal? #\newline (peek-char port))) >> +(if repr-symbol ; found a special symbol, return it. >> +repr-symbol >> +(let unpeek >> +((remaining peeked)) > > Please avoid long lines and write ‘let’ on a line as in: > > (let ((x 2)) > …) > > or: > > (let loop ((x 1)) > …) > > (This is the style commonly used elsewhere in Guile.) Much nicer — thank you! (let ((prefix-maxlen 4)) (let longpeek ((peeked '()) (repr-symbol #f)) (cond ((or (< prefix-maxlen (length peeked)) (eof-object?
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hello Arne,
"Dr. Arne Babenhauserheide" skribis:
> I did the changes for the review. It took a while (sorry for that) but
> it got cleaner as a result (thank you!)
>
> Firstoff: I’d like to assign my copyright to the FSF. I’ll sign the
> papers once I receive them. Also I have an Employer disclaimer of rights
> on paper for Emacs already, so that should not cause trouble.
OK. I assumed you already emailed ass...@gnu.org the relevant form,
right? Let us know how it goes.
> Changes:
>
> - [X] LGPL
> - [X] Please add the new files to the relevant ‘Makefile.am’ files.
> - [X] Note the changes in Makefiles in the commit
> - [X] Please capitalize “Scheme” and “Wisp” (in general we like to pay
> attention to typography, spelling, and language in the manual.)
> - [X] s/(wisp)/, also referred to as @dfn{Wisp} (for ``Whitespace …'')/
> - [X] Two spaces after end-of-sentence periods, to facilitate navigation in
> Emacs.
> - [X] indent “the usual way”
> - [X] comments always with ;; except for margin comments
> - [X] (read-enable 'curly-infix)
> This needs to be:
> (eval-when (expand load eval)
> (read-enable 'curly-infix))
> - [X] Please make them #:use-module clauses in the ‘define-module’ form
> - [X] I’d encourage following the usual naming convention, so
> ‘in-indent?’, ‘in-comment?’, etc.
> - [X] use exception objects or SRFI-35 error conditions instead of throw with
> symbols
> - [X] add a test for source location info
Awesome.
> A change I did not do:
>
> - [ ] +Use record-types for the lines+. Reason: I decided not to do
> this because it currently needs to propagate the source properties
> when retrieving the code, so this is not a good match for a record
> type (it may become one with an annotated reader, but I’d like to
> shift that to a later change:
What about having a ‘location’ field in that record type? Would that
work for you? Or, alternatively, add source properties just on the
relevant part of the list.
Having lots of ‘car’ and ‘cdr’ in the code to access the various
“fields” of the line hinders readability and prevents proper
type-checking and error-reporting.
As I wrote back in June, source properties are not ideal and explicitly
storing location info, as is done in syntax objects, is preferable:
https://lists.gnu.org/archive/html/guile-devel/2023-06/msg8.html
Some comments:
> From 5857f8b961562d1ad2ae201401d5343233422eff Mon Sep 17 00:00:00 2001
> From: Arne Babenhauserheide
> Date: Fri, 3 Feb 2023 22:20:04 +0100
> Subject: [PATCH] Add language/wisp, wisp tests, and srfi-119 documentation
>
> * doc/ref/srfi-modules.texi (srfi-119): add node
> * module/language/wisp.scm: New file.
> * module/language/wisp/spec.scm: New file.
> * test-suite/tests/srfi-119.test: New file.
> * am/bootstrap.am (SOURCES): add language/wisp.scm and language/wisp/spec.scm
> * test-suite/Makefile.am (SCM_TESTS): add tests/srfi-119.test
[...]
> +(define wisp-uuid "e749c73d-c826-47e2-a798-c16c13cb89dd")
> +;; define an intermediate dot replacement with UUID to avoid clashes.
> +(define repr-dot ; .
> + (string->symbol (string-append "REPR-DOT-" wisp-uuid)))
As I wrote in June, please remove those UUIDs and use uninterned symbols
instead (which cannot be serialized but can be compared with ‘eq?’,
which is all we need.)
> +(define (match-charlist-to-repr charlist)
> + (let
> + ((chlist (reverse charlist)))
> +(cond
> + ((equal? chlist (list #\.))
> + repr-dot)
> + ((equal? chlist (list #\'))
> + repr-quote)
This would probably be more readable with ‘match’ instead of ‘cond’.
Also, as mentioned regarding the naming convention, please write
‘char-list’ or ‘chars’ rather than ‘chlist’.
> +(define (wisp-read port)
> + "wrap read to catch list prefixes."
^
Capital letter. Also maybe mention PORT and the return value.
> + (cond
> + ((or (< prefix-maxlen (length peeked)) (eof-object? (peek-char port))
> (equal? #\space (peek-char port)) (equal? #\newline (peek-char port)))
> +(if repr-symbol ; found a special symbol, return it.
> +repr-symbol
> +(let unpeek
> +((remaining peeked))
Please avoid long lines and write ‘let’ on a line as in:
(let ((x 2))
…)
or:
(let loop ((x 1))
…)
(This is the style commonly used elsewhere in Guile.)
> +(define (line-continues? line)
> + (equal? repr-dot (car (line-code line
> +
> +(define (line-only-colon? line)
> + (and
> + (equal? ":" (car (line-code line)))
> + (null? (cdr (line-code line)
> +
> +(define (line-empty-code? line)
> + (null? (line-code line)))
I think this illustrates excessive use of lists, car, and cdr, and its
impact on readability.
> +(define (with-read-options opts thunk)
> + (let ((saved-options (read-options)))
> +(dynamic-wind
> +(lambda ()
> + (read-options opts))
> +thunk
> +(lambda ()
> + (read-options saved-options)
> +
> +(define
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes:
> diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
> index 0cdf56923..5b82f8070 100644
> --- a/doc/ref/srfi-modules.texi
> +++ b/doc/ref/srfi-modules.texi
> +To execute a file with wisp code, select the language and filename
> +extension @code{.w} vie @code{guile --language=wisp -x .w}.
Arg, missed one capitalization error here. I have a local fix, but don’t
want to re-send the whole squashed change for that …
From 6ac896f1bbb5968eca0e4e7b95c5ee9ebf7d5dda Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 15 Aug 2023 00:43:53 +0200
Subject: [PATCH] Fix: capitalize Wisp
* doc/ref/srfi-modules.texi (srfi-119): capitalize Wisp
---
doc/ref/srfi-modules.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 5b82f8070..0ffc01252 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -5686,7 +5686,7 @@ define : factorial n @result{} (define
(factorial n)
* n : factorial @{n - 1@} @result{}(* n (factorial @{n - 1@}
@end example
-To execute a file with wisp code, select the language and filename
+To execute a file with Wisp code, select the language and filename
extension @code{.w} vie @code{guile --language=wisp -x .w}.
In files using Wisp, @xref{SRFI-105} (Curly Infix) is always activated.
--
2.41.0
> +;; Scheme-only implementation of a wisp-preprocessor which output a
> +;; scheme code tree to feed to a scheme interpreter instead of a
> +;; preprocessed file.
Same here, but for Scheme:
From 78287cf3b584e3c0dd481d1a4d84735165ad5e3a Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 15 Aug 2023 00:46:53 +0200
Subject: [PATCH] Fix: capitalize Scheme
* modules/language/wisp.scm (comments): capitalize Scheme
---
module/language/wisp.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/module/language/wisp.scm b/module/language/wisp.scm
index b4e885eec..f3127c9d3 100644
--- a/module/language/wisp.scm
+++ b/module/language/wisp.scm
@@ -21,7 +21,7 @@
;;; Commentary:
;; Scheme-only implementation of a wisp-preprocessor which output a
-;; scheme code tree to feed to a scheme interpreter instead of a
+;; Scheme code tree to feed to a Scheme interpreter instead of a
;; preprocessed file.
;; Limitations:
--
2.41.0
> diff --git a/module/language/wisp/spec.scm b/module/language/wisp/spec.scm
> new file mode 100644
> index 0..1efd3e8b2
> --- /dev/null
> +++ b/module/language/wisp/spec.scm
> …
> + #:printer write ; TODO: backtransform to wisp? Use source-properties?
and here …
From 9e797f17d5f001ca81b5c7e0a6b31399fec7ce6d Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Tue, 15 Aug 2023 00:56:07 +0200
Subject: [PATCH] Fix: capitalize Wisp
* modules/language/wisp/spec.scm (define-language): capitalize Wisp
---
module/language/wisp/spec.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/module/language/wisp/spec.scm b/module/language/wisp/spec.scm
index 1efd3e8b2..5f8feca9a 100644
--- a/module/language/wisp/spec.scm
+++ b/module/language/wisp/spec.scm
@@ -57,7 +57,7 @@
#:compilers `((tree-il . ,compile-tree-il))
#:decompilers `((tree-il . ,decompile-tree-il))
#:evaluator (lambda (x module) (primitive-eval x))
- #:printer write ; TODO: backtransform to wisp? Use source-properties?
+ #:printer write ; TODO: backtransform to Wisp? Use source-properties?
#:make-default-environment
(lambda ()
;; Ideally we'd duplicate the whole module hierarchy so that `set!',
--
2.41.0
That’s when I read my own patch after submission … but now that’s fixed.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
signature.asc
Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
"Dr. Arne Babenhauserheide" writes: > Attached is a new squashed patch. I’ll send another email with only the > commits for the individual changes on top of the original squashed patch > to avoid tripping up tools that extract diffs. This is the promised email with just the changes compared to the original squashed patch :-) I tried to create atomic changes, but the indentation change mixed a few together that I did not manage to separate (I did that indentation change too early and didn’t commit in time — I’m sorry for that). To minimize the impact I added a last change including just a diff without whitespace changes (-w). It starts with DIFF_WITHOUT_WHITESPACE I hope this simplifies reviewing for you! Best wishes, Arne From ec1d873871040a7bf99cc8f0ab940e09fd76977b Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Mon, 12 Jun 2023 01:22:56 +0200 Subject: [PATCH 02/11] SRFI-119: add new files to Makefile.am and bootstrap.am * am/bootstrap.am (SOURCES): add language/wisp.scm and language/wisp/spec.scm * test-suite/Makefile.am (SCM_TESTS) add tests/srfi-119.test --- am/bootstrap.am| 3 +++ test-suite/Makefile.am | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/am/bootstrap.am b/am/bootstrap.am index ff0d1799e..80a8dcdde 100644 --- a/am/bootstrap.am +++ b/am/bootstrap.am @@ -393,6 +393,9 @@ SOURCES = \ \ system/syntax.scm\ \ + language/wisp.scm\ + language/wisp/spec.scm \ + \ system/xref.scm \ \ sxml/apply-templates.scm \ diff --git a/test-suite/Makefile.am b/test-suite/Makefile.am index 81e63bce2..247d97746 100644 --- a/test-suite/Makefile.am +++ b/test-suite/Makefile.am @@ -162,7 +162,8 @@ SCM_TESTS = tests/00-initial-env.test \ tests/srfi-98.test \ tests/srfi-105.test \ tests/srfi-111.test \ -tests/srfi-171.test \ + tests/srfi-119.test \ + tests/srfi-171.test \ tests/srfi-4.test \ tests/srfi-9.test \ tests/statprof.test \ -- 2.41.0 From c07a1643ca4df87a552abd32cc00d80741ef8e17 Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Thu, 10 Aug 2023 08:32:17 +0200 Subject: [PATCH 03/11] SRFI-119: change license of language/wisp/spec to LGPLv3+ * module/language/wisp/spec.scm: changed license. This was changed from LGPLv3+ to MIT for inclusion in SRFI-119 and was now reverted back to LGPLv3+. Permission granted by Maxime Devos who had done changes in the MIT version. --- module/language/wisp/spec.scm | 33 ++--- 1 file changed, 14 insertions(+), 19 deletions(-) diff --git a/module/language/wisp/spec.scm b/module/language/wisp/spec.scm index 477036c71..821033432 100644 --- a/module/language/wisp/spec.scm +++ b/module/language/wisp/spec.scm @@ -6,25 +6,20 @@ ;;; Copyright (C) 2014--2023 Arne Babenhauserheide. ;;; Copyright (C) 2023 Maxime Devos -;;; Permission is hereby granted, free of charge, to any person -;;; obtaining a copy of this software and associated documentation -;;; files (the "Software"), to deal in the Software without -;;; restriction, including without limitation the rights to use, copy, -;;; modify, merge, publish, distribute, sublicense, and/or sell copies -;;; of the Software, and to permit persons to whom the Software is -;;; furnished to do so, subject to the following conditions: -;;; -;;; The above copyright notice and this permission notice shall be -;;; included in all copies or substantial portions of the Software. -;;; -;;; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, -;;; EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -;;; MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND -;;; NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS -;;; BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN -;;; ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN -;;; CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE -;;; SOFTWARE. + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 3 of the License, or (at your option) any later version. + + This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hi,
I did the changes for the review. It took a while (sorry for that) but
it got cleaner as a result (thank you!)
Firstoff: I’d like to assign my copyright to the FSF. I’ll sign the
papers once I receive them. Also I have an Employer disclaimer of rights
on paper for Emacs already, so that should not cause trouble.
Attached is a new squashed patch. I’ll send another email with only the
commits for the individual changes on top of the original squashed patch
to avoid tripping up tools that extract diffs.
Changes:
- [X] LGPL
- [X] Please add the new files to the relevant ‘Makefile.am’ files.
- [X] Note the changes in Makefiles in the commit
- [X] Please capitalize “Scheme” and “Wisp” (in general we like to pay
attention to typography, spelling, and language in the manual.)
- [X] s/(wisp)/, also referred to as @dfn{Wisp} (for ``Whitespace …'')/
- [X] Two spaces after end-of-sentence periods, to facilitate navigation in
Emacs.
- [X] indent “the usual way”
- [X] comments always with ;; except for margin comments
- [X] (read-enable 'curly-infix)
This needs to be:
(eval-when (expand load eval)
(read-enable 'curly-infix))
- [X] Please make them #:use-module clauses in the ‘define-module’ form
- [X] I’d encourage following the usual naming convention, so
‘in-indent?’, ‘in-comment?’, etc.
- [X] use exception objects or SRFI-35 error conditions instead of throw with
symbols
- [X] add a test for source location info
A change I did not do:
- [ ] +Use record-types for the lines+. Reason: I decided not to do
this because it currently needs to propagate the source properties
when retrieving the code, so this is not a good match for a record
type (it may become one with an annotated reader, but I’d like to
shift that to a later change:
> implementing the “annotated read” interface (info "(guile)
> Annotated Scheme Read"). That can come in a subsequent patch, though.
Ludovic Courtès writes:
> Overall I’m confident the code has been battle-tested (I suppose there
> are minimal changes compared to Wisp, right?), so I’ll comment mostly on
> cosmetic issues.
Yes, the code comes directly from Wisp. The original was simply
auto-translated. Naturally that’s no guarantee that there are no bugs,
but there should be few enough that this can be used in production.
>> From c7a50f632293cf88f241d45d1fd52fa2f58ce772 Mon Sep 17 00:00:00 2001
>> From: Arne Babenhauserheide
>> Date: Fri, 3 Feb 2023 22:20:04 +0100
>> Subject: [PATCH] Add language/wisp, wisp tests, and srfi-119 documentation
>>
>> * doc/ref/srfi-modules.texi (srfi-119): add node
>> * module/language/wisp.scm: New file.
>> * module/language/wisp/spec.scm: New file.
>> * test-suite/tests/srfi-119.test: New file.
>
> Please add the new files to the relevant ‘Makefile.am’ files.
Added.
>> +* SRFI-119::Wisp: simpler indentation-sensitive scheme.
>
> Please capitalize “Scheme” (in general we like to pay attention to
> typography, spelling, and language in the manual.)
>
>> +The languages shipped in Guile include SRFI-119 (wisp), an encoding of
>
> s/(wisp)/, also referred to as @dfn{Wisp} (for ``Whitespace …'')/
>
>> +Scheme that allows replacing parentheses with equivalent indentation and
>> +inline colons. See
>
> Two spaces after end-of-sentence periods, to facilitate navigation in
> Emacs.
Adjusted.
>> +(define-module (language wisp)
>> + #:export (wisp-scheme-read-chunk wisp-scheme-read-all
>> + wisp-scheme-read-file-chunk wisp-scheme-read-file
>> + wisp-scheme-read-string))
>
> Please remove tabs from this file and indent it “the usual way”. You
> can do that by passing it through Emacs and using ‘M-x indent-region’,
> or possibly using ‘guix style -f’.
I used M-x indent-region.
> Use two leading colons for comments, except for margin comments.
>> +(read-enable 'curly-infix)
>
> This needs to be:
>
> (eval-when (expand load eval)
> (read-enable 'curly-infix))
Adjusted — thank you (when to use eval-when was always a bit of a
mystery to me …).
> Please make them #:use-module clauses in the ‘define-module’ form above.
Done.
> Instead of using lists or pairs for “lines”, I suggest defining a proper
> record type, like:
> …
> This will make the code easier to read and type-clear.
Instead of this, I created a make-line procedure to make this easy to
refactor later when the code no longer needs adaptions when retrieving
the code part.
> I’d encourage following the usual naming convention, so ‘in-indent?’,
> ‘in-comment?’, etc.
Done.
>> + ((and inunderscoreindent (and (not (equal? #\space next-char))
>> (not (equal? #\newline next-char
>> + (throw 'wisp-syntax-error "initial underscores without following
>> whitespace at beginning of the line after" (last
>> indent-and-symbols)))
>
> I suggest using exception objects or SRFI-35 error conditions (they’re
> interchangeable) carrying information about the king of parsing error
> and its location. That way, the user
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Maxime Devos writes: >> [...] >> Can you make it LGPLv3+? It’s a small file anyway. > > Only if David A. Wheeler, Alan Manuel K. Gloria and Maxime Devos > agrees. Otherwise, you still need to include the license text: I just asked David and Alan, and when I checked the sources I realized that this was unnecessary: the file was LGPL originally and I once asked for permission to relicense to MIT for SRFI-119. So yes, thanks to permission of Maxime Devos the file can be LGPL. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Op 10-06-2023 om 18:40 schreef Ludovic Courtès: Instead of using these UUIDs, I suggest using known unique objects, “unique” in the sense of ‘eq?’. So it can be: (define repr-dot (make-symbol "repr-dot")) ;uninterned symbol IIRC, in a previous reply, this was already asked, and the response was that this doesn't actually work because of reasons. + ((and inunderscoreindent (and (not (equal? #\space next-char)) (not (equal? #\newline next-char + (throw 'wisp-syntax-error "initial underscores without following whitespace at beginning of the line after" (last indent-and-symbols))) I suggest using exception objects or SRFI-35 error conditions (they’re interchangeable) carrying information about the king of parsing error and its location. That way, the user interface, such as the compiler, can produce helpful error messages (and internationalized, too). Agreed. > [...] Can you make it LGPLv3+? It’s a small file anyway. Only if David A. Wheeler, Alan Manuel K. Gloria and Maxime Devos agrees. Otherwise, you still need to include the license text: > [...] +;;; The above copyright notice and this permission notice shall be +;;; included in all copies or substantial portions of the Software. [...] and having both this license text and the LGPLv3+ stuff in the same file is messy (technically possible if done carefully, but messy). As its a small file anyway, I don't think it's worth it unless everyone agrees to make in LGPLv3+. As far as I'm concerned, I agree. Best regards, Maxime Devos. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
Hi!
"Dr. Arne Babenhauserheide" skribis:
>>> Ludovic Courtès writes:
[...]
>> Given the complexities in changing the way languages are handled (the
>> required discussions, as we’ve seen in the not yet resolved discussion),
>> would you be OK with keeping the question about adding support for
>> SRFI-119 to Guile separate from the general discussion about language
>> handling?
>>
>> Are there improvements needed besides the ones I did thanks to the
>> review by Maxime or is this good to go?
>
> I created a new (squashed) version of the patch to simplify reviewing:
It does, thank you!
Overall I’m confident the code has been battle-tested (I suppose there
are minimal changes compared to Wisp, right?), so I’ll comment mostly on
cosmetic issues.
> From c7a50f632293cf88f241d45d1fd52fa2f58ce772 Mon Sep 17 00:00:00 2001
> From: Arne Babenhauserheide
> Date: Fri, 3 Feb 2023 22:20:04 +0100
> Subject: [PATCH] Add language/wisp, wisp tests, and srfi-119 documentation
>
> * doc/ref/srfi-modules.texi (srfi-119): add node
> * module/language/wisp.scm: New file.
> * module/language/wisp/spec.scm: New file.
> * test-suite/tests/srfi-119.test: New file.
Please add the new files to the relevant ‘Makefile.am’ files.
> +* SRFI-119::Wisp: simpler indentation-sensitive scheme.
Please capitalize “Scheme” (in general we like to pay attention to
typography, spelling, and language in the manual.)
> +@subsection SRFI-119 Wisp: simpler indentation-sensitive scheme.
> +@cindex SRFI-119
> +@cindex wisp
Same: “Scheme”, “Wisp”.
> +The languages shipped in Guile include SRFI-119 (wisp), an encoding of
s/(wisp)/, also referred to as @dfn{Wisp} (for ``Whitespace …'')/
> +Scheme that allows replacing parentheses with equivalent indentation and
> +inline colons. See
Two spaces after end-of-sentence periods, to facilitate navigation in
Emacs.
> +++ b/module/language/wisp.scm
> @@ -0,0 +1,761 @@
> +;;; Wisp
> +
> +;; Copyright (C) 2013, 2017, 2018, 2020 Free Software Foundation, Inc.
> +;; Copyright (C) 2014--2023 Arne Babenhauserheide.
> +;; Copyright (C) 2023 Maxime Devos
I see you don’t have a copyright assignment on file for Guile. If you
wish, you can assign copyright to the FSF:
https://lists.gnu.org/archive/html/guile-devel/2022-10/msg8.html
Let us know what you’d like to do.
> +(define-module (language wisp)
> + #:export (wisp-scheme-read-chunk wisp-scheme-read-all
> + wisp-scheme-read-file-chunk wisp-scheme-read-file
> + wisp-scheme-read-string))
Please remove tabs from this file and indent it “the usual way”. You
can do that by passing it through Emacs and using ‘M-x indent-region’,
or possibly using ‘guix style -f’.
> +; use curly-infix by default
Use two leading colons for comments, except for margin comments.
> +(read-enable 'curly-infix)
This needs to be:
(eval-when (expand load eval)
(read-enable 'curly-infix))
> +(use-modules
> + (srfi srfi-1)
> + (srfi srfi-11); for let-values
> + (ice-9 rw); for write-string/partial
> + (ice-9 match))
Please make them #:use-module clauses in the ‘define-module’ form above.
> +;; Helper functions for the indent-and-symbols data structure: '((indent
> token token ...) ...)
> +(define (line-indent line)
> + (car line))
> +
> +(define (line-real-indent line)
> + "Get the indentation without the comment-marker for unindented
> lines (-1 is treated as 0)."
> + (let (( indent (line-indent line)))
> + (if (= -1 indent)
> + 0
> + indent)))
> +
> +(define (line-code line)
> + (let ((code (cdr line)))
> + ; propagate source properties
> + (when (not (null? code))
> +(set-source-properties! code (source-properties line)))
> + code))
Instead of using lists or pairs for “lines”, I suggest defining a proper
record type, like:
(define-record-type
(input-line indent content)
input-line?
(indent input-line-indent)
(content input-line-content))
This will make the code easier to read and type-clear.
> +; literal values I need
> +(define readcolon
> + (string->symbol ":"))
> +
> +(define wisp-uuid "e749c73d-c826-47e2-a798-c16c13cb89dd")
> +; define an intermediate dot replacement with UUID to avoid clashes.
> +(define repr-dot ; .
> + (string->symbol (string-append "REPR-DOT-" wisp-uuid)))
> +
> +; allow using reader additions as the first element on a line to prefix the
> list
> +(define repr-quote ; '
> + (string->symbol (string-append "REPR-QUOTE-" wisp-uuid)))
> +(define repr-unquote ; ,
> + (string->symbol (string-append "REPR-UNQUOTE-" wisp-uuid)))
> +(define repr-quasiquote ; `
> + (string->symbol (string-append "REPR-QUASIQUOTE-" wisp-uuid)))
> +(define repr-unquote-splicing ; ,@
> + (string->symbol (string-append "REPR-UNQUOTESPLICING-" wisp-uuid)))
> +
> +(define repr-syntax ; #'
> + (string->symbol
Re: [PATCH] add SRFI-119 / language/wisp to Guile? (new patch, squashed)
> "Dr. Arne Babenhauserheide" writes:
>> Ludovic Courtès writes:
Why should Wisp be a separate package when other SRFIs are made part
of Guile? Your point about maintenance and evolving applies equally
to other SRFIs.
>>>
>>> That’s a good point. Making it available as (srfi srfi-119) would make
>>> sense I guess. I need to take a closer look…
>>
>> That’s where the documentation and tests are located:
>>
>> - test-suite/tests/srfi-119.test
>> - doc/ref/srfi-modules.texi::5666:@node SRFI-119
>>
>> The language implementation is in (language wisp) because that’s in the
>> language search path.
>
> Given the complexities in changing the way languages are handled (the
> required discussions, as we’ve seen in the not yet resolved discussion),
> would you be OK with keeping the question about adding support for
> SRFI-119 to Guile separate from the general discussion about language
> handling?
>
> Are there improvements needed besides the ones I did thanks to the
> review by Maxime or is this good to go?
I created a new (squashed) version of the patch to simplify reviewing:
From c7a50f632293cf88f241d45d1fd52fa2f58ce772 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide
Date: Fri, 3 Feb 2023 22:20:04 +0100
Subject: [PATCH] Add language/wisp, wisp tests, and srfi-119 documentation
* doc/ref/srfi-modules.texi (srfi-119): add node
* module/language/wisp.scm: New file.
* module/language/wisp/spec.scm: New file.
* test-suite/tests/srfi-119.test: New file.
---
doc/ref/srfi-modules.texi | 30 ++
module/language/wisp.scm | 761 +
module/language/wisp/spec.scm | 85
test-suite/tests/srfi-119.test | 81
4 files changed, 957 insertions(+)
create mode 100644 module/language/wisp.scm
create mode 100644 module/language/wisp/spec.scm
create mode 100644 test-suite/tests/srfi-119.test
diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 0ef136215..759e293ec 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -64,6 +64,7 @@ get the relevant SRFI documents from the SRFI home page
* SRFI-98:: Accessing environment variables.
* SRFI-105::Curly-infix expressions.
* SRFI-111::Boxes.
+* SRFI-119::Wisp: simpler indentation-sensitive scheme.
* SRFI-171::Transducers
@end menu
@@ -5662,6 +5663,34 @@ Return the current contents of @var{box}.
Set the contents of @var{box} to @var{value}.
@end deffn
+@node SRFI-119
+@subsection SRFI-119 Wisp: simpler indentation-sensitive scheme.
+@cindex SRFI-119
+@cindex wisp
+
+The languages shipped in Guile include SRFI-119 (wisp), an encoding of
+Scheme that allows replacing parentheses with equivalent indentation and
+inline colons. See
+@uref{http://srfi.schemers.org/srfi-119/srfi-119.html, the specification
+of SRFI-119}. Some examples:
+
+@example
+display "Hello World!" @result{} (display "Hello World!")
+@end example
+
+@example
+define : factorial n @result{} (define (factorial n)
+if : zero? n @result{} (if (zero? n)
+ . 1 @result{} 1
+ * n : factorial @{n - 1@} @result{}(* n (factorial @{n - 1@}
+@end example
+
+To execute a file with wisp code, select the language and filename
+extension @code{.w} vie @code{guile --language=wisp -x .w}.
+
+In files using Wisp, @xref{SRFI-105} (Curly Infix) is always activated.
+
+
@node SRFI-171
@subsection Transducers
@cindex SRFI-171
@@ -5705,6 +5734,7 @@ left-to-right, due to how transducers are initiated.
* SRFI-171 Helpers:: Utilities for writing your own transducers
@end menu
+
@node SRFI-171 General Discussion
@subsubsection SRFI-171 General Discussion
@cindex transducers discussion
diff --git a/module/language/wisp.scm b/module/language/wisp.scm
new file mode 100644
index 0..7a12e126a
--- /dev/null
+++ b/module/language/wisp.scm
@@ -0,0 +1,761 @@
+;;; Wisp
+
+;; Copyright (C) 2013, 2017, 2018, 2020 Free Software Foundation, Inc.
+;; Copyright (C) 2014--2023 Arne Babenhauserheide.
+;; Copyright (C) 2023 Maxime Devos
+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 3 of the License, or (at your option) any later version.
+
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+;;;
