Live data from Hacker News

The Pre-Scheme Restoration

prescheme.org

31–40 of 61 posts

Re: The Pre-Scheme Restoration

#31

Earlier quoted context omitted.

> Does Guix not have GHC (Glasgow Haskell Compiler) or did it somehow bootstrap GHC? Last time I checked bootstrapping GHC on today's hardware is effectively an unsolved problem. I think you're right, it looks like they've gotten a little further now than in that post but there's still a gap in the bootstrap chain. So maybe not every package is fully bootstrapped, but they do seem to take it more seriously. > While y…

> it looks like they've gotten a little further now than in that post Can you say more, or provide any references? I would be interested in the state of the art here.

There's a comment in the Guix source (added by the author of that first post you linked, Ricardo Wurmus) that seems to indicate that they found a way around the segfault problem described in the post by using a registerised version of GHC: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...

I had to look up exactly what this means, not being very familiar with the Haskell ecosystem myself. It looks like it's not the raw source form and is architecture-specific, but it's also not the compiled binary form. So that's not perfect, but better than relying on the compiled binaries I guess. (Unfortunate for me since my laptop is ARM and I'd like to be able to use git-annex, haha.) But this seems to work for older versions of GHC.

This post by Simon Tournier from last year describes the current situation near the bottom, and from what I can tell this is still correct: https://simon.tournier.info/posts/2023-10-01-bootstrapping.h...

> The bootstrapping problem for Haskell is not solved. And Ricardo works hard on it. Currently, from the older GHC around (4.08.2), which relies on gcc-2.95 – part of the Bootstrapping story above – it is possible to chain until version 6.10.4. Then versions 6.12.3 and 7.4.2 are not packaged yet for completing the Haskell chain from version 4.08.2 to modern version as 9.2.5; fully connecting the dots with bootstrap-seeds and dropping these 450MiB of binaries. The solution of this chicken-or-the-egg is not yet complete.

Re: The Pre-Scheme Restoration

#32

Earlier quoted context omitted.

It doesn't read as tongue-in-cheek to me. NixOS does not have an equivalent to Guix's full-source bootstrap mentioned in the next sentence: https://guix.gnu.org/blog/2023/the-full-source-bootstrap-bui... Nixpkgs also doesn't seem to require that all packages be built from source - which, if you're really looking for reproducibility, is a downside. I recognize that there are practical reasons for this, and it's part o…

Nix doesn't require everything to be built from source, sure, but everything downloaded must match a provided hash. What's the difference between downloading source code and binaries at that point?

It's easier to audit source code than binaries, and easier to audit it once than once for each architecture.

Re: The Pre-Scheme Restoration

#34
post #24

I am so excited for a Lispy systems language. Existing languages just don't do it for me, though I think Zig is the closest to being what I'm into. So much good stuff in Scheme48. Glad the good ideas are being revived.

> I am so excited for a Lispy systems language. Can recommend Gerbil Scheme. Although fair warning, still GC'd and (for now) only type-annotated, not (100%) statically typed. But stdlib-wise and compilation-wise still way more "systems-bent" than most Schemes out there.

Related:

Gerbil Scheme – A Lisp for the 21st Century - https://news.ycombinator.com/item?id=39809323 - March 2024 (126 comments)

Gerbil – A meta-dialect of Scheme - https://news.ycombinator.com/item?id=20585637 - Aug 2019 (17 comments)

Gerbil Scheme - https://news.ycombinator.com/item?id=17707622 - Aug 2018 (9 comments)

Gerbil – An opinionated dialect of Scheme designed for systems programming - https://news.ycombinator.com/item?id=15394603 - Oct 2017 (78 comments)

Re: The Pre-Scheme Restoration

#35

Fantastic news! This is a really interesting place in the design space and has come so close to being lost to history. I believe the idea is essentially to write C semantics in scheme notation. Variables get marked with 'u32' or similar instead of being implicit sum types of anything the language can represent, memory allocation is explicit instead of garbage collected. In itself that essentially means writing C synt…

Smalltalk can use a similar bootstrapping method, which blew my mind the first time I read and understood (see https://ftp.squeak.org/docs/OOPSLA.Squeak.html, "Smalltalk to C Translation"). In that world, images can easily obscure some of the lineage. Scheme has the advantage of having a standard to hold dialects to. I am watching this project with interest.

Re: The Pre-Scheme Restoration

#37

The hell of the systems language is the systems, not that it has infix syntax.

Pre-Scheme can be run in a Scheme system, then when it is found to be correct there, compiled VERY straightforwardly to C. This is a huge win in terms of productivity. Plus, at the top level, at compile time, you have all of Scheme available.

Re: The Pre-Scheme Restoration

#38
post #24

I am so excited for a Lispy systems language. Existing languages just don't do it for me, though I think Zig is the closest to being what I'm into. So much good stuff in Scheme48. Glad the good ideas are being revived.

> I am so excited for a Lispy systems language. Can recommend Gerbil Scheme. Although fair warning, still GC'd and (for now) only type-annotated, not (100%) statically typed. But stdlib-wise and compilation-wise still way more "systems-bent" than most Schemes out there.

Gerbil is based on Gambit, right? Have you tried Gambit itself? I'm curious how they compare.

Re: The Pre-Scheme Restoration

#39

https://github.com/carp-lang/Carp is a recent attempt to create a similar language, but with a Rust-inspired borrow checker. though it looks like prescheme would end up being less dependent on C ultimately, this is another option in the space.

Without a new maintainer and perhaps a group of dedicated supporters, Carp may as well be considered abandoned. The existing head maintainer and major contributor has moved on to other things.

https://github.com/carp-lang/Carp/issues/1460#issuecomment-2...

Re: The Pre-Scheme Restoration

#40
This is very cool. I've added it to my RSS reader, can't wait to see what comes of it.

Genuine question: would there be any advantages in targeting LLVM IR, rather than transpiling to C? With C being notoriously implementation dependent (down to things like the sizes of integer types), it seems like a messy target for something intended to be a sane systems language.

Post reply on HN