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: Mon, 27 Feb 2023 08:26:47 +0100
Message-ID: <CAEYrNrSLwq1cc9XVGxSmxMuzWuREtsC8zbUC_7WnJnzW8urN0w@mail.gmail.com>
References: <mailman.886.1677397547.13386.guile-devel@gnu.org>
 <CAEYrNrSa+U4ZCwa5G_vkR1WJH17H_-QBcnPnOrM7FafjP7gJPQ@mail.gmail.com>
 <3517394.V25eIC5XRa@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="13650"; 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 Mon Feb 27 09:12:49 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 1pWYcr-0003Je-38
	for guile-devel@m.gmane-mx.org; Mon, 27 Feb 2023 09:12:49 +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 1pWXur-0005e2-5j; Mon, 27 Feb 2023 02:27:21 -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 1pWXuo-0005c9-UK
 for guile-devel@gnu.org; Mon, 27 Feb 2023 02:27:18 -0500
Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.218])
 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 1pWXuf-000736-Er
 for guile-devel@gnu.org; Mon, 27 Feb 2023 02:27:17 -0500
ARC-Seal: i=1; a=rsa-sha256; t=1677482819; cv=none;
 d=strato.com; s=strato-dkim-0002;
 b=eHOrIen9zEpLDA5rp5hy0to0BuonZ21tSbad9eUKrFyMex5U4VYKU5stlq4gbbMoHx
 9IBzzV2jefSrypWw+5jAFXSM4JoVqGUPH46uDFH0PXw4aXArJqpJxxKE8Lz06f4mr3Ey
 uAwcxcRKeSjTcqURJQ8L8G4fpCP3dNw8GfTAHukgrbrYRQWt9r+j1kGUg5QI3o8ZIvH7
 kE73Ot0y3Li+giprtcFJCNc2NOYHWgvu76C5ESv1RGKsAMU+f8E+vbV/iF0cyS8Z+y5X
 GaSTKidKkOboZve+eZqYE15yzVeGpwO2pEpFS8hkSDwnGUDM7O2thDUUzLBsib8ebcDf
 CYaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1677482819;
 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=+4u2DGqt7IQVtLX8E1Pd+uRjGcV/55Tzj7Q274Q+LPg=;
 b=AyyzGhPKjMX4ohFbv4zUeT6nVvbtLjdpML76yh9wm8ZamBPol6ub7YDbPO1gibk1rI
 U5Oxzc18x3EOs3MMcnoHZUuxafAz92lC8fU5uXK32IS4+G1IpMo6LMUa0viQQIxaBuQM
 UPVhIQvKO7guaN0MZj0ZRTpDAkqd3JMIT7JZQpkyY8Y0nk1/Mp6ikXIvZEv/vLbsed20
 9kAzJy3NBMnAU1FLQmbSHj415bv9WA6UMNAotRgpTzLcmX2F2G+JRbwrXf5cFEJ/JLtr
 ExnT9AFVdqDbZdlfNMhXPe0yj99+Lw+feaND+wZXAHNSmxck8S1yk5aDOxbTJTSNKTcy
 AkTw==
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=1677482819;
 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=+4u2DGqt7IQVtLX8E1Pd+uRjGcV/55Tzj7Q274Q+LPg=;
 b=toz7fEAoQInQx6ruKQkBTXZ+e3HfevQjBniWqdjeuuI96UA73DXuDUbeO5GLCQ8nhy
 vE6jV8WOX4DIcP+K7sekWyi1wIRl7TsZMA0h9ATpPNdFZ8LYNTBS/o5+2CWWCI8jiakk
 nMV+OUkY32jACQzzkXhoMf+xPo6FiaO+nGVyq45NN8f3tmGmjBNJx4pQIW+f9p073wQr
 DzQcGEPscjYH2Kp3u8NrLsvJPj0hvGDJqMMn/7NB8lhkrIg8XVIUwzGOsLTjUtWB/DC1
 jTa2P+NCeCUIqxTstBApHr8jIpf1KCQnhZn8dHvpTtVVh0FFIw0UczW78ABgyRsKVX7D
 qCrQ==
X-RZG-AUTH: ":IW0WdmCmcvpIrP2+VJuPtIhjJvc4Ig+QdhX22iZVwSDOx4Kp3cYsBVGy6CZgmO/guIaKVMt57pJs"
Original-Received: from mail-wr1-f47.google.com by smtp.strato.de (RZmta 49.3.0 AUTH)
 with ESMTPSA id e79b15z1R7QwmSF
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
 (Client did not present a certificate) for <guile-devel@gnu.org>;
 Mon, 27 Feb 2023 08:26:58 +0100 (CET)
Original-Received: by mail-wr1-f47.google.com with SMTP id r18so5125188wrx.1
 for <guile-devel@gnu.org>; Sun, 26 Feb 2023 23:26:58 -0800 (PST)
X-Gm-Message-State: AO0yUKXuogVWeAtBeTClPYbp/pn/c97mAT9bu4c3KQoQPL/HknG1w6qR
 NUCkt4I3j92+FiPRSy/hiNl37OJvk2JN2lZdYmA=
X-Google-Smtp-Source: AK7set+XcPIOWKtJ6P8+uq0l4M5VrgRLYNMSOVKon3c7ygan6sKkJc2bnKYchxLUG+hotvXh3xOW1EQoEJFPv0gCMQY=
X-Received: by 2002:a5d:4205:0:b0:2c9:bd6e:83c0 with SMTP id
 n5-20020a5d4205000000b002c9bd6e83c0mr694658wrq.3.1677482818733; Sun, 26 Feb
 2023 23:26:58 -0800 (PST)
In-Reply-To: <3517394.V25eIC5XRa@bastet>
X-Gmail-Original-Message-ID: <CAEYrNrSLwq1cc9XVGxSmxMuzWuREtsC8zbUC_7WnJnzW8urN0w@mail.gmail.com>
Received-SPF: none client-ip=81.169.146.218;
 envelope-from=marc@nieper-wisskirchen.de; helo=mo4-p00-ob.smtp.rzone.de
X-Spam_score_int: -11
X-Spam_score: -1.2
X-Spam_bar: -
X-Spam_report: (-1.2 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001,
 SPF_NONE=0.001, URI_DOTEDU=1.644 autolearn=no 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:21754
Archived-At: <http://permalink.gmane.org/gmane.lisp.guile.devel/21754>

Am Mo., 27. Feb. 2023 um 00:22 Uhr schrieb Philip McGrath
<philip@philipmcgrath.com>:
>
> Hi,
>
> On Sunday, February 26, 2023 6:02:04 AM EST Marc Nieper-Wi=C3=9Fkirchen w=
rote:
> > Am So., 26. Feb. 2023 um 08:46 Uhr schrieb <guile-devel-request@gnu.org=
>:
> > > Message: 1
> > > Date: Sun, 26 Feb 2023 02:45:12 -0500
> > > From: "Philip McGrath" <philip@philipmcgrath.com>
> > > To: "Maxime Devos" <maximedevos@telenet.be>, Ludovic Court=C3=A8s
> > >
> > >         <ludo@gnu.org>, "Matt Wette" <matt.wette@gmail.com>,
> > >         guile-devel@gnu.org
> > >
> > > Cc: "Christine Lemmer-Webber" <cwebber@dustycloud.org>
> > > Subject: Re: [PATCH] add language/wisp to Guile?
> > > Message-ID: <981b0e74-96c0-4430-b693-7fc8026e3ead@app.fastmail.com>
> > > Content-Type: text/plain;charset=3Dutf-8
> >
> > [...]
> >
> > I would like to make two remarks, which I think are essential to get
> > the semantics right.
> >
> > The R6RS comments of the form "#!r6rs" are defined to modify the
> > lexical syntax of the reader; possibly, they don't change the language
> > semantics (after reading).  In particular, "#!r6rs" also applies to
> > data files but does not affect the interpretation of the data after it
> > is read. It cannot because the reader otherwise ignores and does not
> > report comments.
> >
> > Thus a comment of the form "#!r6rs" may be suitable for Wisp, but it
> > is not a substitute for Racket's "#lang" (or a similar mechanism).
> > Guile shouldn't confuse these two different levels of meaning.
> >
>
> I agree that it's important to distinguish between lexical syntax (`read`=
) and
> the semantics of what is read.
>
> However, Racket's `#lang` in fact operates entirely at the level of `read=
`.
> (Racketeers contribute to confusion on this point by using `#lang` as a
> shorthand for Racket's entire language-creation infrastructure, when in f=
act
> `#lang` specifically has a fairly small, though important, role.) When `r=
ead`
> encounters `#lang something`, it looks up a reader extension procedure in=
 the
> module indicated by `something` and uses that procedure to continue parsi=
ng
> the input stream into data. Importantly, while syntax objects may be used=
 to
> attach source location information, there is no "lexical context" or bind=
ing
> information at this stage, as one familiar with syntax objects from macro
> writing might expect: those semantics come after `read` has finished pars=
ing
> the input stream from bytes to values.

[...]

Thank you for the reminder on Racket's #lang mechanism; it is a long
time ago since I wrote some #lang extensions myself when experimenting
with Racket.

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).  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.

(It must be compatible with calling the procedures "read" and "eval"
directly, so "#!r6rs" must not wrap everything in some module form,
say.)

Racket's "#lang" mechanism has more freedom (regardless of how it is
implemented).

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.

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).

[...]

> > The second comment concerns the shebang line in R6RS scripts (as
> > described in the non-normative appendices).  The shebang line is not a
> > comment in the R6RS lexical syntax; it does not even reach the reader
> > - at least, conceptionally.  The Scheme reader only sees the lines
> > following the shebang line.
> >
> > For example, a conforming R6RS implementation must raise an exception
> > when trying to read (using get-datum, for example) a file that begins
> > with a shebang line.
> >
> > Thus, the shebang line doesn't need to be considered when discussing
> > comment formats in lexical syntax.
> >
>
> This is a very persuasive account of the R6RS appendices. I just find the
> approach somewhat unsatisfying. An R6RS implementation with script suppor=
t
> must have a procedure `not-quite-read` that handles a potential shebang l=
ine
> before calling `read`. I wish this `not-quite-read` procedure were made
> available from some Scheme library (and perhaps somewhat more explicitly
> specified), and I'd probably find it most beautiful for this `not-quite-r=
ead` to
> be unified with `read`. But that's not really relevant per se.

The R6RS approach is the sound one.  The shebang line is interpreted
by the kernel, which only sees the binary file.  The Scheme reader, on
the other hand, operates on a textual file.  So the logically correct
way to implement script support is to open a binary port, and check
whether the file starts with the bytes (!) corresponding to "#!/" or
"#! /" and, if so, skips bytes until #\newline is seen.  Only then it
changes the binary port into a textual port (using whatever encoding
the user may have specified) and uses the Scheme reader.

This doesn't mean that there is no room for a procedure "read-script"
that takes a binary port/filename.  It just cannot and shouldn't be
merged with "read".  Another reason why this is not possible is that
Scheme's lexical as defined in the R6RS does not include shebangs as
possible tokens ("#!<delimiter>" is not a valid token, for example).


>
> >
> > Best,
> >
> > Marc
>
> Thank you for these thought-provoking remarks!
>
> Philip
>
> [1]: https://www-old.cs.utah.edu/plt/publications/macromod.pdf
> [2]: https://jeapostrophe.github.io/home/static/icfp065-mccarthy.pdf