Tritlo
December 22, 2024, 6:51pm
1
Tom Ellis works at Groq, using Haskell to compile AI models to
specialized hardware. In this episode, we talk about stability of both
GHC and Haskell libraries, effects, and strictness, and the premise of
functional programming: make invalid states...
Tom Ellis works at Groq, using Haskell to compile AI models to specialized hardware. In this episode, we talk about stability of both GHC and Haskell libraries, effects, and strictness, and the premise of functional programming: make invalid states and invalid laziness unrepresentable!
11 Likes
Promoting Non-Strict Programming , Olaf Chitil (2006)
[…] I suspect that space leaks often occur because functions are not non-strict enough. When strict and non-strict functions are mixed, intermediate data structures have to be constructed completely and then they use significant amounts of space. Similarly a single strict function in a sequential composition of functions can destroy the desired online behaviour of a program.
So the programmer has to identify functions that are too strict, that consume large parts of their arguments to produce small parts of their results. Such a function should be redefined less strictly. Here I present a tool, a Haskell library, that semi-automatically identifies such problematic functions amongst a large number and that suggest how the function could be less strict. The aim is to provide a tool that supports programming for non-strictness and thus modularity.
1 Like
Streaming Compression via Laziness , V. E. McHale (2023)
Lazy data structures offer an elegant interface to streaming compression. However, compression libraries are implemented in C and work by effects (memory writes). Monadic I/O is the blessed way to handle effects in Haskell, but can induce unwanted strictness in the resulting stream. We step through how to recover streaming via lazy lists for the LZ4 compression library, and show off some of the sophisticated facilities for interfacing C and Haskell.
1 Like