I ported @mattmight’s CPS conversion code (https://matt.might.net/articles/cps-conversion/) to #Haskell and after some fighting with the type system, it worked! To make the interpreters work with the Cont monad, I had to remove recursive lets and hence, functions being able to call themselves recursively, but the rest works fine.
The attached images show the conversion of the Fibonacci function into the CPS version.
The decision to use Ruby for Mastodon was a poor choice, to put it mildly.
The diagram below shows relative energy consumption, with values normalized to the most efficient one. So C, as the most energy efficient, has the value 1.
I wrote the fourth part of my #blog series “Implementing Co, a small programming language with coroutines”. And this time, we add support for channels in Co for inter-coroutine communication. https://abhinavsarkar.net/posts/implementing-co-4/
#Vervis the reference implementation of @forgefed just released a tech preview of their refactored codebase that is based on the Actor Model. A mirror of the codebase can be found on #Codeberg at:
Also CL folks: "I developed an entire #Haskell-like programming language in Common Lisp only to realize its lack of features found in its 50-page standard cousin #Scheme is holding the whole project back"
> The GHC developers are happy to announce the availability of GHC 9.6.2. This release is primarily a bug-fix release addressing a few issues
found in 9.6.2.
We have found a fixpoint! Finally the knot is tied! #haskell
Moving those parts of #haskell's base library that are experimental or low-level GHC interna into a separate package to have a cleaner and more stable base sounds obviously good to me, but the proposal (and related threads) has already over 300 comments: https://github.com/haskellfoundation/tech-proposals/pull/47#issuecomment-1558028287
It shows a kind of rift and distrust between the Core Library Committee and the GHC developers:
> I have little trust in GHC developers to manage changes, and this distrust is not hypothetical or speculative.
I think something the scheme community could learn from Haskell is to lean-in on it's prestige. I see so many people post about how they were never able to figure out how to use scheme in any practical way, and most schemers I've spoke to said it took them about a year to get really compfortable. But I think the #scheme community has traditionally advertised it as "so easy, you can learn it in an afternoon!", and so people, often times already coming from some other #lisp like #clojure, expect to be able to just pick it up, and when they fail to they think the language is lacking. But nobody comes to #Haskell with such expectations, and the Haskell community never advertised it as super easy and quick to learn. In my experience, Haskell has always been sold as "takes time to learn, but is worth it".
@otfrom sheer versatility. Clojure is pretty attached to the jvm in the sense that it's secondary implementations (cljs, cljr etc) tend to lose and gain platform-specific features afaict. So Clojure doesn't have near instant startup time, thus making it not fit for scripting (theres babashka, but afaik thats a subset of clojure in javascript). Also, the lack of tail-calls makes it very difficult to implement scheme's signature features (first class continuations etc) because you have to construct a trampoline, while most of Clojure's functionality is relatively easy to implement in Scheme. And Scheme has shown itself to be a better compilers platform than #Haskell, which i've heard described by it's advocates as "a programming language for authoring compilers". Scheme is even good for writing little kernels for your programs, it's incredible for co-routines and engines in general. So it's this massive range where it comes out top in it's class in so many fields (using #chez at least) which I think makes #scheme unique, special, and worth pursuing.
Did you know? impurepics is working on a Video series based on 'Learn #Haskell by building a blog generator'. 8 videos have already been published covering up-to (and including) the I/O chapter!
Something thats kept me from getting into #Haskell beyond the periodic month long affair is that it brings out the worst of my exploratory impulses, in part because there is so much cool stuff going on. Already with #scheme I have to struggle with all my might to stop myself before I ever start trying to implement any idea I have concerning continuations, because if I dont, what would otherwise be productive time can easily melt away into to 10 hours of watching simple experimental REPLs I build unwind and turn inside out and contort in the most mind boggling patterns, like sugar poured into my braincells... when you put me behind Haskell with Wingman typed holes I'm probably even worse, because in addition to having to the ever looming seduction of "what can I get it to put in the hole?" #GHC is also sitting there practically taunting mr, as if its always asking: "would you like to go deeper?"
It's time for the #haskell Unfolder again! Tonight at 1830 UTC I'm going to talk with Edsko about injectivity of types in Haskell, and what to do if your type families are not injective.
To be fair, I think Haskell will continue to fill the niche it filled ~10 years ago, around the time it started to get mainstream hype. Small teams of skilled devs delivering robust products that would normally require much larger teams to maintain will continue to prevail. Purely functional lazy programming was never bound for world domination in an economy which is antagnostic to curiosity, creativity and truths.
On the other hand, I have the feeling that we're going to see more and more Haskellers-turned-Rustaceans come to realize that #Rust does little to alleviate the primary barrier to Haskell's wider success -- fast and predictable turnaround time for projects developing cutting-edge technologies -- and will wind up going the same route as some major Haskell projects such as #Unison and #Idris have in recent years, which is to try #Chez Scheme, only to discover that it allows them to release blazing fast functional programs on a generic foundation where major breaking changes are practically non-existent, providing incredible flexibility while significantly reducing dependencies by dint of the ad-hoc tooling that falls out of the bottom of #scheme. Not to mention the joys that come from near-instant startup times, some of the fastest compile time you've ever encountered, fully-customizable interactive development and a surgical #debugger that rivals Haskell in scheer fun. Yesterdays naysayers will become tomorrow's enthusiastic bootstrappers. Or a at least a boy can dream.
That said, in all seriousness I don't think Scheme will ever reach the heights of Haskell's moderate commercial success. But I do think that projects built on Scheme, like Unison, will get a leg up and eventually surpass it, and interest in #lisp will only grow.
Though I must admit, I am exhausted trying to get people in my company and elsewhere to see the benefit of Haskell. I had hope for a time maybe 5-10 years ago, that the world of computer education would latch on to it as an education language. But alas, they went with Python because it's "easy." Easy to get started (not easy to maintain). But if you start people with Python, that is the only language they will ever want to use for their whole life and they will quiver in fear and react violently like a cornered animal if you ever tell them they have to use anything other than Python. And now the whole AI industry is using Python and JavaScript exclusively.
I am back to using Haskell as "for personal use projects" only. But lately I have become interested in using Scheme for personal use, so much of my unfinished Haskell code has gone untouched for a few months now. I just have so little motivation to continue working on those projects when no one seems to care about it outside of that subset of software engineers who have really understand how it is better than #Python or #JavaScript in every possible way.
I'll probably get around to releasing some of my old #Haskell projects at some point, but right now I am just having too much fun with #Scheme, and I am just so god damned tired of this AI bullshit.
Fuck Python. Fuck JavaScript, fuck the whole god damned software industry who all insist these are the only languages anyone should be using.
I've been playing around with implementing a #haskell wrapper to #opencascade with a view to using it to do programmable CAD.
It's early days so far (the code has no structure, and I'm leaking memory all over the shop), but I've been able to implement the bottle example from the library tutorials.