#schemacs — Public Fediverse posts

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

Huge shout out to @ramin_hal9001 for what he's doing on #schemacs .
This has a bright future. I think Elisp lock-in is currently the main thing holding Emacs back (I don't mean it's going to get mainstream like VSCode, I mean compared to Emacs itself).
If with a refined architecture and #scheme / #guile as the base language, we can get multithreading, better speed overall, and configurations in guile instead of #elisp !

I would fully jump to the Emacs team.

https://codeberg.org/ramin_hal9001/schemacs

Huge shout out to @ramin_hal9001 for what he's doing on #schemacs .
This has a bright future. I think Elisp lock-in is currently the main thing holding Emacs back (I don't mean it's going to get mainstream like VSCode, I mean compared to Emacs itself).
If with a refined architecture and #scheme / #guile as the base language, we can get multithreading, better speed overall, and configurations in guile instead of #elisp !

I would fully jump to the Emacs team.

https://codeberg.org/ramin_hal9001/schemacs

Huge shout out to @ramin_hal9001 for what he's doing on #schemacs .
This has a bright future. I think Elisp lock-in is currently the main thing holding Emacs back (I don't mean it's going to get mainstream like VSCode, I mean compared to Emacs itself).
If with a refined architecture and #scheme / #guile as the base language, we can get multithreading, better speed overall, and configurations in guile instead of #elisp !

I would fully jump to the Emacs team.

https://codeberg.org/ramin_hal9001/schemacs

Huge shout out to @ramin_hal9001 for what he's doing on #schemacs .
This has a bright future. I think Elisp lock-in is currently the main thing holding Emacs back (I don't mean it's going to get mainstream like VSCode, I mean compared to Emacs itself).
If with a refined architecture and #scheme / #guile as the base language, we can get multithreading, better speed overall, and configurations in guile instead of #elisp !

I would fully jump to the Emacs team.

https://codeberg.org/ramin_hal9001/schemacs

Huge shout out to @ramin_hal9001 for what he's doing on #schemacs .
This has a bright future. I think Elisp lock-in is currently the main thing holding Emacs back (I don't mean it's going to get mainstream like VSCode, I mean compared to Emacs itself).
If with a refined architecture and #scheme / #guile as the base language, we can get multithreading, better speed overall, and configurations in guile instead of #elisp !

I would fully jump to the Emacs team.

https://codeberg.org/ramin_hal9001/schemacs

I cross my fingers for #Schemacs. Pretty cool! #emacs #scheme

https://youtu.be/KmMeLfYn1xY

I cross my fingers for #Schemacs. Pretty cool! #emacs #scheme

https://youtu.be/KmMeLfYn1xY

I cross my fingers for #Schemacs. Pretty cool! #emacs #scheme

https://youtu.be/KmMeLfYn1xY

I cross my fingers for #Schemacs. Pretty cool! #emacs #scheme

https://youtu.be/KmMeLfYn1xY

I cross my fingers for #Schemacs. Pretty cool! #emacs #scheme

https://youtu.be/KmMeLfYn1xY

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event)
  (let*-values (((state-ok modifiers) (event:get-state event))
               ((mod-bits)           (modifier-type->number modifiers))
               ((first-mod)           (car mod-bits)))
    (display "first modifier: ") (write first-mod) (newline)
    (display "is symbol? ") (write (symbol? first-mod)) (newline)
    (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline)
    #t
    ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask
is symbol? #t
eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event)
  (let*-values (((state-ok modifiers) (event:get-state event))
               ((mod-bits)           (modifier-type->number modifiers))
               ((first-mod)           (car mod-bits)))
    (display "first modifier: ") (write first-mod) (newline)
    (display "is symbol? ") (write (symbol? first-mod)) (newline)
    (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline)
    #t
    ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask
is symbol? #t
eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event)
  (let*-values (((state-ok modifiers) (event:get-state event))
               ((mod-bits)           (modifier-type->number modifiers))
               ((first-mod)           (car mod-bits)))
    (display "first modifier: ") (write first-mod) (newline)
    (display "is symbol? ") (write (symbol? first-mod)) (newline)
    (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline)
    #t
    ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask
is symbol? #t
eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event)
  (let*-values (((state-ok modifiers) (event:get-state event))
               ((mod-bits)           (modifier-type->number modifiers))
               ((first-mod)           (car mod-bits)))
    (display "first modifier: ") (write first-mod) (newline)
    (display "is symbol? ") (write (symbol? first-mod)) (newline)
    (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline)
    #t
    ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask
is symbol? #t
eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

Yes it is, I can tell you from experience. Of course, I was never under any illusion that it would be easy.

@kana , a.k.a. “Gudzpoz,” wrote a blog post which was shared on Lobste.rs, and they kindly mention my own Emacs clone Schemacs, though they refer to the old name of it “Gypsum” because they are citing my EmacsConf 2024 presentation done before the name changed.

It is a pretty good post going over some of the odd details about how Emacs edits text, e.g. the character range is from 0x0 to 0x3FFFFFF rather than the Unicode standard range from 0x0 to 0x10FFFF, issues with using a gap buffer as opposed to a “rope” data structure, attaching metadata (text properties) to strings to render different colors and faces, and issues with Emacs’s own unique flavor of regular expressions in which the \= symbol indicates matching on the point in the buffer. (I did not know about that last one!)

Apparently, they know these things because they are also working on their own clone of Emacs in Java for the JVM called Juicemacs (the name “Juice” upholding the theme of Java-based applications being named after drinks), and I deduce that their approach is to read through the Emacs C source code to ensure better compatibility. This is now the fourth modern Emacs+EmacsLisp clone that is still under active development that I know of, fascinating work!

My approach is to clone Emacs well enough to get it to pass regression tests, and I don’t read the C source code, I do black-box testing (because those tests become regression tests for my own source code).

Also, the goal with the Schemacs project is more to provide a Scheme-based Emacs that is backward-compatible with GNU Emacs. You use Schemacs because you want to program it in Scheme, not Emacs Lisp, but Emacs Lisp is there for you so you can still use your Emacs config. As a result, I will ignore a lot of these fussy details of the GNU Emacs implementation unless it is going to prevent regression tests from passing.

#tech #software #Emacs #GNUEmacs #Schemacs #EmacsLisp #Lisp #Java #Scheme #R7RS #SchemeLang #LispLang #JavaLang

Yes it is, I can tell you from experience. Of course, I was never under any illusion that it would be easy.

@kana , a.k.a. “Gudzpoz,” wrote a blog post which was shared on Lobste.rs, and they kindly mention my own Emacs clone Schemacs, though they refer to the old name of it “Gypsum” because they are citing my EmacsConf 2024 presentation done before the name changed.

It is a pretty good post going over some of the odd details about how Emacs edits text, e.g. the character range is from 0x0 to 0x3FFFFFF rather than the Unicode standard range from 0x0 to 0x10FFFF, issues with using a gap buffer as opposed to a “rope” data structure, attaching metadata (text properties) to strings to render different colors and faces, and issues with Emacs’s own unique flavor of regular expressions in which the \= symbol indicates matching on the point in the buffer. (I did not know about that last one!)

Apparently, they know these things because they are also working on their own clone of Emacs in Java for the JVM called Juicemacs (the name “Juice” upholding the theme of Java-based applications being named after drinks), and I deduce that their approach is to read through the Emacs C source code to ensure better compatibility. This is now the fourth modern Emacs+EmacsLisp clone that is still under active development that I know of, fascinating work!

My approach is to clone Emacs well enough to get it to pass regression tests, and I don’t read the C source code, I do black-box testing (because those tests become regression tests for my own source code).

Also, the goal with the Schemacs project is more to provide a Scheme-based Emacs that is backward-compatible with GNU Emacs. You use Schemacs because you want to program it in Scheme, not Emacs Lisp, but Emacs Lisp is there for you so you can still use your Emacs config. As a result, I will ignore a lot of these fussy details of the GNU Emacs implementation unless it is going to prevent regression tests from passing.

#tech #software #Emacs #GNUEmacs #Schemacs #EmacsLisp #Lisp #Java #Scheme #R7RS #SchemeLang #LispLang #JavaLang

Yes it is, I can tell you from experience. Of course, I was never under any illusion that it would be easy.

@kana , a.k.a. “Gudzpoz,” wrote a blog post which was shared on Lobste.rs, and they kindly mention my own Emacs clone Schemacs, though they refer to the old name of it “Gypsum” because they are citing my EmacsConf 2024 presentation done before the name changed.

It is a pretty good post going over some of the odd details about how Emacs edits text, e.g. the character range is from 0x0 to 0x3FFFFFF rather than the Unicode standard range from 0x0 to 0x10FFFF, issues with using a gap buffer as opposed to a “rope” data structure, attaching metadata (text properties) to strings to render different colors and faces, and issues with Emacs’s own unique flavor of regular expressions in which the \= symbol indicates matching on the point in the buffer. (I did not know about that last one!)

Apparently, they know these things because they are also working on their own clone of Emacs in Java for the JVM called Juicemacs (the name “Juice” upholding the theme of Java-based applications being named after drinks), and I deduce that their approach is to read through the Emacs C source code to ensure better compatibility. This is now the fourth modern Emacs+EmacsLisp clone that is still under active development that I know of, fascinating work!

My approach is to clone Emacs well enough to get it to pass regression tests, and I don’t read the C source code, I do black-box testing (because those tests become regression tests for my own source code).

Also, the goal with the Schemacs project is more to provide a Scheme-based Emacs that is backward-compatible with GNU Emacs. You use Schemacs because you want to program it in Scheme, not Emacs Lisp, but Emacs Lisp is there for you so you can still use your Emacs config. As a result, I will ignore a lot of these fussy details of the GNU Emacs implementation unless it is going to prevent regression tests from passing.

#tech #software #Emacs #GNUEmacs #Schemacs #EmacsLisp #Lisp #Java #Scheme #R7RS #SchemeLang #LispLang #JavaLang

Yes it is, I can tell you from experience. Of course, I was never under any illusion that it would be easy.

@kana , a.k.a. “Gudzpoz,” wrote a blog post which was shared on Lobste.rs, and they kindly mention my own Emacs clone Schemacs, though they refer to the old name of it “Gypsum” because they are citing my EmacsConf 2024 presentation done before the name changed.

It is a pretty good post going over some of the odd details about how Emacs edits text, e.g. the character range is from 0x0 to 0x3FFFFFF rather than the Unicode standard range from 0x0 to 0x10FFFF, issues with using a gap buffer as opposed to a “rope” data structure, attaching metadata (text properties) to strings to render different colors and faces, and issues with Emacs’s own unique flavor of regular expressions in which the \= symbol indicates matching on the point in the buffer. (I did not know about that last one!)

Apparently, they know these things because they are also working on their own clone of Emacs in Java for the JVM called Juicemacs (the name “Juice” upholding the theme of Java-based applications being named after drinks), and I deduce that their approach is to read through the Emacs C source code to ensure better compatibility. This is now the fourth modern Emacs+EmacsLisp clone that is still under active development that I know of, fascinating work!

My approach is to clone Emacs well enough to get it to pass regression tests, and I don’t read the C source code, I do black-box testing (because those tests become regression tests for my own source code).

Also, the goal with the Schemacs project is more to provide a Scheme-based Emacs that is backward-compatible with GNU Emacs. You use Schemacs because you want to program it in Scheme, not Emacs Lisp, but Emacs Lisp is there for you so you can still use your Emacs config. As a result, I will ignore a lot of these fussy details of the GNU Emacs implementation unless it is going to prevent regression tests from passing.

#tech #software #Emacs #GNUEmacs #Schemacs #EmacsLisp #Lisp #Java #Scheme #R7RS #SchemeLang #LispLang #JavaLang

With pull request #50 the Schemacs Elisp interpreter is now able to load all of two very important Emacs Lisp source files:

• ./lisp/emacs-lisp/byte-run.el and
• ./lisp/subr.el

…which are two files that define most of what you could call the the Emacs Lisp “core” language (by which I mean macros like defun and lambda).

With these files now loaded, I can proceed to the next task, which is implementing enough of the C-level built-in functions in Scheme to be able to run ./lisp/emacs-lisp/cl-lib.el, which is in-turn one of the dependencies for running the Emacs Regression Tests (ERT) suite.

Once ERT is up and running, it will be much easier for anyone to contribute code to this project as you will just be able to pick a failing regression test and write whatever code is necessary to make it pass.

#tech #software #Emacs #EmacsLisp #Lisp #Scheme #SchemeLang #R7RS #FOSS #FreeSoftware

With pull request #50 the Schemacs Elisp interpreter is now able to load all of two very important Emacs Lisp source files:

• ./lisp/emacs-lisp/byte-run.el and
• ./lisp/subr.el

…which are two files that define most of what you could call the the Emacs Lisp “core” language (by which I mean macros like defun and lambda).

With these files now loaded, I can proceed to the next task, which is implementing enough of the C-level built-in functions in Scheme to be able to run ./lisp/emacs-lisp/cl-lib.el, which is in-turn one of the dependencies for running the Emacs Regression Tests (ERT) suite.

Once ERT is up and running, it will be much easier for anyone to contribute code to this project as you will just be able to pick a failing regression test and write whatever code is necessary to make it pass.

#tech #software #Emacs #EmacsLisp #Lisp #Scheme #SchemeLang #R7RS #FOSS #FreeSoftware

With pull request #50 the Schemacs Elisp interpreter is now able to load all of two very important Emacs Lisp source files:

• ./lisp/emacs-lisp/byte-run.el and
• ./lisp/subr.el

…which are two files that define most of what you could call the the Emacs Lisp “core” language (by which I mean macros like defun and lambda).

With these files now loaded, I can proceed to the next task, which is implementing enough of the C-level built-in functions in Scheme to be able to run ./lisp/emacs-lisp/cl-lib.el, which is in-turn one of the dependencies for running the Emacs Regression Tests (ERT) suite.

Once ERT is up and running, it will be much easier for anyone to contribute code to this project as you will just be able to pick a failing regression test and write whatever code is necessary to make it pass.

#tech #software #Emacs #EmacsLisp #Lisp #Scheme #SchemeLang #R7RS #FOSS #FreeSoftware

With pull request #50 the Schemacs Elisp interpreter is now able to load all of two very important Emacs Lisp source files:

• ./lisp/emacs-lisp/byte-run.el and
• ./lisp/subr.el

…which are two files that define most of what you could call the the Emacs Lisp “core” language (by which I mean macros like defun and lambda).

With these files now loaded, I can proceed to the next task, which is implementing enough of the C-level built-in functions in Scheme to be able to run ./lisp/emacs-lisp/cl-lib.el, which is in-turn one of the dependencies for running the Emacs Regression Tests (ERT) suite.

Once ERT is up and running, it will be much easier for anyone to contribute code to this project as you will just be able to pick a failing regression test and write whatever code is necessary to make it pass.

#tech #software #Emacs #EmacsLisp #Lisp #Scheme #SchemeLang #R7RS #FOSS #FreeSoftware

…except there is not much in the way of original research. But I have received a lot of positive feedback about my project from the Scheme and Emacs community. So let me ask the Scheme/Emacs fediverse: if you would be interested in using or contributing to a Scheme-based Emacs that is mostly backward-compatible with #GNUEmacs , what is it about this prospect that is most interesting to you?

Personally, I live inside of Emacs and program most of my personal workflows in Emacs Lisp, though I feel that Scheme is a more interesting and fun language to use when compared to other #Lisp-family languages. So I would just like to be able to use Scheme as the language in which I program all of my personal workflows. Also I am curious if it is possible to write a large application in #R7RS Scheme such that it runs on many different Scheme implementations.

So does anyone else agree, or are there other things about a prospective Scheme-based Emacs that interest you that might be worth mentioning to a the audience of the Scheme-related chapters of the ICFP?

I was talking with William Byrd, who is one of the conference organizers of ICFP/SPLASH this year, and he says the committee could possibly accept anything of interest to the Scheme community, for example experience reports and “position papers” (helping others understand an opinion or philosophy on the topic). And they would judge these papers on different criteria than a paper about novel scientific research.

Anyone feel free to comment, but I am going to ping a few people in particular who seem to have opinions on this, like @dougmerritt @jameshowell @david_megginson @tusharhero @arialdo @lispwitch @cwebber @dpk and also @PaniczGodek who published on GRASP at this conference last year, if I recall correctly.

• https://conf.researchr.org/home/icfp-splash-2025/scheme-2025#Call-for-Papers
• https://codeberg.org/ramin_hal9001/schemacs

#tech #software #FOSS #FLOSS #SchemeLang #ProgrammingLanguage

…except there is not much in the way of original research. But I have received a lot of positive feedback about my project from the Scheme and Emacs community. So let me ask the Scheme/Emacs fediverse: if you would be interested in using or contributing to a Scheme-based Emacs that is mostly backward-compatible with #GNUEmacs , what is it about this prospect that is most interesting to you?

Personally, I live inside of Emacs and program most of my personal workflows in Emacs Lisp, though I feel that Scheme is a more interesting and fun language to use when compared to other #Lisp-family languages. So I would just like to be able to use Scheme as the language in which I program all of my personal workflows. Also I am curious if it is possible to write a large application in #R7RS Scheme such that it runs on many different Scheme implementations.

So does anyone else agree, or are there other things about a prospective Scheme-based Emacs that interest you that might be worth mentioning to a the audience of the Scheme-related chapters of the ICFP?

I was talking with William Byrd, who is one of the conference organizers of ICFP/SPLASH this year, and he says the committee could possibly accept anything of interest to the Scheme community, for example experience reports and “position papers” (helping others understand an opinion or philosophy on the topic). And they would judge these papers on different criteria than a paper about novel scientific research.

Anyone feel free to comment, but I am going to ping a few people in particular who seem to have opinions on this, like @dougmerritt @jameshowell @david_megginson @tusharhero @arialdo @lispwitch @cwebber @dpk and also @PaniczGodek who published on GRASP at this conference last year, if I recall correctly.

• https://conf.researchr.org/home/icfp-splash-2025/scheme-2025#Call-for-Papers
• https://codeberg.org/ramin_hal9001/schemacs

#tech #software #FOSS #FLOSS #SchemeLang #ProgrammingLanguage

…except there is not much in the way of original research. But I have received a lot of positive feedback about my project from the Scheme and Emacs community. So let me ask the Scheme/Emacs fediverse: if you would be interested in using or contributing to a Scheme-based Emacs that is mostly backward-compatible with #GNUEmacs , what is it about this prospect that is most interesting to you?

Personally, I live inside of Emacs and program most of my personal workflows in Emacs Lisp, though I feel that Scheme is a more interesting and fun language to use when compared to other #Lisp-family languages. So I would just like to be able to use Scheme as the language in which I program all of my personal workflows. Also I am curious if it is possible to write a large application in #R7RS Scheme such that it runs on many different Scheme implementations.

So does anyone else agree, or are there other things about a prospective Scheme-based Emacs that interest you that might be worth mentioning to a the audience of the Scheme-related chapters of the ICFP?

I was talking with William Byrd, who is one of the conference organizers of ICFP/SPLASH this year, and he says the committee could possibly accept anything of interest to the Scheme community, for example experience reports and “position papers” (helping others understand an opinion or philosophy on the topic). And they would judge these papers on different criteria than a paper about novel scientific research.

Anyone feel free to comment, but I am going to ping a few people in particular who seem to have opinions on this, like @dougmerritt @jameshowell @david_megginson @tusharhero @arialdo @lispwitch @cwebber @dpk and also @PaniczGodek who published on GRASP at this conference last year, if I recall correctly.

• https://conf.researchr.org/home/icfp-splash-2025/scheme-2025#Call-for-Papers
• https://codeberg.org/ramin_hal9001/schemacs

#tech #software #FOSS #FLOSS #SchemeLang #ProgrammingLanguage

…except there is not much in the way of original research. But I have received a lot of positive feedback about my project from the Scheme and Emacs community. So let me ask the Scheme/Emacs fediverse: if you would be interested in using or contributing to a Scheme-based Emacs that is mostly backward-compatible with #GNUEmacs , what is it about this prospect that is most interesting to you?

Personally, I live inside of Emacs and program most of my personal workflows in Emacs Lisp, though I feel that Scheme is a more interesting and fun language to use when compared to other #Lisp-family languages. So I would just like to be able to use Scheme as the language in which I program all of my personal workflows. Also I am curious if it is possible to write a large application in #R7RS Scheme such that it runs on many different Scheme implementations.

So does anyone else agree, or are there other things about a prospective Scheme-based Emacs that interest you that might be worth mentioning to a the audience of the Scheme-related chapters of the ICFP?

I was talking with William Byrd, who is one of the conference organizers of ICFP/SPLASH this year, and he says the committee could possibly accept anything of interest to the Scheme community, for example experience reports and “position papers” (helping others understand an opinion or philosophy on the topic). And they would judge these papers on different criteria than a paper about novel scientific research.

Anyone feel free to comment, but I am going to ping a few people in particular who seem to have opinions on this, like @dougmerritt @jameshowell @david_megginson @tusharhero @arialdo @lispwitch @cwebber @dpk and also @PaniczGodek who published on GRASP at this conference last year, if I recall correctly.

• https://conf.researchr.org/home/icfp-splash-2025/scheme-2025#Call-for-Papers
• https://codeberg.org/ramin_hal9001/schemacs

#tech #software #FOSS #FLOSS #SchemeLang #ProgrammingLanguage

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

#Schemacs, yet another #emacsen written in #chez #scheme

https://github.com/guenchi/Schemacs

#Schemacs, yet another #emacsen written in #chez #scheme

https://github.com/guenchi/Schemacs

#Schemacs, yet another #emacsen written in #chez #scheme

https://github.com/guenchi/Schemacs

#Schemacs, yet another #emacsen written in #chez #scheme

https://github.com/guenchi/Schemacs