From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= <marc@nieper-wisskirchen.de> Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] add language/wisp to Guile? Date: Tue, 28 Feb 2023 07:57:07 +0100 Message-ID: <CAEYrNrR4PnVUGbv+oZ637XPZx7Mq7k4Hj+vHN2CsNK11WTfDdA@mail.gmail.com> References: <mailman.886.1677397547.13386.guile-devel@gnu.org> <3517394.V25eIC5XRa@bastet> <CAEYrNrSLwq1cc9XVGxSmxMuzWuREtsC8zbUC_7WnJnzW8urN0w@mail.gmail.com> <2267642.HovnAMPojK@bastet> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7154"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org To: Philip McGrath <philip@philipmcgrath.com> Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Feb 28 07:57:52 2023 Return-path: <guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org> 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 <guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org>) id 1pWtvq-0001ao-Jx for guile-devel@m.gmane-mx.org; Tue, 28 Feb 2023 07:57:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <guile-devel-bounces@gnu.org>) id 1pWtvU-00044X-8j; Tue, 28 Feb 2023 01:57:28 -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 <marc@nieper-wisskirchen.de>) id 1pWtvS-00044O-3N for guile-devel@gnu.org; Tue, 28 Feb 2023 01:57:26 -0500 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.162]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <marc@nieper-wisskirchen.de>) id 1pWtvP-00080P-9l for guile-devel@gnu.org; Tue, 28 Feb 2023 01:57:25 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1677567439; cv=none; d=strato.com; s=strato-dkim-0002; b=seAM0QSuGXdbqJVVP/6/GQ2xe7VK4Is1bTk55LbmAhrCMOXoZJEEpkz6v1tMNRRzm8 ElY2DM0OFR0+wp2jjp5YYq+/t9C88uxgkvCvuZTcoivQHzOpNHLZ5RfY8HR9S8Jyo2Gn yIddh/WgMMzc+pjLnVmbOGqMw0aI7iVAuGxUq3B+9HTTDKqtMX1wxLTaW/3rgffkdogN trFnRFu6ylU5lrD/WLx1IeT3+NRGjETMnxTnWRRUrw/+IGxQJgNqoH1EbPsCXbebDjyp VebCu4kFvm8BxrbpeLP0gHbsxRwWx7BtAkCINF4cM6iQtBibDwSxgm7Hk23jDl+U0EdF xN1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1677567439; s=strato-dkim-0002; d=strato.com; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=siN8o16I8hTmMZZw2UUYb5cytJtEsvRgSfjxfcmlkuQ=; b=gE+D1SppbhC7gJCbov8J8tsiTXf3RtKjvTcpaA7o2Ju9V097dV7CIDpRaMMlOvT9tq ZSWLhayNuzmxQFysRMH2wzcugk6SzcGFicv9cbBjBEfycAIieTcX3r0Slec9cYQxct6p WTJ8m1lwQWJCLNrxLnK2sIkpkGqkDmtPUcBmxl8w2hXPiol/dI/MEUihZUitS1C52Ekb DMqSZ/dQTSL7A+aFgZa8zk9tg4dYEHukbGOlA9XlCpXjTYh1uykVGuZlv8I2G5Bc5V1R 1tAHl8yytiJ+Xzp6YAz+JUARqU5xMQjvHNlvYvjjjUY6tjfocgiQY26gwaduu2rrJvbo t9Eg== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1677567439; s=strato-dkim-0002; d=nieper-wisskirchen.de; h=Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:Cc:Date: From:Subject:Sender; bh=siN8o16I8hTmMZZw2UUYb5cytJtEsvRgSfjxfcmlkuQ=; b=i7lvHiSucC/8wZl4qEXqFj5MKDm45pQKZpUnX5UzDp9YQtpDoMKd2whi3ftilJIYIZ oDSEwFvx7ktLY4XkgtTqFGi+4b/rXWdvocWZjpaOuhDjoZdnj9UD8TN0CcQZda3GmSkw /SqLH0rhuYYploHPss/i/pm8Jb8ERsRuEeH4Sadw49WnttxuSH6h0gRC3DGx6FBrTy5O M6mAWpfjpz5mXjMoyXfhszoEbwO3gA1wqip+EPOopVeTw8Ld2QgVHWZ9oG5iHI8N1eO/ zJphPxi6uIhT4gcxtDB8STW6Z0NpVmIFXeXH7JVyGREx+ScgulNQGhGyEeKTAzEqoiJ8 1vLQ== X-RZG-AUTH: ":IW0WdmCmcvpIrP2+VJuPtIhjJvc4Ig+QdhX22iZVwSDOx4Kp3cYsBVGy6CZgmO/guIaKVMt57p33" Original-Received: from mail-wr1-f48.google.com by smtp.strato.de (RZmta 49.3.0 AUTH) with ESMTPSA id e79b15z1S6vJtVe (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for <guile-devel@gnu.org>; Tue, 28 Feb 2023 07:57:19 +0100 (CET) Original-Received: by mail-wr1-f48.google.com with SMTP id bt28so8589809wrb.8 for <guile-devel@gnu.org>; Mon, 27 Feb 2023 22:57:19 -0800 (PST) X-Gm-Message-State: AO0yUKUQqTnDFmJydP1eSu0pAy7WDzPqhHuszHXtJmztBuecfrq6Ztrs a5ccvXID39zCeKQ3oPdz9VuADLnPShInnouMrLY= X-Google-Smtp-Source: AK7set+hNvJ8XYoW7RnyHTJWGEXcw+85A/S8UVJvrXtN0PtxYlDiqil83sktZcDb6jCU6SOGQ46KN/Bv1PUObHSU+2E= X-Received: by 2002:adf:d0c8:0:b0:2c5:633c:eec7 with SMTP id z8-20020adfd0c8000000b002c5633ceec7mr292387wrh.3.1677567438928; Mon, 27 Feb 2023 22:57:18 -0800 (PST) In-Reply-To: <2267642.HovnAMPojK@bastet> X-Gmail-Original-Message-ID: <CAEYrNrR4PnVUGbv+oZ637XPZx7Mq7k4Hj+vHN2CsNK11WTfDdA@mail.gmail.com> Received-SPF: none client-ip=81.169.146.162; envelope-from=marc@nieper-wisskirchen.de; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=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" <guile-devel.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/guile-devel>, <mailto:guile-devel-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/guile-devel> List-Post: <mailto:guile-devel@gnu.org> List-Help: <mailto:guile-devel-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guile-devel>, <mailto:guile-devel-request@gnu.org?subject=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:21757 Archived-At: <http://permalink.gmane.org/gmane.lisp.guile.devel/21757> Am Di., 28. Feb. 2023 um 05:27 Uhr schrieb Philip McGrath <philip@philipmcgrath.com>: > > Hi, > > On Monday, February 27, 2023 2:26:47 AM EST Marc Nieper-Wi=C3=9Fkirchen w= rote: [...] > > Nevertheless, I am not sure whether it is relevant to the point I > > tried to make. The "#!r6rs" does not indicate a particular language > > (so tools scanning for "#!r6rs" cannot assume that the file is indeed > > an R6RS program/library). > > I think I had missed that some of your remarks are specifically about th= e > "#!r6rs" directive, not directives of the form "#!<identifier>" more gene= rally. > I agree that implementations have more responsibilities with respect to > "#!r6rs", that the presence of "#!r6rs" in a file is not enough to conclu= de > that the file is an R6RS program/library, and that a straightforward > implementation of "#!r6rs" as reading like "#lang r6rs" in the manner of = my > previous examples would not conform to R6RS. Yes, this summarizes it well. > Also, on the broader question, my first preference would be for Guile to > implement `#lang language/wisp`, not least to avoid the confusing subtlet= ies > here and the potential for humans to confuse `#!language/wisp` with a she= bang > line. I raise the possibility of `#!language/wisp` only as an alternative= if > people are more comfortable using a mechanism that R6RS specifically desi= gned > for implementation-defined extensions. When wisp only changes the lexical syntax, `#!wisp` would be fine (and it cannot be confused with a shebang line IMO because a shebang line must begin with `#! ` or `#!/`. However, the authors of the R6RS clearly had minor changes of the lexical syntax in mind when they introduced comments like `#!r6rs` or `#!chezscheme` (e.g. Chez Scheme adds a syntax for gensyms). As wisp radically changes how the text is tokenized, something like `#!wisp` probably only follows the latter but not the spirit of R6RS. > Nonetheless, I'll try to explain why I think "#!r6rs" can be handled, and= is > handled by Racket, consistently with both "#lang r6rs" and the behavior > specified in the report. > > > > > Of course, R6RS gives implementations the freedom to modify the reader > > in whatever way after, say, "#!foo-baz" was read. Thus, "#!foo-baz" > > could be defined to work like Racket's "#lang foo-baz," reading the > > rest of the source as "(module ...)". But as long as we stay within > > the confines of R6RS, this will only raise an undefined exception > > because, in general, "module" is not globally bound. > > > > Before getting to the general point, specifically about "module" not bein= g > bound: in Racket, a root-level `module` form is handled quite similarly t= o the > `library` form in R6RS, which says in 7.1 [1]: > > >>>> The names `library`, `export`, `import`, [...] appearing in the libr= ary > syntax are part of the syntax and are not reserved, i.e., the same names = can > be used for other purposes within the library or even exported from or > imported into a library with different meanings, without affecting their = use in > the `library` form. > > None of the libraries defined in R6RS export a binding for `library`: ins= tead, > the implementation must recognize it somehow, whether by handling it as a > built-in or binding it in some environment not standardized by R6RS. > > (The `racket/base` library/language does in fact export a binding for `mo= dule` > which can be used to create submodules with the same syntax as a root-lev= el > `module`, but that isn't relevant to the handling of a `root-level` modul= e > form itself.) Sure, but not relevant. I didn't say that module is bound at the Racket top-level, only that an R6RS implementation wouldn't expect it (and cannot interpret it because it is not bound). > > I don't want to contradict you; I just mean that a plain "#!r6rs" > > without a top-level language where "module" is bound is not equivalent > > to "#lang" and that trying to switch to, say, Elisp mode with > > "#!elisp" would leave the boundaries of the Scheme reports (and when > > this is done, this specific discussion is moot). > > > > [...] > > > > (It must be compatible with calling the procedures "read" and "eval" > > directly, so "#!r6rs" must not wrap everything in some module form, > > say.) > > Now I'll try to sketch Racket's handling of "#!r6rs" from an R6RS perspec= tive. > For the sake of a concrete example, lets consider this program: It is obvious that one can do it; it is just outside the realm of R6RS because the "non-conformant mode" can be any (even a C-interpreting mode) that can listen to whatever magic numbers there may be in the input. That said, the use of "#!r6rs" as such a magic marker is not in the spirit of the lexical syntax of R6RS (where it was introduced). This has been my original point. Doable, of course. [...] > > In an implementation that supports, say, > > R6RS and R7RS, "#!r6rs" can only switch the lexical syntax but cannot > > introduce forms that make the implementation change the semantics from > > R7RS to R6RS, e.g., in the case of unquoted vector literals. > > I'm not very familiar with R7RS, and, quickly skimming R7RS Small, I didn= 't > see a notion of directives other than `#!fold-case` and `#!no-fold-case`. > (That's a bit ironic, given that the R6RS editors seem to have contemplat= ed > `#!r7rs` *before* they considered `#!r6rs`.) I think a similar technique = could > work in this case, though. From an R6RS perspective, at least, an > implementation could implement a directive such that the `read` from `(rn= rs)` > would parse: > > >>>> #!r7rs #(1 2 3) > > as: > > >>>> (quote #(1 2 3)) > > The other direction is a bit trickier, but the R7RS specification for `re= ad` > from `(scheme base)` does say that "implementations may support extended > syntax to represent record types or other types that do not have datum > representations." It seems an implementation could define a type "non-sel= f- > evaluating-vector" and have `read` from `(scheme base)` produce a value o= f > that type when given: > > >>>> #!r6rs #(1 2 3) This cannot work because the macros can detect the presence of quotes before vector literals; the reader must not insert quotes that weren't there. The expander must be made aware of what the valid literal expressions are. In Racket, this can be done with #%datum, but this does not easily translate to R6RS (because of the presence of unwrapped syntax objects in R6RS). > Presumably `eval` from `(scheme eval)` would raise an error if asked to > evaluate such a datum, as it does if asked to evaluate an unquoted (), bu= t > `quote` from `(scheme base)` would arrange to replace such a datum with a > vector. > > (I'm not at all sure that an implementation *should* do such a thing: I'm= only > trying to explain why I don't think the Scheme reports prohibit it.) My point is that just switching the lexical syntax won't do it. Of course, you can interpret a leading `#!r7rs` as switching from conformant to non-conformant R6RS mode, but this would again be a misuse (I guess this is also the reason why Racket favors `#lang` over `#!...`. But even then, one has a problem because the change cannot be file local. If a library in R7RS mode exports a macro that is used in a context with R6RS mode, the vector literals inserted by the macro should still be interpreted in R7RS mode. If we could have #%datum, this wouldn't be a problem. Thank you a lot for your insights and your detailed explanations, Marc > -Philip > > [1]: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1 > [2]: http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-3.html#node_cha= p_A > [3]: https://docs.racket-lang.org/r6rs/Running_Top-Level_Programs.html > [4]: https://docs.racket-lang.org/r6rs/Installing_Libraries.html