@someodd, here's a few thoughts on #haskell packaging/distribution:
Support the widest range of GHC versions, deps, and all related tools you can reasonably manage, reducing unnecessary friction.
Get your packages and their dependencies into Stackage nightly and keep them there. From there they will trickle into Stackage LTS, which is a starting point for many packaging systems.
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?
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).
This paper also includes an empirical comparison with prior work which I attempted to design in a reproducible way by using #Guix for the evaluation artifacts: https://doi.org/10.5281/zenodo.10925791
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.
Relatedly, it would be a nice feature for Haddock if the instances local to a module could be sorted and grouped for the purposes of documentation and telling a story.
Like "These are the instances for tuples of various sizes" or "this is the base case and these are some instances that recurse".
Is there any future in languages like #haskell where AI makes code a factor of small frequently and easily replaced glue and scraps, where whatever is most trained on and most hackable, most easily replaced/iterable is king?
Are big pieces of software that benefit from the architectural assurances Haskell brings a dead paradigm?
AI is here to stay and I feel if something was not already in or out of orbit, it may never reach escape velocity
effectfully describes #Haskell as a beautiful and amazing language. In episode 46 of #TheHaskellInterlude, Wouter Swierstra and Joachim Breitner asked effectfully about how he found a new passion for programming. Listen to the episode here: https://haskell.foundation/podcast/46/
"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.
Roman, known better online as effectfully, is interviewed by Wouter and Joachim. On his path to becoming a Plutus language developer at IOG, he learned English to read Software Foundations, has encountered many spaceleaks, and used Haskell to prevent robots from killing people.
Compatible types across programming languages are also important.
What if you could easily make universal types across the languages in your stack, at the same time?
That's what I'm hoping to achieve with DataTypeTool. Still a very early product, but we're getting there. Currently producing valid (albeit not-yet-serializable) #elmlang#haskell and #gleam
You can always try out #haskell snippets on https://play.haskell.org! Many libraries, like aeson, containers, vector, effectful, text and text-builder-linear, are readily available!
Is it just me or is this whole thing about „don’t do X if you don’t really know what you’re doing“ really counter productive? Many people live in fear of X now and don’t start thinking if X is an actual problem or learn what the problems are that could rise from X.
I see this very often in the #haskell ecosystem where the solution to doing X properly is often learnt in a few minutes investigation.
@mangoiv I know I've said that a few times. Two examples I can think of:
AllowAmbiguousTypes, GHC suggests this but you should probably just use Proxy arguments instead.
Typeable, people coming from OOP languages often want a typeof function, but 99% of the time there is a better way to structure your programs using simple ADTs.
I still think these are not learnt in a few minutes. Even if that was the case, the most important thing you should learn is that you shouldn't use them very often.
Flora v1.0.17 now allows you to look up executable names to find their package! No more wondering which package exposes gen-hie, refactor, or pandoc (it's pandoc-cli).
