> Why add Wisp? > > For Wisp: it is then available directly wherever Guile is available. > This will make it much easier for people to follow tutorials. I'm not convinced of this argument, because package managers exist, but ... > For Guile: > > - Wisp has proven to be good at enabling people to get an > entrance to Scheme² without pulling them out of the community. > - [...] ... all good points, and the implementation of Wisp is tiny anyway. For an additional reason: Wisp is a SRFI (Scheme Requests for Implementation) and Guile is a Scheme implementation. > So I’d like to ask: can we merge Wisp as supported language into Guile? From some conversations elsewhere, I got the impression that (use-modules (foo)) will search for foo.scm and not in foo.w. I think you'll need to tweak the loading mechanism to also look for foo.w instead of only foo.scm, if not done already. Also, I think that when foo.go exists, but foo.scm doesn't, then Guile refuses to load foo.scm, though I'm less sure of that. If this is the case, I propose removing the requirement that the source code is available, or alternatively keep the 'source code available' requirement and also accept 'foo.w', if not done already. > +; Set locale to something which supports unicode. Required to avoid > using fluids. > +(catch #t * Why avoid fluids? * Assuming for sake of argument that fluids are to be avoided, what is the point of setting the locale to something supporting Unicode? As-is, it now becomes impossible to use 'gettext' to translate software to non-English locales when the software imports (language wisp), which seems unfortunate to me. If you elaborate on what your goal here is, maybe I have an alternative solution. > + ;; allow using "# foo" as #(foo). > + (read-hash-extend #\# (λ (chr port) #\#)) That's a rather Wisp-specific extension, but it appears you are extending things globally. Instead, I propose extending it temporarily, with the undocumented '%read-hash-procedures' fluid. > + (let > + ( > + (l Lonely parenthesis. + (not (= 0 (line-real-indent (car lines ))))); -1 is a line with a comment Superfluous space after 'lines'. > + ; simple recursiive step to the next line I think the convention is ';;', OTOH there exist multiple conventions. +(define (wisp-scheme-replace-inline-colons lines) + "Replace inline colons by opening parens which close at the end of the line" Too much space; convention is two spaces. (Similar styles issues in other places.) "guix style" might be useful. > +(define (wisp-replace-paren-quotation-repr code) > + "Replace lists starting with a quotation symbol by > + quoted lists." > + (match code > + (('REPR-QUOTE-e749c73d-c826-47e2-a798-c16c13cb89dd a ...) > + (list 'quote (map wisp-replace-paren-quotation-repr a))) > [...] > +(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))) There is a risk of collision -- e.g., suppose that someone translates your implementation of Wisp into Wisp. I imagine there might be a risk of misinterpreting the 'REPR-QUOTE-...' in wisp-replace-parent-quotation-repr, though I haven't tried it out. As such, assuming this actually works, I propose using uninterned symbols instead, e.g.: (define repr-dot (make-symbol "REPR-DOT")). If this change is done, you might need to replace + ;; literal array as start of a line: # (a b) c -> (#(a b) c) + ((#\# a ...) + (with-input-from-string ;; hack to defer to read + (string-append "#" + (with-output-to-string + (λ () + (write (map wisp-replace-paren-quotation-repr a) + (current-output-port))))) + read)) (unverified -- I think removing this is unneeded but I don't understand this REPR-... stuff well enough). Also, I wonder if you could just do something like (apply vector (map wisp-replace-paren-quotation-repr a)) instead of this 'hack to defer to read' thing. This seems simpler to me and equivalent. (AFAIK, these REPR-... symbols are never written to a port or turned into syntax, so I think that uninterned symbols would work here.) (Aside from the REPR-... thing, I'm assuming (language wisp) is alright -- the SRFI is in 'final' status and it has been stable for years now, after all.) Greetings, Maxime