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