Thank you for your review! Maxime Devos writes: >> 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. That’s a good point — I should really have written it :-) >> 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. This needs an addition to the extensions via guile -x .w — I wrote that in the documentation. I didn’t want to do that unconditionally, because detecting a wisp file as scheme import would cause errors. Is there a way to only extend the loading mechanism to detect .w when language is changed to wisp? readable uses (set! %load-extensions (cons ".sscm" %load-extensions)) Would that be the correct way of doing this? > 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. I think accepting any extension supported by any language in Guile would be better. >> +; Set locale to something which supports unicode. Required to avoid >> using fluids. >> +(catch #t > > * Why avoid fluids? I’m not sure anymore. It has been years since I wrote that code … I think it was because I did not understand what that would mean for the program. And I actually still don’t know … Hoow would I do that instead with fluids? > * Assuming for sake of argument that fluids are to be avoided, > what is the point of setting the locale to something supporting > Unicode? I had problems with reading unicode symbols. Things like define (Σ . args) : apply + args > 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. That is very much not what I want. > If you elaborate on what your > goal here is, maybe I have an alternative solution. This is to ensure that Wisp are always read as Unicode. Since it uses regular (read) as part of parsing, it must affect (read), too. >> + ;; 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. Thank you! Will be fixed :-) > + (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. I’ll do that … >> +(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. This is actually auto-translated from wisp via wisp2lisp :-) > As such, assuming this actually works, I propose using uninterned > symbols instead, e.g.: > > (define repr-dot (make-symbol "REPR-DOT")). That looks better — does uninterned symbol mean it can’t be mis-interpreted? Can I (match l ...) on uninterned symbols? They are used to match on precisely these symbols later. Can I write it into a string and then read it back? When I see them, I have to turn them into a different representation that I can then write back into the string and allow it to be read by the normal reader. > 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). The REPR supports the syntactic sugar like '(...) for (quote ...) by turning (' ...) into '(...). Also it is needed to turn ((. a b c)) into (a b c). However the literal array is used to make it possible to define procedure properties which need a literal array. > 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. That looks much cleaner. Thank you! > (AFAIK, these REPR-... symbols are never written to a port or turned > into syntax, so I think that uninterned symbols would work here.) They are unread into a string. > (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.) Thank you! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de