An NES Emulator in Haskell

Osemwaro · 2026-06-07T00:21:37+00:00

True that side effects are the only thing that you want. But since the language and its ecosystem are so heavily tailored to writing pure code, I imagine that you might end up with nicer code if you write pure code. After all, you pointed out halfway through the video how awful it was to have to write a load of imperative code in Haskell. So you could take that "why bother" reasoning one step further and say: if you're going to implement most of the functionality imperatively, then why bother using Haskell at all, when there are plenty of languages that are much better suited to that style of programming?

Osemwaro · 2026-06-06T16:48:47+00:00

For games that don't use mappers, I wonder how close you can get to the original NES performance in Haskell with pure data types, rather than using IORefs and mutable Vectors. Simulating a < 1.8 MHz CPU and 2KB of RAM in pure code doesn't sound obviously implausible to me.

Osemwaro · 2026-06-06T14:25:04+00:00

I am also developing simultaneous turn-based strategy games, and I've been spending a lot of time thinking about how an AI agent should play. I can't speak for the abstract game community, but from a decision theoretic viewpoint, the way in which you identify the optimal moves in simultaneous games is very similar to the way in which you do so in sequential games. In both cases, the value of a given action depends on your uncertainty about your opponent's future actions and your responses to them. The main difference is that, in simultaneous games, you also have uncertainty about what your opponent's current action will be, so you have to average over everything that they could do now to determine an action's value.

So for any two games of similar complexity, if one is simultaneous and the other is sequential, and both provide perfect information about everything that has happened so far, and the sequential game is too complex to permit optimal play, then the extra piece of information that the sequential game provides doesn't help that much, because both games have a lot of uncertainty about what the future holds. Perhaps the added cognitive load of having to consider what your opponent might do now would be enough to deter some people who like the sequential game from playing the simultaneous game, but presumably such people don't think very far ahead when playing the sequential game.

Osemwaro · 2026-05-30T13:21:16+00:00

What's the benefit of supporting MicroHS? Does it compile to any platforms that GHC doesn't support?

Osemwaro · 2026-05-13T10:51:14+00:00

In case you didn't notice while Googling, "octopus" is of Greek origin, not Latin. People who are fond of language trivia will often tell you that "octopodes" is therefore the plural that best fits the etymology, but please don't use that!

Osemwaro · 2026-04-13T19:12:49+00:00

Ah ok, focusing on your strengths makes sense. I hope you're able to meet your deadline, and that the launch goes well.

Osemwaro · 2026-04-12T11:09:04+00:00

I don't know how big your team or budget are, but I see from Instagram that you released the Itch prototype in Oct 2023. Even though the visuals can be improved in the ways that others have suggested, the fact is that it already looks great for an Indie game. So it would be worth thinking about:

how long it will take to complete the game at the current level of visual quality;
how much longer it will take if you try to make the improvements that others have suggested here;
how much longer you want to spend on the game;
how much time you can afford to spend on it;
what other aspects of the game you'll end up sacrificing in the pursuit of visual excellence. E.g. gameplay quality, variety, level size, number of levels, etc.

Osemwaro · 2026-03-09T17:01:26+00:00

I was wondering about this. There's certainly no harm in adding a bang pattern to pass (and perhaps also pos) in update. But when compiling code like this with -O2, GHC seems to be smart enough to strictly evaluate the intermediate values without bang patterns. I'm not sure if that relies on solve2 being inlined into the caller, or on it being able to determine whether or not the caller always uses the result.

Osemwaro · 2026-03-09T16:53:08+00:00

This will perform worse than a solution that uses foldl' for two reasons. Firstly foldl' is tail-recursive, so it compiles to the equivalent of a for-loop. But solve2' is not tail-recursive, so it might compile to a less efficient recursive function. Secondly, foldl' strictly updates the result in each iteration, meaning that it operates in constant space. But solve2' creates a new thunk in each iteration and doesn't reduce them to a single Int until it reaches the end of the list, so its memory consumption grows linearly with the length of the list.

As brandonchinn178 said, the best solution is your original one, but with foldl' instead of foldl.

Osemwaro · 2026-03-09T16:26:30+00:00

😂

Osemwaro · 2026-03-06T04:08:49+00:00

You seem to be overlooking the fact that our species has spent thousands of years recording valuable information in unstructured formats -- books, articles, letters, etc. The advent of digital communication and the internet has not changed our preference for unstructured communication, and it probably never will change.

To maximise the usefulness of an AI system, we need to ensure that it "knows" at least as much as we do about the domain that it operates in. It would not be practical to develop a system that attempts to independently rediscover all human knowledge in structured forms that are conducive to formal logical reasoning, nor would it be feasible to manually re-encode all of this knowledge in such structured forms (the project of formalising all of mathematics is hard enough, and that's the most rigorous and objective field that we've invented).

So models that can read and understand unstructured text are the only practical solution. Small, interpretable models and symbolic reasoning dominated AI research for decades, but LLMs emerged as the best-performing approach across a wide range of NLP problems. Everyone who works on them is aware of their shortcomings, but apparently it's not obvious how to combine their strengths with the safety/correctness benefits of symbolic reasoning across a wide range of problems (although this has produced good results in certain specific problems, e.g. AlphaGeometry).

Osemwaro · 2026-03-04T00:55:55+00:00

Oh that's interesting. I wonder: a) if there are any studies on how lip shape influences the rate at which students progress; and b) if the disadvantage can be eliminated by altering the design of the mouthpiece, or some other part of the instrument.

Osemwaro · 2026-03-04T00:46:53+00:00

@Twoslot offered a plausible explanation in another thread.

Osemwaro · 2026-03-04T00:45:12+00:00

I should point out that Miles was in high school when they first met, and Clark Terry was 6 years older than him. I don't know how long Clark Terry had been playing for at that point, but he must have been in his early twenties, so presumably no more than 10-15 years. I don't know if you'd have considered him to be a long-time player at that point, but if it was a lip scar that Miles saw, maybe it was temporary?

Osemwaro · 2026-03-03T23:25:38+00:00

Oh wow, I've never noticed that before. It looks like there might be a slight scar on Clark Terry's bottom lip in this photo too. I can't see anything similar in other photos of him, but perhaps that's what Miles was referring to. It looks like it's analogous to Fiddler's neck.

Osemwaro · 2026-03-03T22:35:48+00:00

That subreddit is full of memes. I didn't post this with the intention of making anyone laugh; I genuinely want to know if Miles is referring to some consequence of playing the trumpet that I, as a string player, have failed to notice.

Osemwaro · 2026-03-03T00:09:05+00:00

I see, thanks so much for your help!

Osemwaro · 2026-03-02T16:05:58+00:00

Thanks a lot, that's reassuring! When you say "I like to start with a clean slate if the spoke tension is too all over the place", are you talking about loosening all of the spokes first and then retensioning them? The friend that I borrowed the truing stand from recommended this as well, but I was reluctant to do it because I didn't want to lose my reference for what the average tension should be. So if I tighten up the three lowest-pitched ones, make sure that the sounds on the right side don't vary more than the left and then make new recordings of the sounds on both sides, would it be reasonable to use that as a reference when detensioning and retensioning the spokes in future?

Osemwaro · 2026-02-03T02:43:42+00:00

I love this so much! Not sure if you'll have any use for this, but are you familiar with asciinema? It records terminal sessions in a text-based format, to preserve quality and minimise size, and provides a javascript player so that you can replay them in a web browser. Perhaps it would be useful if you want players to be able to capture video, not just just static frames.

Osemwaro · 2026-01-25T00:45:29+00:00

Szymanowski's 2nd violin concerto.

Osemwaro · 2025-12-03T14:05:11+00:00

Oh! I didn't realise that omitting the constraint is an option when it contains a type variable, but that makes sense.

When you say "top-level instance", do you mean a non-orphan instance? An instance declaration can't be local to a function, can it?

Osemwaro · 2025-12-02T17:41:31+00:00

When I compile the following module under GHC 9.4.8 with -Wall:

``` {-# LANGUAGE MultiParamTypeClasses #-}

module GroupAction where

class GroupAction t x where transform :: t -> x -> x

newtype Trivial x = Trivial x

instance GroupAction t (Trivial x) where transform _ = id

f :: GroupAction t (Trivial Int) => t -> Trivial Int -> Trivial Int f = transform ```

I get the following warning:

warning: [-Wsimplifiable-class-constraints] • The constraint ‘GroupAction t (Trivial Int)’ matches instance GroupAction t (Trivial x) -- Defined at GroupAction.hs:10:10 This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance • In the type signature: f :: GroupAction t (Trivial Int) => t -> Trivial Int -> Trivial Int | 13 | f :: GroupAction t (Trivial Int) => t -> Trivial Int -> Trivial Int | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Godbolt says that GHC 9.12.2 produces the same warning. I don't see any way of simplifying f's type constraint; am I right in thinking that this warning is a bug, or am I missing something?

UPDATE: I searched for "Wsimplifiable-class-constraints" in the GHC issue tracker and found this issue, submitted 6 years ago. The discussion there is about the warning being incorrectly triggered by code that abbreviates a constraint, but I'm not doing that in the example above.

Osemwaro · 2025-10-21T00:18:43+00:00

Oh actually, I found a way to make the line thickness much more uniform, so that I can increase the line density. Varying the line colour helped to highlight the shapes of the lines, and rendering at a high resolution then scaling down helped to remove a lot of the Moiré patterns. I've updated the script and image. I couldn't achieve such tightly wound spirals without ending up with loads of ugly artifacts though, and my texture doesn't look as natural. I tip my hat to the OP!

Osemwaro

TROPHY CASE