From: "Marc Nieper-Wißkirchen" <marc@nieper-wisskirchen.de>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] add language/wisp to Guile?
Date: Tue, 28 Feb 2023 07:57:07 +0100 [thread overview]
Message-ID: <CAEYrNrR4PnVUGbv+oZ637XPZx7Mq7k4Hj+vHN2CsNK11WTfDdA@mail.gmail.com> (raw)
In-Reply-To: <2267642.HovnAMPojK@bastet>
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ßkirchen wrote:
[...]
> > 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 the
> "#!r6rs" directive, not directives of the form "#!<identifier>" more generally.
> I agree that implementations have more responsibilities with respect to
> "#!r6rs", that the presence of "#!r6rs" in a file is not enough to conclude
> 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 subtleties
> here and the potential for humans to confuse `#!language/wisp` with a shebang
> line. I raise the possibility of `#!language/wisp` only as an alternative if
> people are more comfortable using a mechanism that R6RS specifically designed
> 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 being
> bound: in Racket, a root-level `module` form is handled quite similarly to the
> `library` form in R6RS, which says in 7.1 [1]:
>
> >>>> The names `library`, `export`, `import`, [...] appearing in the library
> 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`: instead,
> 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 `module`
> which can be used to create submodules with the same syntax as a root-level
> `module`, but that isn't relevant to the handling of a `root-level` module
> 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 perspective.
> 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 contemplated
> `#!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 `(rnrs)`
> would parse:
>
> >>>> #!r7rs #(1 2 3)
>
> as:
>
> >>>> (quote #(1 2 3))
>
> The other direction is a bit trickier, but the R7RS specification for `read`
> 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-self-
> evaluating-vector" and have `read` from `(scheme base)` produce a value of
> 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 (), but
> `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_chap_A
> [3]: https://docs.racket-lang.org/r6rs/Running_Top-Level_Programs.html
> [4]: https://docs.racket-lang.org/r6rs/Installing_Libraries.html
next prev parent reply other threads:[~2023-02-28 6:57 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.886.1677397547.13386.guile-devel@gnu.org>
2023-02-26 11:02 ` [PATCH] add language/wisp to Guile? Marc Nieper-Wißkirchen
2023-02-26 23:22 ` Philip McGrath
2023-02-27 5:00 ` Dr. Arne Babenhauserheide
2023-02-27 7:26 ` Marc Nieper-Wißkirchen
2023-02-28 4:27 ` Philip McGrath
2023-02-28 6:57 ` Marc Nieper-Wißkirchen [this message]
2023-02-03 21:26 Dr. Arne Babenhauserheide
2023-02-04 15:08 ` Maxime Devos
2023-02-04 15:46 ` Dr. Arne Babenhauserheide
2023-02-04 19:09 ` Maxime Devos
2023-02-04 21:35 ` Dr. Arne Babenhauserheide
2023-02-05 15:08 ` Maxime Devos
2023-02-14 8:32 ` Dr. Arne Babenhauserheide
2023-02-14 21:24 ` Dr. Arne Babenhauserheide
2023-02-14 23:01 ` Maxime Devos
2023-02-15 1:46 ` Matt Wette
2023-02-16 21:38 ` Dr. Arne Babenhauserheide
2023-02-17 1:26 ` Matt Wette
2023-02-23 11:36 ` Ludovic Courtès
2023-02-23 17:48 ` Dr. Arne Babenhauserheide
2023-02-23 18:42 ` Maxime Devos
2023-02-24 15:45 ` Ludovic Courtès
2023-02-24 16:34 ` Dr. Arne Babenhauserheide
2023-03-08 10:34 ` Dr. Arne Babenhauserheide
2023-02-24 23:48 ` Maxime Devos
2023-02-24 23:51 ` Maxime Devos
2023-02-25 0:15 ` Matt Wette
2023-02-25 10:42 ` Maxime Devos
2023-02-17 23:06 ` Maxime Devos
2023-02-18 3:50 ` Philip McGrath
2023-02-18 15:58 ` Maxime Devos
2023-02-18 19:56 ` Matt Wette
2023-02-21 12:09 ` Dr. Arne Babenhauserheide
2023-02-26 7:45 ` Philip McGrath
2023-02-26 15:42 ` Maxime Devos
2023-02-26 16:14 ` Dr. Arne Babenhauserheide
2023-02-26 17:58 ` Matt Wette
2023-02-26 18:03 ` Dr. Arne Babenhauserheide
2023-02-26 18:20 ` Matt Wette
2023-02-26 21:39 ` Dr. Arne Babenhauserheide
2023-10-02 14:59 ` Christine Lemmer-Webber
2023-02-23 7:59 ` Maxime Devos
2023-02-23 8:51 ` Dr. Arne Babenhauserheide
2023-02-23 18:04 ` Maxime Devos
2023-02-23 18:22 ` Maxime Devos
2023-02-23 18:36 ` Maxime Devos
2023-02-23 18:37 ` Maxime Devos
2023-02-15 8:36 ` Dr. Arne Babenhauserheide
2023-02-15 20:13 ` Maxime Devos
2023-02-16 7:01 ` Dr. Arne Babenhauserheide
2023-02-16 8:03 ` Dr. Arne Babenhauserheide
2023-02-16 11:30 ` Maxime Devos
2023-02-16 21:35 ` Dr. Arne Babenhauserheide
2023-09-30 13:17 ` Christine Lemmer-Webber
2023-09-30 20:09 ` Maxime Devos
2023-10-02 14:48 ` Christine Lemmer-Webber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEYrNrR4PnVUGbv+oZ637XPZx7Mq7k4Hj+vHN2CsNK11WTfDdA@mail.gmail.com \
--to=marc@nieper-wisskirchen.de \
--cc=guile-devel@gnu.org \
--cc=philip@philipmcgrath.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).