unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip McGrath <philip@philipmcgrath.com>
To: Sage Gerard <sage@sagegerard.com>, guix-devel@gnu.org
Subject: Re: How did you handle making a GNU/Linux distribution?
Date: Sun, 22 Aug 2021 18:54:12 -0400	[thread overview]
Message-ID: <66138ed4-2725-03a9-5f09-0b8541046ed3@philipmcgrath.com> (raw)
In-Reply-To: <f5c429fb-f5b5-716d-00a6-513cd0fbef87@sagegerard.com>

Hi Sage,

On 8/22/21 5:53 PM, Sage Gerard wrote:
> Thanks for the detailed answer!
> 
> It seems wise to adapt GNU Mes towards Racket or Chez Scheme instead of
> Guile to bring GNU's benefits to more Scheme and Racket programmers. Has
> someone already tried something like that?

I haven't tried Xiden yet, and I haven't done any concrete work toward 
this (I have been working on managing Racket packages with Guix), but 
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).

As I said, I haven't actually tried any of this, but, as I've thought 
about what might be involved, 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.

  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.

If I were going to work on this, I'd start by looking at having Racket 
and Guile coexist as siblings with interoperability through their FFIs 
level. Even better, eventually you could compile Guile to Racket 
linklets, so the two could coexist in the same primitive module system. 
There would probably always need to be something along the lines of 
require/typed to interoperate between the languages, since Guile has 
mutable pairs and an unusual approach to falsehood and nullity to let 
Scheme's #f and '() coexist with Emacs List's nil. (See 
https://www.gnu.org/software/guile/manual/html_node/Nil.html).

>>> I'm at the point where users are requesting a GNU/Linux distribution for
>>> Xiden, such that Racket is the primary language for day-to-day
>>> operation. I'm ignorant of the scope of work, and am unsure if I can do
>>> it alone.

To me, at least, the scope of the work in creating a new GNU/Linux 
distribution seems daunting. My hope would be that bringing Racket and 
Guile closer together would let most if not all of the effort be shared.

Hope some of this is useful, and best of luck!

-Philip



  reply	other threads:[~2021-08-22 22:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-21 16:43 How did you handle making a GNU/Linux distribution? Sage Gerard
2021-08-21 21:18 ` Leo Famulari
2021-08-22 21:53   ` Sage Gerard
2021-08-22 22:54     ` Philip McGrath [this message]
2021-09-13  3:09       ` Christine Lemmer-Webber
2021-10-02  3:32         ` Philip McGrath
2021-10-02 12:59           ` Christine Lemmer-Webber
2021-08-23 10:43 ` Maxime Devos
2021-08-23 12:48   ` Sage Gerard
2021-08-23 15:38 ` zimoun
2021-08-23 17:30   ` Philip McGrath
2021-08-24 10:24     ` zimoun
2021-08-23 18:24   ` Sage Gerard
2021-08-23 19:23     ` Ryan Prior
2021-08-23 20:00       ` Sage Gerard
2021-08-24 16:42     ` Maxime Devos
2021-08-24 17:17       ` Sage Gerard

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://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66138ed4-2725-03a9-5f09-0b8541046ed3@philipmcgrath.com \
    --to=philip@philipmcgrath.com \
    --cc=guix-devel@gnu.org \
    --cc=sage@sagegerard.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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