Anyone in my #haskell (or other, I guess) circles in charge of www.cs.nott.ac.uk ? It was working yesterday, but it keeps timing out (for me) today.
I need to re-read the section of blampied-thesis.pdf on the prefix functor, and especially how it works when the non-uniform type is self-nested in interesting ways.
Trying to do a "project :: t -> f t" and keep getting hung up on the Scope-modified recursions.
Alternatively, is that thesis available elsewhere? I searched, but haven't found.
This is a great blog post on the WellTyped blog on specialization in Haskell! It's a good reminder that I (or someone) should really get around to getting rid of -fexpose-all-unfoldings and -fspecialize-agressively in the Agda codebase.
Helsinki Haskell Users Group's first book club had its conclusion meeting today with Sockets and Pipes coming to its very end. It has been a ride, one with plenty of scheduling difficulties, but I think we only fell like a month and a half from the original planned schedule and actually had a member retention rate of 100% (of members who were there in the beginning, sadly we could not quite make it 133%)!
To talk a bit about the book as a whole, I do feel like I understand Monad Transformers a lot better now though I'll still need to reread the sections introducing them I am sure. ReaderT especially was something I could see was colossally handy, but given it was in the second to last chapter we were already quite deep with trying to understand everything else so the true utility of it remains somewhat hazy despite the quality of the chapter itself which felt higher than those surrounding it. The habit of reading RFCs and attempting to match the spec in the types one writes is also one I should include in my general workflow, though that is probably a no-brainer for most. It just wasn't a thing in my previous work, so bear with me while I call it a novel concept!
I'm still working on my personal project, but getting nix-build working seems difficult. I'll just have to bring it up in the next main group Office Hours meetup I suppose, lest I never get this show on the road!
I've got a specific type that uses a #bound approach but I'd like to write some general folds (using e.g. algebra families) instead of duplicating the "traversal" code.
I might have done the categorical approach (functor categories instead of algebra families) before, but that has limitations and I think I lost the code.
You might say "Well, that's not a problem, just make those intermediate components that don't care about the connection polymorphic over MonadUnliftIO! Later, when composing the application, they will be injected a repository that does know about the ReaderT and the connection. Problem solved."
That's true, but what if I wanted those intermediate components to be as dumb as possible? Just plain records of functions in IO, no monad transformers, and no polymorphism over the monad, either?
Only very few breakages from Flora's #Haskell dependencies with GHC 9.10.1-alpha3. We may be able to adopt it as soon as HLS supports it (and a nice dose of "allow-newer" in cabal.project configuration)
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.
This is the first of a two-part series of blog posts on GHC specialization, an optimization technique used by GHC to eliminate the performance overhead of ad-hoc polymorphism and enable other powerful optimizations. There will also be a Haskell Unfolder episode about this topic.
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:
@simonmic Done-ish (mostly linked to my post here)
On a separate note, how portable is my account? I just picked element since it seemed like a zero-install option. If I use matrix more, I might want to switch clients to something that integrates will with KDE.
After extensively using the #lens#Haskell library for half a year at work I have now played around with the #optics library again. I am amazed by how much more helpful error messages are with #optics. It’s an amazing library and I would recommend it over #lens whenever you have the choice.
@mangoiv Hasn’t been my impression with #optics yet. To me it feels like the type level stuff is "finished". As long as you only define and use existing types of optics you don’t need to worry about it.
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
"registry"-like approaches do seem to make it easier to reuse previously assembled application contexts because the wiring is done through a dictionary-like data structure. You can easily overwrite any key with a different implementation, or with a mock.
@DiazCarrete That slide seems to misrepresent effect systems. It is easy to replace just runInputConst:
runAllEffects (runInputDifferently program)
The runInputDifferently effect handles the Input Config effect and it leaves an unused Input Config in the list of effects. So the runInputConst config handler in runAllEffects will not be used.
@boarders This is one of my use cases. The great thing about recursion schemes is that they don’t require recursion. And all streaming can be done with recursion schemes, so also no recursion.
But currently it’s pretty basic. You can use recursive functions from other modules … as long as they don’t get inlined. And there’s no way to restrict imported recursive functions. But please, open issues with stuff you’d like to see.
@sellout ah fantastic, I want the same thing (I actually wanted it as a language extension similar to explicitly letrec, but dont currently have faith in the language proposal process as it attracts a lot of lawyer types)
For the guarded recursion thing, I had in mind coinductive programming which can be done with recursion schemes for coalgebra or with have an explicit tick operator as in guarded type theory / agda
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.
