New blog post by my colleague Finley on "Choreographing a dance with the GHC specializer (Part 1)". This is in addition to our #Haskell#Unfolder episode on the same topic tomorrow, 2024-04-16, at 1830 UTC on YouTube.
I expect the docker image would contain a GHC that stack would find and use; I am using the matching resolver for the tag (e.g.: 22.17). :blobfoxhappy:
Having to deal with type conflicts at runtime is exhausting to me. Writing non-trivial JS at work is a slog. But, I'd say #purescript is almost as much fun as #ghc#haskell and might be better-specified!
pseq combinator is used for sequencing; informally, it eval-
uates its first argument to weak-head normal form, and then eval-
uates its second argument, returning the value of its second argu-
ment. Consider this definition of parMap:
parMap f [] = []
parMap f (x:xs) = y ‘par‘ (ys ‘pseq‘ y:ys)
where y = f x
ys = parMap f xs
The intention here is to spark the evaluation of f x, and then
evaluate parMap f xs, before returning the new list y:ys. The
programmer is hoping to express an ordering of the evaluation: first
spark y, then evaluate ys.
The obvious question is this: why not use #Haskell’s built-in seq
operator instead of pseq? The only guarantee made by seq is that
it is strict in both arguments; that is, seq a ⊥ = ⊥ and seq ⊥
a = ⊥. But this semantic property makes no operational guaran-
tee about order of evaluation. An implementation could impose this
operational guarantee on seq, but that turns out to limit the optimi-
sations that can be applied when the programmer only cares about
the semantic behaviour. Instead, we provide both pseq and seq
(with and without an order-of-evaluation guarantee), to allow the
programmer to say what she wants while leaving the compiler with
as much scope for optimisation as possible. https://simonmar.github.io/bib/papers/multicore-ghc.pdf
I remember recently reading a new paper elaborating a novel presentation of graph algebras. But I can't for the life of me remember the title or the author.
The central idea was axiomatizing vertices as pairs of sets of all incoming and outgoing edges.
It also had example code in Haskell.
Does anybody have an idea of the title? I'd be very thankful for suggestions.
@simon_brooke Hey buddy, checked out #Scheme/#Scsh yesterday, super intriguing stuff. Actually, I've been digging into #Lisp and its dialects lately. Got curious about why there are so many dialects, you know?
Recently dabbled in #Clojure, which got me looking at Lisp in a new light. Unlike #Haskell, which is awesome for sure, #Lisp has been out of academia and in the market for quite a while... found it pretty cool.
Finding Success (and Failure) in Haskell by Type Classes is on sale on Leanpub! Its suggested price is $35.00; get it for $12.50 with this coupon: https://leanpub.com/sh/4sG8LBPo#Haskell
Here is a preprint of fun paper that I've been working on which investigates the utilization of formal descriptions of instruction semantics to perform symbolic binary-level program analysis: https://doi.org/10.48550/arXiv.2404.04132
It includes a prototype implementation in Haskell which performs symbolic execution of RISC-V binary code without requiring the transformation to an intermediate representation (like LLVM IR).
I'm currently finishing "The Heart of Salamanderland" for the Amstrad CPC, that will have a physical release by PolyPlay (see my Brick Rick for an example!).
The latest and greatest GHC version (9.8.2) is now available in the Alpine Linux Edge repositories and will be included in the upcoming 3.20 stable release.