taolson

Agreed. But there's a big difference between parametric polymorphism (List<A>) and ad-hoc polymorphism like typeclasses. It would be very painful to have to write a new list type for any kind of value type it might hold, but with monads you have many fewer distinct implementations (mainly just Maybe / Either / List / State / IO) and their actions are so different that you almost have to know exactly which monad you are using in the code, so "generic" code that can operate with any monad is less useful.

That may be true for functions which operate on a generic Monad typeclass, but typeclasses (Higher kinded types) aren't required to implement concrete Functor / Applicative / Monad instances for a particular type, e.g. Maybe:

    fmap f Nothing = Nothing
    fmap f (Just x) = Just (f x)

    pure x = Just x

    Nothing >>= f = Nothing
    Just x >>= f = f x

In a lazy language like Haskell, the order in which things are actually evaluated is f -> g -> h -> x, because arguments to a function are only evaluated when the are needed, rather than before they are called. But even so, I still prefer writing it as x |> h |> g |> f.

Yes, that's an even better picture! Austrian air-force version, right?

Congrats to the Squeak 6.1 team! I was an early contributor to Squeak from when Alan Kay's group was at Apple (I see that SameGame, the first game implemented in Morphic is still in the image), and still enjoy following the progress of Squeak and all of its spinoffs.

Since your language is very "rust-like", what made you choose Ocaml as the implementation language?

The FPU in the 29050 was based on the Am29325 bit-slice family FPU; an extra write port was added to the register file to allow for asynchronous FPU result writeback, which allowed the parallel operation.

gr2 and gr3 were used in the 29050 for FP condition code registers, but otherwise I'm pretty sure accessing the rest caused a trap.

The registers could also be partitioned into fixed sizes and protected, to allow for a banked register file that allowed for amazingly fast context switches in RTOS systems.

> Well that was basically an am29000 but with an x86 instruction decoder front end.

The K5 was based upon a 29K-family design, but it was actually an un-released superscalar project code-named "Jaguar", rather than just a 29K with an x86 decoder.

Yep, it wound up as the main CPU in a bunch of laser-printers, as well as Apple's 8*24GC QuickDraw accelerator card for the Macintosh, and as part of the flight-control computer on Boeing 777s, among many other embedded system designs.

Wow, blast from the past! I was on the architecture / micro-architecture team for the 29K and 29050, and your story of writing and debugging the emulator brought up similar memories of working on the performance simulator for these chips.

Very impressive work -- congratulations!