[bug#46865] gnu: racket: update to 8.0.

* gnu/packages/scheme.scm (racket, racket-minimal): Update to 8.0.
---
 gnu/packages/scheme.scm | 98 +++++++++++++++++++++++++++++------------
 1 file changed, 71 insertions(+), 27 deletions(-)

I changed the description primarily because, as of Racket 8.0, it is no 
longer accurate to say, "It features a compiler and a virtual machine 
with just-in-time native compilation"—the default implementation is now 
a native code compiler based on Chez Scheme.

But there's certainly still room for improvement. In particular, I see 
that Nix is using the description:

 > Racket is a full-spectrum programming language. It goes beyond
 > Lisp and Scheme with dialects that support objects, types,
 > laziness, and more. Racket enables programmers to link
 > components written in different dialects, and it empowers
 > programmers to create new, project-specific dialects. Racket's
 > libraries support applications from web servers and databases to
 > GUIs and charts.

The Racket project has used descriptions along those lines in other 
places before.

I left the synopsis, "Implementation of Scheme and related languages", 
alone, but that's also debatable. From a Racketeer's perspective,
Racket contains a Scheme implementation, but it is not primarily a 
Scheme implementation. Nix uses the short description, "A programmable 
programming language".

Hi Philip,

Philip McGrath <philip@philipmcgrath.com> skribis:

> * gnu/packages/scheme.scm (racket, racket-minimal): Update to 8.0.

I applied it and tweak the commit log to mention the fields that were
changed.  The new synopsis and description LGTM!

Did you try unbundling Chez?  It would be great if we could do that.
(In Guix we unbundle software as much as possible, notably for security
reasons.)

Thanks!

Ludo’.

Hi!

On 3/5/21 6:49 AM, Ludovic Courtès wrote:
> I applied it and tweak the commit log to mention the fields that were
> changed.  The new synopsis and description LGTM!

That's great!

> Did you try unbundling Chez?  It would be great if we could do that.
> (In Guix we unbundle software as much as possible, notably for security
> reasons.)

The Racket fork of Chez Scheme has diverged significantly from upstream.
Racket regularly syncs with upstream Chez and contributes patches back, 
but they are likely to coexist as two different "flavors" of Chez for 
the foreseeable future. There's a detailed (though almost two-year-old) 
review of the differences in their ICFP report[1]. In essence, some of 
Racket's "changes to Chez Scheme are either controversial or heavyweight 
compared to the expected benefit for applications other than Racket". 
You can see how one controversial pull request[2] became a Flatt and 
Dybvig 2020 PLDI paper.[3] At this point, for example, Racket's Chez has 
gained an Aarch64 backend, floating-point unboxing, and a 
type-reconstruction compiler pass.

So, no, I don't think there's a prospect of unbundling Chez.

On the other hand, since sending this patch, I saw that much of the work 
Guix and Nix had to do with around absolute paths could be better 
addressed upstream. Racket has merged my fixes for most of them[4] (and 
Matthew solved another in C [5]), which means we can greatly simplify 
the package definition. I hope to get those fixes into upstream Chez, too.

I do think I should be able to unbundle Nanopass, as the Chez Guix 
package does.

Just now I've been working on bootstrapping. Chez has the usual problem 
that you need the old version of Chez (specifically "bootfiles") to 
compile the new version. Racket's fork added an architecture-independent 
backend: those bootfiles are in the source distribution, which are how 
the Guix package is building now. But Racket is also able to simulate 
enough of Chez to (slowly) compile the Chez compiler, providing a path 
to Chez from just a C compiler. Racket does its whole bootstrapping 
process regularly in CI, and I'm working on getting the Guix package to 
do likewise.

(I knew from previous discussions that Racket on Guix could benefit from 
some attention, so I'm hoping to use it as an opportunity to learn more 
about Guix.)

-Philip

[1]: https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf
[2]: https://github.com/cisco/ChezScheme/pull/336
[3]: https://www.cs.utah.edu/plt/publications/pldi20-fd.pdf
[4]: https://github.com/racket/racket/pull/3710
[5]: 
https://github.com/mflatt/racket/commit/7319a22ed605fb3110b98f6c9aa1e8ed3aa03794

Ludovic Courtès writes:

> Hi Philip,
>
> Philip McGrath <philip@philipmcgrath.com> skribis:
>
>> * gnu/packages/scheme.scm (racket, racket-minimal): Update to 8.0.
>
> I applied it and tweak the commit log to mention the fields that were
> changed.  The new synopsis and description LGTM!
>
> Did you try unbundling Chez?  It would be great if we could do that.
> (In Guix we unbundle software as much as possible, notably for security
> reasons.)
>
> Thanks!
>
> Ludo’.

My understanding is that Racket is shipping a modified Chez, which could
make that difficult (but the goal is for the Chez it ships to be
less-modified-over-time).

Philip,

On Fri, 5 Mar 2021, Philip McGrath wrote:

> The Racket fork of Chez Scheme has diverged significantly from upstream.

[…]

> [1]: https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf
> [2]: https://github.com/cisco/ChezScheme/pull/336
> [3]: https://www.cs.utah.edu/plt/publications/pldi20-fd.pdf
> [4]: https://github.com/racket/racket/pull/3710
> [5]: https://github.com/mflatt/racket/commit/7319a22ed605fb3110b98f6c9aa1e8ed3aa03794

Thanks for pulling all this information together and writing a nice 
summer. It definitely helped me better understand what was going on with 
Racket CS. I'm excited to hear about that possibility of a full-source 
bootstrap as well.

Thanks!
Jack

Hi,

Philip McGrath <philip@philipmcgrath.com> skribis:

>> Did you try unbundling Chez?  It would be great if we could do that.
>> (In Guix we unbundle software as much as possible, notably for security
>> reasons.)
>
> The Racket fork of Chez Scheme has diverged significantly from upstream.
> Racket regularly syncs with upstream Chez and contributes patches
> back, but they are likely to coexist as two different "flavors" of
> Chez for the foreseeable future. There's a detailed (though almost
> two-year-old) review of the differences in their ICFP report[1]. In
> essence, some of Racket's "changes to Chez Scheme are either
> controversial or heavyweight compared to the expected benefit for
> applications other than Racket". You can see how one controversial
> pull request[2] became a Flatt and Dybvig 2020 PLDI paper.[3] At this
> point, for example, Racket's Chez has gained an Aarch64 backend,
> floating-point unboxing, and a type-reconstruction compiler pass.
>
> So, no, I don't think there's a prospect of unbundling Chez.

OK, that makes sense; thanks for explaining.

> On the other hand, since sending this patch, I saw that much of the
> work Guix and Nix had to do with around absolute paths could be better 
> addressed upstream. Racket has merged my fixes for most of them[4]
> (and Matthew solved another in C [5]), which means we can greatly
> simplify the package definition. I hope to get those fixes into
> upstream Chez, too.

Nice!

> I do think I should be able to unbundle Nanopass, as the Chez Guix
> package does.

Cool, that’d be a welcome improvement.

> Just now I've been working on bootstrapping. Chez has the usual
> problem that you need the old version of Chez (specifically
> "bootfiles") to compile the new version. Racket's fork added an
> architecture-independent backend: those bootfiles are in the source
> distribution, which are how the Guix package is building now. But
> Racket is also able to simulate enough of Chez to (slowly) compile the
> Chez compiler, providing a path to Chez from just a C compiler. Racket
> does its whole bootstrapping process regularly in CI, and I'm working
> on getting the Guix package to do likewise.

Awesome.

> (I knew from previous discussions that Racket on Guix could benefit
> from some attention, so I'm hoping to use it as an opportunity to
> learn more about Guix.)

Yup!  There have been discussions about having a raco importer (for the
“guix import” command), but I think the effort stalled.  It’d go a long
way bringing the Racket/Guix/Guile communities together, and it can be
hacked in a language all three communities love.  :-)

Thanks for your work!

Ludo’.