I have learned a lot about the Guile platform recently, and it is starting to feel a bit more familiar to me now. The #Scheme programming language does have support for multithreading, but in classic Scheme fashion, is much more minimal than what something like #Haskell provides (Haskell concurrency is what I know best). What Haskell calls a "mutex variable" or MVar is actually a combination of two fundamental components: "mutexs" and "condition variables." After coding my own Haskell-like MVar, I feel like I understand Scheme multithreading well enough to implement any concurrent algorithm...
...which I don't need to do because Guile Scheme provides just about every single #ConcurrentProgramming algorithm to you already, between Andy Wingo's (@wingo) Fibers library, and the Actors Library, which they describe as "a standard library of sorts ... for a variety of common actor model patterns." I can see why @cwebber occasionally shows bouts of hubris over this project, it is truly an achievement! With a little more work, Guile could become a fully networked software platform, like the World Wide Web itself.
I am also working with the Guile-GI library to program GUIs using Gtk. At the moment I am trying to figure out how to define my own class of Goblins "Vat" objects using GLib Threads so I can run a Gtk application within a Vat. I want to update the Gtk Application view from the Scheme REPL. (Any help is appreciated.)
I was kind of hoping to create my own GSource (an event source) that could actually wake up the event loop listener in Gtk and trigger the REPL, rather than do polling. But polling might be a better way to do it. I will consider both approaches.
> "sounds like you've got some cool hacks brewing :)"
I hope so. Maybe a new text editor written in Scheme, with Emacs Lisp emulation based on Robin Templeton's interpreter that is already built-in to Guile...
To be honest though, I would be happy just to do some GUI app development in Scheme.
Add comment