From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id aGsGKwrTV2G4dwEAgWs5BA (envelope-from ) for ; Sat, 02 Oct 2021 05:33:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KLyGJgrTV2EPaAAAbx9fmQ (envelope-from ) for ; Sat, 02 Oct 2021 03:33:30 +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 F00EBEDCE for ; Sat, 2 Oct 2021 05:33:29 +0200 (CEST) Received: from localhost ([::1]:43452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWVmD-0001fj-2k for larch@yhetil.org; Fri, 01 Oct 2021 23:33:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49936) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWVlj-0001fV-T3 for guix-devel@gnu.org; Fri, 01 Oct 2021 23:33:00 -0400 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:43572) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mWVlh-00020m-UI for guix-devel@gnu.org; Fri, 01 Oct 2021 23:32:59 -0400 Received: by mail-qt1-x835.google.com with SMTP id a13so10886249qtw.10 for ; Fri, 01 Oct 2021 20:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=T3t9z5VxuJKAdvANtCqf7nPNJ8iGqsafME9L/nLjWmI=; b=Ql/dbL/yl073nNdrrGyd9cAZnx3s/sPRLRqBJ3B9KMb0BLqcVTmeRrrLJTFtKErSxi jQyx+HK1QdpbiYtzGJe74vF+vOoVVNbbzk4jvtzQZnqCSqM16HP+q3I3zzpPoSiLceig y5HG7LbJ1g4dBrvd8k0JdQ6+wqc4v5uUVgyqQ5t8BtiIuiTpUNMjGaDZUF1ZJeMDVOZV 7hSgQooQb5SLgP1iViIGAVC0ep2QKaHLRnWNNXO+FUAHVTOCNZl+6MS5FtZKNDTcMuJR ETPX/uD6h71/Ai1MPGWOyTEqWh4h3iijIr3HsjoMwhtA5iy989LZiUH1OSR8XPVjIKdq jwcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T3t9z5VxuJKAdvANtCqf7nPNJ8iGqsafME9L/nLjWmI=; b=eQfa/PxVu+y5FClYyU54JJ1Hb/UdZkqgGfrQVEwltTZGlBVxO7iYghi+wQL1HofpgL FlH6FHkM8vmZNJ2aLiJTir+MJfSY/T7bBvYT4na96m+s4V7l7GzFjzUBvCCq3SiK/mXU qaQfy2hCG7wiq2UiwGZp2XeXobgvtaCexeTbbqrovjVUfvXALWKkgB+jk8zqdOGIKtVU uTedQa4KgIORwqSLHgNQfRIN44D0DKd9crWVX78Xy/9kHmuH1W753oNuq0IdM3b0xUiU mq5fzCzaQCoFVJHg1/in8FMItdcRr7VjPEDH4Sv1k49R3vGLT5Qd/fcZ34JtlgNfEhgs THIA== X-Gm-Message-State: AOAM530ANjcTHfNSdFg3VTO1OqoQbXBZ/rA/Jevmj8WgsIkNXNL5h1+d 0OPYDVvQYwDZG+MWwF7mJ5MPOPcmGraynx1d X-Google-Smtp-Source: ABdhPJwtwO8euEH/kBq7Ev3FstasNhLK/Xohp9QWFA265XAyWf2pwqyXMlQ1OUCPyul0u6qgjTFLgQ== X-Received: by 2002:ac8:4f0b:: with SMTP id b11mr1629649qte.124.1633145575691; Fri, 01 Oct 2021 20:32:55 -0700 (PDT) Received: from [192.168.45.37] (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id x5sm4155153qkf.135.2021.10.01.20.32.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Oct 2021 20:32:55 -0700 (PDT) From: Philip McGrath Subject: Re: How did you handle making a GNU/Linux distribution? To: Christine Lemmer-Webber References: <73f02b09-6983-7535-b71d-69ff0b0124f4@sagegerard.com> <66138ed4-2725-03a9-5f09-0b8541046ed3@philipmcgrath.com> <87v935gof9.fsf@dustycloud.org> Message-ID: <9cdb3c2d-8096-1fa1-1e15-9371c40b0817@philipmcgrath.com> Date: Fri, 1 Oct 2021 23:32:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87v935gof9.fsf@dustycloud.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: neutral client-ip=2607:f8b0:4864:20::835; envelope-from=philip@philipmcgrath.com; helo=mail-qt1-x835.google.com X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 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, NICE_REPLY_A=-1.127, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URI_DOTEDU=1.83 autolearn=no 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=1633145610; 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:dkim-signature; bh=T3t9z5VxuJKAdvANtCqf7nPNJ8iGqsafME9L/nLjWmI=; b=BxybXkOP5CAejEGok8OoRndiCUye6XB5BaWgFUMOZJZT6y27S+pMahWiXiJXlTCHH3DD+n ALGDjM6YzjcePZAfhzGIwC8+aRR8mpJNstALlsZLZLELTN0iNhH17u7+U9oFWmF+miOcoI saCA58gyswyvqLuSeTzS15hcKS9dz9Oih3roHOpNKonReLMIsfz6ZcDAuu3DMBkzxg5g0o 6YBbUeD1SRk1TZYmKJyQ4n7o0YJtFGyZ2/RfiutVSnFoOuzCYji0nP2kjn4XB5raoeyMYW pLysj5mxmSkTV+tgI7KVuMo1kOQLHiELUUjx4iDiKys16G8C1gKbkmOl+K9yiA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633145610; a=rsa-sha256; cv=none; b=tpCM1mXTzMKHfywj2Lc1QFEn4/Yum716E2Tz0CvmY08GVlvYjW4ZKTREJiG1qjn6A5ffnJ 2yt8FlqQm3oUZGL1gGwl1E41Yc8itk1RL3sgqoKUN5Bhj+TDxKeuUcvXrrxyZ92VQtexPJ z5PPRRd3JgBVlf1HOIJmiXyjNhPq2DQceFNgMFdQ4DLAcKlkJ0wzgA3Lp00n4bfILAQykK VUxMMowtXmpmK86Uv4HYZPWnMx9YHedCKsYZd8jWH7qTKxC8M3PseFSXMosqnEGvFD790R T1sIX18+CPxnTAPqFLTK8NYac+bjgOhHOdHeVSuZqdPptmTUt1VblZ9IhDa6mQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b="Ql/dbL/y"; 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: -0.81 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b="Ql/dbL/y"; 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: F00EBEDCE X-Spam-Score: -0.81 X-Migadu-Scanner: scn1.migadu.com X-TUID: 3zPj3pN1N5nH 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)" (§6, p. 13) that, "If our task were to compile Racket to an >> existing target, then we would not have achieved such a high degree >> of compatibility. … 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 require >> 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 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.) More generally, the "linklet" abstraction[1] seems to provide a much more clear boundary between the responsibilities of a backend 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 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 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 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, produce linklets. If the existing Guile backend (which does have some strengths) became a linklet engine, it could run linklets generated by the Racket front-end. Linklets from the Guile frontend could likewise run on other Racket backends: Racket-and-Guile-on-Chez, Pycket, or any exciting backend someone creates in the future. [2]: https://www.gnu.org/software/guile/manual/html_node/Compiler-Tower.html 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