#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

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

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

dynamic array in PreScheme

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

#lisp #scheme #prescheme

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?

@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?

@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?

@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

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

https://prescheme.org/

https://codeberg.org/prescheme/prescheme

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

https://prescheme.org/

https://codeberg.org/prescheme/prescheme

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

https://prescheme.org/

https://codeberg.org/prescheme/prescheme

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 ?

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 ?

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 ?

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?

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

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

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.

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.

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.

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.

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.

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

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

@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

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

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

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

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

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

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!

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!

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!

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

@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

@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

@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:

@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:

@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:

@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:

@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

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

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

@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