#guilescheme — Public Fediverse posts

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

Found out about this while i was scrolling through andy windo blog, #Wastrel compiles Wasm modules to C, and thence to native code. we can compile #guilescheme #hoot code to native code.

https://codeberg.org/andywingo/wastrel

Found out about this while i was scrolling through andy windo blog, #Wastrel compiles Wasm modules to C, and thence to native code. we can compile #guilescheme #hoot code to native code.

https://codeberg.org/andywingo/wastrel

Found out about this while i was scrolling through andy windo blog, #Wastrel compiles Wasm modules to C, and thence to native code. we can compile #guilescheme #hoot code to native code.

https://codeberg.org/andywingo/wastrel

Found out about this while i was scrolling through andy windo blog, #Wastrel compiles Wasm modules to C, and thence to native code. we can compile #guilescheme #hoot code to native code.

https://codeberg.org/andywingo/wastrel

What am I doing... Sitting here making an algorithem to automatically mount drives on guix...
And I am more then half way there... using the out put from "lsblk -J" as a text object and some pasing shinanigans. All that's left is to find a way to get partition format outputted by something...

With this I can also automate formating.

#guixSystem #guix #GuileScheme #scheme

@momo cool!

Well then, please have a listen to the episodes of the #LispyGopherClimate podcast that me, @kentpitman and @screwlisp did these past few weeks:

• Kent Pitman presents his lisp condition system implemented for python
• Kent Pitman, Scott Zimmermann, Ramin Honary, Screwlisp: Lisp Conditions in Python
• Common Lisp condition handling lore
• Common Lisp condition system, code review of my programming example
• Common Lisp condition handling w/ Kent Pitman, Ramin Honary

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@momo cool!

Well then, please have a listen to the episodes of the #LispyGopherClimate podcast that me, @kentpitman and @screwlisp did these past few weeks:

• Kent Pitman presents his lisp condition system implemented for python
• Kent Pitman, Scott Zimmermann, Ramin Honary, Screwlisp: Lisp Conditions in Python
• Common Lisp condition handling lore
• Common Lisp condition system, code review of my programming example
• Common Lisp condition handling w/ Kent Pitman, Ramin Honary

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@momo cool!

Well then, please have a listen to the episodes of the #LispyGopherClimate podcast that me, @kentpitman and @screwlisp did these past few weeks:

• Kent Pitman presents his lisp condition system implemented for python
• Kent Pitman, Scott Zimmermann, Ramin Honary, Screwlisp: Lisp Conditions in Python
• Common Lisp condition handling lore
• Common Lisp condition system, code review of my programming example
• Common Lisp condition handling w/ Kent Pitman, Ramin Honary

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@momo cool!

Well then, please have a listen to the episodes of the #LispyGopherClimate podcast that me, @kentpitman and @screwlisp did these past few weeks:

• Kent Pitman presents his lisp condition system implemented for python
• Kent Pitman, Scott Zimmermann, Ramin Honary, Screwlisp: Lisp Conditions in Python
• Common Lisp condition handling lore
• Common Lisp condition system, code review of my programming example
• Common Lisp condition handling w/ Kent Pitman, Ramin Honary

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

Ohooo :robot_surprised: Guile 3.0.11 has just been released. The SRFI-207 String-notated bytevectors look kind of nice. And inbuilt threading functions too 7.5.48 SRFI-197: Pipeline Operators.

#Guile #GuileLang #Scheme #GuileScheme

Ohooo :robot_surprised: Guile 3.0.11 has just been released. The SRFI-207 String-notated bytevectors look kind of nice. And inbuilt threading functions too 7.5.48 SRFI-197: Pipeline Operators.

#Guile #GuileLang #Scheme #GuileScheme

Ohooo :robot_surprised: Guile 3.0.11 has just been released. The SRFI-207 String-notated bytevectors look kind of nice. And inbuilt threading functions too 7.5.48 SRFI-197: Pipeline Operators.

#Guile #GuileLang #Scheme #GuileScheme

Ohooo :robot_surprised: Guile 3.0.11 has just been released. The SRFI-207 String-notated bytevectors look kind of nice. And inbuilt threading functions too 7.5.48 SRFI-197: Pipeline Operators.

#Guile #GuileLang #Scheme #GuileScheme

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket

I sat down the other day to re-look through David Thompson guile-bstructs library, as a learning exercise.

I re-learnt a few things I didn't know before. Like how far it's possible to push syntax-rules/case. I've never quite seen anything like it before.

I've said it before, but scheme syntax-rule related stuff isn't the most intuitive thing. Fear of Macros is still the best explanation I've read; but doesn't show off the capability quite like that library does.

#Scheme #Guile #GuileScheme

I sat down the other day to re-look through David Thompson guile-bstructs library, as a learning exercise.

I re-learnt a few things I didn't know before. Like how far it's possible to push syntax-rules/case. I've never quite seen anything like it before.

I've said it before, but scheme syntax-rule related stuff isn't the most intuitive thing. Fear of Macros is still the best explanation I've read; but doesn't show off the capability quite like that library does.

#Scheme #Guile #GuileScheme

I sat down the other day to re-look through David Thompson guile-bstructs library, as a learning exercise.

I re-learnt a few things I didn't know before. Like how far it's possible to push syntax-rules/case. I've never quite seen anything like it before.

I've said it before, but scheme syntax-rule related stuff isn't the most intuitive thing. Fear of Macros is still the best explanation I've read; but doesn't show off the capability quite like that library does.

#Scheme #Guile #GuileScheme

I sat down the other day to re-look through David Thompson guile-bstructs library, as a learning exercise.

I re-learnt a few things I didn't know before. Like how far it's possible to push syntax-rules/case. I've never quite seen anything like it before.

I've said it before, but scheme syntax-rule related stuff isn't the most intuitive thing. Fear of Macros is still the best explanation I've read; but doesn't show off the capability quite like that library does.

#Scheme #Guile #GuileScheme

I sat down the other day to re-look through David Thompson guile-bstructs library, as a learning exercise.

I re-learnt a few things I didn't know before. Like how far it's possible to push syntax-rules/case. I've never quite seen anything like it before.

I've said it before, but scheme syntax-rule related stuff isn't the most intuitive thing. Fear of Macros is still the best explanation I've read; but doesn't show off the capability quite like that library does.

#Scheme #Guile #GuileScheme

I don't know, maybe the CPU is into it? I'm not judging. All jokes aside and as usual, really cool stuff by the Spritely people.
https://spritely.institute/news/announcing-spritely-oaken.html

#lisp #scheme #GuileScheme

I don't know, maybe the CPU is into it? I'm not judging. All jokes aside and as usual, really cool stuff by the Spritely people.
https://spritely.institute/news/announcing-spritely-oaken.html

#lisp #scheme #GuileScheme

I don't know, maybe the CPU is into it? I'm not judging. All jokes aside and as usual, really cool stuff by the Spritely people.
https://spritely.institute/news/announcing-spritely-oaken.html

#lisp #scheme #GuileScheme

This took me three months (a month longer than I had hoped), but I finally have merged it into the main branch!

This patch rewrites the Emacs Lisp lexer and parser in Scheme using Scheme code that is 100% compliant with the #R7RS standard, so it should now work across all compliant Scheme implementations. Previously the old parser relied on #Guile -specific regular expressions.

This patch also implements a new feature where a stack trace is printed when an error occurs. This of course makes debugging much, much easier. Previously the old parser did not keep track of where code evaluation was happening, it simply produced lists without source location information. The new parser constructs an abstract syntax tree (AST) and source locations are attached to the branches of the tree which can be used in error reporting and stack traces.

Next I will make whatever minor tweaks might be necessary to get my Emacs Lisp interpreter run on other Scheme implementations, in particular MIT Scheme, Gambit, Stklos, and Gauche. I would also like to try to get it running on Chicken and Chez, although these are going to be a bit more tricky.

Then I will continue with the task of implementing a new declarative GUI library.

#tech #software #FOSS #FunctionalProgramming #Lisp #Scheme #SchemeLang #EmacsLisp #Emacs #Schemacs #GuileScheme

This took me three months (a month longer than I had hoped), but I finally have merged it into the main branch!

This patch rewrites the Emacs Lisp lexer and parser in Scheme using Scheme code that is 100% compliant with the #R7RS standard, so it should now work across all compliant Scheme implementations. Previously the old parser relied on #Guile -specific regular expressions.

This patch also implements a new feature where a stack trace is printed when an error occurs. This of course makes debugging much, much easier. Previously the old parser did not keep track of where code evaluation was happening, it simply produced lists without source location information. The new parser constructs an abstract syntax tree (AST) and source locations are attached to the branches of the tree which can be used in error reporting and stack traces.

Next I will make whatever minor tweaks might be necessary to get my Emacs Lisp interpreter run on other Scheme implementations, in particular MIT Scheme, Gambit, Stklos, and Gauche. I would also like to try to get it running on Chicken and Chez, although these are going to be a bit more tricky.

Then I will continue with the task of implementing a new declarative GUI library.

#tech #software #FOSS #FunctionalProgramming #Lisp #Scheme #SchemeLang #EmacsLisp #Emacs #Schemacs #GuileScheme

This took me three months (a month longer than I had hoped), but I finally have merged it into the main branch!

This patch rewrites the Emacs Lisp lexer and parser in Scheme using Scheme code that is 100% compliant with the #R7RS standard, so it should now work across all compliant Scheme implementations. Previously the old parser relied on #Guile -specific regular expressions.

This patch also implements a new feature where a stack trace is printed when an error occurs. This of course makes debugging much, much easier. Previously the old parser did not keep track of where code evaluation was happening, it simply produced lists without source location information. The new parser constructs an abstract syntax tree (AST) and source locations are attached to the branches of the tree which can be used in error reporting and stack traces.

Next I will make whatever minor tweaks might be necessary to get my Emacs Lisp interpreter run on other Scheme implementations, in particular MIT Scheme, Gambit, Stklos, and Gauche. I would also like to try to get it running on Chicken and Chez, although these are going to be a bit more tricky.

Then I will continue with the task of implementing a new declarative GUI library.

#tech #software #FOSS #FunctionalProgramming #Lisp #Scheme #SchemeLang #EmacsLisp #Emacs #Schemacs #GuileScheme

This took me three months (a month longer than I had hoped), but I finally have merged it into the main branch!

This patch rewrites the Emacs Lisp lexer and parser in Scheme using Scheme code that is 100% compliant with the #R7RS standard, so it should now work across all compliant Scheme implementations. Previously the old parser relied on #Guile -specific regular expressions.

This patch also implements a new feature where a stack trace is printed when an error occurs. This of course makes debugging much, much easier. Previously the old parser did not keep track of where code evaluation was happening, it simply produced lists without source location information. The new parser constructs an abstract syntax tree (AST) and source locations are attached to the branches of the tree which can be used in error reporting and stack traces.

Next I will make whatever minor tweaks might be necessary to get my Emacs Lisp interpreter run on other Scheme implementations, in particular MIT Scheme, Gambit, Stklos, and Gauche. I would also like to try to get it running on Chicken and Chez, although these are going to be a bit more tricky.

Then I will continue with the task of implementing a new declarative GUI library.

#tech #software #FOSS #FunctionalProgramming #Lisp #Scheme #SchemeLang #EmacsLisp #Emacs #Schemacs #GuileScheme

@428 I think #GuileScheme was specifically designed to be a Lisp extension language...?

#Guile

@428 I think #GuileScheme was specifically designed to be a Lisp extension language...?

#Guile

@428 I think #GuileScheme was specifically designed to be a Lisp extension language...?

#Guile

@428 I think #GuileScheme was specifically designed to be a Lisp extension language...?

#Guile

@428 I think #GuileScheme was specifically designed to be a Lisp extension language...?

#Guile

@mark @glitzersachen there are actually active projects to use #GuileScheme with #Emacs. I don't have the details handy, but I vaguely remember there was a recent conference with a project to build with scheme and another to use #Guile as the extension language.

@mark @glitzersachen there are actually active projects to use #GuileScheme with #Emacs. I don't have the details handy, but I vaguely remember there was a recent conference with a project to build with scheme and another to use #Guile as the extension language.

@mark @glitzersachen there are actually active projects to use #GuileScheme with #Emacs. I don't have the details handy, but I vaguely remember there was a recent conference with a project to build with scheme and another to use #Guile as the extension language.

@mark @glitzersachen there are actually active projects to use #GuileScheme with #Emacs. I don't have the details handy, but I vaguely remember there was a recent conference with a project to build with scheme and another to use #Guile as the extension language.

@mark @glitzersachen there are actually active projects to use #GuileScheme with #Emacs. I don't have the details handy, but I vaguely remember there was a recent conference with a project to build with scheme and another to use #Guile as the extension language.

@treyhunner
Yep, #R and #GuileScheme

@treyhunner
Yep, #R and #GuileScheme

@treyhunner
Yep, #R and #GuileScheme

@treyhunner
Yep, #R and #GuileScheme

@treyhunner
Yep, #R and #GuileScheme

That's interesting. Guile behind the scenes uses LATIN-1 and UCS-4/UTF-32 for string encoding. #guile #scheme #GuileScheme

That's interesting. Guile behind the scenes uses LATIN-1 and UCS-4/UTF-32 for string encoding. #guile #scheme #GuileScheme

That's interesting. Guile behind the scenes uses LATIN-1 and UCS-4/UTF-32 for string encoding. #guile #scheme #GuileScheme

That's interesting. Guile behind the scenes uses LATIN-1 and UCS-4/UTF-32 for string encoding. #guile #scheme #GuileScheme