all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christine Lemmer-Webber <cwebber@dustycloud.org>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: guix-devel@gnu.org
Subject: Re: How did you handle making a GNU/Linux distribution?
Date: Sun, 12 Sep 2021 23:09:59 -0400	[thread overview]
Message-ID: <87v935gof9.fsf@dustycloud.org> (raw)
In-Reply-To: <66138ed4-2725-03a9-5f09-0b8541046ed3@philipmcgrath.com>

Philip McGrath <philip@philipmcgrath.com> writes:

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

Yes that's what I had in mind :)

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

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

>  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-09-13  3:12 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
2021-09-13  3:09       ` Christine Lemmer-Webber [this message]
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

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

  git send-email \
    --in-reply-to=87v935gof9.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=guix-devel@gnu.org \
    --cc=philip@philipmcgrath.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.