The best case scenario when testing a piece of software is when we have a reference implementation to compare against. Often however such a reference is not available, begging the question how to test a function if we cannot verify what that function computes exactly. In this episode we will consider how to define properties to...
I have been appointed to the ghc steering committee. Very excited about contributing to make #Haskell move forward. Seeing who left the committee there are some shoes left there which I won’t even try to fill.
After my recent crash on arch, the system installation of ghc is so badly broken that I'm temporarily using i3 instead of xmonad. Not having a massive dependency for my window manager feels good, but I love xmonad and would like to get back to it.
If only I could nuke the ghc install and get back to sanity. I've tried reinstalling ghc and all the Haskell libraries to no avail.
In this two-day event, held on the lakeside campus of OST in lovely Rapperswil, Switzerland, you can learn what you need to know in order to get started working on these tools. We’ve asked the presenters to identify ‘good first issues’ for those wanting to get their feet wet on contributing. Because the workshop is...
Haskell is one of the organizations selected for Google Summer of Code 2024! 🌟 This is a great chance for OSS newcomers to dive into the #Haskell ecosystem and make a lasting impact. Huge thanks to all who submitted project ideas and volunteered as mentors! #GSoChttps://discourse.haskell.org/t/haskell-selected-for-gsoc-2024/8916
fixpoint combinators like Y can't be well-typed in #Haskell. Specifically, something of the form x x requires x to have two conflicting types simultaneously. In dynamic languages, this doesn't matter because you just don't care what the type is, only that you can use the value in some way. But a Haskell compiler does care. However there's no need for such combinators, because Haskell's solution fix f = let x = f x in x is more elegant anyway, and has no typing difficulties (but does require lazy evaluation). #javascript is perhaps not the best launchpad to haskell , to their credit they make good fp presentations https://stackoverflow.com/questions/68975627/translating-a-fixed-point-operator-to-haskell-language
The difference between FFI design in #haskell in #lean4
In Haskell all the heavy lifting happens in haskell. I.e. you allocate and free memory, peek and poke data from/to C structures etc. As a result, C part known almost nothing about haskell.
In lean it's other way around: C functions get lean objects as arguments, convert them into C data, create new lean objects and return them. As a result, lean's C API is big, complicated and unstable.
The next episode of the #Haskell Unfolder will be on Wednesday, 2024-03-06, on property-based testing, more specifically on "testing without a reference", i.e., what to do if you want to test code but do not have any kind of reference implementation available.
TFW you cobble together a Haskell program of less than 20 lines of code with one dependency (in addition to the standard runtime) and it takes several minutes to build (the first time around).
one aspect #haskell still sucks is build parallelism:
vanilla cabal builds are coarse grained and have component level build dependency
cabal/ghc has multiple home units now but that's only for repl for the time being
cabal/ghc has semaphores now so multiple ghc --make -jsem processes can share cpu cores without oversubscribing. which is nicer, but not nice enough
semaphore format is home brew and not something more standard like make jobserver. hard to fit in external build systems
external build systems resort to using oneshot mode instead of make mode, so one ghc invocation produces one .hi .o pair, and a fair amount of cpu cycles is wasted compared to make mode due to repeatedly building context that could have been shared
more importantly, once .hi of upstream module is emitted, before ghc -c exits, downstream module should queue for compilation immediately. but this is tricky to implement and often omitted
ironically the wasted cpu cycles in ghc oneshot mode is often compensated by increased parallelism. because external build systems parse cabal metadata but breaks cabal component level dependency wall
but now there's a thing called cabal custom setup and now you need to resort to actually respecting Setup.hs for those packages and they can easily become bottlenecks of a build
the people equipped with knowledge to fix the situation thoroughly have tons of more important issues on their plate
another annoying thing about the one shot mode is that it's necessary to be able to distrust the incremental compilation of ghc and have a build system without a concept of previous build. so you have this very frustrating tension between good parallelism and incremental builds in such systems and i have no idea a proper solution: https://jade.fyi/blog/the-postmodern-build-system/
Wouter and Niki interview Jose Calderon, the new Executive Director of the Haskell Foundation. Jose tells why he applied for the job, how he sees the foundation developing over the coming years, and how you can get involved in the Haskell community.
The Haskell.org Committee is thrilled to welcome new members on board: Avi Press, Matthías Páll Gissurarson, and Moritz Angermann. A big thank you to Tikhon Jelvis, Ryan Trinkle, and Ida Bzowska, who served as committee members until the end of 2023, contributing significantly to various projects within the #Haskell language ecosystem and community.
@DiazCarrete I don't think I'd want to change the string type that often, but being able to make it be a specific type instead of having it be overloaded would be nice.
ok. sparks is indeed a nice way to get work stealing nested parallelism for free in #haskell, as long as you work with spark# directly and don't use par, pseq or anything built upon these combinators
@leftpaddotpy spark# is state# passing so you can explicitly spawn a spark as a monadic operation in io or st which feels natural. on the other hand, par's purity is an undesired burden because you now have evaluation order to worry about and litter your code with pseq. the entire "Strategy" thing and "Eval" monad in the parallel package is a huge distraction in the same sense
The GHC developers are happy to announce the availability of GHC 9.8.2. Binary distributions, source distributions, and documentation are available on the release page....
Anyone know of an interactive "lambda calculus" expression evaluation site? Or something in that UX neighborhood that I should use for inspiration?
I know I used to answer a lot of #haskell questions just by stepping though evaluation. I thought it would be nice to have that on a website and I have a basic expression parser and visualizer in #purescript running on my website ("production" is a buggy version, tho) but need to design interactive stepping.
