Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pre-Scheme Restoration

prescheme.org

Post reply on HN
Print view View original

51–60 of 61 posts

Re: The Pre-Scheme Restoration

#51

Post by rekado »

rssoconnor wrote: post #26
ryukafalz wrote: post #19

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…

> 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. 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. [1] > NixOS does not have an equivalent to Guix's full-source bootstrap While you are not wrong…

I've built up to GHC 6 (I've stopped after reaching 6) from GHC 4. GHC 4 does use some generated C files, so it's not a pure bootstrap, but it's still much better than taking a binary of GHC 6 or later.

(I'm the author of the 2017 blog post. I had planned a follow-up but since I didn't have much to show I scrapped it.)

Re: The Pre-Scheme Restoration

#52

Post by rekado »

ryukafalz wrote: post #31
rssoconnor wrote: post #29

Earlier quoted context omitted.

> 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 i…

The technical details of the quote are correct, but FWIW I'm no longer working on the GHC bootstrap. It's fun for a while but the lack of interest in the Haskell community and the general high level of ridicule and hostility from the rest of the software world towards all things GNU / free software / bootstrapping have kinda turned me off the whole computer thing.

Re: The Pre-Scheme Restoration

#53

Post by ryukafalz »

rekado wrote: post #52
ryukafalz wrote: post #31

Earlier quoted context omitted.

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 i…

The technical details of the quote are correct, but FWIW I'm no longer working on the GHC bootstrap. It's fun for a while but the lack of interest in the Haskell community and the general high level of ridicule and hostility from the rest of the software world towards all things GNU / free software / bootstrapping have kinda turned me off the whole computer thing.

That's unfortunate to hear, I'm sorry you've had to deal with that :(

Re: The Pre-Scheme Restoration

#54

Post by fire_lake »

JonChesterfield wrote: post #8

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…

This is (potentially) so much better than complex C preprocessor or C++ template complexity.

Re: The Pre-Scheme Restoration

#55

Post by rssoconnor »

rekado wrote: post #51
rssoconnor wrote: post #26

Earlier quoted context omitted.

> 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. 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. [1] > NixOS does not have an equivalent to Guix's full-source bootstrap While you are not wrong…

I've built up to GHC 6 (I've stopped after reaching 6) from GHC 4. GHC 4 does use some generated C files, so it's not a pure bootstrap, but it's still much better than taking a binary of GHC 6 or later. (I'm the author of the 2017 blog post. I had planned a follow-up but since I didn't have much to show I scrapped it.)

Is this committed to Guix and/or otherwise available somewhere?

Re: The Pre-Scheme Restoration

#56

Post by troad »

gergo_barany wrote: post #48
troad wrote: post #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.

C has had fixed-size integers since C99: https://en.m.wikibooks.org/wiki/C_Programming/inttypes.h Targeting LLVM IR has the drawback that it is not platform independent: Details of calling conventions must be modeled in the IR, so the compiler must know what ABI it is targeting and emit the appropriate code. Compiling to C doesn't have this problem, since the C compiler will handle calling conventions for you. That s…

> C has had fixed-size integers since C99: https://en.m.wikibooks.org/wiki/C_Programming/inttypes.h

Good point! You don't tend to see them too much in the wild, but they're available, which is good enough for present purposes.

> Targeting LLVM IR has the drawback that it is not platform independent: Details of calling conventions must be modeled in the IR, so the compiler must know what ABI it is targeting and emit the appropriate code. Compiling to C doesn't have this problem, since the C compiler will handle calling conventions for you.

Ooft, that would be a rough one. It kind of seems like there'd be some benefit to a low-level IR that's neither platform / implementation-specific, nor has the warts of C, but I appreciate that'd be well outside the scope of this project.

> That said, LLVM would indeed have some advantages. Scheme has guaranteed tail call optimization, which you cannot guarantee with C. But LLVM does allow you to annotate calls as tail calls, and it can transform tail self-recursion into a loop for you.

I suppose this will need be handled manually in the Pre-Scheme transpiler itself. Losing TCO seems like it ought to be a non-starter for anything Scheme-like.

Re: The Pre-Scheme Restoration

#57

Post by a2code »

Tail-call optimization is very important when writing Scheme programs. By removing those, you loose the power of recursion.

Also when it comes to macros, does that include `syntax-rules` or `syntax-case` style macros, where the latter are much more powerful?

While an embedded Scheme-like language is incredibly useful, at some point I feel as if you would simply have to include these features, and to that end it would just be Scheme reinvented.

Re: The Pre-Scheme Restoration

#58

Post by gergo_barany »

troad wrote: post #56
gergo_barany wrote: post #48

Earlier quoted context omitted.

C has had fixed-size integers since C99: https://en.m.wikibooks.org/wiki/C_Programming/inttypes.h Targeting LLVM IR has the drawback that it is not platform independent: Details of calling conventions must be modeled in the IR, so the compiler must know what ABI it is targeting and emit the appropriate code. Compiling to C doesn't have this problem, since the C compiler will handle calling conventions for you. That s…

> C has had fixed-size integers since C99: https://en.m.wikibooks.org/wiki/C_Programming/inttypes.h Good point! You don't tend to see them too much in the wild, but they're available, which is good enough for present purposes. > Targeting LLVM IR has the drawback that it is not platform independent: Details of calling conventions must be modeled in the IR, so the compiler must know what ABI it is targeting and emit t…

WebAssembly fans might say that it's the kind of universal low-level but portable IR that you envision. It would certainly make sense for a Scheme compiler to consider a WebAssembly target.

Re: The Pre-Scheme Restoration

#59

Post by 392 »

troad wrote: post #56
gergo_barany wrote: post #48

Earlier quoted context omitted.

C has had fixed-size integers since C99: https://en.m.wikibooks.org/wiki/C_Programming/inttypes.h Targeting LLVM IR has the drawback that it is not platform independent: Details of calling conventions must be modeled in the IR, so the compiler must know what ABI it is targeting and emit the appropriate code. Compiling to C doesn't have this problem, since the C compiler will handle calling conventions for you. That s…

> C has had fixed-size integers since C99: https://en.m.wikibooks.org/wiki/C_Programming/inttypes.h Good point! You don't tend to see them too much in the wild, but they're available, which is good enough for present purposes. > Targeting LLVM IR has the drawback that it is not platform independent: Details of calling conventions must be modeled in the IR, so the compiler must know what ABI it is targeting and emit t…

I wonder if a subset of Rust would be a good candidate. It would certainly involve hardcoding the templates for some `unsafe` incantations into the compiler in order to treat Rust as remotely equivalent to a C target, which is beyond me, but _if_ it could be done the opportunity to reuse all of the Rust ecosystem would be killer. Heck, even generating only safe Rust with runtime overhead might be a fast enough of a runtime for an experiment with this.

Re: The Pre-Scheme Restoration

#60

Post by 392 »

trealira wrote: post #2

According to the article: thanks to a grant from the NLnet foundation under the NGI Zero Core program, Pre-Scheme can continue to be developed. It's supposed to be a C alternative. Currently, it compiles to C, has a Hindley Milner type system, macros, and it can run in a Scheme REPL. And they have a roadmap of features now. This is pretty cool, and it's generous of them to grant them funding, but (and I'm not trying…

Another way to look at it is a long shot on a new higher level language to entice the folks currently reaching for Java, Python, or other runtime interpreters. An easy and safe language that shifts more work to compile time and offers high performance with ergonomic use will use less power, reduce the education requirements to writing fast code, and potentially change the world like another fast memory safe language governments are increasingly endorsing. Or if nothing else it may serve as a language for interpreters of those languages, or to make extensions to them more ergonomic. With enough scale the improvements can come very incrementally.
Post reply on HN