#prescheme — Public Fediverse posts

PreScheme arena allocator, the funny part is i can just define external C text like in address->color and color-size LOL

#scheme #prescheme #lisp

dynamic array in PreScheme

prescheme from scheme48 source in ps-compiler directory, not from restoration prescheme

#lisp #scheme #prescheme

@daviwil #systemcrafters #sigil I’m really excited to see what sigil could actually be. I really envision a flutter like UI kit using #scheme and able to compile to wasm. Is there any interest with #prescheme , possibly have sigil compile down to C?

Whatever happened to the #PreScheme restoration project? Was it abandoned?

https://prescheme.org/

https://codeberg.org/prescheme/prescheme

So I guess it makes more sense to create wrappers from rust to C then create #guile bindings from the C code. #niri #guile #scheme, maybe is a great time to learn #prescheme ?

Is #prescheme still being worked on? Is #gerbil worth it? What other #lisp #scheme dialects would be great for systems programming?

I'd love to get an update on what's going on with #PreScheme, but alas:

- There's only been a single progress report posted on https://prescheme.org, over a year ago
- @flatwhatson hasn't posted on Mastodon in many months

I worry that the Pre-Scheme project might have died a quiet death.

Small Headed Programming by Pjotr Prins

#PreScheme looks really nice (for Pythonistas think Cython but this transpiles to proper C, just like #Vala transpiles a C# like language to C)

Readable Lisp, readable C

https://fosdem.org/2025/schedule/event/fosdem-2025-5848-small-headed-programming-for-performance-with-prescheme-nim-and-zig/ #FOSDEM
#FOSDEM2025
#FLOSSConf
#FLOSSConference

@kaveman @lisp_discussions CRUNCH looks excellent! I'm very glad that the work on #prescheme has encouraged others to experiment with the combination of static typing, minimal runtime, and Scheme metaprogramming. Felix has covered a lot of ground on the language design & tooling, I'll definitely be keeping CRUNCH compatibility in mind as the Pre-Scheme restoration progresses.

Thanks @pjotrprins, #prescheme is definitely lacking in documentation and examples right now, and I know that people are eager to dive in. Unfortunately it's not very user-friendly in its current state; the language didn't see much use outside of its initial use-case, and it shows!

After the port is complete, I'll be making a number of language and tooling changes to improve this situation. Once those are settled, I'll move on to documentation and guides to make the language accessible to a wider audience.

An outline of the planned changes can be found here: https://prescheme.org/roadmap.html

@nlnet

It's time for an update on the Pre-Scheme Restoration project!

TL;DR: The compiler is approximately 75% ported to Chibi, Sagittarius and Guile, with Unsyntax expander integration underway. We've also got a new R7RS compatibility layer for Scheme 48, and a bunch of tooling written with Scsh.

Thanks to @nlnet for supporting this project under the NGI Zero Core program.

See my update post for more details: https://prescheme.org/posts/first-report-on-the-pre-scheme-restoration.html

#scheme #prescheme

Wow @aartaka, this is excellent, thanks!

This beautifully demonstrates a number of nice things about #prescheme:

- The power of using #scheme macros to define language constructs.
- The flexibility of full type inference as the base model for static typing.
- The efficiency of having a proper optimizing compiler (in this case, dead code elimination).

Very cool!

@aartaka I was curious how SRFI 253 could be supported without predicates, but I see the implementation-specific macros treat the predicates as identifier literals and translate them into the equivalent type names. That approach could definitely be made to work for #prescheme, nice!

I think the situation with support for explicit types in Scheme can be explained by survivorship bias. Programmers who strongly prefer type declarations are better served by other languages, so we're left with a community that are generally happy to omit them. FFI's are just one place where they're really not optional.

Cheers!

@daviwil

@aartaka thanks for working on SRFI 253, and thanks for your interest in #prescheme!

The original/legacy implementation of Pre-Scheme provides no support for runtime type checks. This is because there is no type information available at runtime; all types are inferred & resolved at compile-time, and the type information is discarded when lowering to machine code. This reflects the functionality of C, which has no analogue for Scheme's `integer?`.

It does have explicit types in two places: the definition of record types (where each field must have a type), and the declaration of external identifiers. The notation for types uses `(=> (integer integer) integer)` to represent a binary operation on integers, and `(^ integer)` to represent a pointer-to-integer. This resembles Chicken's notation (http://wiki.call-cc.org/man/5/Types) if `=>` was an alias for `procedure`, though Chicken doesn't appear to support typed pointers.

Given this starting point, something like Chicken's `:` and `the` (which is also a Common Lisp-ism) would be the easiest way to extend Pre-Scheme with support for type annotations. As for Bigloo's `::` type suffixes, they're not compatible with Scheme's rules for identifier naming, and therefore not compatible with Pre-Scheme's goal of being a Scheme "subset".

I think the "holy grail" for a future version of Pre-Scheme would be to support Scheme's type predicates as compile-time checks. This would be the most natural system for Scheme programmers, and could form the basis of a lightweight type checking syntax compatible with SRFI 145 and SRFI 253. In addition to type checking, predicates would introduce a general mechanism for ad-hoc polymorphism to Pre-Scheme, which would be very useful, but has implications for type inference which need to be explored.

In the coming months I'll be working on some initial (simpler!) extensions for Pre-Scheme's type system to support sized numeric types, polymorphic arithmetic, and unions/sum types. These all touch on the same topic from slightly different directions, and I'll be in a better position to plan further extensions once they're done.

@daviwil

@daviwil Sorry I couldn't catch this live, but I enjoyed watching the VOD!

Going "first principles" from the manual to a working program popping up a Raylib window is impressive, a valiant effort despite the arcane tooling!

You might be interested in looking at the https://codeberg.org/prescheme/prescheme-demo repository, it has some basic examples tied together with a Guix manifest and a simple Makefile which makes for a slightly more comfortable workflow.

For the Scheme 48 REPL, you can leave error levels with `,reset`, equivalent to Guile's `,q` or `,quit`. I also find it useful to run scheme48 inside rlwrap to get some completion and history:

https://codeberg.org/prescheme/s48-r7rs/src/branch/main/bin/run-s48

Really appreciate the stream and getting some more hands and eyeballs on #prescheme :blobcatscience:

@ramin_hal9001

> #Scheme on top of #PreScheme
Ah, you are a minimalist that way. Sort of what #Squeak #Smalltalk does with its VM development (based on C). I'd want the high-level language to do heavy-lifting, so maybe #LispFlavouredErlang on top of PreScheme.

> OS in PreScheme and Scheme
GNU Mes and #Guix must be on that track.

@louis @craigbro

@ramin_hal9001
As a #Zig fan, and also unhappy about NIH, yours is a very sobering take. I guess you imply that only code to bootstrap a higher-level language should be written in a lower-level language and #PreScheme is enough for that. But what do you typically use for everything on top of that?
@louis @craigbro

@lechner It depends how you want to define "arrival"!

The compiler has been around for a long time, and you can use #prescheme today; the easiest way is the scheme48-prescheme package in Guix, as shown here: https://codeberg.org/prescheme/prescheme-demo

There are plenty of rough edges, hence the Pre-Scheme Restoration project. I expect to be done with initial porting work in the next month, and then continue with the other improvements outlined. There will be posts along the way so you can follow my progress, and this should culminate in a release early 2025.

@jamiejennings Thanks Jamie, it's great to hear from people with hands-on experience in this space.

I haven't looked into Kali Scheme closely, but a distributed Scheme system reminds me a lot of what the @spritelyinst are working on with the Goblins framework. Very cool stuff!

Running the Pre-Scheme compiler on Scheme 48 is a bit easier these days, the scheme48-prescheme package in Guix hides most of the messy details, and the prescheme-demo repository has some simple examples tied together with a Makefile.

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/scheme.scm#n428

https://codeberg.org/prescheme/prescheme-demo

#scheme #prescheme

@mirkoh Yes, this limitation is one of the first things that will be addressed after the initial porting work is complete. The plan is to expose the full set of signed and unsigned 8/16/32/64-bit integers (stdint.h), float, and double, along with polymorphic arithmetic operators so you can use them together in the same program, as you would in C.

#prescheme

@filip The current project is focused on running the compiler in a Scheme implementation, and generating native code with a C compiler.

The bootstrapping story is really a question of "how much Scheme" and "how much C". I'd love for Pre-Scheme to run on GNU Mes, but that hasn't been investigated yet. I'm in touch with folks in the bootstrapping community who are experts in minimal C compilers, and intend to do a detailed analysis of compatibility at some point. Early diagnosis is that Pre-Scheme isn't very demanding of a C compiler and targeting minimal compilers should be possible.

Beyond that, there's the possibility for adding new backends to the Pre-Scheme compiler. The original compiler described in "Compilation By Program Transformation" emitted m68k assembly. The paper "A Tractable Native-Code Scheme System" describes re-purposing the compiler as a bytecode optimizer, which involved writing a backend to emit Scheme 48 bytecode. I also have colleagues who are very interested in the possibility of a WebAssembly backend.

https://prescheme.org/references.html

#prescheme #bootstrappablebuilds

Maybe the denizens of Guix and Guile worlds are interested in this

«Announcing the Pre-Scheme Restoration project! Many thanks to @nlnet who have made this project possible.»

«The primary objective of the Pre-Scheme Restoration project is to make Pre-Scheme available as a practical alternative to C for the wider Scheme community.»

— @flatwhatson

https://prescheme.org/posts/announcing-the-pre-scheme-restoration.html

#gnu #guix #guile #scheme #prescheme

Announcing the Pre-Scheme Restoration project! Many thanks to @nlnet who have made this project possible.

https://prescheme.org/posts/announcing-the-pre-scheme-restoration.html

#scheme #prescheme

after finishing LiSP I might have a stab at reading along with #prescheme