From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Dr. Arne Babenhauserheide" Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] add language/wisp to Guile? Date: Sat, 04 Feb 2023 16:46:48 +0100 Message-ID: <877cwxe4ar.fsf@web.de> References: <87h6w2fkz8.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5567"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.13; emacs 28.1 Cc: guile-devel@gnu.org To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Feb 04 18:20:27 2023 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pOMDD-0001Es-2O for guile-devel@m.gmane-mx.org; Sat, 04 Feb 2023 18:20:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOMCr-0003hY-Ay; Sat, 04 Feb 2023 12:20:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOMCp-0003hI-GG for guile-devel@gnu.org; Sat, 04 Feb 2023 12:20:03 -0500 Original-Received: from mout.web.de ([212.227.15.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pOMCn-0001pf-5C for guile-devel@gnu.org; Sat, 04 Feb 2023 12:20:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1675531199; bh=yGtGfUdqxC4Onp6IEijy2F6xXpl0lmJG20cQ8bui6H8=; h=X-UI-Sender-Class:References:From:To:Cc:Subject:Date:In-reply-to; b=KgvLHtPq1+jk4i6K0yccWhR8BzdGxX8wRk2Zwxm/RPu1N/mhcmqTfk0dTfnEUm9LK B4MfxtYYR+tB0DnSCdqlPAxMot4RXHcPv0PUOhxM7cv9qHeHx2Xi3npirr+vVtt7pJ PgureDmhHcd2M+iRpPSl+UlYcyRfu4vKNO7NEyvo+n+zQaouM/xcgdaaMGVepa4mG/ 6oVMd8NCFDTh+V3PSFRAG1JGhniY2RWihVCEtqZeWe5+edHj4hhTIHxQilB2ifDS5v rQVLuUFZjkYZJZ8EDYcFW7SqkZycIXv06gFa77RH3qAfdlp8+BcE/drx6dfF0QiGVE O1WyHfxe4dAXA== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from fluss ([84.149.95.143]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MmQcf-1oy83b41FR-00iR4r; Sat, 04 Feb 2023 18:19:59 +0100 In-reply-to: X-Provags-ID: V03:K1:OKSXYgcI+R49rlB3qAhRcBFmMNiz36HcTNxExJG4MPtYjXZoMDE DlwClOKZeLrCL+rMVPXTYpPehXYX9Ua+MPL5Z5JTw0NZrjxE/yBT6bhp/kWRP7cIDCWuiyo 0BqO7kFYagiI8G7xK2MEl3wojHBInw5ClfghjWZo/q2SfjDdWP5GcVvlFQxP3KPZMXPdwuh mxx7rgE/Axx9eYYsEY5+w== UI-OutboundReport: notjunk:1;M01:P0:U21O0Ykdx64=;T8ABmLWxshYiT6iXMUsXuVKJ2TC CSV8Ct/5dDi0iTordoPSjE/g28X39PN1O+ZiNREcs32MZ1/3itxzz/EHN6xVL/e18PCoTZSAG ReLLCuJ+iUQp//EzxIWiV8nNqxrIIEKdClYR1RKS703DlHt/+3Yanfvkw+PoqzA0UAhjM850c uJn+WqWXWxC/PFENj09E9S9jgzoQI04j9n0dbcyxily0RuZiFtSepfBtXAZRTMeznmb4rwRe8 n0BMqPynVWb/twY30bUKDZv8AaAizXIFUtqAyvYK2yW52Ao/1dL4bdkoyUHCh4cv36FEOZicY 7Hc3F3+q4oL3FR7ay0dTer1XGTVmg3YQQ/A8Nwg2Gi2GzQ7yyxYbLJq7MT4EPYyaadepKR+r5 GfVAT6fXHlAhDiJY9RB7VVYx7wQ9AIk4/Ox8XrOwYcN8oc5RwfdD/WG4xUqKYIMq7InjC2JAH VhTTO+QWGoPkYSbRz6YlIkWl1poivKhnIRz4uzVsTpjqUoRjsDyWCiXwIQSGS5UwVYZfhII/k U61FqrQOqN2/y9G1yC4yIpq7GgmMmapfNbnP+Ru3sRlTdSVoB+lEQPHNeFzNIaE/ELc6++WlO C+757zLLEHrVbDEo9cv74uT6ASbnf+VcqFo488q/eFzSAtKMJiKLNZ86DJVecAitSmmw3Ja9r zHBZtJfEzJ8+Fbr4oOCegIQ0jS7SE4IFUelshH0j+pNI1muoUy6pb9Sstk469PaDbFq5O7/zS NssBCvZD9aq78qoJOEO1PdGcFH9mEfWqunHiBtED8EDJ8dlLJTKdeIXruaQnwFZPMXGmiroa Received-SPF: pass client-ip=212.227.15.3; envelope-from=arne_bab@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21683 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=C2=B2 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=E2=80=99s a good point =E2=80=94 I should really have written it :-) >> So I=E2=80=99d 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 =E2=80=94 I wrote = that in the documentation. I didn=E2=80=99t want to do that unconditionally, bec= ause 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=E2=80=99m not sure anymore. It has been years since I wrote that code =E2= =80=A6 I think it was because I did not understand what that would mean for the program. And I actually still don=E2=80=99t know =E2=80=A6 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 (=CE=A3 . 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 #\# (=CE=BB (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 (=3D 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=E2=80=99ll do that =E2=80=A6 >> +(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 =E2=80=94 does uninterned symbol mean it can=E2=80=99t 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 > + (=CE=BB () > + (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 =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein, ohne es zu merken. draketo.de --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAmPek70QHGFybmVfYmFi QHdlYi5kZQAKCRAT741FJAPD6zngEAC9SERUxOTf3mlseLZqeKy4iGj4vZo5Kgd7 GRwu82MV3Oj+EbWNDF+nRkmC6YdVpIyNW4GiRIIV06ZKc5/iTge9Eq589YInQ6Zt R7j2aw6Bl7DDd1kJFJfi/mBtUZvQwnqHo4cj7eWbNNBmg4DhKhGsZpw/QZZFM97E c6wFLmJiWqtnlBq6JFl//1tmaTv78tR8Iu5suJcjyFcZWxF7INSoivXQUwTWK66d x/kwCegGyUoLNymEjd8yXr3eJYKjuIJH8fWWE2QN5xxxJrlmMDUg2Tv8vO6ahSk2 /1E6tr4pM8V++OckvxcUiM1N5xibPLJqhNqGzs4uYBAuE8lcGfuT1IvDpP1VGm6x GLof42hairvYWEvjEd1Fn+im3K8Qh6TwZee+xRo1xuo9Ttllvvk50whMIh4fFm7A SHFcQV6nH6vy269+DlsyLixqsGzz690H3a1UjveuQ9ri1Wf5B8oDDGYnEJcO9Xms CXMeFYnH6L4qjRVz9HF3dmLsnAaIjW2TnpdXGL2dZ5cFVFeTrEiqr676r3m3Ra4k bP4e6oiH7hlKPPvJpEI4gc//eSghQfI8gr8esOa1ksefeYhQ2PnoLyaCDQ31yd53 MemjgoxJOirqGzCtYQrenmPc5+jcxOpC5/auwuvjNvHBpk0tc8dJHZasJ3xLtaan mkY5nUCAtYjEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAmPek74QHGFy bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSPizA/4hXvsU38CxF/2uNCW+oHzrNNW2 B9UP6QJ6SUoT8CkR63vMBBIXOLvefOjLzlDXmTk+YlZKf0KxTUPGrgIi0a1nKeAt r0BRHmGL3yKx1/mKeAaTyWFXQFve3rxChaV/4bwIDDYwlrynP1/yRAQRBN6cLHOs TWiYl5V3fxZ++RVlVQ== =wFO0 -----END PGP SIGNATURE----- --=-=-=--