Meta

Note: An LLM was not used in writing this article.

Commentary and updates about my blog, its software, features, etc.

I added a “microblog” feature to my blog. It lets me use the form feed character in a post to split it up into a series of sub posts, which have independent pages. It’s a nice way to organise updates to a topic and avoid them necessarily hitting my main RSS feed.

Examples are

• LLMs
• My raspberry pi

Blogs

Note: An LLM was not used in writing this article.

A list of blogs I like. I’ll add to this from time to time.

Proper blogs

Small, quirky, intimate. Proper blogs.

• http://static.v25media.com/edw519_mod.html
• https://lr0.org/blog/
• https://ratfactor.com/
• https://caolan.uk/

Big blogs

Big, well known, somewhat performative. Post-blogging blogs.

• https://danluu.com/
• https://prog21.dadgum.com/

System Colic

Note: An LLM was not used in writing this article.

Colic is a thing that some newborn babies go through. Your newborn baby cries for hours on end, every day, for weeks. And they’re by all measures healthy. Experts don’t know what causes it and they don’t have any remedies for it. As a parent, you and your partner pretty much lose your marbles and start questioning all your life choices that lead up to this moment. You will try all the remedies; massages, positions, “anti-colic drops”, whatever you can. The NHS page on colic suggests you ask for support from friends, family and their helpline.

That’s an extreme case of the broader experience of having a baby, which is often just trying to figure out what’s wrong with them, with very little to go on, because they can’t talk to you, and actually they scream at you, making it harder to discuss nuanced hypotheses with your partner.

Complex software systems aren’t babies. But they can be a bit like that. They’re going wrong, because they’re slow, or they’ve got bugs, or something, and there isn’t one obvious cause. The system is alerting but you’ve got nowhere to start from. You try out remedies that maybe have an affect and maybe don’t. Emery Berger did a great talk called Performance Matters at Strange Loop, showing how, especially in modern systems, everything from the hardware (think L* caches, branch prediction), the OS (swap, virtual memory, syscalls, memory layout), runtime (allocators, GC, etc), and your application code, and then in cloud times, distributed systems and all their failure modes, are all independent layers with their own affordances and tolerances that trigger at opposing intervals. You think you’ve got something performing reliably and then some threshold of the layer below is passed and suddenly performance goes up or down, and you aren’t wise as to why.

I’m calling this system colic as a negative term for an undesirable state of affairs. We know we don’t have to accept the illegibility of a system, and can put work into exposing visibility into them, or choose better components that do better in this regard.

Home fibre

Note: An LLM was not used in writing this article.

When a Cat6 cable does the job, but I want fibre optic anyway

Table of Contents

• Why
• Things I learned
• Components
  • The fibre optic patch cable
  • Side B
  • Side A
  • Computer side
• The final result
  • Whole setup
  • The FS media converter in action
  • TP-link media converter in action
• Pictures of the parts
  • SC-APC test patch cable
  • FS media converter
  • FS power lead
  • TP-Link media converter
  • TP-Link power lead
  • LC UPC to AC APC patch cable
  • SC-AC connectors
  • SC-UPC to SC-APC
  • Gigabit ethernet to USB-C

Why

I’ve got an ethernet port by my TV, and my desk is on the other side of the room. WiFi is fine, but I want to be cabled to take full advantage of my gigabit internet.

My home is a newbuild, so I don’t feel like fishing through stud walls. I discovered that these days fibre optic is well within hobby price range, and you can get a magical InvisiLight EZ-Bend fibre cable that can bend around sharp corners and lose no signal. They look invisible to a casual glance when ran on the edges of walls. I took it as an opportunity to have fun with simple hardware!

As of June 2nd 2026, I’m still waiting for the EZ-Bend cable to arrive, but I’ve done a test with the rest of the setup.

Things I learned

You need to understand this if you’re buying.

1. Fibre optic has modes (which comes from optical modes):
   • Single-mode means the glass tube through which light is emitted is very tiny. Something like 8-10μm. It requires a laser, it’s more expensive, and the alignment has to be very precise. Its distances before attenuation are measured in kilometers.
   • Multi-mode has a really big core diameter. You can use LED or other emitters, the light attenuates quicker (under half a km), but it’s cheaper. The wavelengths used are also different.
2. A patch cable may contain one or two or more fibres.
   • Single fibre, you’ll need two of these cables then if you’re emitting only in one direction.
   • Duplex cable, contains two fibres, one for TX, one for RX.
   • And media converters accept either TX/RX (transmit/receive) ports, where you might have one TX fibre and one RX fibre.
3. Scenarios: Duplex vs half-duplex vs simplex:
   • Full duplex: two fibres, one TX, one RX.
   • Half duplex: you have one fibre, but take turns TX’ing and RX’ing.
   • Simplex: one fibre, but sending concurrently via BiDi (separate TX/RX wavelengths via WDM).
4. Fibre cables have a variety of connectors:
   • SC (standard connector), it’s bigger.
     • SC UPC - domed glass.
     • SC APC - angled glass.
   • LC APC/UPC - it’s smaller, and has a different clasp like an RJ45 connector.
   • None of these are compatible, but you can buy all the combinations of patch cables that have X on one end and Y on the other end, which is what I did.
   • See the pictures!

My setup is: a single mode, single fibre, simplex, bidirectional (WDM). The main fibre is SC APC, but my media converters are on LC UPC and SC UPC. One media converter transmits data at 1310 nm wavelength and receives data at 1550 nm wavelength, and the other media converter has the transmit/receive flipped.

Components

The setup comprises the following components.

The fibre optic patch cable

I ordered the real InvisiLight EZ-Bend and a 1m yellow test cable.

• The real thing: InvisiLight® EZ-Bend™ Indoor Jumpers, 20m, SC APC, white, Single Mode
  • This 3mm cable is capable of 2.5mm bend radius, is easy to run along a wall and around corners.
  • Still waiting for delivery, estimated 4 weeks.
• The test cable: 1m (3ft) Fiber Patch Cable, 1 Fiber, SC APC Simplex to SC APC Simplex, Single Mode (OS2), Riser (OFNR), 2.0mm, Tight-Buffered, Yellow
  • For testing, equivalent to the EZ-Bend one.
  • Arrived, delivered promptly by fs.com.

Side B

This was my first choice for simplicity; grab an off the shelf TP Link that has fibre in and eth in and you’re good.

• TP-Link Gigabit WDM Media Converter, Auto-negotiation, TL-FC311B-20
  • transmits data at 1310 nm wavelength and receives data at 1550 nm wavelength
  • Arrived, from Amazon.
• 1x: 1m (3ft) Fiber Patch Cable, 1 Fiber, SC UPC Simplex to SC APC Simplex, Single Mode (OS2), Riser (OFNR), 2.0mm, Tight-Buffered, Yellow
  • Arrived, delivered promptly by fs.com.
• 1x: SC/APC to SC/APC Simplex Single Mode Fiber Keystone Jack
  • Arrived, delivered promptly by fs.com.

I attempted to order the corresponding TL-FC311A-20 (note the ‘A’) unit, but:

• Ordered from Amazon. Delayed. Amazon. I cancelled.
• Ordered from Scan. Delayed. I cancelled.
• Ordered from Converge Technology Solutions. They cancelled due to no stock despite claiming a few in stock.

These suppliers are a bit fast and loose with their stock inventory.

Side A

After my experience trying to source the ‘A’ part for the TP Link media converter, I decided that since I had such a good experience with fs.com, that I’d just ordered everything from there.

I got an SFP media converter and module.

• 1000BASE-BX-D SFP BiDi 1550nm-TX/1310nm-RX 20km Simplex LC/UPC SMF Transceiver Module for FS Switches

• Mini Unmanaged 1x 10/100/1000Base-T RJ45 to 1x 1000Base-X SFP Gigabit Ethernet Media Converter, British Plug Standard

• 1m (3ft) Fiber Patch Cable, 1 Fiber, LC UPC Simplex to SC APC Simplex, Single Mode (OS2), Riser (OFNR), 2.0mm, Tight-Buffered, Yellow

• 1x: SC/APC to SC/APC Simplex Single Mode Fiber Keystone Jack

  • Arrived, delivered promptly by fs.com.

Computer side

MacBooks don’t have ethernet (so brave), so I needed an adapter for it.

• Belkin USB-C to 2.5Gb Ethernet Adapter - White
  • Bought from Apple.

The final result

If you just want to see the final test result, here it is. For pictures of all the parts, see further down.

Whole setup

The FS media converter in action

TP-link media converter in action

Pictures of the parts

SC-APC test patch cable

FS media converter

FS power lead

TP-Link media converter

TP-Link power lead

LC UPC to AC APC patch cable

SC-AC connectors

SC-UPC to SC-APC

Both SC, but the polish differs.

Gigabit ethernet to USB-C

Some updates about Hell in 2026

Note: An LLM was not used in writing this article.

I’ve added a few neat bits and bobs to Hell since I last blogged about it.

On the API side, things have slowed down when compared with the prior year,¹ but other improvements were still made.

Sum types

I’ve added support for using case statements on built-in primitive types, like Maybe, as in:

case i of
  Maybe.Just x -> IO.print x
  Maybe.Nothing -> Text.putStrLn "nope"

Previously, one only had Maybe.maybe, which is fine, but is often not the direct way to write something. So having case syntax for that is handy. You just have to qualify the constructor names, and then it knows that it’s a built-in.

Type class entailment

I’ve added limited support for resolving instances which feature entailment on the instance, such as Eq a => Eq [a], and this works in a nested way. So one can compare values of any depth provided they have an Eq instance, as seen in the following examples:

Text.putStrLn $ Show.show $ Eq.eq (1,1) (1,1)
Text.putStrLn $ Show.show $ Eq.eq [Maybe.Just 1] [Maybe.Just 2]
Text.putStrLn $ Show.show $ Eq.eq [Either.Left 1] [Either.Right "abc"]
IO.print [Maybe.Just 1, Maybe.Nothing]
IO.print $ Maybe.Just [1] <> Maybe.Nothing
IO.print $ [Either.Left (Maybe.Just 1), Either.Right (Maybe.Just "abc"), Either.Left Maybe.Nothing]
IO.print [Maybe.Just (1, 2), Maybe.Nothing]

The complete list of instances is now on the API documentation page.

The implementation is quite nice, where instances are listed like this:

instances :: Instances
instances =
  Instances $
    Map.fromList
      [ entail1 @Show @[],
        entail1 @Show @Set,
        entail1 @Show @Tree,
        entail1 @Show @Maybe,
        entail1 @Show @Vector,
        entail2 @Show @Either,
        entail2 @Show @(,),
        ...
        instance1 @Functor @Either,
        instance1 @Functor @(,), -- Functor (a,)
        instance0 @Applicative @IO,
        instance0 @Applicative @Maybe,
        instance0 @Applicative @[],
        instance0 @Applicative @Tree,
        instance0 @Applicative @Options.Parser,
        instance1 @Applicative @Either,
        instance0 @Alternative @Options.Parser,
        instance0 @Alternative @Maybe,
        entail1 @Monoid @Maybe,
        instance0 @Monoid @Text,
        instance1 @Monoid @Vector,
        instance2 @Monoid @Options.Mod,
        instance1 @Monoid @[],
        entail1 @Semigroup @Maybe,
        instance2 @Semigroup @Either,
        instance2 @Semigroup @Options.Mod,
        instance0 @Semigroup @Text,
        ...

With

instance0 ::
  forall cls a.
  (cls a, Typeable cls, Typeable a) =>
  ((SomeTypeRep, SomeTypeRep), Dynamic)
instance0 =
  ( (SomeTypeRep $ typeRep @cls, SomeTypeRep $ typeRep @a),
    toDyn $ Dict @(cls a)
  )

instance1 ::
  forall {k0} {k1} (c :: k1 -> Constraint) (t :: k0 -> k1).
  ((forall a. c (t a)), Typeable c, Typeable t, Typeable k0, Typeable k1) =>
  ((SomeTypeRep, SomeTypeRep), Dynamic)
instance1 =
  ( (SomeTypeRep $ typeRep @c, SomeTypeRep $ typeRep @t),
    toDyn $ D1 @c @t Dict
  )

entail1 ::
  forall {k1} (c :: k1 -> Constraint) (t :: k1 -> k1).
  ((forall a. c a => c (t a)), Typeable c, Typeable t,  Typeable k1) =>
  ((SomeTypeRep, SomeTypeRep), Dynamic)
entail1 =
  ( (SomeTypeRep $ typeRep @c, SomeTypeRep $ typeRep @t),
    toDyn $ ED1 @c @t (Sub Dict)
  )

-- Entailment, c a => c (t a), E.g. Eq a :- Eq [a]
newtype ED1 c t = ED1 (forall e. c e :- c (t e))

And then resolution looks like this:

resolve1 ::
  forall {k0} {k1} (t :: k0 -> k1) (c :: k1 -> Constraint) (a :: k0).
  (Typeable k0, Typeable k1) =>
  TypeRep (c (t a)) ->
  TypeRep c ->
  TypeRep t ->
  Instances ->
  Maybe (Dict (c (t a)))
resolve1 cta c t (Instances m) = do
  Dynamic rep dict <- Map.lookup (SomeTypeRep c, SomeTypeRep t) m
  (do Type.HRefl <- Type.eqTypeRep rep $ Type.App (Type.App (typeRep @D1) c) t
      let D1 d = dict
      pure d) <|>
    -- When we see e.g. C (T A), where T A and A have the same kind,
    -- we can lookup C A, for the entailment C A :- C (T A).
    (do case cta of
          Type.App _c a@(Type.App f a') -> do
            Type.HRefl <- Type.eqTypeRep (typeRepKind a') (typeRepKind a)
            Type.HRefl <- Type.eqTypeRep rep $ Type.App (Type.App (typeRep @ED1) c) f
            let ED1 entailment = dict
            dictA <- lookupDict a' c
            pure $ mapDict entailment dictA
          _ -> Nothing)

For future reference, you can see the latest implementation in Hell.hs in the repo.

What remains is adding support for e.g. Ord a => Eq (Set a), but I don’t expect it’ll be too hard.

APIs added

I added optparse-applicative, so the following code works exactly as it would in Haskell:

-- Includes example of Semigroup.
data Opts = Opts {
  quiet :: Bool,
  filePath :: Maybe Text
 }
options =
  (\quiet path -> Main.Opts { quiet = quiet, filePath = path })
       <$> Options.switch (Flag.long "quiet" <> Flag.help "Be quiet?")
       <*> (Alternative.optional $ Options.strOption (Option.long "path" <> Option.help "The filepath to export"))
main = do
  opts <- Options.execParser (Options.info (Main.options <**> Options.helper) Options.fullDesc)
  Text.putStrLn $ Maybe.maybe "No file path" Function.id (Record.get @"filePath" opts)
  Text.putStrLn $ Show.show @Bool $ Record.get @"quiet" opts

It’s got date/time APIs:

main = do
  now <- UTCTime.getCurrentTime
  Text.putStrLn "Current time:"
  IO.print now

  Text.putStrLn "ISO8601:"
  Text.putStrLn $ UTCTime.iso8601Show now

  Text.putStrLn "Parsed:"
  Maybe.maybe (Error.error "Impossible!") IO.print $ UTCTime.iso8601ParseM "2025-05-30T11:18:26.195147084Z"

  Text.putStrLn "Increased:"
  IO.print $ UTCTime.addUTCTime (Double.mult 60.0 60.0) now

  Text.putStrLn "Parts:"
  IO.print $ TimeOfDay.timeToTimeOfDay $ UTCTime.utctDayTime now
  IO.print $ UTCTime.utctDay now

  day1 :: Day <-
    Maybe.maybe (Error.error "Invalid") IO.pure $ Day.fromGregorianValid (Int.toInteger 2025) 08 09
  day2 <- Maybe.maybe (Error.error "Invalid") IO.pure $ Day.iso8601ParseM "2025-08-09"
  IO.print $ Eq.eq day1 day2 -- True
  Text.putStrLn $ Day.iso8601Show day1 -- 2025-08-09

I think Haskell has a really nice date/time API – compared to most other languages, anyway.

I’ve been planning for my next thing to add to be Wai/Warp, so that it’s easy to write HTTP servers which comes up surprisingly often. The Wai/Warp API is very stable, so I can feel happy including it as a primitive.

Syntactic constructs added

I added the ability to declare type sigs on top-levels like this:

data Foo = Foo { bar, mu :: Int }
main :: IO () =
  Main.foo

Also added applicative operators, and NamedFieldPuns. I think that’s about it.

Remaining work

I need to implement a faster unification—I have a work in progress unification-fd branch, which I may or may not proceed with, as the API doesn’t bring me much joy. Some speed up is needed, though, as my naive algorithm is slow.

It still needs to be ported to the GHC parser, so we can get all the extra syntactic goodies like foo.bar, multi-line strings, etc. But that’s boring, labrious work, so I’ll get to it when I really, really want to.

No LLMs have been used on any part of this project so far. It’s more of an art project at this point. My artisanal open source project.

Proposal to extend JSON with sum types (variants)

Note: An LLM was not used in writing this article.

A small syntactical addition that I propose to add to JSON is variants. It looks like this:

#"succeeded"
#"failed"("Problem flerbing the fobnicator.")
#"loading"({ "remaining": 3, "completed": 7 })
[ #"foo", #"bar"(1), #"boz"("Ok!") ]

I trust that the syntax is intuitive and follows norms that a hashtag is a way of labelling something.

The grammar is simply:

root ::= string | number | ... | object | variant
variant ::= "#" string variant-arg?
variant-arg ::= "(" root ")"

It would be more convenient without the quotes, but JSON is primarily a transfer format and secondarily a human readable format. The latter is what JSON5 is for. Additionally, it’s faster to crunch through JSON’s explicitly delimited string literals than more elaborate rules.

I think this syntax gives a good balance of intention and practicality. Sum types exist nicely in XML and static languages (Rust, Haskell), and this is always covered by convention in JSON. It seems about the right time to make this concept first-class.

Laws

Note: An LLM was not used in writing this article.

Laws that apply to our industry (and others) are interesting to me, and I’m writing up here the ones that often come to mind. I usually forget the name, so writing them up might be helpful for remembering in future.

Brooks’s law

Adding manpower to a late software project makes it later.

Ramp-up time, increased communication overhead are the causes.

Parkinson’s Law

C. Northcote Parkinson’s law: Work expands so as to fill the time available for its completion. Similarly, in computing, data expands to fill the space available for storage, or tasks expected of a computer expand to fill the resources.

Related is William Stanley Jevons’s paradox (Jevons paradox): Making resource use more efficient leads to more using more resources, negating the perceived benefits. Computers get faster and get more memory, so our apps are written in high-level languages that use more resources to do the same thing, and then the experience is slow again.

Related: Andy and Bill’s law (of Intel and Microsoft): “what Andy giveth, Bill taketh away.”

Law of Triviality

C. Northcote Parkinson’s law of trivality, from which bikeshedding derives, is that within an organization or committee, people will more passionately argue about trivial matters than difficult, complex matters, naturally because that requires less thinking.

Conway’s Law

Melvin Conway’s law is:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Law of Leaky Abstractions

Joel Spolsky’s law states that every nontrivial abstraction leaks the details that it’s trying to protect you from. Worse still, if you’ve only learned the abstraction and not the level below it, you’re ill-equipped to deal with the leak anyway.

Hutber’s law

Patrick Hutber: Improvement means deterioration. If a company tells you it is improving a service it provides, it almost always means it will do less for you, charge you more, or both.

Argumentum ad colossum

Note: An LLM was not used in writing this article.

I’m coining a new phrase to use for discussion purposes: argumentum ad colossum.

It’s very difficult to replicate what worked for one company at another company, because culture is hard to transfer. This has been argued in business literature, e.g. Google’s OKRs and silly interviews, Amazon’s “two-pizza teams”, Netflix’s culture of radical candor, Apple’s BDFL-style leadership, Toyota’s lean manufacturing systems, Basecamp’s Shape Up. It’s hard to acknowledge that these can run counter to another company’s DNA.

In tech circles, there’s commentary about “cargo cult engineering” (scrum, SRE, fix-bugs-first), or copying methodologies. Similarly, adoption of specific architectures, technologies and design choices has been criticised. Kafka event driven architecture, microservices or monorepos, cloud deploy vs roll-your-own, Kubernetes, chaos monkey, using TLA+, adopting generative AI, and so on. You can’t transplant a technological design isolated from other factors, inconveniently. The full thinking needs to be done.

It reminds me somewhat of The Logical Fallacy of Generalization from Fictional Evidence, where people are essentially arguing from stories, not experience or science.

Nevertheless I hear people slipping into this line of thinking, of the form “well, if we were at X giant corporation we would just…”, including myself, and feel like I need a catchy tongue-in-cheek name, so here it is: argumentum ad colossum.

Applicative-wired monad pattern

Note: An LLM was not used in writing this article.

In Haskell API design, you sometimes want to model a computation that looks like a monad, i.e. some things depend on other things, and make use of do-notation, but you want to be able to statically inspect the resulting structure, too.

The ApplicativeDo notation attempts to bridge this gap by a language extension and some conventions. It lets you write applicatives with do-notation, but dependencies between actions are explicitly forbidden. That limits its utility for this purpose.

Here’s a separate pattern I’ve put to use in a build system library, but has been used in popular database libraries and FRP libraries, before I ever did.

You have two types like,

data Action a
data Value a

The Action is some instance of Monad, and could be a free monad. The Value is some instance of Applicative, and can be a free applicative.

The trick is that all functions exposed by the API only return the type Action (Value a), and sometimes accept Value a as arguments. This means you wire up a graph, with Action containing nodes and Value serving the edges. You combine multiple output values into a single argument value via its Applicative instance. Then it’s easy to graph it out or batch it as needed. Works for SQL DBs (e.g. Rel8), build systems or FRP (e.g. Reflex).

This does mean you can’t simply run mapM against a Value [a], and this often requires a special operator for the action in the domain in question.

I’m not sure that there’s already name for it, but it’s definitely a pattern. You see it in quite a few places. Hence pointing it out.

Full code example below. I’ve added an extra f parameter on the Action type to emphasize that by exposing an API like this, you can inspect the monad’s structure, but that you can also keep your monad well-formed (i.e. interpret the Applicative as Identity). But it’s not necessary to add a parameter to everything, and in practice all examples I’ve seen do not have a parameter, and are specialized on a particular type. Sometimes the type isn’t actually an Applicative, but is similar in spirit (e.g. DB libraries often have Expr a returned by Query a monad).

Thanks to Liam Goodacre for his suggestion to eliminate the earlier inlined Coyoneda in my example. Thanks to Jack Kelly for his suggestion to use a Coyoneda rather than free-Applicative, as this example doesn’t need it. Separately, Emeka Nkurumeh has noted that, if you squint, this is an implementation of relative monads, which I’ll likely write another post about because it’s very interesting!

{-# language KindSignatures, BlockArguments, GADTs, LambdaCase, GeneralizedNewtypeDeriving #-}
import Data.Functor.Coyoneda
import Data.Kind
import Data.Functor.Const
import Control.Monad.Free
import qualified Data.ByteString as S
import qualified Data.ByteString.Char8 as S8
import Data.Functor.Identity
import Data.ByteString (ByteString)
import qualified Data.Map as Map
import Data.Map (Map)
import qualified Data.Set as Set
import Data.Set (Set)
import Control.Monad.Trans.State.Strict

--------------------------------------------------------------------------------
-- The applicative-wired monad pattern

data Spec f m a where
  Spec :: String -> f (m a) -> Spec f m (f a)

newtype Action f m a = Action { runAction :: Free (Coyoneda (Spec f m)) a }
  deriving (Functor, Applicative, Monad)

act :: String -> f (m a) -> Action f m (f a)
act l f = Action $ liftF $ liftCoyoneda $ Spec l f

--------------------------------------------------------------------------------
-- An example

example :: Applicative f => Action f IO (f (ByteString, ByteString))
example = do
  file1 <- act "read_file_1" (pure $ S.readFile "file1.txt")
  file2 <- act "read_file_2" (S.readFile .  unwords . words . S8.unpack <$> file1)
  pure $ (,) <$> file1 <*> file2

--------------------------------------------------------------------------------
-- IO interpretation

runIO :: Action Identity IO a -> IO a
runIO = foldFree (lowerCoyoneda . hoistCoyoneda io) . runAction where
  io :: Spec Identity IO x -> IO x
  io = \case
    Spec name act' -> do
      putStrLn $ "Running " ++ name
      out <- runIdentity act'
      pure $ Identity out

--------------------------------------------------------------------------------
-- Graphable interpretation

newtype Value (a :: Type) = Value { runValue :: Const (Set String) a }
  deriving (Functor, Applicative)
instance Show (Value a) where
  show = show . keys

runGraph :: Applicative m => Action Value m (Value a) -> (Value a, Map String (Set String))
runGraph x = flip runState mempty $ graph $ do
  v <- x
  act "root" (pure <$> v)

graph :: Action Value m a -> State (Map String (Set String)) a
graph = foldFree (lowerCoyoneda . hoistCoyoneda go) . runAction where
  go :: Spec Value m a -> State (Map String (Set String)) a
  go = \case
   Spec string i -> do
    modify (Map.insert string (keys i))
    pure $ Value $ Const (Set.singleton string)

keys ::  Value a -> Set String
keys = getConst . runValue

Example:

-- Example:

-- Run as raw IO:

-- > runIO example
-- Running read_file_1
-- Running read_file_2
-- Identity ("hello.txt\n","you found me\n")

-- Dependency graph:

-- > runGraph example
-- (fromList ["root"],fromList [("read_file_1",fromList []),("read_file_2",fromList ["read_file_1"]),("root",fromList ["read_file_1","read_file_2"])])

My blog now runs on a Raspberry Pi at home

Note: An LLM was not used in writing this article.

A mini microblog on Raspberry Pi at home.

2025-05-09

I discovered that my new house had OFNL internet, which is one of a handful competing fibre providers in England (others: BT OpenReach, VirginMedia, Hyperoptic, etc). Some of the infra providers are also the sole ISP, like VirginMedia and Hyperoptic, whereas BT OpenReach and OFNL just provide the infra and then companies can offer consumer ISP services on top of it.

I picked one (Merula) who, like a few others, provide a gigabit connection, and for about £3 per month, a static IPv4 address.

Some ISPs in the world–even in rich countries–put people behind a CGNAT, as a way to get more mileage out of the few IPv4 addresses they have. This means that you can’t listen on a port and have someone directly connect to you, because the NAT wouldn’t know who to pick. A very sad state of affairs. I’ve also heard about a German ISP that provides IPv6-only and then handles all IPv4 connections via a proxy!

In that context, it’s a pretty fortunate situation to be able to get a static IP at my home address. As a programmer it’s more joyful to have this.

I grabbed a Raspberry Pi 5 (highly overpowered for a blog), connected it to my router via gigabit Ethernet, and got it running with a simple SD card for the root file-system. All logs (journald) are moved to tmpfs (‘volatile’ storage mode). The blog itself is sync’d via a webhook from GitHub, and is stored in tmpfs, too. Like this, it should run for a couple years without the SD card wearing out.

The server is Caddy and the webhook service is webhook, both come as systemd services, so the effort was very minimal.

There’s no particular technical advantage of you reading this page from my home, over the Digital Ocean server I’ve had for years, which only cost me about $10/mo. But it was a fun little project!

2026-05-09

It now lives in a little stainless steel T-190 Japanese box.

LLMs

Note: An LLM was not used in writing this article.

This page serves as my place to journal what are hopefully balanced thoughts on the current AI summer, driven by LLMs.

2026-07-03

I enjoyed these quotes by Jaron Lanier on the topic of AI:

“A lot of modern enlightenment thinkers and technical people feel that there is something old-fashioned about believing that people are special – for instance that consciousness is a thing. They tend to think there is an equivalence between what a computer could be and what a human brain could be.” Lanier has no truck with this. “We have to say consciousness is a real thing and there is a mystical interiority to people that’s different from other stuff because if we don’t say people are special, how can we make a society or make technologies that serve people?”

In a refreshing twist, his position on LLMs is nuanced. For example, he seems quite positive about the randomness:

For Lanier, the classic example of restricted choice is Wikipedia, which has effectively become the world’s encyclopedia. “Wikipedia is run by super-nice people who are my friends. But the thing is it’s like one encyclopedia. Some of us might remember when on paper there was both an Encyclopedia Britannica and Encyclopedia Americana and they provided different perspectives. The notion of having the perfect encyclopedia is just weird.”

So could the new chatbots challenge this? “Right. That’s my point. If you go to a chatbot and say: ‘Please can you summarise the state of the London tube?’ you’ll get different answers each time. And then you have to choose.” This programmed-in randomness, he says, is progress. “All of a sudden this idea of trying to make the computer seem humanlike has gone far enough in this iteration that we might have naturally outgrown this illusion of the monolithic truth of the internet or AI. It means there is a bit more choice and discernment and humanity back with the person who’s interacting with the thing.”

This is an interesting perspective. Though I’m not sure how well it holds up to scrutiny due to bias easily put into models via reinforcement learning, which is discussed in AI models’ values are very different from most people’s. I’m also not sure how this squares with his criticism of Wikipedia the bulk of which do apply to LLM models (mainstream voice, sterile style, abuse by states to manipulate).

2026-06-24

Two articles on the same topic about or encompassing workslop, which I thought were good and helpful:

• “Adversarial communication”, great article.
• If you are requesting human attention, demonstrate human effort.

2026-06-05

I’m connecting a few areas of thought together in the context of LLMs.

• The Mythical Man Month
• Worse is Better
• Moloch

Firstly, some Fred Brooks comments that seem relevant to whether LLMs may fundamentally change sofware development:

I believe the hard part of building software to be the specification, design and testing of this conceptual construct, not the labour of representing it and testing the fidelity of the representation. […] If this is true, building software will always be hard. There is inherently no silver bullet.

More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.

Separately, commentary by Richard P. Gabriel indicating that this may not matter for industry, and so LLM adoption may be inevitable:

The essay argues simple, hacked-together software that makes it to market first will often outcompete better and more elegant designs.

Gabriel offers the examples of the adoption of C over Lisp, Unix over Lisp machines and VMS, and x86 over reduced instruction set computers as examples of technically worse solutions defeating more elegant ones by arriving to market first.

Finally, a deeper meditation on why this happens generally by Nick Land, which touches on failed collective action, race to the bottom, etc.

Moloch is exactly what the history books say he is. […]

He always and everywhere offers the same deal: throw what you love most into the flames, and I can grant you power.

As long as the offer’s open, it will be irresistible.

2026-05-25

A recently recurring thought is that many people criticise LLMs/“AI” on the wrong terms. I may be accidentally coming back to McLuhan, arguing that people should be looking at the medium and not the message, but I see arguments like “LLMs aren’t good at X”, or “good but not human level good”, etc. at e.g. writing code or reasoning. There’s usually an anecdote involved.

The questions should, in my view, assume that LLMs will attain fully realised potential, after presumably a protracted boom/bust iteration, and then ask whether and how that would affect how we enjoy life and conduct business.

2026-03-12

The Medium is the Message keeps coming to mind again and again, as people seem frequently surprised by the side-effects of the adoption of LLMs. The content (articles, code, images) produced by LLMs is not the higher order bit, but how they change the people and institutions that use them.

No other changes in viewpoints to report this time.

2026-02-07

I shared a thought on a big dev call at work, when talking about agentic “skill” based workflows, that one problem is that you lose Flow, which is often one of the most enjoyable ways to work as a software dev (most of the rest is frankly frustration and toil, but valuable). Today I saw this post by Gabriella Gonzalez about the same topic, with examples of interfaces that try to do a better job of that. I’m not as gung ho about LLMs as Gabriella is, but I’m enjoying these simple articles that discuss a particular technical point.

This way of thinking has been on my mind for some time, as generally I am always working to reduce feedback loops in my work, never increase them. (This doesn’t follow from using Emacs, but Emacs can help with that: look at magit.) It’s why slow CI ruins my day, and why most cloud ops like Terraform are painful (e.g. Amazon resources aren’t content addressable, so checking for changes to apply is always O(n)–brutal!).

Separately, but somewhat related; arguably, there’s a certain psychogeography to “walking around” a codebase when doing an update or refactor, taking the scenic route reminds you of the landscape and dark alley ways, it activates and gently tickles parts of your brain in a way that I imagine is valuable for the larger work, which is an experience removed by being teleported from A-Z.

2026-01-30

A paper discusses a similar topic that I’ve addressed in this microblog, which is the negative relationship between skill and using GenAI.

I haven’t generated anything since the last update. But I hand wrote a little experimental library that uses a free applicative to both declare a GBNF grammar and consume the output back into Haskell. I didn’t add an Alternative instance (yet) to support disjunction in the grammar, but this direction appeals to me. I’ve been dabbling with the same llama3.2 (3b model) via llama.cpp’s server locally on the same MacBook Pro M4 Max. It’s quite easy to get reliable outputs. I intend to dabble more with this in coming weeks.

I’ve been recently thinking that the whole phrasing around interacting with LLMs has become increasingly anthropomorphic, and thought of a clever mental hack to avoid it: instead of “talking to Claude,” say “talking to the computer,” (doesn’t that sound silly!) and instead of “AI generated” or “LLM generated,” simply say “computer generated.” (How dull!) I find it thoroughly cuts through the illusion that we are doing anything more. But YMMV.

2025-12-20

Another positive experience I’ve had with LLMs is finding an opportunity to redo the frontend of a fairly simple web app, which was previously a server-side app at work. It’s an internal tool, so it’s highly suited to this kind of mode of working.

I remain uncomfortable shelling out my cognition for load-bearing code, especially on the backend, and I’m increasingly sure in my determination that one should only genAI things they could do readily themselves for work that they back and own.

Elsewhere, I’m poking at formal methods. If, indeed, the trajectory of software development–in industry–is away from the labor of implementation, there may perhaps be space for verification. The feeling might pass, but it feels possible that LLMs may make formal methods mainstream. That wouldn’t be so bad, as a good subset of programmers like formal thinking. Whether software, subject to market forces and competition, will get any better or worse objectively, I’m skeptical.

2025-12-03

My experience with LLMs since my last update has been both positive and negative.

On the one hand, I’ve seen a quality and comprehension drop in some programmers. “I vibed it” is becoming a familiar explanation for both. I’m increasingly concerned.

On the other hand, I have found a workflow with LLMs that works for me. For those things that I could write myself and practically see in my head, this flow makes me happy:

1. Prompt a tool like Cursor or Claude Code with a paragraph description of what to do and where, with the permission to edit files.
2. Close it and return to Emacs.
3. Browse through the diff in magit.
4. Edit almost everything, rewrite some things, leave others that are good.
5. Continue myself by hand as normal.

This has been quite effective for me as a means to speed up tasks which are doing what I’ve done elsewhere with small differences. I’m using it as glorified autocomplete.

2025-10-24

I’ve had what I’d describe as “hole in one” experience where I generated two Haskell packages, sse-conduit and llm-conduit, from a single Claude prompt, which both compiled and worked the first time when pointing it at llama.cpp’s server. This gave me pause as in the past I would enjoyed sitting down to write these and publishing them. Given that the whole thing took about 10 minutes, I didn’t do either.

I call this a funny name like “hole in one” because it’s not a normal experience. I had a few weeks prior implemented the same thing manually with Emacs Lisp, so I wasn’t entirely robbed of the experience. I believe I’m arriving at a new standpoint which is that one may “vibe” projects, but only those things they could do themselves readily. The exercise of writing is often as valuable as the written thing.

The more things that you vibe that you do not understand, the more your knowledge will stand still and that muscle will not be exercised, and atrophy. By contrast, if you only vibe things that you already understand fully, but do the hard work on everything else, you’ll continue growing, but will also get the accelerative edge of LLM vibing.

2025-09-23

Harvard published this article defining “workslop”, a new term for when someone substitutes hard thinking for LLM generated slop. I had been thinking about this recently, having witnessed it at work, but hadn’t articulated it yet, so I’m glad for the new term.

I accidentally discovered this article while looking up Holly Herndon, I enjoyed the reframing of LLMs from “artificial intelligence” to “collective intelligence”, which more accurately describes what a large language model is, and sounds a bit more positive and inclusive.

I got llama.cpp working from Emacs for both regular queries and GBNF-constrained outputs. I’m happy with the outputs, though I’ve not been using it for a couple weeks. Will come back to it.

Current mood: still interested to dabble more. Currently sceptical that organisations across the board are benefitting from LLMs. I read in the Economist that more small, boutique models, aka SLMs, are becoming preferred over the Big models provided by OpenAI, Anthropic, etc. which makes some sense.

2025-08-19

Since the last update, I’ve experimented with local LLM models on my MacBookPro Max M4, which can run 3b parameter models. I wanted to approach the whole LLM hype as a tool, like grep or awk, and see whether there was a niche for it as a way of making free text tractable, rather than as some kind of sci-fi oracle, as many people seem to treat it. I wrote a module for Emacs that could stream responses from Ollama.

Those models are very unpredictable as an individual observer. I tried out Ollama’s “tool use”, which is when a model will reply with a specific format to call a function when given a prompt of the right schema. That’s also unreliable (to the extent I discount its viability for my own purposes), because the mechnism is the same as normal prompting and generation.

A tool that might be viable is GBNF, which is a BNF grammar format that llama.cpp supports; it is a filter function that sits very close to the generation of tokens, and discards tokens that do not match the GBNF grammar. This is promising because you can at least rely on the output syntax if not the meaning. It also works well on small models, and is expensive on larger models. Ollama are not planning to support it, but llama.cpp does, so I will abandon the former in favor of the latter.

In code generation, I’ve experimented with fully agentic “make a PR to do x”, to a 50% success rate. Code review bots are hit and miss at the moment. Failure meaning, it would have been easier and mentally more nourishing to do a task myself than to deal with the failed interaction.

I’ve found that cloud LLMs are quite good replacements for Google search, to discover direct sources. I’ve in contrast found that exploring ideas like architectures and such to be unhelpful. It has ironically renewed my interest in theory (TLA+, Liquid Haskell), tools that make me think better, rather than delegating my thinking.

I had a month of apathy for working on my open source scripting language, Hell, due to a fairly bleak outlook for niche languages due to LLMs. But that passed and my interest came back.

I’m not an economist, but hopefully no winter or crash is coming.

Overall, present outlook is: tinkering with mild interest, local first, so-so performance for job-related tasks, using as a Google++, avoiding delegating thinking, renewed interest in learning theory.

2025-06-04

Small update: I’d presently describe my outlook as sceptical. I go in cycles, of long troughs of scepticism, with very, very, brief (one-day), widely spread out, spikes of FOMO and belief that AI is an existential situation for software developers (see previous 2025-04-18 thought dump). But those are becoming more infrequent. I think I see which way the trend for me is going.

Having cut out the final vestige of social media (RSS feeds; BazQux) from sheer disinterest, and digital devices in the evening entirely, I am also serene and a little bored by the whole thing. But it still does play on the minds of some friends.

I might change my mind on the next update, we’ll see.

2025-04-18

I’ve been collecting thoughts on LLMs in a peacemeal way. I add to this document from time to time. It’s not an article as such.

• Hype: On forums like HN people have long, familiar, arguments about whether AI is hyped or not. This is consistent with any other hyped thing, like crypto or micro services or whatever.
• Objective value: Tools have gotten very good at generating code, which means that some people’s work, especially those which involve generating throwaway things which are iterated on quickly, has been accelerated, and some tasks which were previously inaccessible to people who didn’t have the patience to wait through poorly documented APIs is now accessible.
• Not learning: By looking at any topic which is not sufficiently exposed in the training data, one can see that, for example, an individual human can learn a given topic and it doesn’t take millions of examples to learn a thing, because we can use reasoning –symbolic reasoning/manipulation– to learn a program language which has just one book, for example. Whereas the LLM doesn’t actually learn the programing language, but essentially is learning how to parrot it as if it’s a human language. This is why all the popular models are kind of crap at Haskell and cannot speak Lojban at all, despite there being a complete and comprehensive book describing Lojban’s grammar, semantics, dictionaries and everything like that.
• If it’s not written, it doesn’t exist: Essentially, if someone hasn’t written about it in detail, and posted it online or in a book, then it’s basically a piece of human insight which is not accessible to an LLM. For example, if nobody ever talked about print debugging online or in books, and then you asked an LLM about different ways to debug a program, I’m quite confident the answer would not mention any concept of printf debugging because that is a completely human experience which is interactive and comes from experience.
• Objective benefit: LLMs essentially turn human language into code which is digestible, analysable, translatable, summarizeable and generable. That means we can apply all of our regular engineering tools like compression and linting and test suites and DSLs. Modulo nondeterminism.
• Objective limitation: As implemented, we know that LLMs are capable within their probabilistic transformers to estimate answers to questions, but, for example, cannot count the individual letters in a word or do basic arithmetic. (At the time of writing; these leaks will be plugged eventually by postprocessing and tools, I’m sure.) Update: see Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs.
• Speculation on anthropomorphism: I think the reason that LLMs appeared to reason is that the base model, which is essentially a snapshot of the Internet, is then of course trained on millions of conversations in which a question is posed and an answer is generated, which can give the appearance and impression of comprehension and an internal mental model. Clever hans.
• Relating to language theory: I’m reminded of a chapter in Stephen Pinker‘s book The Blank Slate, in which he discusses the case of a young woman who has a developmental issue such that she is not able to reason or function independently, but is able to speak and tell long, detailed stories, which are completely fabricated, but which have an internally consistent grammar and a consistent storyline. In this chapter Pinker is pointing out that you can have a grasp of language, but no grasp of logic reasoning et cetera.
• Relation to a consistent pattern of abstraction due to layers of complexity: the MIT book Structure and Interpretation of Computer Programs was switched from a from-the-ground-up, principles first, implementation of various topics, to essentially a goodie bag of scientific ways of using vast APIs and Python. And this is completely not a criticism of Abelson or Sussman: in fact, this reflects a deep insight; that they had the foresight and integrity to accurately reflect in the education. Hardware was too complex; now it’s been abstracted away. The operating system is a layer of abstraction, and the programming language is a layer of abstraction. And now there is a language which is not only a black box, but it’s also probabilistic… so it’s yet another layer of unpredictability.
• Dijkstra on anthropomorphism:
  • People talking about “asking it..” and “it thinks…” etc. makes me feel icky.
  • Quote from EWD854: I think anthropomorphism is worst of all. I have now seen programs “trying to do things”, “wanting to do things”, “believing things to be true”, “knowing things” etc. Don’t be so naive as to believe that this use of language is harmless. It invites the programmer to identify himself with the execution of the program and almost forces upon him the use of operational semantics.
• The Lisp Curse: see my other article
• A prior colleague remarked, “Category theory is white magic, AI is black magic.” It stuck with me as it succinctly summarises much of the above.
• Humans as machines: Dijkstra and Frank Herbert have this in common: Dijkstra railed against anthropomorphising machines, but he also argued against treating humans in mechnistic terms, i.e. treating them like machines. It’s a funny way to flip things around.

The LLM Curse

Note: An LLM was not used in writing this article.

I encountered a package, and 99.9% of the Haskell code of that package was–proudly!–written using Claude. I took a browse through the code.

Something that came to mind was The Lisp Curse: Broadly speaking, the Lisp curse is that syntactic abstraction, and extension of the language, is so powerful that Lisp programmers don’t bother to buy into broader abstractions. They don’t make compromises with the community in order to get things built into the language in the same way as, say, Haskell programmers do. A lot of long discussions in the GHC proposals list could often just be a macro in Lisp, for example. So, in a way, every large project in Lisp is kind of reinventing many ideas sui generis, and you’re not advancing the language forward.¹ Whereas, one could argue, many ideas that have developed in Haskell, that were put into the language itself, have spread to other languages. It’s ironic because when you think of assembler or C, that’s (reinvention) the kind of thing that they suffer with, and it’s not something that you would imagine a really high-level language like Lisp would suffer with.

How a language interacts with the people that use it is quite important.

I am starting to wonder whether this practice of vibe coding, i.e. having 99% of the code generated by an LLM interaction, may lead to a similar problem. If it’s so cheap for me to generate walls of code which have loads of repetition, simply because I can just drop it and re-create it on a whim, that reduces the value of abstraction and it reduces another human’s interest in reading that code. (I can’t be the only one who has zero motivation to read AI-generated code.) In other words, you start losing interest in actually programming Haskell, and the particular language matters even less, so now every project out there will, basically, not have to share any kind of abstractions or ideas, because you’re just going to use an AI to explain someone else’s project to you anyway.

Then we’re back to The Lisp Curse. Coming to a language near you. The LLM Curse?

Less-Than Estimation

Note: An LLM was not used in writing this article.

Mechanics

A method of estimation I’ve used successfully on a bunch of projects over the years goes like this. Estimations are one of four choices:

• <hour
• <day
• <week
• <month

I call it “less than estimation” because if a given piece of work is obviously under an hour, your estimate is <hour. If it’s not obvious, you bump it up to <day. If it doesn’t obviously fit within a day, bump it up to a <week. If you’re not sure it’ll fit into a week, my experience says that it could take even three weeks, so bump it up to <month.

Finally, if it doesn’t obviously fit into a month, your powers of estimation have been exhausted: break the thing down into smaller tasks that can be estimated. This also applies to the fact that some people may think that a task takes about two weeks, so they don’t want to bump it up to a month. But if it takes 2 weeks, then you can split it into two tasks.

Advantages

There are a few advantages to making estimates like this:

1. You don’t have to be too precise with granular numbers over something that is inherently imprecise. That makes decision-making quicker. No dithering!
2. People think in terms of time units. An hour, a day, a week, or a month fit neatly into people’s heads without extra thinking involved.
3. Time units are also concrete: people can use them directly, unlike T-shirt sizing that is abstract for people to think about.
4. Often managers/stakeholders don’t care particularly whether it’s two or three of something, they just want that when you estimate something that it’s delivered on time. It’s better to be predictable than fall short and lose trust.
5. Less experienced devs have trouble breaking down work into digestible units, this method encourages that.

Considerations

One consideration is that this can either be considered non-additive (like T-shirt sizing), or can be additive, but needs special software to add them up. E.g. 1 month = 4 weeks, 1 week = 5 days, 1 day = 8 hours, etc. Either works for me. I think on paper organizations like to work without adding up estimates, but in practice that’s what everybody needs anyway.

A handy way to think about the priorities in this scheme is: unit up, split down. I.e. estimates always jump up to the next unit if they grow. But your estimates should never be reduced in unit (by e.g. being pressured by stakeholders), and instead be split into separate estimates, if possible. If it’s easy to split a week up into two days, great! If it’s not, perhaps the week was the right choice after all.

Registers of code authoring

Note: An LLM was not used in writing this article.

I’ve recently been thinking about the fact that there are very distinct registers (for lack of a better word) of authoring code, for me, depending on the type of project.

• Work codebases: in my experience over a couple decades, are of medium standard; we do our best with expedience coming first, and code reviews attend to quality.
• Open source projects: especially libraries, tend to be exhibitions of your best, beauty and good taste is emphasised, you often see innovation, idealism, yak shaving, going down the garden path.
• My personal Emacs config: tidy in my own way, but I don’t need to impress anyone, I don’t need to make anything reusable. I inline all dependencies because I have no need to stay up to date. In fact stability is the #1 priority. It’s like slow food. It’s my own little work bench and home at the same time.
• Shell scripts: they never really grow beyond one file and can be wasteful, avoid any abstraction or reuse, and generally just do the job and don’t worry about modelling the domain too much. I’ve gotten a lot more enjoyment out of this since making Hell.

These all tend to talk about how style and aesthetics and quality are balanced based on the user of the code, and there’s intent in there somewhere. A possible new register (or complete lack of one) may be AI generated projects, but we’ll see. They all have their respective merits.

Hell (Haskell shell): Year in Review

Note: An LLM was not used in writing this article.

Hell is my little shell scripting language which is a thin layer¹ over Haskell, using its syntax, its standard library and runtime, with a simpler static type system. You can find examples here.

Over the year of 2024, I’ve written a few non-trivial shell scripts in Hell at work, and now a few colleagues have used it, too. Now I can use that to evaluate strengths and weaknesses of it as a tool. I can’t really share those shell scripts because it’s not open source, but I’ll drop in some contrived example code at the start of each heading as an amuse-bouche. The short version of work scripts is:

• Generating an HTML page summarising deployments by talking to Git and Terraform and pushing it somewhere to be served up as a web page. Like a small, read-only version of ArgoCD.
• Triggering notifications when deploys happen.
• Script to import many “things” via our own customer API in an idempotent way.
• Running end-to-end tests involving launching processes together and coordinating where they write and what happens when one fails, etc.
• Generally; talking to various APIs (Notion, Intercom, GitHub, etc.).

In Hell, I also implemented type inference, record types, sum types, and added a whole bunch of library functions.

Practical

main = do

  -- Run two things concurrently and return both results
  (left, right) <-
    Async.concurrently
       (Main.curl "https://worldtimeapi.org/api/timezone/Europe/London")
       (Main.curl "https://worldtimeapi.org/api/timezone/Europe/Rome")
  Text.putStrLn left
  Text.putStrLn right

  -- Run two things concurrently and return the one that completes first
  result <-
    Async.race
       (Main.curl "https://worldtimeapi.org/api/timezone/Europe/London")
       (Main.curl "https://worldtimeapi.org/api/timezone/Europe/Rome")
  Either.either Text.putStrLn Text.putStrLn result

curl = \url -> do
  (out, err) <- Text.readProcess_ (Process.proc "curl" [url])
  IO.pure out

I’ve seen that it scales quite well e.g. to scripts that are a few hundred lines, without feeling that the file is getting out of hand. That’s not a surprise and is the main reason I decided to make this project in the first place.

Because the runtime performance is about as good as GHCi, it seems to be fast enough for all purposes I’ve used so far. Really, scripting languages only need to be nimble enough not to show themselves as being slower than the I/O and sub-process work they inevitably perform.

Concurrency in Haskell is very good. Some say “best in class,” which is debatable, but it’s had green threads for decades and has a maturity and predictability about it. Hell grabs that power tool from the shelf and puts it under your belt. So, things like “race” or “map concurrently” are things you often want in a shell script, because many things are just I/O intensive and can sometimes be embarrassingly parallel jobs. The other benefit is that you often want to run N sub-processes concurrently for a long time, such as web services and attendant jobs, and structured concurrency with Async makes that neat and tidy.

Another absolute win, which I’m sure the PowerScript and Oil Shell people will tell you, is that using real data structures in a script is phenomenal. I’ve got a script at work (The Deploy Dashboard) that uses Map and Set in non-trivial ways to compute time slices over a Git commit history, for example. They’re ample efficient, but mostly the benefit comes from using a sensible data structure that has a predictable behaviour about it.

Ergonomic

main = do
  env <- Environment.getEnvironment

  -- Maybe monad works!
  Maybe.maybe (Text.putStrLn "Oops!") Text.putStrLn
     (do path <- List.lookup "PATH" env
         home <- Functor.fmap Text.reverse $ List.lookup "HOME" env
         Monad.return (Text.concat [path, " and ", home]))

  -- Either monad works!
  Either.either Text.putStrLn Text.putStrLn
    (do x <- Main.parse "foo"
        y <- Main.parse "foo"
        Monad.return (Text.concat [x,y]))

parse = \s ->
  if Eq.eq s "foo"
     then Either.Right "foooo :-)"
     else Either.Left "oh noes!"

As the syntax is familiar, it’s pretty ergonomic. It’s a very, very small subset of Haskell, as can be seen in the examples. I think when I write it, I’m mostly checking what’s in this small page of API functions. I think the familiarity and small scope makes it predictable and that means one can approach a task using it with confidence.

As a Haskeller, being easy to write is great. But the larger part is being easy to read. It was easy at the start of this project in early 2024 to say I like reading the code, because I was the only user. Now, after reading the code of a few colleagues, I still find it very easy to read the code. That’s a big win for me.

When writing scripts for work, I use the --check flag to typecheck it regularly. (Pairing with watchexec/entr is snappy.) The type system saves me time, as often scripts will run something that’s sluggish like Terraform that takes ages to do anything, and then you find out you made a silly mistake after all that. So it improves the feedback loop.

Low risk

main = do
  Temp.withSystemTempFile "example" \filePath handle -> do
    Text.putStrLn $ Text.concat ["Created temp file ", filePath]
    let proc = Process.setStdout (Process.useHandleClose handle) $
         Process.proc "ls" ["-al"]
    Process.runProcess_ proc
    contents <- Text.readFile filePath
    Text.putStrLn contents

The nice thing about this project is that because it doesn’t deviate² from Haskell, one could easily translate any script literally to Haskell by adding some imports and then compile it to a binary. So any scripts written in Hell has a low bus factor: you can always just “lift” it into Haskell and be on a maintained ecosystem. This is incidentally the same answer to the question: what if my script isn’t fast enough? Haskell compiles to competitive machine code with a high throughput garbage collector, so if down the line a Hell script became part of some core infra and also became a performance problem, you could compile it to get a huge performance boost, at the cost of more complicated build infrastructure vs Hell which is just a single-binary interpreter.

The other part is that I haven’t added any backwards-incompatible changes, because I made it easy for myself not to, in two ways.

The first way to do that is to just Learn to Stop Worrying and let things stay in that I don’t like. I’ve written about this elsewhere; not breaking things for your users doesn’t come naturally, because, ew, I hate this function and regret it being born! In the long-run, though, it makes everything easier to just accept that some small blemishes.

The other way is to defer 95% of design decisions to the host language (Haskell) and its libraries. So, if you see any API in Hell that you don’t like, well, it’s not my design, sorry! It’s standard Haskell! None of the above code sample is my design, it’s all lifted from Haskell. Getting into API design is tempting, and a sign of hubris… it can drive some to madness!

A final benefit of not diverging is that one can use any regular Haskell source formatter. A source formatter is a huge undertaking for any language with a big surface area like Haskell. So Hell gets that for free. Use ormolu the standard Haskell formatter.

Weaknesses

It has no editor support.³ I don’t plan on writing editor support for it. That’s a very large undertaking; larger than writing the language itself, I expect. So this aspect of the tool might remain rubbish.

The error messages aren’t great. They’re okay, but they’re a bit barebones. The type errors might point out a location that isn’t obvious. This can be improved and I do want to improve it over time. See the discussion on GitHub here: Reproduction of a bad type error message

Future work

For the year 2025, I will probably work on these over the course of the year:

• Better error messages.
• Move from haskell-src-exts (a Haskell parser) to GHC’s own parser, to reduce any possible deviations from the norm, and to get recent syntactic goodies. This is a big job, but I’ve got the whole year.
• Move to an efficient unifier for the inference pipeline.
• Probably a steady but decreasing pace of adding library functions.

Otherwise, I think my plans are more orientated around using it to write automation, rather than adding any new features.

Adding sum types (variants) to Hell

Note: An LLM was not used in writing this article.

Hell is my little shell scripting language that’s a thin layer over Haskell’s own standard library and runtime. This post is for people that like language implementation details. It has a simply typed system, without polytypes (no forall).

It has classic Haskell 98-ish records, this is a valid Hell program:

data Person = Person { age :: Int, name :: Text }

main = do
  Text.putStrLn $ Record.get @"name" Main.person
  Text.putStrLn $ Record.get @"name" $ Record.set @"name" "Mary" Main.person
  Text.putStrLn $ Record.get @"name" $ Record.modify @"name" Text.reverse Main.person

person =
 Main.Person { name = "Chris", age = 23 }

It’s built upon the following “classic” anonymous records definition in Haskell:

data List = NilL | ConsL Symbol Type List

data Record (xs :: List) where
  NilR  :: Record 'NilL
  ConsR :: forall k a xs.
    a -> Record xs -> Record (ConsL k a xs)

The record is a linked list type that is indexed by a type which itself is also a linked list, and in both cases we keep both a key k and a value a.

This exact representation is used in Hell. It’s defined in the meta language (Haskell) and used in the object language (Hell) directly and is manipulated in a type-safe way; so accessor functions are all total (they don’t have an “otherwise throw an error” case). I cover this in a bit more detail in Tour of Hell.

This week I added a very rudimentary implementation of sum types, so the following is a valid Hell program:

data Value = Text Text | Number Int

main = do
  let printIt = \x ->
        Text.putStrLn case x of
          Number i -> Show.show i
          Text t -> t
  printIt $ Main.Number 123
  printIt $ Main.Text "abc"
  Monad.mapM_ printIt [Main.Number 123,Main.Text "abc"]

The runtime representation of a constructor is shaped like a combination of Either and Record:

data Variant (xs :: List) where
  LeftV :: forall k a xs. a -> Variant (ConsL k a xs)
  RightV :: forall k a xs k'' a''.
    Variant (ConsL k'' a'' xs) ->
    Variant (ConsL k a (ConsL k'' a'' xs))

The trick here is to note that the index of kind List is only ever ConsL .. meaning it cannot be ever NilL (empty).

The challenging question in defining a case analysis on this type is how to make it total, and not require an “or else throw” case. I went with a simple accessor data structure that looks like a case:

data Accessor (xs :: List) r where
  NilA  :: Accessor 'NilL r
  ConsA :: forall k a r xs. (a -> r) ->
    Accessor xs r ->
    Accessor (ConsL k a xs) r

It’s basically the same as Record except that every field is (a -> r) instead of just a, meaning we have a record of functions.

runAccessor :: Variant xs -> Accessor xs r -> r
runAccessor (LeftV a) (ConsA f _) = f a
runAccessor (RightV xs) (ConsA _ ys) =
  runAccessor xs ys

This function is total and GHC is happy that it is exhaustive.

From here, Hell’s runtime didn’t need to be touched. The desugarer simply replaces

data Value = Number Int | Text Text

with something like:

_Number = Variant.left @"Number" x)
_Text = Variant.right (Variant.left @"Text" x))

(I sort the constructors alphabetically for a canonical ordering.)

And replaces

case .. x of Number i -> Show.show i; Text t -> t

with

Variant.run
  x
  $ Variant.cons @"Main.Number" (\i -> Show.show i) $
     Variant.cons @"Main.Text" (\t -> t) $
       Variant.nil

I thought this was pretty neat, because it’s very simple and very clean, and total!

(To be entirely precise, Hell wraps both records and variants defined with data Foo with a Tagged "Foo" to keep some semblance of nominal typing. In case someone reads the code and thinks the tagged part is important.)

A modest critique of Htmx

Note: An LLM was not used in writing this article.

At work, we really like the basic simple idea of Htmx. Based on using Htmx in a non-trivial user interface, across a team, we’ve found that the following cases are actually not simple and are quite complicated.

Inheritance of Htmx properties is a definite mistake

Across pieces of code, it’s very surprising and it’s implicit. Like in CSS, inheritance is a cheap hack but you get what you pay for.

It contradicts the author’s reasonable argument of locality of behaviour. It’s not local, it comes from all the way up there or some other module. Pretty much dynamic binding.

Default inheritance differs across various properties (e.g. hx-delete is not inherited, but hx-confirm and hx-ext are). So you have to remember these exceptions and you end up just being explicit about everything, which means inheritance is pointless.

Most interesting web apps cannot replace wholesale a DOM element

Because DOM elements almost always have browser-local state, such as the open/closed state of a <details> element, the input of an <input> element, the open/close state of a dropdown element (which, note, is not encoded by an attribute of the element when you click it). All of this state is lost if you replace outerHTML directly with the naive happy path of Htmx.

Even morphdom overwrites some things you’d expect it not to, so we had to patch it to avoid messing with input elements, and details elements.

Storing state in the DOM element itself is a bad idea

Morphdom is intended to correct the pains of the previous heading, but we discovered that the way that Htmx works assumes it’s based on replacing elements wholesale: it stores the request queue for the element on the DOM element itself. When you kick off a request, either from this element or from another that points to it, you have a request queue. Some bad failure modes are avoided by wholesale-replacing the DOM element, as the queue is reset. But with morphdom, the queue is retained because the element is retained. You’re now in a sort of undefined behavior land, where the designs of Htmx are violated.

The default queuing mode is bonkers

By default, Htmx will cancel requests that are in-flight if you trigger another request on the same queue (element). That’s the default strategy. We discovered this afterwards. It’s highly unintuitive, it meant we were losing work.

Event triggers are non-local

Event triggers often help to make things happen, but they’re a non-local effect, and suffer from similar issues as property inheritance. A bit of DSL work in the server-side language can help with this, but it feels like old-school JavaScript callback-based programming to some extent; where you “subscribe” to an event happening and do something.

Component state cannot be maintained very well

A broader problem, similar to the DOM element state issue, is that your own components have their own state. E.g. if you want a page that consists of three sections that have their own state that the server needs (e.g. which page of a set of results) and state that some e.g. React or WebComponents need, then you have a problem of synchronising state between a parent component and the child component.

Htmx does not provide a good story for this. We have some ideas, but they all have big caveats: use query parameters, use hidden form inputs, use event triggers.

React and Halogen (see also Halogen is better than React at everything) do have an answer to this. In both cases, child components have their own state, and parents can give them “props” which are pretty much “advice”, and they also have their own internal state, and can choose to ignore/take precedence over props. The props are typically sourced from the server or derived from the server, and the state is usually some client-side state.

We often do need to use React for off-the-shelf components or components that we have to use that are just provided as React. React and Htmx do not interact nicely.

• We’ve done some unsatisfying work with WebComponents, but those things have bizarre limitations that are surprising.
• We’ve also made a bridge directly to React components that we use from our server-side language, but in general Htmx and React fight for control over the flow of state and management of DOM elements.
• We’ve played with Alpine, which is nice, but it represents yet another client-side-programming library and is therefore redundant if React is already in your codebase.

The up sides

Our current thinking is that being able to use your server side language is a huge obvious and uncontroversial win, no one on the team would want to go back to writing all this business logic in TypeScript:

• No serialisation from our DB types to frontend types is needed.
  • No data leaks, and no GraphQL needed.
• We can use our (in our opinion) more powerful abstraction facilities of the server-side language.
• We can use the form builder in our server side language; instead of doing one frontend and also one backend implementation of the same validations.

But the above downsides are real.

Htmx-in-React?

An attractive future direction might be to re-implement Htmx in React:

• The server sends a JSON blob that React converts into virtual DOM components.
• That would solve the component state problem.
• It would mean we require no special bridge to use React components.
• It would let us use our React-connected web fetching library, and carefully avoid the queuing choices made by Htmx.
• It would solve the morphdom problems and browser DOM input elements problem, too, which is pretty much a solved problem in React.

In this way, we could drop the Htmx dependency but retain the benefits of the idea. That is, given a budget to embark on such a big piece of work.

Naming sum types is often hard

Note: An LLM was not used in writing this article.

After doing quite a lot of software design in systems which encourage use of enumeration types, I’ve noticed that there’s a common challenge in naming both the type and the cases of the type. It usually exposes a painful inadequacy in the English language and my grasp of it, assuming any kind of aesthetic appreciation.

To take a trivial example, it’s only thanks to George Boole that we have an elegant and concise name for the type of terms that consist of either true or false. If we went for “truth” or “truthiness” we’d be left unsatisfied because this name is biased towards one of the two choices.

A more realistic example is the type of terms that consist of either “local” or “remote.” If we call this “locality” then we are both biased towards the local and overlap with a common, political understanding of the word “locality.” “Remoteness” presents similar problems. The word “location” doesn’t capture the modality. I’ll stop here because I’m just upsetting myself.

Another example is the challenge of expressing whether something is qualified or not qualified, in the sense of prefixed or suffixed with some extra term. It’s really grating to have to express the thing in terms of not-something. We prefer to say static versus dynamic, and not static versus non-static or, above, local versus non-local. Ignoring this, what do we call the type of these terms? “Qualified” is biased. “Qualification” overlaps with a recognised achievement. We frown and move on with something rubbish.

I probed an LLM to search for more obvious, satisfying answers to these, in vain. But these are mere examples of a common experience. I know that one of the two hard problems of computer science is naming things, but this feels like a particularly bothersome flavour of it.

Portals in Emacs

Note: An LLM was not used in writing this article.

I’ve been working on a new way to launch and manage processes in Emacs in my personal repo. It’s an alternative to shells. A bit like a notebook. It also partially serves the same need that Prodigy-mode does. The name is evocative of that video game Portal from 2007.

It has a major mode, where M-! is rebound to Portal’s way of running shell scripts. It inserts a nano-ID for the portal, e.g. portal_abc123456sdkjfal, as text into the buffer at the current point. It creates a corresponding directory under ~/.portals/. All stdout and stderr are redirected to files under ~/.portals/$portalid/{stdout,stderr,command,directory,env}.

The purpose of this is that Emacs can lock up a bit when you run a very long running process, or one that spews output very quickly. Instead of storing it in a buffer or displaying all of it, Portal just writes it all to a file and displays a little preview of it anywhere in the buffer that the portal’s nano-ID is.

The preview is updated every couple seconds, it’s not instant. That design is intentional, so that no process can ever really overwhelm Emacs. It’s an extremely aggressive design. Even the line length in the preview is limited to 80 columns.

Another motivation is simply UX-based, which is that I run a lot of commands at work that spit out a bunch of useless output. Like Terraform, Cabal, GHC, etc. Most of the output is not of interest, but occasionally, one does want to read the output.

Example, below:

portal_M2FjMjMyZWIxZjI4MTNmN
# (0) ls
# package.yaml
# readme.md
# scripts
# stack.yaml
# stack.yaml.lock

portal_ZmZhZThiMmFiNzQ1Y2E3N
# (run) stack build
# Preparing to download ghc-tinfo6-libc6-pre232-9.4.8 ...
# ghc-tinfo6-libc6-pre232-9.4.8: download has begun
# ghc-tinfo6-libc6-pre232-9.4.8:  256.00 KiB / 178.01 MiB (  0.14%) downloaded..
# ghc-tinfo6-libc6-pre232-9.4.8:  432.00 KiB / 178.01 MiB (  0.24%) downloaded..
# ghc-tinfo6-libc6-pre232-9.4.8:  736.00 KiB / 178.01 MiB (  0.40%) downloaded..

The (0) indicates a successful exit. The command, stdout and stderr have different colours. In the major mode, you put your cursor over them and hit RET and it’ll pop open the file for you.

The other reason for storing all of this is that one can restart Emacs and re-open a file containing portals and see what was ran, and re-launch them if desired, with the same arguments, directory, etc.

I often use M-x portal-edit to tweak a command line, which prompts in the mini-buffer with the existing text to edit. After hitting RET, it restarts the portal for you. M-x portal-rerun does what you’d expect.

All newly ran portals get a new nano-ID, so you can always go back and find the outputs of a previously ran portal.

Emacs handles all the stdout and stderr, so it could in theory be possible to pipe from one portal to another. One could even attach and detach portals to/from one another, or edit arguments and restart, while some of the processes are still running. But I haven’t explored this because it’s more of a side-effect of my design than an intentional part of it.

It also works perfectly with envrc mode, which is how Emacs integrates with direnv.

C-c C-c on a portal will interrupt the process, as expected.

I’ve been using this for a few weeks and frankly I’m surprised how well it works and fits my workflow. At work I have a foo.portals buffer which has 30 portals in it. Of those, 3 are presently running, the rest are things I can scroll through and re-run when I feel like it. I save the file, so I can always restart Emacs and lose nothing.

I’m not interested in maintaining it as a “package.” But in the spirit of Emacs, I am interested in sharing the code, so that others can rip, riff and remix! Hope someone found this fun!

All my projects (2008-2023)

Note: An LLM was not used in writing this article.

It might be a “getting old[-er]” thing, but I’ve recently started feeling like documenting the complete set of software projects I’ve worked on that I remember. Not as a CV (an advertisement of paid work), but a comprehensive list of everything.

I’m done for now for 2008-2023. I filled out all the headings of my projects with blank bodies. I started with the old stuff and continuously made updates a little bit per day. After a month I was done. At somepoint I was saying “oh for god sake, there’s still more left”, which, if I may boast a little, indicates I did a lot of things over the years.

Some of these projects are trivial, frivolous, very dubious, and some of them are genuinely interesting, novel, or high quality. But it’s all me.

Table of Contents

• 2023
  • copy-paste-sync
  • hell
• 2022
  • envy
• 2021
  • proclog
  • lexx
  • hag
• 2020
  • inflex
• 2019
  • novella
  • streaming-parsers
  • forge
  • env-args
  • dynamic
  • webshow
• 2018
  • lpaste
  • odbc
  • hex-server
  • sdl2-sprite
  • caseof
  • rocksdb-haskell-ng
  • phase
  • audit
  • codeparty
  • duta
  • prana
  • intero
  • cron-daemon
• 2017
  • xeno
  • profile-query
  • snappy
  • liquid-post
  • tdiff
  • vado
  • jl
  • duet
• 2016
  • purify
  • labels
  • org-focus
• 2015
  • descriptive
  • stack
  • path
  • xinput-conduit
  • conditions
  • haskell-trace
• 2014
  • clockin
  • present
  • ace
  • hl
  • formatting
  • hindent
  • foreign-store
  • shell-conduit
  • lucid
  • gmail
  • osdkeys
  • ghc-server
  • ats-examples
  • carvo
• 2013
  • z
  • ini
  • pure-io
  • god-mode
  • structured-haskell-mode
  • haskellnews
  • ircbrowse
  • snap-app
  • cabal-sign
• 2012
  • sourcemap
  • fay
  • scrobble
  • bdo
• 2011
  • numbergeddon
  • pdfinfo
  • chrisdone-xmonad
  • flo
  • freenect
  • hulk
  • ji
  • pgsql-simple
  • css
  • url-generic
  • hog
• 2010
  • tryhaskell
  • jquery-console
  • lisk
• 2009
  • asp-mode
• 2008
  • kibro
  • lojbot
• 2006
  • slsk/soulski
  • wdn

2023

copy-paste-sync

I wrote this trivial tool called copy-paste-sync that can copy/paste between systems by always keeping the clipboard in sync. It basically just watches the clipboard for changes and then POSTs the content to interested parties. At work I use a MacBook, but I also have my Linux laptop next to it, so being able to copy/paste between the two is handy.

hell

Hell is a shell scripting language that is a tiny dialect of Haskell that I wrote for my own shell scripting purposes. Full blog post about it here.

2022

envy

I found myself using tools that want to control my shell environment at work in order to run commands properly. This makes it annoying to simply run a command from Emacs. So I wrote a mini tool called envy that simply saves the environment generated by such a tooling setup, and then execute any command with the same environment later.

2021

proclog

While consulting on a project that ran executables deeply within it, I wrote proclog as a kind of ‘smarter tee’. I haven’t used this for a while and it isn’t maintained anymore, but it was handy in the moment.

lexx

I wrote a project called lexx, which lexes Haskell code, specifically Show instances, but it can handle fairly unstructured input, and still pretty print it with colours nicely. It’s good for dev logs or general pretty printers.

hag

I fiddled about with a project called hag, “Haskell ag”, which would let one “grep” Haskell files for identifiers, and exclude strings, comments, etc. by lexing them properly. I haven’t used this for a while, it’s currently in the freezer.

2020

inflex

This was my dream project that I planned on being The Big One for my 30s. It involves all my skills: web, services, parsers, type checkers, interpreters, UI, etc. I had a business, a registered trademark, lawyers draft up Ts&Cs and a privacy policy, accountant, Stripe account, etc. It was going to be an online spreadsheet competitor. Inflex was going to be a big hit.

I had a kid and then it took a back seat, I couldn’t financially justify paying an accountant and for all the services when I only had an hour a week to dabble in it. So I packed it in.

However, it has some of my best work. The compiler pipeline is beautiful. Some of the implementation is wonderful. The design trade-offs are brilliant and I researched everything over 2 years. The archive repo is here.

2019

novella

For some bizarre reason, I thought it would be a good idea to make a structured editor in the terminal called novella: the big idea was to define a simple grammar for any language and get a structured editor out of it, like this:

grammar :: Grammar
grammar = $(checkGrammar $ runDefine $ mdo
  -- General expression
  expression       <- rule "Expression" (ChoiceSchema [variable, constructor, parentheses
                                                      ,tuple, let', application, string])
  application      <- rule "Application" (CompositeSchema [expression, expression])
  parentheses      <- rule "Parentheses" (CompositeSchema [openParenSchema, expression, closeParenSchema])
  -- Tuple
  tuple            <- rule "Tuple" (CompositeSchema [openParenSchema, tupleElements, closeParenSchema])
  tupleElements    <- rule "Tuple elements" (ListSchema expression ",")
  -- Identifiers
  variable         <- rule "Variable" (IdentifierSchema "Variable")
  constructor      <- rule "Constructor" (IdentifierSchema "Constructor")

streaming-parsers

I wrote, along with Michael Snoyman, some streaming JSON/YAML parsers, in a package I called streaming-parsers, with the express intent to avoid security issues implied by packages like aeson which consume the whole input given by the user. This package never got used, but I did end up using reparsec elsewhere, which was like a parsec that streams like attoparsec, but works on any token rather than Text/ByteString. Arguably megaparsec fits that niche these days, although I find megaparsec kind of awkward and I can never remember how to use it.

forge

I wrote forge as my answer to modernizing formlets,¹ after the world forgot about multi-page web apps and switched to frontend/backend stratification.

However, it introduces a few novel ideas:

• Static checking of the uniqueness of names within a form
• Errors can go both up and down in the form, meaning you can “send” a validation error from above down to the input that caused it
• Selective-like behavior
• Typed handling of optional vs required fields, which in other libraries is a bit wishy-washy

env-args

A simple tool called env-args that would convert environment variables to program arguments. With this, it became trivial to either pass –foo arguments or PROGRAM_FOO variables. Used for a client.

dynamic

Partly as a joke, partly serious, I made a package called dynamic which gives you dynamic types in Haskell. It makes it trivial to explore unknown data in Haskell. I’ve never used it, but in principal it is interesting.

webshow

I made a simple tool to generate a hierchical data structure browser for Haskell Show output (similar to present), and called it webshow. I have occasionallly resurrected this, when I need to explore really hairy Haskell data structures.

2018

lpaste

Back before GitHub’s gist took over, I wrote a service called lpaste which sat at lpaste.net, and superceded hpaste.org (Haskell paste), for pasting code samples. It was mostly IRC-driven. It actually featured some useful features, where e.g. pasting a revision would notify users on IRC in a given channel. That facilitated a lot of discussion about a given piece of code, with people able to make suggestions and improvements.

Spam became a large problem, and after I stopped using IRC I didn’t feel like continuing to run it.

odbc

For a client, I needed to interact with SQL Server, but it was clear that the libraries out there were all quite badly put together. So I took Microsoft’s own now-native Linux driver and wrote a from-scratch Haskell library to talk to it, here. This one is still maintained and used as far as I’m aware, but a few companies. I put special care and attention into stability and performance, and I think did a good job on that.

hex-server

I can’t explain some of the motivations for my projects. I wrote hex-server which was a ground-up implementation of Xorg-server in Haskell. I have no idea why. Curiosity, I guess.

sdl2-sprite

I was fiddling about with sdl2 at this time. sdl2-sprite just repeats a sprite for you (see the README gif). I think there are other tools around for this, but I found this one just did exactly what I wanted while making a sprite in InkScape.

caseof

The caseof package is just a proof of concept to test whether I could avoid lens and get what I wanted: trivially ask whether a value is of a particular constructor and if so, return a Maybe of the slots. Answer is: yes, you can. Does anyone use it? No, lens is too popular.

rocksdb-haskell-ng

rocksdb-haskell-ng was needed for some cryptocurrency client, who were inadvisedly using rocksdb, in Haskell, and the existing package was, well, neither stable or efficient. I rewrote it from scratch, with stability and performance in mind. I’m quite proud of the work I did on this, it was good work.

phase

Another case of having too much time on my hands perhaps. phase basically provides a frontend to Emacs in your browser. It’s not as native as the GTK or terminal frontends, but the latency wasn’t too bad. I’m not sure I’ll ever pick this up again. But it was surprisingly usable.

audit

I had to audit a number of projects at FP Complete. This emacs mode helped me interactively mark any selection of any file as viewed, accepted or problematic, with comments. I would still use this today if I need to audit or heavily review a project.

codeparty

When teaching Haskell to companies at FP Complete, it was handy to have everyone type out the answer to an exercise live on screen. For that I made codeparty, which was a bit like a mass screen share, but more efficient, and ensured everyone had the same editing experience. I would use this again if I needed to teach Haskell again.

duta

I wrote my own email server called duta, which was about being able to self-host email. I actually ran it for years; it was only because LetsEncrypt at the time was harder to use and required upgrades and maintenance that I gave up on it, but for a while I was reading my mail with my own Haskell-made email web and Emacs client.

prana

I was really into the idea of being able to interpret Haskell within Haskell, so I made a project called prana which would compile GHC Haskell down to STG, convert that STG to an internal format, and then interpret it. It turns out, there are quite a few “implicit” things in STG that you just have to know, figure out or ask around about. The GHC internals change far too often, so I gave up on this. But I took a good crack at it.

intero

intero was my “complete” (intero is Italian for ‘whole’) Haskell IDE in Emacs. I was given space at FP Complete to work on it as a product to solve the whole Haskell tooling issue. It was actually a brilliant project, and worked on almost everything, and rarely if ever broke. There was a lot of Emacs Lisp, and a modicum of Haskell in a GHCi fork I called intero.

Some of that Elisp still lives on in my Emacs config, but the project itself I sunsetted some years ago after I was subjected to one final GHC upgrade and could not bare to port my code over to yet another GHC API API change. I just gave up.

But on the whole it was a great project and had 1k users at least.

cron-daemon

I wanted a handy way to have a ‘service’ run and re-run easily, which I called cron-daemon. This was my first tool that I statically built with musl. I haven’t used this for a while, but I might use it in the future. It can be used in combination with stack build --file-watch --exec 'cron-daemon ..' to cause a service to restart after recompiling.

2017

xeno

After seeing that Neil Mitchell had written a fast XML parser by using C for the parsing, I was motivated to use it as a demonstration of writing fast parsers in Haskell. The resulting demonstration library, I called xeno, but left it for someone else to pick and maintain, which Marco Z took up. It was 100x faster than the other “fast” Haskell XML parser called Hexpat. It was faster than the C one at SAX parsing, and 2x slower at allocating a DOM, but this also predates the introduction of proper Word8, Word16, etc. types in GHC.

profile-query

I wrote a tool at FP Complete called profile-query to parse GHC’s profiler output (.prof) and to provide aggregated summaries of cost centres, with sorting by e.g. time or allocations.

It was a handy tool, but isn’t maintained today. I expect it would still work, though.

snappy

A brief experiment called snappy to try out Reflex-like FRP with SVG. It’s not as easy as you think to do this, and there are all sorts of gotchas. Where possible, don’t DIY FRP. It’s hard.

liquid-post

I wrote a post about Liquid Haskell for FP Complete, but this repo shows all the examples and they are quite good, I think.

tdiff

I still use this sometimes. tdiff just gives you timing between lines of output from a process. This can be really good for checking timings of other programs than your own.

vado

In an exhibition of sorts, I made a 90s-style web browser called vado (“I go” in Italian), which can show rich text documents and browse around. I think it’s pretty cool that I was able to do this in a few hundred lines of code, and it works/worked on Windows, macOS and Linux, too!

jl

I like jq a bit, but I always found myself just wishing I had a basic mini lambda calculus/Haskell. So I wrote a small statically typed mini language called jl. I used it for a while, but somehow I’ve managed to go years and years without needing to do JSON munging in scripts or anything. So this project died due to lack of use. I otherwise think the design and implementation are both good.

duet

I have no idea why I started working on this, but I wrote a small Haskell implementation called Duet, which is helpful for teaching because it has a substitution-based interpreter. It was based on Typing Haskell in Haskell, which was refactored a bit, more types added, etc. It’s quite a viable Haskell implementation. Great for teaching.

I never found other uses for it, because frankly I don’t fully understand the type-checker, because I didn’t author it from scratch. Future projects involved writing one from scratch, which I do understand. See Inflex or Hell.

2016

purify

I was doing more PureScript dev in 2016, so I made purify, which was basically stackage+stack, but for PureScript. It was popular for a while, but then the main PureScript package manager gained these capabilities and it wasn’t necessary anymore. But it was a solid project, I think.

labels

As part of proving out whether Haskell could really be useful as a data analysis language (answer: not really), I wrote labels, which is an extensible records package, along with CSV, JSON capabilities. It worked, actually, but nothing much came of it after that.

org-focus

In an effort to track all my time on projects, I wrote org-focus for Emacs. It was a bit like org-agenda, but included time spent, estimates, and stuff that a consultant might need. I don’t track my time with such fine-grain detail these days, so I stopped using it.

2015

descriptive

I noticed that optparse-applicative, formlets, yaml/json parsing, etc. were all a type of self-describing parser. Hence descriptive. I think the task of generalizing all of these under one framework is harder than I anticipated, despite the grand vision, and the project died.

stack

At FP Complete, clients wanted a tool that covered all their use-cases, which typically involved multi-package projects and wanting to avoid the cabal solver. Motivated by previous success with internal tools,² we decided to make a proper tool and decided the name would be ‘stack’ (from stackage). I made the first commit for Stack. I worked on it for a year or two, alongside many people at FP Complete like Michael Sloan, Manny Borsboom, Dan Burton and Michael Snoyman, and I have used it ever since. Most everyone else did the bulk of the work, I only kick started the basics (reading cabal files, GHCi support, things like that).

The first version used Shake, but we discovered it was very hard to reason about what it was doing. Michael rewrote the scheduler to not need Shake, and did further work to basically make Stack a bit like Nix and lock down all packages, package sets into with SHA256 hashes. I wrote casa.stackage.org to store content-addressed blobs of package files for Stack to later retrieve.

It went on to become the build tool of choice for Haskell projects for some years. It’s only in recent years that cabal-install has caught up with feature parity and the sentiment seems to be shifting back to cabal-install. I still use stack because the ergonomics are more designed for my workflow.

path

As part of my work on stack, we deal with filepaths a lot, so I wrote the path package, with a blog post motivating it. I was pretty happy with this package, it solved a real need that initially a lot of people were sceptical of, but colleagues told me it saved their asses a few times.

That package is still maintained to my knowledge.

xinput-conduit

This package simply converts the xinput output (which yields all keys pressed in Xorg), and provides them as a Haskell source conduit. I was using it for keypress analysis back then. I still think it’s a nifty trick.

conditions

Conditions are a Common Lisp idea. Unlike exceptions which unwind the stack, they call a function which is bound in the dynamic scope, which gives the option of providing a different value for the calling code to use. There are whole workflows built around them in Lisp. You can be reading from a bunch of files in a loop, encounter a problem, fix it, and then continue running the program.

I was inspired to demonstrate that in Haskell. But it’s not as good as in Lisp, which embraces it fully.

haskell-trace

I wrote a small tool to add trace calls in one’s Haskell code. This is something that Haskell sorely lacks, and I can’t see acquiring any time soon.

2014

clockin

I wrote clockin as a command-line app to be able to clockin and clockout of any task. I used this for a while, maybe a year, before losing interest in clocking my time so accurately.

present

After looking at CLIM (Common Lisp Interface Manager), I really liked the idea of being able to present a value with multiple interpretations. That’s what present was about. I used template-haskell to inspect any type and derive a representation for it. Even ByteString had multiple views, e.g. as a list of bytes, as UTF-8 text, hex, a pointer, etc.

I kind of ran myself into the ground with this when it came to higher kinded types. I got stuck and lost interest. I would love to pick it up again some day.

ace

In the afterglow of growing bored of Lojban, but still enamoured by formal human languages, I got into Attempto (Latin for ‘I dare’) Controlled English. I ended up writing a parser package for it in Haskell here. It’s surprisingly comprehensive, I wrote a blog post on it. It even permits passing a record of parsers, permitting the user to define their own vocabulary and syntax for terms.

When I wrote it, use of such things was questionable. Combine it with a logic database and poof, magic understanding! In reality, not quite. Arguably, the use for such a thing in today’s brave new world of LLMs is even more questionable.

But I suppose there still lies a small place in my heart for a formal language that is also readable by anyone who speaks English.

hl

The Haskell web site has already been a bit crap. Today, it’s okay. It’s been much worse. During that period of much-worseness, I wrote hl, an alternative Haskell homepage, complete with reasoning, which I launched at haskell-lang.org as an alternative competing page, due to making no progress at all for years in trying to get access to haskell.org itself. Eventually, it did become the Haskell homepage due to some diplomatic heroics. In that sense, I suppose the project was a success. There was, as expected, lots of politics surrounding it, but that’s always the case with home pages of community projects.

formatting

I thought that the HoleyMonoid package was very neat, and decided it would make a perfect type-safe printf-like package. I called it formatting, after Common Lisp’s FORMAT.

Actually, it turned out that despite the neat trick, I really doing like the position-dependent style of printf/FORMAT at all. I prefer just writing x <> " and " <> y instead, or concat [x, "and", y]. So the whole thing became an experiment in novelty, but ultimately I lost interest and passed the maintainership onto someone else.

hindent

hindent was my bold attempt to make a complete pretty printer for Haskell, so that manual code formatting would be a thing of the past. This was quite a substantial project and took a lot of work. The blog post explains the motivations, but I just wanted to type less and get autoformatting. I later went one step further and limited it to a single style (which is what gofmt famously did), which I documented here. I even chose a style that I didn’t like, but that was popular. The decision to enforce just one style made a lot of people mad.

Years later, there was a remake project called Ormolu³, which also enforced one style. There was subsequently a fork called Fourmolu, which permitted more style configuration.⁴

foreign-store

The foreign-store package is a simple bit of C code wrapped in a Haskell package that lets you keep a reference to a Haskell object between GHCi reloads, which I wrote for the purpose of hot reloading. It’s actually still used to this day and maintained by someone else. There are 12 direct dependencies of it on Hackage, mostly various different ways of doing code reloading.⁵ They’re all fancy wrappers around this.

10 years after it had been published and not been touched for just as long, someone found and fixed a segfaulting bug in the C code. Can you believe it?

shell-conduit

I’ve been wanted to write shell scripts since 2014. This attempt, shell-conduit, was to get all available names in the PATH, available as real Haskell identifiers to run. And then “scripts” would be regular Haskell programs.

I’ve since changed my mind that this is a good idea, and see above for the Hell project.

lucid

Lucid is still actively developed, and was motivated by have a uniformity of combinators, like HTML handling in Common Lisp.

It’s also a proper monad transformer, which has a small theoretical satisfaction to it.

It’s one of my projects that is using the Immutable Publishing Policy.

gmail

When Google released a new mail app, that was a smaller version of GMail, with an API, I rejoiced and made an Emacs mode for it. Google would later kill it, as they killed all things eventually. One of many lessons learned about depending on any kind of public software service.

osdkeys

A simple tool that would display keys pressed on the screen, for screencasting.

ghc-server

ghc-server was my attempt to make a language server before “language server” was a meaningful term, inspired by SWANK for Common Lisp, that powers the SLIME Emacs package. It had a good start, but I encountered a lot of lockups and issues. Also, I couldn’t make GHC stop outputting things to stdout. I found it really hard to bring the GHC API under control. Eventually, I just gave up.

ats-examples

ATS is a fascinating C-like programming language with linear types and proofs, it has linear memory management (track malloc/free’s), among other features like unpacked data, and tail recursion, and macros. It could have been Rust before Rust. But its author, Hongwei Xi, didn’t do the best job of presenting it well. I made these examples based on reading the book.

carvo

Part of a “Maker Space” place, we wanted to make some visual representation of poetry, so I made this one which “handwrites” Poe’s The Raven.

2013

z

I wrote a post called z and accompanying source which demonstrated an idea that a language could be built upon a macro system which is based on indentation rather than delimiters like ( ) or [| .. |]. I still think it’s a fun idea, because it has unlimited extent. I might return to it one day.

ini

Back before YAML took over, there wasn’t a winning configuration format. XML had lost its lustre. So I wrote ini, which parsed the simple INI format.

Since, YAML is now de-facto standard (although TOML is floating around), so I stopped using this.

pure-io

A small project called pure-io that provided a little IO monad that would run as a pure function. I used this for tryhaskell.org.

god-mode

After suffering from RSI for a while, I had decided with Emacs I’d look at my typing with statistics. After a week or so of full day typing every day, I found that I made a significant proportion of key chords in succession. I evaluated vim modes and realised that they depart from Emacs quite a bit or lacked a story for many modes. In the end I had the thought to make the Ctrl implicitly on all the time, and this turned out to be undeniably productive and practical in the form of god-mode.

I’m still using it to this day, although it has been folded into my Emacs config.

structured-haskell-mode

In similar themes to god-mode, I made a structured editor for Emacs’s haskell-mode that would essentially let one edit Haskell code like paredit. That used a Haskell parser via haskell-src-exts, and produced a set of s-expressions for Emacs to convert to a set of markers. The minor mode was called structured-haskell-mode.

haskellnews

haskellnews was a simple web app to list all the sources of blogs, posts, tweets, etc. about Haskell. I sort of lost interest in social Mead and therefore stopped running it. But for a while I enjoyed using it.

ircbrowse

I wrote ircbrowse at ircbrowse.net to be a replacement to the much older ircbrowse.com.

ircbrowse.com was a great web site for browsing chat logs of various IRC channels, it was also infamously slow as hell. So a fundamental motivator was to make something that would be instant, and I succeeded on that, much to my personal pride.

It could handle about 30 million lines of chat across a few channels for about 10 years of logs. There were something in the order of 30k lines of chat from the #haskell channel per month.

I stopped running it after I lost interest in IRC, but it was a very satisfying project and I learned a lot about PostgreSQL’s performance characteristics in the process.

snap-app

snap-app was my small library to wrap the Snap web framework (for Haskell), with an MVC structure, so that there would be Model and Controller monads, and some associated functions.

After that, Snap became irrelevant and Yesod remained the only real web framework for a while.

cabal-sign

There was an old discussion in Haskell about signed packages. So I made a demo tool called cabal-sign which, given a .tar.gz, would sign it, and then inject the signature into the .tar.gz. It was never used by anyone, but it did contribute to a discussion.

2012

sourcemap

For fay, I thought it’d be good to include sourcemaps, so I wrote this package as a more or less line-by-line translation of the reference implementation. The spec itself was very informal. It worked, though, and performed fairly well.

fay

I wrote a language called Fay, which was a Haskell without type-classes that compiled to JavaScript, and used GHC’s type system for the type-checking.

It ended up being quite popular, it garnered its own organisation, and I had a co-maintainer called Adam Bergmark, who was very nice and smart.⁶

I was invited to and went to a conference in Lisbon to give a talk on it.

FP Complete used it for their IDE which was a web based Haskell IDE, which is pretty much how I got the job at FP Complete in 2013. A couple years or so later, after the IDE project petered out, we stopped using it. There were better options by then (PureScript, etc.).⁷

• Blog post

scrobble

Like many people, I used Last.fm/Audioscrobbler, and would ‘scrobble’ all my music listens to the service, and get back in response recommendations. I wrote a Haskell library to do it. It’s irrelevant these days, nobody scrobbles.

bdo

This Emacs library permits one to update .js/.css files in the browser live. This predates many “modern” tools like Vite or whatever. I don’t use it these days, because all web programming exists inside of a build system. But there was a glorious period in which that wasn’t the case.

2011

numbergeddon

I wrote a fun game called Numbergeddon, on the basis that one could rote learn arithmetic by typing it. I think I got inspiration from games at the time that involved typing out words to destroy ships, in order to practice touch-typing.

pdfinfo

This utility package just launches pdfinfo and parses the output. I needed it for work at the time.

chrisdone-xmonad

I was using xmonad in 2011, hence my config of course was published on GitHub. Like your Emacs config, it’s traditional to publish your XMonad. I don’t use tiling window managers anymore. But XMonad is a good one.

flo

I wrote a small tool that would let you annotate your source code and project a flow diagram, called flo. This could still be used today with relative ease, I think. It’s language-agnostic. I never advertised it, though.

freenect

I bought a Kinect, which was Microsoft’s XBox camera/infra-red-distance viewer hardware. There were C libs, so I wrote Haskell bindings to it and called it freenect. There were some fun things I made with it.

hulk

I wrote an IRC server for use at work for us to chat on. We used it for some years after we all left, until we eventually migrated to an app called Wire (also written in Haskell).

This was my first proper experience using threading in Haskell and working on a sockets server in Haskell. I would note that architecting an IRC server in a nice way remains an unsolved problem in my head. In any language.

• GitHub archive
• Blog post

ji

I wrote a library called Ji, which is a simple concept to write a web app in Haskell that sends commands to a browser of what DOM changes to make and what events to listen to.

It was taken over by Heinrich Apfelmus and renamed to threepenny-gui, after which he added many FRP-based things and has likely rewritten all of it by this point.

pgsql-simple

pgsql-simple was my naive, although fairly successful, attempt to talk to the PostgreSQL protocol directly from Haskell, without any C library. It worked, and some people used it at work. But it was slow, and not featureful. And I wasn’t interested in maintaining it as a real, serious project, with serious users. Still, it was quite fun.

css

css is a miniature DSL letting one write CSS in Haskell. Similar to SASS and Tailwind. Nothing special, but I did use it on at least one app.

url-generic

This is a fully worked out package that would, given a type that’s an instance of Data, produce a parser/printer as a URL. No one ever used it, including myself. But it was a nice exercise.

hog

I wrote an IRC logger called hog, which I used for years on my personal IRC server with friends. There isn’t much special in here, but I used it.

2010

tryhaskell

tryhaskell.org

This was a big splash when I made it, it hit the top of some big subreddits and Hacker News. It was inspired by tryruby.org, which was made by _whytheluckystiff, the mysterious Rubyist who disappeared from the community. It runs you through an interactive tutorial about Haskell basics and checks your answers.

I’ve been meaning to rewrite this one day, but so far haven’t been sufficiently inspired to do so.

It’s been running for 14 years, which is quite a long time.

jquery-console

Written for Try Haskell, this is was dumb terminal/console-like experience in the browser using JQuery. It still works correctly to this day, on tablets, phones and computers. I stopped maintaining it as a separate package years and years ago, but tryhaskell still works fine.

lisk

I had enough hubris to think I would be able to write a Lisp syntax on top of Haskell, and called it Lisk.

I was happy with Haskell, but bummed out by its syntax compared to the beauty of Lisp. That hasn’t changed today in 2024.

• GitHub archive

2009

asp-mode

I wrote a lot of ASP and PHP in my early career, so I had a small Emacs mode called asp-mode. Nothing interesting in here, other than to note how seriously I was using ASP enough to warrant a mode, but obstinantly refused to use Dreamweaver or whatever was popular at the time. Now-a-days the equivalent would be Visual Studio Code.

2008

kibro

In 2008 I was working for a small sum on a hair salon’s new web site, in Haskell. And I made a very trivial web library called “Kibro” (from the Lojban “cyberspace”), which sat upon CGI and could be ran from PHP, which is how I was running it.

• Source code archive: kibro-0.5.0.tar.gz
• Other links: Kibro refactoring

lojbot

Around this time I was an enthusiastic Lojban hobbyist, so I wrote an IRC bot with various capabilities.

• GitHub archive
• Blog post

2006

slsk/soulski

A project for the Soulseek music sharing network. Web site, which may not remain long-term: slsk.sourceforge.net. Amusingly, it still looks great. Here’s a screenshot. Another. I started writing a C library for Soulseek: soulseek-library-0.01.zip I started writing a GUI library in C for it: exgui-library-0.1.zip I started writing a CSS parser in C for it: css-library-prototype-0.01.zip

I originally had big ambitions for this, but later lost interest. It looks like I planned to rewrite it in Common Lisp, but got bored of the project before I did.

wdn

I had a project called ‘windows desktop notes’ (WDN), that I originally wrote in C. It would overlay some plain text notes on your desktop and you could click it and get an edit box and then hit Enter to save again.

Then I ported it, or tried to, to Lisp.

Halogen is better than React at everything

Note: An LLM was not used in writing this article.

I wrote these notes in 2022, but found that they still hold up in 2024.

Having used TypeScript + React with its hooks in a code base that fully embraces them for more than a year, I return to my original assessment that PureScript + Halogen is better at almost everything.

PureScript has a sensible, type class based notion of equality, and JavaScript/TypeScript does not, and this comes up regularly, causing both logic bugs and cache invalidation issues.

Halogen components have a clear explicit reason that a re-render occurs: calling the modify function in the command evaluator. Inputs (“props”) generate a command, which means one can trivially implement custom (i.e. efficient) re-rendering conditions.

Halogen components also have a trivial, built-in way for information messages to travel both upwards and downwards, outside of the input mechanism (“props”), which is exceedingly useful. It’s all in the type signature, too.

Halogen has elegant ways to interact with foreign (non-frameworked) libraries. The built-in event streams lets you react to out of band changes (webhook, CodeMirror edits,…). The explicit life cycle and evaluation-vs-execution distinction makes the interplay predictable.

Halogen sits on an explicit effect monad, meaning you can write async imperative code with the same syntax as synchronous imperative code, and know the difference at the type level. It’s harder for things to go wrong.

In contrast, in React everything is hard and experienced users are regularly baffled. Re-rendering, caching, execution of effects, lifecycle, message bubbling and broadcasting, state, are all marvellously unhelpful by comparison. Asyncs make things even worse!

TypeScript’s type checker regularly falls over, its inference is brittle in ways that interrupt work, type errors unhelpful, union types only make things harder. It doesn’t even have sum types. PureScript’s got all these basic things and were pretty well done from the start.

All in all, my conclusion is that TypeScript + React is a bad investment. It will cost you in dev time, bugs, maintenance, performance. Generally, I think the SPA trend is broadly misapplied, I prefer something like Htmx these days, but if I’m playing the SPA game (lower latency GUIs), there are far better tools out there.

If you know Haskell then PureScript is better than TypeScript at everything, and isn’t a dead-end like Elm. For full context on Haskell frontend, see my other post Client-side web programming in Haskell: A retrospective.

Reports of RSS/Atom’s death are greatly exaggerated

Note: An LLM was not used in writing this article.

I’m not old, but I remember when people said “my web log.” That then became “blog.”¹

I subscribe via a feed reader² to a collection of individual blogs, and a few aggregators (but only the top posts of the week).

This strikes a good balance of interesting reads (mostly technology and programming related), and keeping my finger on the pulse of what the tech world is excited about (big data, IoT, NoSQL, cloud, VR, crypto, AI, insert trend du jour here).

It also means I only have about 30 or so new posts per day appearing in my feed, and they can be flicked through in a few minutes. I’ll bookmark ones that sound interesting to read for when I’m at home and sitting comfortably. “Screen time” and FOMO are not problems for me.³ I can also setup filters for bullshit content mill authors.⁴

However, about once a fortnight–on my RSS feed–I regularly see a post debating why RSS has died, or why it’s making a comeback. There’s usually related discussion about adoption, the user experience, or corporate interests (Google Reader, or $popular_newspaper).⁵

For people who digest things over a course of days or weeks, rather than doom scrolling and posting their knee-jerk reactions, the situation for a very broad set of people is that RSS/Atom is in the background doing what it’s supposed to. No VC-backed endless growth, or decline.

Feeds continue to serve their modest purpose.

For people lamenting the death of Google Reader, or that Mozilla dropped the built-in feed icon and reader from Firefox: don’t. Be thankful that the Great Eye of Business has lost interest in RSS and does not want to meddle in it anymore.

Hell: Shell scripting Haskell dialect

Note: An LLM was not used in writing this article.

Hell is a shell scripting language that is a tiny dialect of Haskell that I wrote for my own shell scripting purposes. As of February, I’m using Hell to generate this blog, instead of Hakyll.¹

Update: As of 3rd Oct 2024, I’m using it on various large (2k line) scripts at work in combination with Terraform and various APIs.

#!/usr/bin/env hell
main = do
  Text.putStrLn "Please enter your name and hit ENTER:"
  name <- Text.getLine
  Text.putStrLn "Thanks, your name is: "
  Text.putStrLn name

My 2024 New Year’s Resolution is to write more shell scripts in the name of automation. I’ve always avoided this because of the downsides of bash. And other problems.

Bash, zsh, fish, etc. have problems:

• They’re incomprehensible gobbledegook.
• They use quotation (x=$(ls -1) ..) which makes it easy to make mistakes.
• They lean far too heavily on sub processes to do basic things.
• Therefore things like equality, arithmetic, ordering, etc. are completely unprincipled. Absolutely full of pitfalls.²³

But, bash does have some upsides: It’s stable, it’s simple, and it works the same on every machine. You can write a bash script and keep it running for years while never having to change any code. The code you wrote last year will be the same next year, which is not true of most popular programming languages. Look at Haskell.

So in the interest of defining a language that I would like to use, let’s discuss the anatomy of a shell scripting language:

• It should be very basic.
• It should run immediately (no visible compilation steps).
• It should have no module system.
• It should have no package system.⁴
• It should have no abstraction capabilities (classes, fancy data types, polymorphic functions, etc.).
• It should not change in backwards-incompatible ways.⁵

Why no module or package system? They make it harder for a system to be “done.” There’s always some other integration that you can do; some other feature to add. I’d prefer Hell to be cold-blooded software, there’s beauty in finished software.

Based on the above, I can define a scripting threshold, meaning, when you reach for a module system or a package system, or abstraction capabilities, or when you want more than what’s in the standard library, then you probably want a general purpose programming language instead.

Taking this into consideration, I opted for making a Haskell dialect⁶ because of the following reasons:

• I know Haskell.
• It’s my go-to.
• It has a good story about equality, ordering, etc.
• It has a good runtime capable of trivially doing concurrency.
• It’s garbage collected.
• It distinguishes bytes and text properly.
• It can be compiled to a static Linux x86 binary.
• It performs well.
• It has static types!

I made the following decisions when designing the language:

• Use a faithful Haskell syntax parser.
• It’s better that way; you get re-use.
• It has no imports/modules/packages.
• It doesn’t support recursive definitions, but you can use fix to do so.
• It supports basic type-classes (Eq, Ord, Show, Monad), which are needed for e.g. List.lookup and familiar equality things.
• It does not support polytypes. That’s a kind of abstraction and not needed.
• It use all the same names for things (List.lookup, Monad.forM, Async.race, etc.) that are already used in Haskell, which lets me re-use intuitions.

You can download statically-linked Linux binaries from the releases page. To read about the implementation internals, see Tour of Hell which is a set of slides I made for presenting Hell at work.

A spectrum of web dev abstraction

Note: An LLM was not used in writing this article.

There’s a spectrum of web dev with two sides:

1. Abstraction: blur the lines between client and server, pretend you’re writing an offline desktop app with no server, no latency, no RPC calls, etc. as much as possible. Poster child: React.

2. Non-abstraction: write code like it’s the 90s. Admit there is a server, use GET/PUT/DELETE/POST end-points, that serve HTML, use <form>, etc. Poster child: Htmx.

Over 10 years,¹ the more I have done (1), the more I’ve regretted it and wished I’d done (2).

Codebases and love

Note: An LLM was not used in writing this article.

Returning to Theory Building (by Peter Naur), and why rewrites are inevitable (developer/maintainer churn = loss of theory), I have a related thought: In the spirit of “a face only a mother could love”, most (if not all) code-bases larger than a page are inherently unlikeable to anyone but the original author, and absent said author, are doomed to be rewritten, either entirely or in part (Ship of Theseus style), or abandoned, as quickly as is possible.

AI and Machine Thinking

Note: An LLM was not used in writing this article.

AI might take our jobs. That’s bad for us, just like it was for the Luddites.

But I think Herbert had it right when he, through his Dune books, proposed that the problem with “machine minds” is not the machine itself, it’s “machine thinking” which humans are perfectly capable of.

Related quotes from the books:

What do such machines really do? They increase the number of things we can do without thinking. Things we do without thinking — there’s the real danger. (Leto Atreides II)

“The target of the Jihad was a machine-attitude as much as the machines,” Leto said.

The brutal, uncompromising, inflexible, tyranny of, as Little Britain condensed it, “the computer says no.” I’m more afraid of the encroachment of this chilling effect in my life than losing my job.

Pickling: The really obvious missing feature of all web browsers

Note: An LLM was not used in writing this article.

Browsers already provide an excellent delivery mechanism for single page apps. Web apps already have a security model around accessing local files, microphones, webcams, etc. It’s better than anything on macOS, Windows or Linux and any phone’s App Store: you can just run an app instantly and anyone can publish.

The only thing browsers lack is the ability to freeze the page and cut off its internet access, so that the user can block auto-updates and spying. If a web page’s contents can be hashed and pinned, Nix-style, it can be tracked by a community and rated.

Why can’t I download an encryption app or a todo list app on my browser and just use it, without worrying about trust issues and needing an internet connection?

I’m surprised I haven’t seen this discussed at all anywhere. If you’re working on this please email me.

Tamagotchi tooling

Note: An LLM was not used in writing this article.

Remember those tamagotchis that were popular in the early 2000s? Little devices with a screen showing a pet that needed constant maintenance; cleaning, feeding, petting, etc.

Some tools are like tamagotchis. They’re a tool, so they have some use. But that’s not all, they also require substantial upkeep to not break down, and the owner takes some pleasure in the process. It’s no surprise when they fail, it’s part of daily experience.

Other tools are more like an old digital watch. They show the time and don’t require any upkeep at all, are robust, and they work for ages. They’re so reliable that the owner takes them for granted, and it’s a shock when they fail. They require no “updates.”

Sometimes, it’s easy to confuse usefulness of a tool with the enjoyment derived from its upkeep. That can lead to reasoning violently. A project that sometimes needs the old digital watch can plod along sluggishly when a tamagotchi is used instead.

The trick is being able to tell the difference.

Reasoning violently

Note: An LLM was not used in writing this article.

The old bash.org joke goes, “XML is like violence, if it doesn’t solve the problem, just use more.”

This generalises well. I’ve seen a lot of people choose to continue using tools that are obviously running counter to their ability to get work done, even almost paraphrasing the above, but without irony!

It seems to apply strongly to formal languages (XML, Nix, Terraform, Kubernetes YAML), some architectures (microservices, the cloud, SPAs, OO), and type systems (dependent types, effect systems, the borrow checker), and methodologies (scrum, open source). All quite good used in moderation, but tend to be used like violence.

All downsides become mere setbacks, all potholes become user error or ignorance, alternative hammers are black holes of complexity! It’s quite hard to reason with people who are doing this. O ye, of little faith!

That’s reasoning violently.

Three questions of language design

Note: An LLM was not used in writing this article.

There seem to be three interesting questions when I look at a new (mainstream/practical) programming language:

1. How does it deal with equality/ordering?
2. How does it deal with arithmetic and operators for the arithmetic?
3. How does it handle errors?

The typical answers in reply are (1) inconsistently, (2) it’s magic, (3) at least two, incompatible, ways.

Things I’ve changed my mind about

Note: An LLM was not used in writing this article.

Here’s a small blog post to end 2022. I’ve put together a list of things I’ve changed my mind about over the past few years, since the epoch (covid). I’m likely to flesh out each of these in future posts.

Things I have a new appreciation for:

1. Excel
2. Rich Hickey
3. Model checkers, TLA+
4. Federation
5. Kubernetes
6. Email
7. Alan Kay
8. REST/Hypermedia
9. Go
10. RSS, blogging
11. Error handling in Erlang
12. Code vs data

Things I view more negatively:

1. Product types (as opposed to record types)
2. Static types, dependent types
3. Haskell and Haskellers, Rust
4. The cloud and SaaS
5. Fat clients/ the SPA
6. React
7. macOS: it isn’t that great
8. Open source, copyleft, GitHub
9. “Performance is easy”
10. Kubernetes (yaml)
11. Modules
12. Effect systems
13. Twitter, and microblogging

New things I believe/in:

1. Longevity in software
2. Stability in packages
3. Content Addressable Storage, Unison
4. Conservativism
5. Parsimony
6. Common Lisp is valuable because it does everything it does, without ever changing or evolving.

Things I still believe/in:

1. Emacs reigns supreme
2. No-code isn’t good
3. Nix is not ready yet

Inflex

Note: An LLM was not used in writing this article.

Inflex® was a new creative digital workspace: powerful functional language (Haskell-inspired), rich data structures (no grid!), browser-based.

Inflex was a project that I had been working on in my spare time, along with my partner, Giulia Costa, for 2 years. Progress ground to a halt when I had a kid.

I’m no longer working on it.

There is an archive of its source code available under AGPL (that means running it as a service counts as distribution) license:

• https://github.com/chrisdone/inflex
• https://git.sr.ht/~chrisdone/inflex

The compiler source might be of interest to language implementation nerds.

You can checkout the [dead] Twitter account InflexHQ feed for screenshots, videos.

Related posts where you can get more of a feel of where my head was at:

• The language of spreadsheets is bad
• What’s wrong with the grid?
• Bibliography
• Tech talk slides - these are very technical.

Immutable Publishing Policy

Note: An LLM was not used in writing this article.

Summary

This is a policy for publishing Haskell packages. It was published in February of 2022. The aim of this policy is to remove all breaking changes to downstream users of packages, where feasible. It is most applicable to packages which have users, and/or have a more or less stable API. It prioritizes downstream users at the expense of author convenience.

It has been implemented in the lucid package.

Terms

By “levels” in this description, we mean “module” is the first level, and “package” is the level above.

Rules

• If you require more, that’s a break.
  • E.g. adding an extra field to a record or requiring a class constraint, add an extra constructor which users can pattern match on, or another package dependency or newer major version of a package that wasn’t needed before.
• If you provide less, that’s a break.
  • E.g. if you remove an export or a field of a record, return less or different from a function, remove a module, or an instance of an exposed type.
• If you change something, that’s a break of the next level up.
  • E.g. if you change the type signature of an exposed function, or change a data type’s definition which is exposed.
• If you just add something, then just bump the minor version (which is the only thing that changes in this scheme) of the package; you can use the current date e.g. 0.0.20210101.
  • E.g. a non-orphan instance of a type from your own package.

Haskell-specific note:

• If you add an orphan instance in your library–which you should not do–that’s definitely a breaking change for the whole package, bump the package.
• A user may have written an orphan instance for one of your types, but this is a departure from standard practice, and therefore isn’t protected from breaking change. You should feel free to add new instances for your own types.
• Be careful about leaking instances. If you bump your package when you bump your dependencies major versions, then you should be safe from this.

Steps

This differs substantially to the PVP. ⚠️

• If you want to change a thing foo, just make a copy of it and call it foo2.
• If it’s impractical to add another version of a thing (because, e.g. you changed a class or a data type that’s used in many places), then copy the whole module Foo to Foo2.
• If it’s impractical to just copy a module, then it’s time to copy the package, foo to foo2.
• If you want to rename or remove something from a module, clone the module. If you want to remove or rename a module, clone the package.

Rationale

• It’s more effort for an author to make breaking changes. The author pays a price, and has to think twice about whether it’s worth it.
• The user optionally pays a small price to upgrade to new functionality, rather than a mandatory tax for changes they don’t want, which is the PVP system.
• For more elaboration, watch Rich Hickey’s video Spec-ulation.
• Related mantra of the Linux kernel: don’t break user-space
• I don’t agree at all with this post by ezyang

Long-term steps

• You can publish additions to your old versions of modules and packages.
• You can choose to stop maintaining them at some point. For example, a duplicate module hierarchy. You can just drop the old one and publish a new package.
• By the PVP, packages that use your package will force their users to use your newer API, which will make them unhappy. By following the IPP, you give your users the chance to import both library versions and maybe write some migrations between the two versions.

Infrastructure/technical support

• Hackage supports deprecating a package in favour of something else. That’s your means to tell users of newer versions.
• GHC lets you mark declarations and modules as deprecated, which is issued as a warning.
• Users can use module Lib (module Lib2) where import Lib2 to try newer versions of module hierarchies as “drop-ins”.
• For a package following the IPP, you can just depend on package >= 0.0.n where n is the feature that you need. You never need an upper bound because there are no breaking changes.
• Both Hackage and Stackage will allow you to upload package1, package2, etc. and so your users can continue to use the package1 if they’re not interested in package2, and if they’re not forced by PVP-following maintainers of other packages that they’re using.

Compatibility with the PVP

You can do both, the IPP is a subset of behavior within the PVP (but upper bounds aren’t required or needed by the IPP). In practice, people following just the PVP and not the IPP will be a pain for you as Haskellers change things and cause breakage all the time. But don’t bother people about it. Just do your best.

When to use this policy

I propose that you should:

• Put new experimental packages on GitHub/GitLab/sourcehut, etc. and using Stack or Cabal you can specify dependencies on that package by a commit hash. At this stage, authors can change as much as they want and users can pin to commits.
• If your design becomes stable and you want to support the package, put it on Stackage or Hackage. Now apply IPP.

For packages already published, you can apply IPP immediately.

FAQs

Do you just want Unison?

Sure, but that’s a whole new language. Haskell is our language of choice, so let’s do our best to make it nicer to use.

It’s not worth doing because we should have machines automate dependencies based on fine grained uses

That’s true. Here in the real world, however, no such automation exists.

Security fixes can be breaking changes, we should make bad code go away

You don’t know how and in what setting your users are using your libraries. It’s not your place to bully them into changing their programs because you know better.

Shouldn’t old code be garbage collected?

Yes, I covered deprecation above. I also covered removing old code and the ending of maintenance above.

What if I add a constructor to a type? I’d have to duplicate my whole API!

Yes. If you add a new constructor then you’ll indeed require more of the consumer of your package to form a complete pattern match. Duplicate the type. You changed a namespace.

I’ll repeat myself: the IPP is about valuing the user’s time over the maintainer’s time. It’s not all about you and your needs. Think about others who have to consume your work.

Even the containers package authors plan to remove old names, despite there being no reason to do so.

Why have package versions when you are going to duplicate an entire module or package when you make a breaking change?

I already covered this above, but let’s rewrite in a different way: Package versions in Haskell are broken. They force all package maintainers to move in lock step. You can only practically use one version of a package in your installed package scope.

If you want to keep using foo-1.2.3 and another package you’re using wants foo-2.0.0, you shouldn’t be forced to change all your code. You should be given the option to migrate between them.

A plain English description of monads without Haskell code

Note: An LLM was not used in writing this article.

“That’s actually the first time I read an explanation about monads that I understand.” – Commenter

“I just read your explanation, and suddenly I think I understand monads.” – Reviewer

Monads are notorious in the programming world for their use in the Haskell programming language and for being hard to grasp. There’s even a joke that writing a “monad tutorial” is a rite of passage for new Haskellers, and been described as pointless.¹ I’ve been using Haskell for over a decade and have refrained from writing yet another monad tutorial.

A friend asked for an easy explanation of them that doesn’t involve Haskell code.² That’s easier.

You can re-use your intuition from existing common place chaining of things in other popular languages:

• Async chains (JS)
• Parser combinator chains (Rust, JS)
• Optional or erroneous value chains (TypeScript, Rust)
• Continuation passing style (you can do this in Lisp and JS)
• Cartesian products/SQL (C#’s LINQ)

One of the Haskell designers³ in the 90s just came up with a class/interface that worked for all of these. As he was into category theory, he related it to the idea of a “monad”. The types also sort of match the theory if you squint hard enough.

Then they came up with a syntax (actually, two⁴) that was syntactic sugar for calling the class methods to make it feel more ergonomic.

Parsers, CPS, async, optional chaining, all look more or less like this in most modern popular programming languages:

getThing.and_then(x => putThingElsewhere(x+4)).and_then(..)

For a parser you track the position in the string and plumb that through. For an “optional” it just short circuits if the left hand side of and_then is nil/null/undefined. For async it would do something async, like make a web request to get the thing, and then call the callback, etc.

Monad is the name of the class for “and_then”,⁵ defined in a sensible way, with some laws for how it should behave predictably, and then a bunch of library code works on anything that implements “and_then”.

Apart from F# or Haskell (or descendants), no other language⁶ embraces the abstraction with syntax so it’s hard to find a good explanation without them. It’s like explaining Lisp macros without using a Lisp, the explanation tends to be awkward and unconvincing.

If you have mutation, you might not bother plumbing stuff for a parser, you might just update the position in place, and throw an exception on a parse error. If your language supports returning early from functions then you can just use that to short circuit (Rust does this). If your language puts in a special case for async with “await” syntax (JS, Rust, C#), you’ll just use that. Other ways of doing things just make the idea of a monad abstraction kind of unnecessary.

Haskellers don’t like to throw exceptions, or use mutation, and functions can’t return early, etc. Suddenly Monad and syntactic sugar for it looks pretty attractive to them.

Thoughts on type class implementation

Note: An LLM was not used in writing this article.

While designing and implementing Inflex, I discovered that there’s a lot of space in design decisions around type classes. Haskell’s implementation of them has a number of pre-made decisions built into Haskell 98. Many extensions (multiple type params, functional dependencies, associated types) have been added to support type level programming since then. Inflex’s needs are more modest.

Oleg Kiselyov has shown that in practice you only really need one type class, with clever use of instances. So you could imagine that a language with just a single type class and open instances would be called ClosedClassOpenInstances.

You might not permit new classes and instances, only built in ones. So an alternative language might be called ClosedClassesClosedInstances. A language that would benefit from this would be Elm.

I decided not to support multiple methods for a single class. This makes the feature more like “generic functions.” For any multi method class in Haskell, I can often find a type that would be an instance if it weren’t for one method.

Another consideration is whether to permit superclasses. Haskellers are very tempted to make class hierarchies. People like Don Syme would argue that this urge leads nowhere good. Haskell’s own Prelude has a very questionable hierarchy. I decided against superclasses too.

Elsewhere there are other surprises. A really simple compiler like Inflex goes through stages like this:

• Lex, parse, rename
• Generate constraints (elaboration)
• Solve constraints
• Generalize (insert poly types)
• Resolve (resolve class method calls to instances)
• Defaulter

This is reasonable enough. Very easy to understand each stage.

But there’s a non-obvious limitation in this approach which is that if you want to support instance contexts, then, after resolving an instance, you need to add the constraints from the context, and then go back to solving constraints again. Inflex doesn’t support instance contexts, but if it did, it would need a different pipeline.

There’s a bunch of papers about type classes, especially getting inference to work well for them. Other things like instance chains as implemented in PureScript are also a departure from Haskell.

I’ll write more another time with more code examples.

My negative views on Rust

Note: An LLM was not used in writing this article.

2023-10-13: Edited based on feedback, but preserves the same opinions.

This is a little summary of my current thoughts on Rust. I wonder whether I’ll look back in five years and see if my views have changed.

The Good

So that Gentle Reader knows that I’m not entirely biased against the language, there are obviously positive things to appreciate about it:

• Rust’s macros are very good. They act like Lisp’s macros, unlike Haskell’s.
• The fact that Rust has type-classes (“traits”) and sum types (“enums”) and pattern matching is very attractive. Making orphans package-wide rather than module-wide is a very good decision.
• I like its treatment of records.
• Its standard library does a few things well, like handling strings as UTF-8.
• Distinguishing mutability has its advantages, it’s easy to see that a function is “morally” pure–if not actually pure–and that’s good for reading.

Unsafe and panic

The use of unsafe is a little disturbing, because many libraries feature it, and people are tempted to use it on private work projects to quickly get around the language’s limitations. But it’s not much different to using an FFI. I don’t see this is a big downside.

panic is a little more bothersome, because Rust libraries go to great pains (with many syntactic tricks like ? and auto-conversions from smaller error types to larger ones) to handle errors explicitly, but then panics unwind the stack to the top of the process, and panics inside a panic don’t run destructors, etc. The overall effect is that, like my three questions of language design, the answer to “how you handle errors” is “at least two, incompatible ways.”

Take Sugar?

Rust’s use of magical sugar constructs, where the compiler will automatically insert dereferences and copies and drops for you has an initial appealing “it’s all simple underneath” quality to it, but in practice this leads to bad compile errors: The worst kind of compile error is the one where the compiler is complaining about something that it generated for you, rather than something you explicitly wrote.

This can be compared with Haskell’s use of monads, that provide syntactic sugar. The more magic you introduce, the harder it is for newbies to learn and to talk about.

Fetishization of Efficient Memory Representation

I’ve watched people on calls that are a couple years into Rust spend 20 minutes attempting to understand why their perfectly reasonable code doesn’t fit into Rust’s tight memory restrictions.

I’ve also been Rust-splained, by people with white in their hair, with an air of misty-eyed revelation, that once you “get” Rust’s memory model of the stack and the heap,¹ that things just all fit together wonderfully. There’s nothing wrong with that, but it’s a theme.

This touches on another topic I’d like to write about elsewhere: the difference between practice and theory and how users of languages like Rust and Haskell that make big promises and require big sacrifices don’t seem to distinguish the difference. It’s not the technology that’s working poorly, it’s that you’re using it wrongly.

In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler. I predict that tracing garbage collectors will become popular in Rust eventually.

This is both Rust’s main goal–be like C, no garbage collection,² but safe–and also its main downside. People waste time on trivialities that will never make a difference.

The Rewrite Fallacy

I see a lot of “we rewrote X in Rust and it got faster” posts. I think that if you rewrite anything from scratch with performance in mind, you’ll see a significant performance improvement. I’m suspicious of how much Rust itself is needed versus the developers having some performance discipline.

Complexity

Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest. Go was designed as the antidote to this kind of endlessly increasing language surface area. Endless libraries re-treading existing patterns (web services, parsers, etc.) in Rust. As a long-term Haskeller, I’ve done more than 15 years of riding a hamster wheel like that. It is fun for a while, but at some point I grew tired of it. This aspect of Rust puts me off. I don’t need another tamagotchi.

The “Friendly” Community

All new language communities are nice. When things don’t matter much, people have no reason to get mad.

As soon as people have a stake in something, that’s when things heat up and tempers come out. You get a stake in a programming language by writing a lot of code in it, or by building a business on it. When you have a stake in how a language works, you’re highly sensitive to changes that will make you do more work than needed, or will limit your goals.

I’ve seen this play out for Haskell. Around 2007, when I started with Haskell, the community was friendly as anything, evangelic, open. People praised it for this. Everyone just felt blessed to be able to use this exciting language. Today, it’s more like any other community. What happened? People started using Haskell for real, that’s all.

Rust is going through the same thing, much more rapidly. Is it a reason to avoid Rust? No. But a “nice” community isn’t a reason to join an upcoming language, either.

Since I wrote this, people are already trying to fork Rust because they’re not happy with the governance of it. This doesn’t mean anything deep other than that people are using Rust now, as stated above, and the “friendly, welcoming” starts to become mixed with more diverse moods and motivations.

Async is highly problematic

Rust’s choice to exclude a runtime/scheduler blessed and built-in to the language means they had to develop alternative strategies in the language itself. This is not turning out well.

Coloured Functions is a powerful metaphor for the incompatibility between async and synchronous functions and the awkward situations that mixing them introduces. Some blog posts have attempted to downplay the situation by focusing on technical aspects of specific syntactic forms. That doesn’t really matter, though, because the reality is much simpler: Async code is easier to use when dependencies are in an async form.

People will choose libraries that are async over libraries that are not. However, maintainers that have written good, maintained code, are also resistant to adopt async.

• One conversation I’ve overhead:

  Person 1: Another difference between diesel and sqlx is that diesel is not async yet and from looking at the issues it doesn’t seem to be priority yet.

  Person 2: That sounds like a major issue

As the saying goes, the proof of the pudding is in the eating of the pudding. Async introduces long, heated discussions.

The problem for Rust is that its users want a runtime, but want the option of not having one. The result is a mess. When combined with iterators, I think understanding such code is quite difficult.

Generally, I think Go, Erlang and Haskell are the better choice here for general purpose use. A tracing garbage collector and green threads make programmers more productive for general purpose programming (not systems programming). Which brings me to the next section.

As a general purpose language

I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things.

This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for.

This post still offends many who have tied Rust to their identity, but that’s their problem, not mine.

Conclusions, if any

I won’t be using Rust for any of my own personal projects for the above stated reasons. But it was used at my job at the time of writing, so I felt the need to express myself about it.

But I wouldn’t mind using it as a replacement for single-threaded C if I just use the standard library, that might be fun, although I don’t do any embedded work, so I wouldn’t hold my breath.

I think that the excellent tooling and dev team for Rust, subsidized by Big Tech, pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in. There’s danger in that type of thinking.

Inflex Bibliography

Note: An LLM was not used in writing this article.

Direct influences

• Why do we need modules at all?
• Polymorphic variants
• Behaviors of Reflex
• Ray Panko’s work on spreadsheets and bugs
• Pain We Forgot
• Haskell (classes, pure)
• Duet (stepper)
• PureScript (row types)
• Unison (CAS code)
• Clojure
• Type classes vs the world (coherence)
• Simple made easy (names over positioning)
• Spec-ulation (specifically, dependencies)

Reading list

• Haxcel
• Streaming spreadsheets
• Smalltalk spreadsheet
• Implementing VisiCalc - some things in Inflex coincidentally match VisiCalc’s original design: @func for functions, fixed precision numbers
• Excel will never die
• The trouble with typeclasses

Consulted

• Stepping OCaml
• Typing Haskell in Haskell
• Type Inference with Polymorphic Recursion
• A reckless introduction to Hindley-Milner type inference
• Type classes: confluence, coherence and global uniqueness
• Haskell with only one typeclass
• Algorithmically Scrapping Your Typeclasses

Similar space research projects

• Mesh
• Gneiss
• Plutojl
• Apogee
• Bubble Pop!
• Ravi Chugh’s work (Sketch-n-Sketch, Ivy)

Vaguely similar market products

• Mito
• Bamboo
• Blockpad
• CubeWeaver
• Livebook
• Coda
• Rows (previously dashdash)
• Grid
• Ellx
• Baserow
• CloudTables
• BaseDash
• SeaTable
• Casual
• Grid Studio
• Patera
• Visor
• AirTable
• Lido

Dead products

The irony of some of these link names is not lost on me.

• https://ethersheet.org/
• http://getpermanent.com/
• https://stenci.la/stencila/blog/introducing-sheets/spreadsheets-are-dead-long-live-reactive-programming-environments-
• http://dtab.io/
• https://www.herculus.io/ (Haskell spreadsheet)
• https://www.resolversystems.com/

The Movement Principle

Note: An LLM was not used in writing this article.

A language design principle I wanted to highlight in a page of its own is what I’m calling the movement principle.

In particular, for statically-typed languages, type-classes are what I have in mind for this post.

Type-classes

We can write a piece of code like this:

thing = 'a'
example = length (show thing) * 2 + 7

There’s a type for this example expression: Int

The language compiler infers that. Some observations:

• The operators * and + are generic functions that will work on any numeric type.
• The length function returns the length of a sequence as a specific Int type.
• The show function is a generic function that will show a value as a string.

Now I can perform a step to move this logic out of this function into its own:

thing = 'a'
example = work thing
work x = length (show x) * 2 + 7

There’s a type for work, too: Show a => a -> Int

The language compiler infers that too. That means: the input is a and, by the way, it has a constraint that there’s an instance of the class Show for that a, and the output is Int.

We can do it again. Let’s move the arithmetic to its own function:

thing = 'a'
example = work thing
work x = arith (length (show x))
arith n = n * 2 + 7

There’s a type for arith, too: Num a => a -> a

The language compiler infers that too. As above, this means: input and output is a type a that is an instance of Num (numbers).

What’s going on here? The type system is saying: I don’t know which instance to use for this function, so I’m going to make it someone else’s problem and throw a constraint on the type. Job done.

This is what I’m calling “movement”. I can move my code freely and there is still a type for the code and the compiler will accept it.

Type-directed name resolution

If we suppose that instead of type-classes we had type-directed name resolution, such as seen in Idris, or C++ (function overloading), we run into a problem at the first step. Consider an imaginary Haskell where operator overloading is achieved via this mechanism instead of type-classes:

n :: Int
n = 1
example = n + 5

If we imagine that + is one of many functions called +: one for Int, one for Float, etc. and then the compiler picks which one you intended based on the type, then it can see n is an Int and then pick the right + which has type Int -> Int -> Int.

However, if we try to abstract this:

n :: Int
n = 1
example = oops n
oops x = x + 5

What is the type for oops? We can’t give one, because we don’t know which + is intended. We don’t know what the type of x will be. So this is a compile error. At this point we’ve interrupted the programmer with an awkward problem.

This is a very leaky abstraction. I can’t even move code.

Exercise

Here’s an exercise. Try this in your statically-typed language of choice. If you can use overloading of some kind in an expression, and then abstract the generic part of it into its own function, then your language’s overloading satisfies the movement principle.

Summary

There are many factors that go into making a language let you move code easily. One is making everything an expression, rather than distinguishing between statements and expressions, for example. Another is to avoid things like move semantics and ownership as seen in Rust, which puts a lot of friction on moving code.¹

I think type-classes are overlooked in contributing to this quality in a language. They enable generic programming, but in a way that preserves the movement principle.

What’s wrong with ImplicitParams

Note: An LLM was not used in writing this article.

Implicit parameters, enabled by the ImplicitParams extension in GHC, often come up in Haskell discussions,¹ with the statement that they’re so convenient, yet nobody² seems to use them. Why is that?

The problem is incoherence. Type class resolution works in a very binary way: either it finds one, singular instance with one behavior and we compile, or it finds none at all and we don’t compile. It’s never³ the case that changing our code will change a resolved instance. I can change my import list, or update my type-signatures.

Incoherence breaks this guarantee. Implicit parameters rely on incoherence to work, because they piggyback on the type-class machinery with magical instances that appear as needed.

Let’s see an example of how this leads to surprising results. The two declarations below produce different results.

> let ?myparam = 123 in terror
(123,123)
> let ?myparam = 123 in horror
(123,456)

Check out the code and find the reason why.

{-# LANGUAGE ImplicitParams #-}
horror :: (?myparam :: Int) => (Int, Int)
horror =
  let result :: (?myparam :: Int) => Int
      result = ?myparam
   in ( result
      , let ?myparam = 456
         in result)

terror :: (?myparam :: Int) => (Int, Int)
terror =
  let result :: Int
      result = ?myparam
   in ( result
      , let ?myparam = 456
         in result)

You found it; it’s that we added a type signature to result. That changed the behavior! If you find this surprising, it’s because you’re used to coherence. In normal Haskell, an inferred type and an explicit type don’t produce different code.

Here’s another, more insidious, way to evoke the problem:

{-# LANGUAGE ImplicitParams, NoMonomorphismRestriction #-}
terror :: (?myparam :: Int) => (Int, Int)
terror =
  let result = ?myparam
   in ( result
      , let ?myparam = 456
         in result)

Try removing NoMonomorphismRestriction. The output is different depending on whether this extension is on or not. Be afraid, be very afraid.

If this constraint was Show, I wouldn’t be able to reproduce this difference, because there’s only one Show Int instance.

Implicit parameters break fundamental expectations about one of Haskell’s most basic features: its type inference. For me, this is reason enough to avoid it.

Thanks Andrew Martin for insightful discussion on this topic a few years ago.

How exactly ExceptT differs to EarlyDo

Note: An LLM was not used in writing this article.

After publishing my early GHC plugin, I saw a lot of response from people saying “Why not ExceptT?”, despite having outlined it in the README of the project. After reading some sincere responses failing to see why I bothered with this at all, it seems I haven’t explained myself well.

I’m happy for people to just disagree because they have different values, but I want to make sure we’re talking about the same trade-offs.

I think people need to see real code to see why I think this is a substantial improvement. You’ll have to use your imagination generously to raise the contrived to the “real world”.

(I’m calling this plugin EarlyDo so I can talk specifically about the syntax extension.)

Setup

Here is a module of three functions (but use your imagination to make a couple dozen), where the IO actions return Either failure a. The proposal I have been repeatedly given is to use ExceptT. I’m typically using RIO, so I define a fake one, and then use a real one later.

Basic ExceptT

To do concurrency or exception handling or any with-like thing, you need the equivalent of MonadUnliftIO to capture the current context, and then re-run the monad further in the new thread. Here we do it manually to demonstrate what’s happening.

import Control.Concurrent.Async
import Control.Monad.Trans.Except
import Control.Monad.Trans.Reader
import Control.Monad.Trans

type RIO r a = ReaderT r IO a

foo :: Int -> RIO () (Either () ())
foo i = runExceptT $ do
  _ <- ExceptT $ bar (i + 1)
  ExceptT $ zot (i + 2)

bar :: Int -> RIO () (Either () ((), ()))
bar i =
  runExceptT $ do
    ExceptT $ zot 0
    r <- ExceptT $ fmap Right ask
    (x, y) <-
      ExceptT $ lift $
      fmap
        (\(x, y) -> (,) <$> x <*> y)
        (concurrently
         (flip runReaderT r $ foo (i + 1))
         (flip runReaderT r $ zot (i + 2)))
    pure (x, y)

zot :: Int -> RIO () (Either () ())
zot i = runExceptT $ do
  _ <- ExceptT $ bar (i + 1)
  ExceptT $ zot (i + 2)

(Why am I not using ExceptT () (RIO ()) .. in my type signatures? Continue reading to the end.)

Using MonadUnliftIO

Here’s a version using MonadUnliftIO. Not that the work of unlifting has been done for me.

import           Control.Monad.Trans.Except
import           RIO (RIO)
import           UnliftIO

foo :: Int -> RIO () (Either () ())
foo i = runExceptT $ do
  _ <- ExceptT $ bar (i + 1)
  ExceptT $ zot (i + 2)

bar :: Int -> RIO () (Either () ((), ()))
bar i =
  runExceptT $ do
    ExceptT $ zot 0
    (x, y) <-
      ExceptT $
      fmap
        (\(x, y) -> (,) <$> x <*> y)
        (concurrently
         (foo (i + 1))
         (zot (i + 2)))
    pure (x, y)

zot :: Int -> RIO () (Either () ())
zot i = runExceptT $ do
  _ <- ExceptT $ bar (i + 1)
  ExceptT $ zot (i + 2)

Evaluating cost and ergonomics

What remains is the runExceptT and ExceptT calls which cannot be eliminated. Here we are unsatisfied, because all the functions in our module are using this “pattern”. A pattern is what we call repeating yourself because your language can’t abstract it for you. We pay an O(1) cost per definition, and an O(n) cost for calls per definition.

Additionally, any traverse call that is just MonadIO m => .. in the middle of the function, or logging function, will also run in ExceptT, causing a performance penalty that we didn’t want. If we want to avoid that penalty, we must use lift. But I haven’t benchmarked this. You are welcome to do so.

You pay to short-circuit and you pay to do normal actions in the base monad, and if you’re not careful you may accidentally pay extra.

Given that pretty much all of my apps have monads that look something like this, this seemed worth improving.¹

EarlyDo

With EarlyDo, we have:

{-# OPTIONS -F -pgmF=early #-}
import Control.Early
import RIO (RIO)
import UnliftIO

foo :: Int -> RIO () (Either () ())
foo i = do
 _ <- bar (i + 1)?
 zot (i + 2)

bar :: Int -> RIO () (Either () ((), ()))
bar i = do
  zot 0?
  (x, y) <-
    fmap (\(x, y) -> (,) <$> x <*> y) (concurrently (foo (i + 1)) (zot (i + 2)))?
  pure (Right (x, y))

zot :: Int -> RIO () (Either () ())
zot i = do
  _ <- bar (i + 1)?
  zot (i + 2)

A single character that appears in a not-normally-valid syntax position signals short-circuiting. Any base monad action like mapRIO (runs in RIO r) can be used without lifting or unlifting. I have to explicitly produce Right in bar, which is a cost, but not in zot/foo.

Using our own monad type

Finally, we can use our own wrapper monad:

{-# OPTIONS -F -pgmF=early #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import Control.Early
import RIO (RIO)
import UnliftIO

data AppEnv
newtype App a = App { runApp :: RIO AppEnv a} deriving (Functor, Applicative, Monad, MonadIO)
instance MonadUnliftIO App where withRunInIO = wrappedWithRunInIO App runApp

foo :: Int -> App (Either () ())
foo i = do
  _ <- bar (i + 1)?
  zot (i + 2)

bar :: Int -> App (Either () ((), ()))
bar i = do
  zot 0?
  (x, y) <-
    fmap (\(x, y) -> (,) <$> x <*> y) (concurrently (foo (i + 1)) (zot (i + 2)))?
  pure (Right (x, y))

zot :: Int -> App (Either () ())
zot i = do
  _ <- bar (i + 1)?
  zot (i + 2)

The App monad has the full power of all the previously mentioned things.

But not with ExceptT. I cannot put ExceptT in this monad stack and retain the MonadUnliftIO instance. It has no valid instance!

But you should still use ExceptT because I like it

Could the mechanics of this syntax use ExceptT underneath? Sure, but then the whole do block would be under ExceptT, and I’d have to lift the rest of the do notation too (even if it’s not necessary, incurring extra cost for no reason). Even if I could tell which statements should be ExceptT’d or lift’d, it would be overkill.

At this level, it doesn’t matter much. All you need the syntax to produce is a case expression. The use of an Early class is unneccessary, it just makes it easy to use either Maybe or Either with the same syntax.

Haskell doesn’t have macros

Note: An LLM was not used in writing this article.

I wanted to underscore a specific point about Haskell’s metaprogramming capabilities. It doesn’t have a macro system, the kind that Lispers love. It has metaprogramming, yes. But not the kind that’s useful in the same way.

What macros are

In Lisp, macros are:

1. Syntactically light-weight.
2. Don’t require writing a parser to deal with the language’s native syntax.
3. They work on trees of lexical tokens of the language; not abstract syntax trees. At best, they are incomplete ASTs.

Macros are functions that take in this tree of tokens, either atomic lexical tokens, or lists denoted by balanced parentheses, and do some transforms, and return the same as output.

foo
"bar"
123
(foo "bar" (123) nil (blob x))

Quoting in Lisp vs Haskell

In Haskell, we have GHC’s Template Haskell. What that provides is:

1. Splices: $(foo) – this syntax means: run the code foo, in the Q monad, at compile time, and it should produce a valid Haskell abstract syntax tree.
2. Quotation: [|bar|] – this means: produce an action in the Q monad which will produce the abstract syntax tree for the code bar.
3. Quasiquotation: [zot|anything|] – this means: the zot is a parser that will parse the string contents anything and produce an abstract syntax tree in the Q monad.

This code is ran at compile-time. That’s different to Lisp.

In Lisp, e.g. Common Lisp, we have:

1. Splices: ,foo – run the code to produce a tree.
2. Quotation: 'bar or '(bar abc) – quote the code, that’s all.
3. Quasiquotation: `bar or `(bar ,foo) – this is like a regular quotation, but I can place , anywhere to mean “run this code”.

The code runs at runtime at this point, not compile-time yet.¹

Macros

To have macros run at compile-time, Common Lisp specifically has defmacro to define a macro. Here’s an example of the famous anaphoric if. It’s a short-hand for let-binding followed by an immediate if, testing that the value is “true-ish” (non-nil), and makes whatever it is available as it in the if:

(defmacro aif (test-form then-form else-form)
  `(let ((it ,test-form))
    (if it ,then-form ,else-form)))

You use it like this:

(aif (calculate-something) (use it) (do-something-else))

Here’s how we implement the same thing in Template Haskell:

aif testForm thenForm elseForm =
  [| let it = $testForm
     in if it
     then $thenForm
     else $elseForm
  |]

So far so good, apart from the fact no one would write this macro in Haskell.² Here’s how we use it:

$(aif [|calculate something|] [|use it|] [|something other|])

Oh no! I have to manually quote every argument myself! The quotation syntax isn’t even short, I have to write [| .. |] around everything. No one will use your macros if they are like that.

Quasiquotes don’t solve the problem

Haskell has what it calls “quasiquotes” which are like Lisp’s reader macros: You can parse an arbitrary string and produce an AST for the compiler. They’re actually great for embedding other languages into Haskell like JSON, YAML, HTML, etc.

Maybe that could make writing this easy? Perhaps something like:

[aif|calculate something; use it; something other|]

On the surface this looks like we’re there. But we’re not, because remember that Haskell’s metaprogramming requires you to produce an AST. The type Exp forms the abstract syntax tree and looks like this:

data Exp = VarE Name | ConE Name | LitE Lit | AppE Exp Exp | AppTypeE
Exp Type | ...

So you can’t go from the string above into the compiler without converting to an AST. You need a parse step.

Fine, let’s just import GHC’s own parser to produce the AST. Surely that’s possible? Sadly, not. GHC’s own API parser has a completely different tree type to the one in Template Haskell.³ This is where we get stuck.

Implementing such a translation might be the way to salvage quasi-quote syntax into a macro system. It might be a little slow, though. It’d need long-term maintenance.

Quasiquotes in GHC optimise a different use-case to macros: they let you deal with foreign languages. Macros let you add slight enhancements to your existing language.

A quick fix

A quick fix to at least let us get at the parse tree would be to have some special syntax, e.g. to make something up completely⁴:

aif!(if calculate something then use it else something other)

Could produce:

$(aif [| if calculate something then use it else something other |])

The limitation here is that the input to the macro has to parse correctly into an AST. You can’t have the branches of the if separately from the if itself.

The surface syntax of Lisp (token trees), used by the macro system, is a superset of the core syntax of Lisp (let/setf/cond/progn, etc.). Unfortunately, the surface syntax of Haskell (used by the metaprogramming) is exactly the core syntax:

> :t $(lamE [varP (mkName "x")] (varE (mkName "x")))
<interactive>:1:3-46: Splicing expression lamE [varP (mkName "x")] (varE (mkName "x"))
======>
\ x -> x

This is how you have to construct the AST in Haskell: it has to be of the right schema immediately, there’s no way to produce a “loose tree of tokens” that TH will consume for you.

Additionally, quotation demands correct syntax too: [| let |] is a syntax error. What if I wanted to define my own variation on let? Too bad.

This would encourage strange warping and re-using of existing syntax to achieve what you want. I don’t think this is a good idea on the whole.

Therefore, we either have to fit our macros into existing syntax (as above), or parse strings (quasiquotes). We need the middle ground that Lisp offers.

An ideal design

Going back to the original definition of macros, we had:

1. Syntactically light-weight.
2. Don’t require writing a parser to deal with the language’s native syntax.
3. They work on trees of lexical tokens of the language; not abstract syntax trees.

Let’s explore this in Haskell. If we had this, it might look like:

aif!(calculate something; use it; something other)

This is light-weight. It doesn’t require a parser. We could receive the lexical tokens as:

calculate  something  ;  use  it  ;  something  other

The only special addendum would be that bracketing syntax be balanced into a tree, so: () {} [].⁵ Just like in Lisp. Finally, the Template Haskell API would provide a trivial way to go from a token tree to an abstract syntax tree: [if,x,then,y,else,z] into CondE ...

Motivating examples

So the following constructs would be fine:

nat!1      -- natural number.
ne![1,2,3] -- non-empty list.
sha1!cf23df2207d99a74fbe169e3eba035e633b65d94 -- compile-time validated sha1
email!"chrisdone@gmail.com" -- compile-time validated email
set!{1 2 3 c 4}
vec![ 1, 2, 3 ] -- vector type
map!{ x: 1, y: 2, z: 3 } -- easier-to-read compile-time constructed map
ado!(x <- y
     y <- z
     x)  -- applicative or qualified do could have been macros

(If you don’t find those examples enticing there’s no hope for you.)

As it happens, Rust’s macros work just like this. Lisp’s do. Haskell could potentially have this. It depends whether the community wants it, and/or whether someone is willing to implement a patch for GHC and lobby for it. But it seemed worth pointing out.

Thanks Jānis Džeriņš and Mihai Bazon for reviewing this post.

Is it Try.do that is dangerous?

Note: An LLM was not used in writing this article.

I wrote the post Try.do for recoverable errors in Haskell and someone has written a nice response post proposing that this pattern is actually dangerous. While reading it I wrote up some of my own notes to share in reply.

I’d like to preface with the fact that I’m grateful for discussion and criticism of this approach. I’d like to use this approach, but if someone finds genuine issues with it, then I’ll naturally have to look elsewhere.

Loss of code re-use

The first point made, and I think this is a solid point, is that you can’t re-use handy monadic functions like traverse or forever with this syntax. That’s a downer.

However, I think it also follows naturally. If ExceptT were easily a clean MonadUnliftIO instance, then we would have a clean interpretation of how such functions would behave under all the circumstances that unliftio is applicable in, most importantly threading and when IO appears in negative position (withX). As it happens, we don’t.

This also applies to free monads, by the way. When you run the monad, you still have to decide on an interpretation, figure out how things will interact, and the idea of doing so does not bring me confidence.

Indeed, I may want to decide on a case-by-case basis whether traverse should optimistically run all actions (even concurrently; which I’m doing in my compiler), only at the end checking all results, or whether it should fail hard on the first failing action. Happily, the pooledMapConcurrentlyN function doesn’t have to know or care about how I do error handling.

In conclusion, I don’t see this as a complete obvious loss, and in some way it’s also a gain. I think there might be some interesting ideas to explore in this area.

Lifting hides results

The second point, in my reading, was that with this syntax, a programmer will get into the habit of lifting all actions that aren’t returning Either E A. The downside being that if you use a function like timeout, like this:

result <- timeout (someAction :: IO (Either E A))

Then you’ll hit a type error,

• Couldn't match type: Maybe (Either ErrorType Int)
                 with: Either e0 b0
• In a stmt of a qualified 'do' block:
    result <- timeout 1000 action1

So, being in a rush, they ignore the code and just add an fmap pure call to fix the error:

result <- fmap pure (timeout 1000 action1)

Now we’ve lost the error, it didn’t short-circuit where it should have! Actually, we haven’t lose the error. In fact, we haven’t finished writing the code at this point. Assuming we have compiler warnings on, we’ll be told that result is unused.

Main.hs:10:7: warning: [-Wunused-matches]
    Defined but not used: ‘result’
   |
10 |       result <- fmap pure (timeout 1000 action1)
   |       ^^^^^^

Furthermore, when we decide to use it, we’ll see that its type is

Maybe (Either ErrorType Int)

The error is still here, we have to do something with it. You can’t use it without having to deal with the error in some way. I think if the compiler tells you something and you ignore it, that’s your responsibility. It can’t save you from yourself.

This is the first instance of a running theme in the post that I’m replying to, which is that code that doesn’t use results is dangerous.

The try function

The next case considered was try, which has this type:

try :: Exception e => IO a -> IO (Either e a)

And what would happen if you wrote:

result <- try (someAction :: IO (Either E A))

So that the type would be:

result <- try (someAction :: IO (Either E A)) :: IO (Either E (Either E A))

The author claims that you won’t get a type error if you do something with the result. Let’s study it:

1. try will catch exceptions thrown by the GHC exception mechanism.
2. It will catch only those exceptions that are an instance of Exception.
3. It will be reported back to the user in the Left case of the either.

In this example:

• This assumes that one would make their failure result type E an instance of Exception. I don’t think there would be a good reason to do that. But let’s continue with this assumption.
• If, further, you actually use the throw call from base to throw your result type (again, why would you?), then try will catch it. So it wasn’t lost.
• If the function simply returns the failure type, then you have it.
• Finally, my point above about the result variable stands here; it has to be used somewhere.

But I believe that this example is contrived. The whole point of the Try.do system is to avoid using the base exception system for our business logic. Why, then, would we implement an instance of Exception and then willingly throw our failure type? Finally, the code doesn’t lose any errors. In fact, the double Either would be enough to indicate to a programmer that something is off here.

Names are not type safety

As an aside, an easy to avoid confusion here is to simply use a type dedicated to this. Let’s call it Failure:

data Failure err ok = Failed err | Ok ok

Now, it’s not possible to be confused about Either as some random data and Failure which only ever is produced by a failure. Many have argued that Either itself is a form of boolean blindness. I used Either in my post as an aid to demonstrate a point; there’s no compelling reason otherwise to use it.

The author, citing Alexis King, would have us believe that names are not type safety. I disagree; all types are type safety. The attempt to put type techniques into “safe” and “unsafe” categories only serves to eliminate nuance.

Additionally, the author believes that syntax is not type safety. I think syntax is the main driving force behind type safety, or so I feel, having written the type generation stage of various compilers.

Finally (pun intended)

The last point the author brings up seems to be more of a criticism of any IO action returning Either, than the special syntax I proposed in my post.

In base there are two functions which are notable in one crucial aspect, their discarding of values:

finally :: MonadUnliftIO m => m a -> m b -> m a
bracket :: MonadUnliftIO m => m a -> (a -> m b) -> (a -> m c) -> m c

finally discards b, and bracket discards b.

The author writes that for,

someAction1 `finally` someAction2

would necessarily discard the result of someAction2. I think this is a good observation. Your result will be discarded, never to be seen again.

This does bring up a wider point, however: the type of bracket and friends is a problem. Why don’t they use ()? These functions can swallow results all the time, regardless of whether you’re using Try.do or writing normal Haskell. In Scala, Kotlin and Ceylon, bracket uses void or unit.

I’m glad the author brought this up, because we don’t currently have any tooling to find and catch these mistakes. Essentially, bracket/finally are risky functions to use due to this.¹ This is what prompted the title of my reply – is it Try.do that’s dangerous, or is it bracket/finally?

Is it a criticism of Try.do? I’m doubtful at the moment.

Concluding

I don’t think there’s any reason to call this technique “dangerous”. I think that the examples in the post were slightly contrived (such as the dubious suggestion that you would implement Exception for your result type, or not using the result of an action that GHC would warn you about), and in the last point it seemed to be arguing against base rather than my proposed technique, to which I can only agree.

I’m unsure about the tone in the penultimate paragraph², but overall I liked the criticism, it got me thinking. I do think there’s a wider discussion to be had about “use”, and perhaps my slow absorption of Rust thinking has me wishing there was less of a complacent attitude to throwing away results in Haskell’s base libraries. It’ll raise my alarms more readily when reviewing/auditing code.

It’ll still be a while before I’m even able to take advantage of QualifiedDo, but I still look forward to pushing the boundaries of this idea.

Try.do for recoverable errors in Haskell

Note: An LLM was not used in writing this article.

UPDATE 2021-01-02: I have since written a GHC compiler plugin to implement an alternative ?-based syntax for early return. I prefer that one than use of Try.do, because it doesn’t require any type magic or special instances, and the ? is more readable.

UPDATE: I’ve added a follow-up post to this here, where I address some criticisms of this post.

The first half of this post is here. Please read that for context.

Qualified do

One thing that struck me was that our earlier Make the IO action return Either approach produced code that was still perfectly satisfying the unliftio laws. Perhaps, like in Rust, we need a syntactic solution to the problem.

Enter QualifiedDo, which will be available on the 9.0.1 version of GHC. What this would allow us to do is rebind (>>=) to mean what we’d like:

module Try ((Try.>>=)) where
(>>=) :: IO (Either e a) -> (a -> IO (Either e b)) -> IO (Either e b)
(>>=) m f = do
  result <- m
  case result of
    Left e -> pure (Left e)
    Right a -> f a

We put this in a module called Try and import it with QualifiedDo enabled.

Now our code becomes:

Try.do constraints <- constrainRenamed renamed
       solved <- solveConstraints constraints
       generalised <- generaliseSolved solved
       resolveGeneralised generalised

where each action’s type is SomeThing -> IO (Either ErrorType OtherThing).

Full working example:

{-# LANGUAGE QualifiedDo #-}
import Try
data ErrorType = OhNo deriving (Show)
action1 :: IO (Either ErrorType Int)
action1 = pure (Right 10)
action2 :: Int -> IO (Either ErrorType Int)
action2 x = pure (Left OhNo)
action3 :: Int -> IO (Either ErrorType Int)
action3 x = pure (Right (x+30))
main = do
  result <-
    Try.do
      output <- action1
      output2 <- action2 output
      output3 <- action3 output2
  print result

If you want a final return, you need to wrap it up in Either, as:

main = do
  result <-
    Try.do
      output <- action1
      output2 <- action2 output
      output3 <- action3 output2
      pure (Right output3)
  print result

Otherwise it won’t match our type:

Main.hs:16:7: error:
    • Couldn't match type ‘Int’ with ‘Either ErrorType b0’
      Expected: IO (Either ErrorType b0)
        Actual: IO Int

People who know a bit of Rust will see this as a familiar pattern; putting Ok(output3) at the end of your function.

What did we gain? We can have our cake and eat it too. We get a trivial, syntactically-lightweight, way to string possibly-failing actions together, while retaining all the benefits of being an unliftio-able monad.

Verdict: Best of all worlds.

Good things come to those who wait

Unfortunately, it’ll be a while before I’ll be upgrading to this version of GHC, but I look forward to being able to use this time saver.

Recoverable errors in Haskell

Note: An LLM was not used in writing this article.

In Haskell, I sometimes have IO-based actions that may produce failures. The IO aspect is usually incidental; because I need logging or metrics generation.

When not using a free monad or a fancy effect-system–just plain IO–I like to follow a mental model similar to Rust’s definition of error handling, which splits them into recoverable vs unrecoverable errors.

In Rust, when a function can fail with a recoverable error, it returns a Result, like:

Result<OutputType, ErrorType>

which the caller can pattern-match on. Let’s compare recoverable errors in Haskell.

Have the IO action throw a runtime exception

Our code might look like:

do constraints <- constrainRenamed renamed
   solved <- solveConstraints constraints
   generalised <- generaliseSolved solved
   resolveGeneralised generalised

And each of these steps may throw an exception. We leave it up to code above in the call chain to remember to catch them.

The trouble with exceptions is that they’re not mentioned in the type system. They’re also handled not at the call site, when for recoverable errors, that is usually the most straight-forward place to handle them.

It’s simply very easy–and it happens all the time–that you either throw the wrong exception type in the wrong place, or you forget to catch exceptions at the right place.

Verdict: Too dangerous.

Make the IO action return Either

A more direct approach, which is a bit like Rust, is to simply have the function return Either ErrorType OutputType and then pattern match on the result to find out whether everything went fine.

Now our code looks like this:

do constraints <- constrainRenamed renamed
   case constraints of
     Left err -> return (Left err)
     Right constraints' -> do
       solved <- solveConstraints constraints
       case solved of
         Left err -> return (Left err)
         Right solved' -> do
           generalised <- generaliseSolved solved'
           case generalised of
             Left err -> return (Left err)
             Right generalised' -> do
              resolveGeneralised generalised'

This is tedious to write, there’s all that repetition on the Left case. Reading it, you also can’t immediately tell whether there’s any extra logic going on here.

Verdict: Too much code.

Wrap your IO code up in ExceptT

One way to solve this issue is to wrap up these actions in the ExceptT monad transformer. We have to make each of the actions now live in the ExceptT monad, so

IO (Either ErrorType OutputType)

becomes

ExceptT ErrorType IO OutputType

And our code goal is clean again:

runExceptT
  (do constraints <- constrainRenamed renamed
      solved <- solveConstraints constraints
      generalised <- generaliseSolved solved
      resolveGeneralised generalised)

The runExceptT produces an IO (Either ErrorType OutputType).

However, ExceptT cannot be an instance of MonadUnliftIO – because it necessarily requires multiple exit points. See this discussion which should give you an idea of how hairy and unpredictable this can be.

This is a big deal.

Essentially, if a monad is unliftio-able, then:

1. The regular exception system will work as normal. This is important, because you do want regular exceptions to be thrown upwards.
2. Concurrent programming works as usual: you can use async with UnliftIO.Async and get predictable results.
3. Resource clean-up is also straight-forward.

So, ExceptT has to be thrown out too, sadly.

Verdict: Not compatible.

Solutions

I previously explored in another post about Try.do, which I’ve decided against in favor of…

I have since written a GHC compiler plugin to implement an alternative ?-based syntax for early return. I prefer that one than use of Try.do, because it doesn’t require any type magic or special instances, and the ? is more readable.

Use import aliases to easily access fields

Note: An LLM was not used in writing this article.

This post demonstrates using imports as a quick and easy way to disambiguate record field names. You can still put all your types in one module.

No fancy type classes or machinery needed.

Define all your types in one module, using DuplicateRecordFields to avoid GHC complaining about conflicting field names:

{-# LANGUAGE DuplicateRecordFields  #-}
module Types where
import Prelude
data Person = Person { name :: String, age :: Int } deriving Show
data Company = Company { name :: String, age :: Int } deriving Show

Now in another module, use import aliases to get at specific types (Person and Company):

{-# LANGUAGE DuplicateRecordFields  #-}
module Use where
import Prelude
import Types as Person (Person(..))
import Types as Company (Company(..))
import Types

main :: IO ()
main =
  let -- Freely use Person/Company constructors, and field names unqualified:
      mary = Person {name = "Mary", age = 23}
      james = Person {name = "James", age = 22}
      company = Company {name="Fish Limited",age=150}
   in do -- Pattern matching convenience:
         case mary of
           Person{name} -> print name
         case company of
           Company{name} -> print name
         -- Easily transfer data between record types because the field names are the same.
         let transferred = Company {..} where Person {..} = mary
         -- Accessing:
         print (Person.name mary)
         print (Person.name james)
         print (map Person.name [mary,james])
         print (Company.name company)
         print (Company.name transferred)
         -- Updating:
         print (mary { Person.name = "Maria"})

Daniel Díaz Carrete commented:

While it doesn’t free you from having to prepend the qualified name when using the selectors, it feels conceptually “better” to define it once at the import list, instead of doing it at each field declaration.

Which I agree with!

The language of spreadsheets is bad

Note: An LLM was not used in writing this article.

The user interface in a spreadsheet is modal. There are two modes:

• The first mode is code (also known as: formula): =SUM(A1:A5)
• The second mode is the result of running that code: 234

You type in some equation, some mathematics, some conditions, and then you hit return, and then you see the results.

Declarative programming is a good fit

The programming language that you write your code in is a declarative programming language. We call programming languages declarative when you say what you want (declarative) more than instructing the computer how to go about achieving it (imperative). When languages are declarative, it gives the system more freedom to make choices about how to go about computing results.

The code in spreadsheets is this kind of language. It has to be. When you change code in one cell, all the other cells are updated. If the language was imperative, that would mean it could change things. That’s bad when cells are re-run all the time during your course of work. It’d be chaos to keep track of what you changed.

That’s why the language must be declarative, to give the system freedom to run formulae whenever it needs to without worrying about side effects. On VisiCalc, the first spreadsheet software from 1979, Ted Nelson said:

“VISICALC represented a new idea of a way to use a computer and a new way of thinking about the world. Where conventional programming was thought of as a sequence of steps, this new thing was no longer sequential in effect: When you made a change in one place, all other things changed instantly and automatically.”

That’s where it ends

However, it’s quite a limited programming language. It was initially designed to handle a small subset of problems that you might encounter in finance. It has been extended with plenty of functions like trigonometric functions and things like that, but without any particular rigour or academic insight or critical eye.

It’s very convenient for simple problems, dealing with simple numbers, text and dates. However, any programmer can tell you immediately that there are limitations to this language. And indeed any Excel or Google Sheets user can tell you that they have hit the limits of this language often.

The solutions aren’t solutions

When you hit the limits of the spreadsheets expression language, there are two approaches:

• The first is to try to remodel your problem to avoid the limitation, this is really just a hack/kludge.
• The other is to simply abandon this language and use either Visual Basic or JavaScript, or Python, or some other general purpose programming language that has the power to express what you really wanted to express in the first place. This is typically called “scripting”.

The first approach is not a solution.

For the second, there are two solid problems with this approach:

• The first problem is that you are no longer using the original language and therefore you have to keep two languages in sync and in your head.
• You have to work with two completely different programming paradigms, because all of the mainstream scripting languages are imperative.

You have lost the declarative nature of what makes spreadsheets great. You also have to learn a new language.

If you were a normal spreadsheet user, with a full plate of work, the chances of actually learning Visual Basic or Python on your own time are very slim.

So, probably, you’ll have to ask a “programmer” to solve your problem for you, which is really annoying. A wise person once said: in computing, there is nothing worse than a computer telling you that you cannot express a thought.

Wizard politics

This creates a funny class system of “muggles and wizards”, to borrow a Harry Potter term, wherein the millions of users of spreadsheets are the muggles that make do with rudimentary tools, and the wizards are a privileged class with all the power. Modern offerings like AirTable continue this narrative: in the community forums, I have read this comment by a community leader:

I don’t recommend attempting this using a formula field. Look into a scripting solution—either in the Scripting app, or in a “Run script” action in an automation—where you can tap into the built-in sorting features of the JavaScript language.

It also makes bad sense from a business perspective; I paid for a tool for all my employees, and now my employees are asking for developers to do something that the tool should be able to do already. My employees are wasted even though they are perfectly good at their domain and are willing.

We are also faced with a secondary problem, which is the problem of choice. You have to choose where to put your logic, either in the spreadsheet or in the scripting language. Now you have two problems.

Let’s call a spade a spade

The elephant in the room is simply that the expression language in spreadsheets is insufficient, not up to the task, not up to snuff, including for people who aren’t programmers or engineers. Hybridisation does not work well to paper over this issue either.

This is also omitting other criticisms, like a lack of first-class functions, which would make awkward abominations like VLOOKUP and friends unnecessary.

We also know that this language simply does not scale. People write god-awful messes of IF(IF(..)) expressions that fill a whole screen in one cell. Formulae are duplicated across ranges and then accidentally modified only in some of them. It’s the wild west.

There is already a better language

The good news is that for 35 years there has been in development so-called pure functional programming languages, which are declarative languages which have the power of general purpose languages like Visual Basic, yet retain the declarative purity that we enjoy in spreadsheets.

The most popular incarnation of this is called Haskell. It has a static type system which prevents some issues. It has a well-developed, comprehensive set of functions for expressing common problems like loops, filters, reductions, etc.

Unlike your Visual Basics, your Pythons, your JavaScripts, Haskell knows how to express normal every day programming problems in a functional declarative way, and that is what makes it a perfect candidate replacement language for spreadsheets.

Haskell also has something to say about dealing with time (think: =NOW()), streams (think reading data from external systems), events (think button clicks) and the rest in a pure language. Spreadsheet systems side-step the whole issue (and miss a huge opportunity), opting to simply call these “volatile” cells that may change in a variety of ad hoc cases, but we’ll see more about that in another future article.

Conclusion

In conclusion, there’s no point trying to maintain a hybrid approach of using a very restricted language combined with an imperative language, when you could go straight to the obvious solution and use a real, functional, powerful language from the beginning, which has been tried and tested for 35 years, and is easily up to the task of expressing spreadsheet problems. There is also an optimising compiler that can compile it to machine code to run very quickly.

You can educate people in a tool to do simple arithmetic and filters very easily, I’ve done it. But the key addition is that you can level up in the same language to do more complex things. There’s a progression path.

Our Inflex language is built from the ground up based on Haskell (with lessons from PureScript, Unison and OCaml). It’s designed to be run in a reactive document, to deal with numbers, records, lists, tables, etc. and in the future, streams. At the time of writing, we’re in an invite-only beta, but we’ll be documenting more of that language over time.

What’s wrong with the grid?

Note: An LLM was not used in writing this article.

The grid system in spreadsheets is very simple. It’s also very powerful, and it’s powerful because it’s simple. As a user you can immediately start entering data without even thinking about it. And then, in an ad hoc fashion, you can add logic and conditions as you think of them.

Lack of boundaries cause bugs

This fast and loose paradigm is also the downfall of spreadsheets, because the user is encouraged to do a form of programming, without encouraging them to do any kind of discipline. Spreadsheets quickly get out of hand. The boundaries are arbitrary, and usually are only visual, which means it’s very difficult to write good code based on this.

For example, there is the famous case of a large spreadsheet used in an economics paper, called Growth in a time of Debt, and there was a miscalculation because a few rows at the end of a list of items were not taken into account, as, per usual in a spreadsheet, the user specified them in a range. It has been criticised anywhere from a gross oversight to disastrous.

Proper data structures are simpler

However, in normal programming, we don’t have just one data structure. The grid is just one data structure, a matrix of practically infinite width and height. You can access its elements by coordinates. But in programming––normal programming––we have, for example, lists. If a proper list data structure were were used for the list of elements in the above example, there wouldn’t have been this bug, because you don’t have to specify how many elements of a list you want to work on. We just say “apply this function to all elements of the list.”

Data structures like lists and matrices can all be approximated in a spreadsheet by a grid, badly. However, anything more than this becomes awkward very quickly.

For example, a simple record consisting of a name and an age in a spreadsheet must be modelled by using a cell for the label of the name and label of the age, and then the value for each thing. This is a hack, using superficial visual embellishments to reflect what is actually data.

In normal programming languages, this is called a record. There’s no need for any kind of strange and brittle hacking and tricks to make this work as you have to do in a spreadsheet. The basic spreadsheet, as-is, is very accessible to the normal person who just wants to do every day calculations about their business. But the ideas of a record, list, tree or graph are also intuitive for normal people because they actually model the kind of data that their domain is dealing with. Sadly, knowledge workers using spreadsheets are deprived of these tools.

Data modelling is poor

Therefore we find spreadsheets very lacking, in fact, when we try to model even every day pedestrian problems. Consider for example trying to model a family tree, or the hierarchical structure of the US government, or a taxonomy of a species.

Trees are three data structures, perfectly normal, well understood, pliable, things that you can express in a programming language and manipulate using code in a very logical manner. You can count how many items are in the tree, you can restrict the tree to a certain branch, perform a transformation on each node in the tree, or transpose the tree and flip it upside down!

Another example is a graph. For example, the Coronavirus can be modelled by its spread using a graph the graph consists of a set of people in the connections between those people. You can easily write code to count how many connections a given node has to it; that’s a normal graph operation. Or count how many transitive node are connected to it in one direction, in other words; you can measure the influences of one person within a community.

Aside from using code to manipulate said data structures, your user interface should allow you to click a node and edit the text, maybe write some code in there, like any other type of cell.

Both of those things are impossible, practically, to describe, talk about, express, manipulate, or visualise, in a traditional grid-based spreadsheet!

So, we’ve established two things so far. The first is that the grid system lacks boundaries between different data structures, which can lead to bugs. Second is that there are actually very normal, every day, useful data structures which we should, in a reasonable system, be able to express, but which the grid system is unable to express.

Additionally, we have seen that these data structures actually have very well understood and rich and useful operations which work only if you have that kind of data structure.

But a spreadsheet simply has one single data structure: the grid. And, the only elements that you can put in that data structure are numbers, strings and dates. In other words, atomic values. But that’s not real life. There’s no reason that I should not be able to have a list of lists. Or a tree of records. Or a list of records (aka a “table”). I should, hypothetically, be able to arbitrarily nest data structures as it fits my problem.

Correctness checks

Turning to a different topic, when you have different data structures, you can start to add checks that help you avoid making other types of mistakes. If your system knows the shape of data, it can have expectations about how you use it.

You can add a type system to the system. The purpose of a type system is to make sure that you are combining your different operations together in a way that makes sense. Not putting a square peg in around hole. For example, you can calculate the sum of an list, of a graph, of a tree. However, you cannot concatenate a graph to an list. What would that even mean?

Conclusion

In conclusion, we’ve looked at reasons why a traditional spreadsheet grid system is lacking in several key areas of expression, correctness, and even convenience, in a way that is actually important for normal knowledge work and not just for programmers.

If you look through various competitors to the established spreadsheet vendors, you’ll see a lot of “reinvent spreadsheets” language. But it’s always the same thing: we have a grid system with coordinates and an underwhelming untyped expression language. But they added JavaScript or Python to it, or added a “low-code” app generator on top of the spreadsheet, or some special views.

We’re working on a system called Inflex that really does rethink the spreadsheet fundamentally from the ground up. And the first thing to be thrown out is the grid, the coordinate system and replace them with real data structures and a type system.

We keep what’s good about spreadsheets: the reactivity and “edit-in-place” user experience.

In our next post we’ll be discussing the fundamental problems with the expression/formula languages used in spreadsheet software, and how we are fixing it.

Ghosts of Departed Proofs Convenience

Note: An LLM was not used in writing this article.

Following on from Ghosts of Departed Proofs with a Named type as defined in Olliver Charles’s post on the same topic, we can add a usability improvement by defining a SomeNamed existential in order to wrap up the new type introduced for the n in Name n a, and then a pattern synonym to conveniently unwrap that constructor.

-- | Our main engine for naming a value, then we can prove properties
--   about a named value.

{-# LANGUAGE ExistentialQuantification #-} -- Used for SomeNamed.
{-# LANGUAGE PatternSynonyms #-} -- Used for the Name pattern.
{-# LANGUAGE ViewPatterns #-} -- Used for the Name pattern.
{-# LANGUAGE RankNTypes #-} -- Used for withName.

module Named ( Named, pattern Name, forgetName
             , withName, someNamed, SomeNamed(..) ) where

-- | Give a generated type-level name to any value.
newtype Named n a = Named_ { forgetName :: a }

withName :: a -> (forall name. Named name a -> r) -> r
withName x f = f (Named_ x)

-- | A convenient way to name something and access the name later.
data SomeNamed a = forall n. SomeNamed (Named n a)

-- | Wrap a value up with a non-exposed name.
someNamed :: a -> SomeNamed a
someNamed x = SomeNamed (Named_ x)

-- | A convenient way to quickly name a value as a pattern.
pattern Name t <- (someNamed -> SomeNamed t)

With this, we can write

case x of Name x' -> ...

And now we have a named version of x! This scales to any number of tuples or pattern matches. See below for a real example.

Some proof generators

For the sake of example in the next section, I introduce a couple trivial modules for checking non-zeroness of a number, and a function that makes use of such proof to perform division.

-- | A trivial proof of nonzero for a given named thing.
--
-- Note that only this module can produce an IsNonzero value. Hence
-- you can only get a proof of nonzero via checkNonzero.

module Nonzero ( IsNonzero, checkNonzero ) where

import Named

data IsNonzero name = IsNonzero

checkNonzero :: (Num i, Eq i) => Named name i -> Maybe (IsNonzero name)
checkNonzero named
  | forgetName named /= 0 = Just IsNonzero
  | otherwise = Nothing

-- | A simple API that requires proof of nonzero.
--
-- An obvious example: division requires a nonzero denominator.

module Div (divide) where

import Named
import Nonzero

divide :: Fractional i => IsNonzero y -> Named x i -> Named y i -> i
divide _ x y = (forgetName x / forgetName y)

Example use

Here’s a simple program that parses two numbers, checks that the latter is non-zero, and then does a division by that non-zero number. Trivial, but it helps demonstrate the syntax without untidiness.

import Div
import Nonzero
import Text.Read
import Named

main = do
  numeratorString <- getLine
  denominatorString <- getLine
  case (,) <$> readMaybe numeratorString
           <*> readMaybe denominatorString :: Maybe (Double, Double) of
    Nothing -> error "Both must be valid numbers."
    Just (Name numeratorNum, Name denominatorNum) ->
      case checkNonzero denominatorNum of
        Nothing -> error "Denominator must be non-zero."
        Just denominatorNonZero ->
          let result = divide denominatorNonZero numeratorNum denominatorNum
          in putStrLn ("Result: " ++ show result)

One nice addition is that we can use monad syntax to name them very conveniently!

main2 = do
  numeratorString <- getLine
  denominatorString <- getLine
  let maybeResult = do
        Name numeratorNum   <- readMaybe numeratorString
        Name denominatorNum <- readMaybe denominatorString
        denominatorNonZero  <- checkNonzero denominatorNum
        pure (divide denominatorNonZero numeratorNum denominatorNum)
  maybe
    (error "Something wasn't right and we don't care why.")
    print
    maybeResult

With an Either E return type, we could return or throw an exception, if we wanted to.

Proof is in the pudding: Examples that do not compile

Here are some example variations of Main which fail to compile, demonstrating that this technique is helping the program be more correct:

This version of main fails to compile simply because I haven’t named the numeratorInt.

import Div
import Nonzero
import Text.Read
import Named

main = do
  numeratorString <- getLine
  denominatorString <- getLine
  case (,) <$> readMaybe numeratorString
           <*> readMaybe denominatorString :: Maybe (Double, Double) of
    Nothing -> error "Both must be valid numbers."
    Just (numeratorInt, Name denominatorInt) ->
      case checkNonzero denominatorInt of
        Nothing -> error "Denominator must be non-zero."
        Just denominatorNonZero ->
          let result = divide denominatorNonZero numeratorInt denominatorInt
          in putStrLn ("Result: " ++ show result)

Yields the error:

Couldn't match expected type ‘Named x0 Double’ with actual type ‘Double’

Here is a version where I got the arguments to divide the wrong way round:

import Div
import Nonzero
import Text.Read
import Named

main = do
  numeratorString <- getLine
  denominatorString <- getLine
  case (,) <$> readMaybe numeratorString
           <*> readMaybe denominatorString :: Maybe (Double, Double) of
    Nothing -> error "Both must be valid numbers."
    Just (Name numeratorInt, Name denominatorInt) ->
      case checkNonzero denominatorInt of
        Nothing -> error "Denominator must be non-zero."
        Just denominatorNonZero ->
          let result = divide denominatorNonZero  denominatorInt numeratorInt
          in putStrLn ("Result: " ++ show result)

Yields the error:

• Couldn't match type ‘n’ with ‘n1’

The denominatorNonZero proof refers to denominatorInt by a generate name type (n1), and numeratorInt’s name (n) is different.

Defaulting fields in a record

Note: An LLM was not used in writing this article.

Do you have 20+ fields of configuration for your kitchen sink API? This approach might be for you.

An approach to specifying many (required) fields, where some are defaulted. What you get:

1. The ability to specify what the defaults are in a single place.
2. That set of defaults is decoupled from the function that uses the record (separating concerns).
3. The ability to choose different sets of defaults easily (e.g. “dev” mode vs “production” mode).
4. Type-safety; you can’t specify defaults for required fields as an API provider.
5. Overriding: you can provide values instead of using the default trivially.
6. Light-weight syntax.
7. Failing to provide a required field as an API end-user results in a type error.

A field which has no sensible default value (such as one enabling a new feature like TLSSettings) can still be Maybe a.

Your consumer of this API:

-- | Usage of API.

module Main where

import DBAPI

-- Omitting either username or password triggers a type error.
main = connect connSpecDefaults {username = "test", password = "mypw"}

-- To override defaults, just specify the field e.g. port:
main2 = connect connSpecDefaults {username = "test", password = "mypw", port = 1234}

-- Thanks Aleksey Khudyakov (@pineapple_zombi) for pointing out that plain record
-- update has the same typing rules as RecordWildCards.
--
-- Old version was: ConnSpec{username="..",password="..",..} where
-- ConnSpec{..} = connSpecDefaults

Definition of an API, in this case the example is a database:

{-# LANGUAGE DataKinds #-}

-- | My database API.

module DBAPI where

import Data.Defaults

data ConnSpec p = ConnSpec
  { username :: !(Required p String)
  , password :: !(Required p String)
  , port :: !Int -- Optional and therefore requires a default.
  , host :: !String -- Optional and therefore requires a default.
  }

connSpecDefaults :: ConnSpec Defaults
connSpecDefaults = ConnSpec {
  -- Required fields are ()
  username = (), password = (),
  -- Defaulted fields need defaults specified
  port = 5432, host = "localhost"
  }

-- Example func.
connect :: ConnSpec Complete -> IO ()
connect _ = pure ()

Basic defaults module to support this approach:

{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}

-- | Providing defaults for fields in a record.

module Data.Defaults where

-- | Purpose of a data type.
data Purpose
  = Defaults -- For specifying defaults.
  | Complete -- For making a complete record.

-- | Required fields are not usable from a defaults spec.
type family Required (p :: Purpose) a where
  Required 'Defaults a  = () -- When we're defining defaults, required fields are ().
  Required 'Complete a = a

Statically Checked Overloaded Strings

Note: An LLM was not used in writing this article.

This page demonstrates a trick I came up with which is defining IsString for Q (TExp a), where a is lift-able. It allows you to write $$("...") and have the string parsed at compile-time.

This offers a light-weight way to enforce compile-time constraints. It’s basically OverloadedStrings with static checks.

This trick works already in old GHC versions.

{-# LANGUAGE TemplateHaskell, OverloadedStrings #-}

import Network.URI
import Path
import PATHTH
import SHA256TH
import URITH

uri :: URI
uri = $$("https://releases.hashicorp.com/vault/1.2.2/vault_1.2.2_linux_amd64.zip")

sha256 :: SHA256
sha256 = $$("7725b35d9ca8be3668abe63481f0731ca4730509419b4eb29fa0b0baa4798458")

home :: Path Abs Dir
home = $$("/home/chris")

Scroll down to see the modules PATHTH, SHA256TH and URITH.

Versus QuasiQuotes

This is more light-weight and overloaded than, e.g.

[quasiquote|...|]

which requires stating the name of the quoter you want (sometimes you’d rather not), requires the QuasiQuotes extension, and leaves syntax highlighters not sure how to highlight your content properly.

A step to make this syntax even lighter

It’d be nice to relax GHC’s parser a little to support $$"..." to mean the same thing. This wouldn’t conflict with any existing syntax that I am aware of, or of any existing plans or proposals.

PATHTH

{-# LANGUAGE FlexibleInstances #-}
module PATHTH where
import Data.String (IsString(..))
import Language.Haskell.TH.Syntax (Q, TExp(..), lift)
import Path
instance IsString (Q (TExp (Path Rel Dir))) where
  fromString = fmap TExp . mkRelDir
instance IsString (Q (TExp (Path Abs Dir))) where
  fromString = fmap TExp . mkAbsDir
instance IsString (Q (TExp (Path Rel File))) where
  fromString = fmap TExp . mkRelFile
instance IsString (Q (TExp (Path Abs File))) where
  fromString = fmap TExp . mkAbsFile

SHA256TH

{-# LANGUAGE DeriveLift, FlexibleInstances, TemplateHaskell #-}
module SHA256TH where
import           Data.ByteString (ByteString)
import qualified Data.ByteString as S
import qualified Data.ByteString.Base16 as Hex
import           Data.String
import           Instances.TH.Lift ()
import           Language.Haskell.TH.Syntax (Q, TExp(..), Lift(..))
newtype SHA256 = SHA256 ByteString deriving (Eq, Ord, Lift)
instance IsString (Q (TExp SHA256)) where
  fromString i =
    if length i == 64
      then case Hex.decode (fromString i) of
             (result, wrong)
               | S.null wrong -> fmap TExp (lift (SHA256 result))
             _ -> fail "Invalid SHA256 format."
      else fail "Incorrect length for SHA256."

URITH

{-# LANGUAGE NamedFieldPuns, FlexibleInstances, TemplateHaskell #-}
module URITH where
import Data.String (IsString(..))
import Language.Haskell.TH.Syntax (Q, TExp(..), lift)
import Network.URI (URI(..), parseURI, URIAuth(..))
instance IsString (Q (TExp URI)) where
  fromString i =
    case parseURI i of
      Nothing -> fail ("Invalid URI: " ++ show i)
      Just uri -> liftURI uri
liftURI :: URI -> Q (TExp URI)
liftURI URI {uriScheme, uriAuthority, uriPath, uriQuery, uriFragment} =
  fmap TExp [|URI {uriScheme, uriAuthority = $(mauthority), uriPath, uriQuery, uriFragment}|]
  where
    mauthority = maybe [|Nothing|] liftAuthority uriAuthority
    liftAuthority URIAuth {uriUserInfo, uriRegName, uriPort} =
      [|Just (URIAuth {uriUserInfo, uriRegName, uriPort})|]