From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 0BZ3C4F9WGFnOAEAgWs5BA (envelope-from ) for ; Sat, 02 Oct 2021 17:40:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id cJIAB4F9WGFCfgAAB5/wlQ (envelope-from ) for ; Sat, 02 Oct 2021 15:40:49 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7AA512FD0C for ; Sat, 2 Oct 2021 17:40:48 +0200 (CEST) Received: from localhost ([::1]:41196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWh83-0000w1-Kn for larch@yhetil.org; Sat, 02 Oct 2021 11:40:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWh7q-0000uv-D5 for guix-devel@gnu.org; Sat, 02 Oct 2021 11:40:34 -0400 Received: from dustycloud.org ([50.116.34.160]:38556) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWh7o-0001mo-8x for guix-devel@gnu.org; Sat, 02 Oct 2021 11:40:34 -0400 Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 6A1322661A; Sat, 2 Oct 2021 11:40:30 -0400 (EDT) References: <73f02b09-6983-7535-b71d-69ff0b0124f4@sagegerard.com> <66138ed4-2725-03a9-5f09-0b8541046ed3@philipmcgrath.com> <87v935gof9.fsf@dustycloud.org> <9cdb3c2d-8096-1fa1-1e15-9371c40b0817@philipmcgrath.com> User-agent: mu4e 1.6.6; emacs 27.2 From: Christine Lemmer-Webber To: Philip McGrath Subject: Re: How did you handle making a GNU/Linux distribution? Date: Sat, 02 Oct 2021 08:59:11 -0400 In-reply-to: <9cdb3c2d-8096-1fa1-1e15-9371c40b0817@philipmcgrath.com> Message-ID: <87o88737l7.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1633189248; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=R6BdSVTiLQRII2rXzww4UPRcuERd5RWmppzuTp71Wgs=; b=p52mpfeSXjWPhg/7lF3Ob5n4qwW/w9QqiYIrlfq2lhOplZ9g/BGvSiziWCRiCmpmpmbjms aLTlFWpQ7fSoGvp3qkKQSt112Aq1eX8PAD7VxW9I55zJTE+4EP2voBN/8oXzO6myHSKCVd YWr/Dh98p+WlPYNJ0SQ7TNdBmE2sW0S8T8/um6hzCYq0z+wbk+gRIBm8noR4qIauJCdvDk eRQOs5Qif+VoXp0Kx0nlA0qwDuE9vXBU7Km2nuTv44g5tqIwJG23fjbAqUHF52hf2/t87S FWhVtBL6yWohl0OJ9Ds1NwaS+4isuVueKGfHJmOY1I8CLXX6V5tHUAaPHGWS7A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633189248; a=rsa-sha256; cv=none; b=ate79XgP3EPwrSTojPAJzEpOq7p5vJhVj/ciLMg3n55o5scGyRKzmzo5Oi92tifMj0trfH /CNT7YgvA1yXBbDMiMXhdbN3Simg04czLbZET/R+5PbPHjPYDfM8eazqfc5a7URBXiIizZ TtkknPgnLhsgfbATm5G8CSbyd8kl+vOpIsKPH8TtCNSAZrKvxvHtbaGVSNnx5SvYTm0bCv NZpOn8XkjOWMl4IuMt/X2G0B1D+SExpSn6S56LfCXGIbgQePhR38L7C5aHmWc6QRX+Hbcu h2rix7ripYmaDiojSXlAu1Q2WXCOJxjgD4wO2Evr2nOvNmgMSpVH+Tr1k/pr5Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.40 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 7AA512FD0C X-Spam-Score: -1.40 X-Migadu-Scanner: scn0.migadu.com X-TUID: vmTDfRF6eGtr Philip McGrath writes: > On 9/12/21 11:09 PM, Christine Lemmer-Webber wrote: >> Philip McGrath writes: >>> Christine Lemmer-Webber had floated the idea at some point of trying >>> to integrate Racket and Guile. >>> >>> IIRC, I think what she's had in mind was trying to make a Guile >>> backend for Racket along the lines of the Chez Scheme backend (or the >>> BC backend, or experimental backends like Pycket). >> Yes that's what I had in mind :) > > A few stray thoughts, all with the caveat that I haven't actually > tried any of this ... > >>> there are two things that have struck me >>> as downsides: >>> >>> 1. Flatt et al. say in "Rebuilding Racket on Chez Scheme (Experience >>> Report)" (=C2=A76, p. 13) that, "If our task were to compile Racke= t to an >>> existing target, then we would not have achieved such a high degree >>> of compatibility. =E2=80=A6 we have taken the liberty of modifying= Chez >>> Scheme to make it an easier target for Racket." >>> >>> https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf >>> >>> Presumably a Racket-on-Guile project would face the same trade-off, >>> where modifications to Guild, if Racket CS is a guide, could requi= re >>> hard work over many years, and lesser compatibility would make the >>> result less useful. >> At one point when I spoke to Matthew, he was very optimistic that >> the >> work on porting on top of Chez would open Racket to running on top of >> many other backends. But yes... since there have been so many "custom" >> modifications to Chez, it's easier to be skeptical about that these >> days... > > I think there a few possible senses for what "running on top of many > other backends" could mean. My impression overall is that it has > gotten easier, but may not necessarily be easy. > > The most clearly demonstrated is that it seems to be easier to port > Chez Scheme to new architectures than to port Racket BC's VM. Racket > CS supports the Apple M1 chip natively (and hopefully will support the=20 > Linux kernel on the M1 when that stabilizes), which Racket BC does > not. Racket CS also fully supports some platforms (ARM in general, > IIRC) on which Racket BC lacks support for futures, places, or the > JIT. The most promising route to Racket on WASM also seems to be > adding a WASM backend to the Chez Scheme compiler. (In fairness, there > are also some architectures, like ppc64le, to which no one has ported > Racket CS yet, for which Racket BC can offer at least some support via > C.) Who will get to WASM first, Racket or Guile? :) > More generally, the "linklet" abstraction[1] seems to provide a much > more clear boundary between the responsibilities of a backend=20 > implementation and the common frontend than existed before Racket > 7.0. For example, the backend doesn't have to deal with macro > expansion or even shadowing of variables: it just need to have some > way to instantiate linklets (likely with further backend-specific > compilation) and to provide a whole bunch of primitives. I believe > I've heard Sam Tobin-Hochstadt say that linklets have made it possible > for Pycket (the experimental Racket implementation in Reticulated > Python) to run most Racket code. > > [1]: https://docs.racket-lang.org/reference/linklets.html > > Another benefit of linklets is that they've defined a clear path for > implementing parts of Racket in Racket itself, like the regexp=20 > implementation on Racket CS. This seems like it could help a lot with > supplying that very large number of primitives. > > So I expect it would be entirely possible to implement a linklet-based > Racket backend in Guile. I do suspect that getting production-quality=20 > performance and compatibility could be a lot of work. But my bigger > concern is ... > >>> 2. As you probably know, Racket programs can't generally use >>> Chez Scheme implemented libraries, because Chez Scheme effectively >>> is the "unsafe" layer of the Racket VM. For example, not all Racket >>> procedures are Chez Scheme procedures, and Racket's continuations >>> wrap Chez Scheme's to implement delimited and composable control, >>> threads, parameters, full continuation marks, etc. >>> >>> For Racket CS, this isn't a great loss (there aren't so many >>> Chez-specific libraries, and portable libraries can run in Racket's >>> R6RS language), but, for a hypothetical Racket-on-Guile, >>> bidirectional interoperability would be a big attraction: imagine >>> Guix, Shepherd, Mcron, syntax/parse, racket/contract, and more all >>> working together. > > I don't think a Racket-on-Guile that worked like Racket-on-Chez would > achieve the most interesting benefit (IMO) of bringing the two > languages together: safe, bidirectional interoperability. > > Probably there are many ways to achieve that goal. In principle, one > could write a Racket-on-Guile implementation where arbitrary Guile > could run without breaking Racket's invariants, but I expect that > would make the task even harder: presumably that's why Racket-on-Chez > doesn't work that way. > > But if linklets are as good as an abstraction as they seem to be for > compiling code in the presence of modules and macros---all of the=20 > complications of Scheme---then a more exciting direction, it seems to > me, would be to adapt Guile's compiler tower[2] to, at some layer,=20 > produce linklets. If the existing Guile backend (which does have some > strengths) became a linklet engine, it could run linklets generated by=20 > the Racket front-end. Linklets from the Guile frontend could likewise > run on other Racket backends: Racket-and-Guile-on-Chez, Pycket, or any=20 > exciting backend someone creates in the future. > > [2]: https://www.gnu.org/software/guile/manual/html_node/Compiler-Tower.h= tml > > It would probably still be a fair bit of work, particularly in > figuring out exactly how the semantics of Guile modules correspond to > Racket modules and in making interoperability convenient. I have no > particular plans to work on this myself. But I think it would be cool > :) > > -Philip Lots of intersesting stuff in here. The compiler tower direction is indeed something I've hoped could be explored. But it's also something not on my agenda immediately either. :)