But I find such articles ridiculously hard to understand, especially system F (although I have been coding in #haskell for years).
Ironically, dependently-typed seem much simpler. In non-dependently-typed systems it's very hard to pinpoint the connections between types and terms. In dependently-typed systems, terms and types are the same thing.
Feeling many systems kinda approach the problem wrong, maybe we should have the constrained program synthesis way instead of typechecking-first everywhere by default - yeeeeeees very much.
1/3 In today's functional programming class we covered file IO in Haskell.
I repeatedly emphasised that for small files, it is much easier to read and write whole files using a single function rather than opening the file, using the file handle, and then closing the file.
When composing several list-processing functions, GHC employs an optimisation called foldr-build fusion. Fusion combines functions in such a way that any intermediate lists can often be eliminated completely. In this episode, we will look at how this optimisation works, and at how it is implemented in GHC: not as built-in...
Hi! Ever wanted to check your cabal projects against the haskell security-advisories database?
Now it has become possible; I have implemented the first prototype of an equivalent to npm or cargo audit, cabal-audit and it now it is in a usable state: https://github.com/haskell/security-advisories/pull/148
there is two ways to run it:
install from source with cabal
(more convenient) nix run github:mangoiv/security-advisories/mangoiv/hsec-cabal#hsec-cabal
soon (next cabal release) this will also work as a plugin, i.e. cabal audit will use the cabal-audit binary in your PATH thanks to @yvan who made that possible.
On Wednesday, 2024-03-20, at 1930 UTC (note that this will be one hour later than usual for people from the US because they're already in DST), Edsko and I will live-stream an all-new episode of the #Haskell Unfolder! This time we're going to talk about foldr-build fusion (which is a special instance of shortcut fusion), an optimisation technique employed by GHC to optimise pipelines of list-processing functions. It is implemented via rewrite rules, so we will also take a look at those. Hope to see you all there!
In this episode, András Kovács is being interviewed by Andres Löh and Matthias Pall Gissurarson. We learn how to go from economics to functional programming, how GHC's runtime system is superior to Rust's, the importance of looking at GHC's Core for spotting stray closures, and why staging might be the answer to all your...
Lots of goodness in this release including a few great steps on the road to Dependent Haskell, the long-awaited introduction of exception backtraces, and Javascript FFI support in the Wasm backend.
Sadly, no Windows binaries in this alpha but we expect to have this sorted for alpha 2.
Non-deterministic behaviour in a specification can be a headache for testing. This updated post explores the non-determinism in the JSONPath RFC 9535, describes how the Compliance Test Suite is being upgraded to deal with non-determinism, and shows how non-deterministic tests can be generated automatically. There's also an "explosive" challenge for Haskell programmers.
Found a couple of trivial optimisations of my Haskell code which sped it up by a factor of over 20,000 (for the "explosive" example mentioned in the above post). That's sufficient for now. 😉
When you use nixpkgs do you neglect the regular cabal setup (like cabal freeze)? Do you not pay much attention to people who aren't using nixpkgs for your project? Or do you try to make it work well without nixpkgs too?
@someodd I do nearly all my Haskell development on NixOS using "normal" cabal builds, using Nix only to provide the compiler version I want and any system / non-Haskell dependencies I might need. That way, there's usually no change in configuration needed to run on non-Nix systems.
I personally think the habit of some Haskell projects to essentially "require" Nix in order to use / work on them is a mistake. This may be an adequate approach for a company working on an internal project, but for an open-source project, it seems like it introduces a completely unnecessary barrier.
There are plenty of descriptions of Haskell's do notation as syntactic sugar for stringing together sequences of operators such as >>=.
There are also "laws" that define the semantics of the do notation.
But I haven't found any decent description of how to use do notation as if it was a first class language construct. That would be especially useful for beginners.
@underlap I am not sure you can get very far with that approach? The semantics of do notation is defined in terms of return / pure and (>>=). So in order to understand what a do block means for a concrete monad, you have to look up the definition of the Monad and superclass instances, and be able to relate that to what the do-block says. So you basically have to be able to do the desugaring in your head.
Treating do-notation as first-class could still be useful if you limit yourself to one fixed type, say IO where the definitions are built-in anyway. But while I agree in principle that introducing IO before talking about monads (at all or in general) is the correct order, even for IO I am not sure that introducing do without talking about its desugaring helps much.
"""
Let m be a monad, and a be a type. The do keyword allows you to define a value of type m a in an imperative style: it starts a context where you can write code as a sequence of statements.
In this imperative mini-language, you can bind names to constants (no variables allowed!) in two ways:
If the value you are binding can be deduced from constants already in scope, just use the let keyword.
If the value you are binding is the result of a monadic action, use <- to perform the action and get the resulting value. If the statement is of type m b, the type associated with the name is now b.
Any name bound in this way can be used in the statements that follow it.
You can also perform a monadic action without assigning its result to anything (just write the monadic action as a separate statement).
Finally, the last statement must be the result of your monadic action, i.e. a value of type m a. Just write the action as your last statement.
"""
I feel like it's a pretty simple thing to write, and that most Haskell texts/courses feature that explanation, so I probably misunderstood your request 😅
@someodd What do you mean by "access"? GHC versions and base versions are tightly connected. GHC 9.0.2 is tied to base 4.15.1.0 (source). There is no way (yet) to change the base version used by GHC.
@jaror sorry I should've figured that when you pin Haskell version for Haskell packages in the haskell-flake basepackages line or whatever that it can access other/older GHC versions (I guess maybe that's what was going on?)
Considering trying a bit of #haskell today to take my mind off of this C project that’s doing my head in. Any recommended reading for a total beginner?
