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

41–50 of 61 posts

Re: The Pre-Scheme Restoration

#41

Post by neilv »

hayley-patton wrote: post #13

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

When they write this:

> Scheme syntax, with full support for macros,

you can read that not as that Scheme prefix syntax alone is a big selling point, but the fact that it then supports Scheme macros (which are much better than in most other languages that support some kind of macros, partly due to the syntax making this easier).

Then you can read the rest of the sentence, for a bonus:

> and a compatibility library to run Pre-Scheme code in a Scheme interpreter.

Which means that you can do things like develop using this language within a normal Scheme development environment, possibly share code between developing for the PreScheme compiler target and non-PreScheme targets, etc.

Re: The Pre-Scheme Restoration

#42

Post by chubot »

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 similar to how https://www.oilshell.org/ is written

There are two complete implementations

1. one that runs under a stock Python interpreter (which doesn't use static types)

2. one that's pure C++, translated from statically typed Python code, and from data structures generated in Python

In the second case, everything before main() is "burned off" at build time -- e.g. there is metaprogramming on lexers, flag parsers, dicts, etc. that gets run and then turned into static C data -- i.e. data that incurs zero startup cost

Comparison to Pre-Scheme: https://lobste.rs/s/tjiwrd/revival_pre_scheme_systems_progra... (types, compiler output, and GC)

Brief Descriptions of a Python to C++ Translator - https://www.oilshell.org/blog/2022/05/mycpp.html

...

And related to your other point, I remember looking at Racket's implementation around the time it started the Chez Scheme conversion. For some reason, I was surprised that it was over 100K lines of hand-written C in the runtime -- it looked similar to CPython in many ways (which is at least 250K lines of C in the core).

Re: The Pre-Scheme Restoration

#43

Post by 3836293648 »

ryukafalz wrote: post #32
3836293648 wrote: post #30

Earlier quoted context omitted.

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.

Auditing is irrelevant to whether or not it's reproducable, which was the question here.

You also forgo any improvements to compiler improvements

Re: The Pre-Scheme Restoration

#44

Post by brabel »

giraffe_lady wrote: post #11

Scheme with HM type system sounds fun. I've used ocaml a fair bit and I really find that the sweet spot for effectiveness of types vs arguing with the compiler. Racket and common lisp both have optional type systems but neither ever really clicked with me.

Common Lisp has Coalton [1]. It's basically a functional Lisp embedded within Common Lisp which has HM types and a bit more modern constructs than CL.

[1] https://coalton-lang.github.io/

Re: The Pre-Scheme Restoration

#45

Post by hayley-patton »

neilv wrote: post #41
hayley-patton wrote: post #13

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

When they write this: > Scheme syntax, with full support for macros, you can read that not as that Scheme prefix syntax alone is a big selling point, but the fact that it then supports Scheme macros (which are much better than in most other languages that support some kind of macros, partly due to the syntax making this easier). Then you can read the rest of the sentence, for a bonus: > and a compatibility library to…

> but the fact that it then supports Scheme macros

Good for them.

> possibly share code between developing for the PreScheme compiler target and non-PreScheme targets

"possibly" is a strong word, seeing that Pre-Scheme is a statically typed, explicitly memory managed subset and all. There's a very large and coarse-grained semantic leap.

Then you can read the rest of https://www.steveblackburn.org/pubs/papers/vmmagic-vee-2009....>, for a bonus.

Re: The Pre-Scheme Restoration

#46

Post by sham1 »

Y_Y wrote: post #20
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…

There is also the "secret" nonguix channel which packages nonfree things for Guix: https://gitlab.com/nonguix/nonguix It's a funny problem but because it's antithetical to the original project's spirit you won't hear about it from any official Guix sources and so it's relatively unknown.

Nonfree software is a major part of nonguix, both because of the ethical problems which are the raisons d'être of the GNU project, there's also the more practical consequence drom the nonfree nature, that you can't bootstrap the binaries any you can't know their provinence beyond "it's from the vendor".

However just to clarify for others, it's not the only thing there of course. There is free software in nonguix, maybe because it's PITA to bootstrap, like for example Leinigen and other parts of the Clojure ecosystem, as well as everything and anything written using Electron. And of course notable free software things there are also the blobbed Linux kernel (probably obvious reasons), as well as Firefox, since Mozilla has some interesting trademark opinions, so you can't have it on the main Guix channel.

Re: The Pre-Scheme Restoration

#47

Post by dualogy »

nerdponx wrote: post #38
dualogy wrote: post #24

Earlier quoted context omitted.

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

Haven't, so no hard "comparison" results to offer — but Gambits libs are included in Gerbil and readily importable or some of them (maybe all? dunno) auto-imported, and Gambit is Gerbil's compilation foundation essentially AFAIK. Where it differs from or expands upon the Gambit basis is "our own macro expander" (haven't particular gotten into that area of understanding yet tho) and the extremely-modern-real-worldish stdlib (http, json, actors, db driver bindings etc), perhaps other aspects too (ie. might cover further SRFIs beyond what Gambit does, dunno for sure though; ie. the FFI might be beyond Gambit's or not, again I wouldn't know).

Re: The Pre-Scheme Restoration

#48

Post by gergo_barany »

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

Re: The Pre-Scheme Restoration

#50

Post by samatman »

davexunit wrote: post #6

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 welcome any and all experiments in the low-level programming space, and writing a good one with Lisp syntax is an obvious approach. Carp (mentioned in the article) was a good start, but seems to have stalled out, and while it's easy to see the advantages of bootstrapping from an ML language, I view it as essential to the philosophy that the compiler itself be in a broadly-compatible Lisp syntax, compatible, that is, to the resulting language or sub-language.

But I also think it will exacerbate an existing problem with C, namely, macros. Low-level programming is all about knowing exactly what's going on, and since C has a preprocessor, that's more difficult than it otherwise would be. Just because something looks like a function call, doesn't mean it actually is one.

Schemes have a much better macro system, and that will simultaneously make the core issue both better, and worse. But it's very much worthwhile to try it, imho, and see if good tooling can ameliorate the downsides, while still enjoying the power, and freedom from tedium, which macros bring to the table.

Post reply on HN