Supported by our EPSRC HAFLANG project.

haflang.github.io

Credit www.reddit.com/r/therewasan...

The final post-reviewed paper will be published by Springer in a few months.

The work is supported by the EPSRC HAFLANG project.

haflang.github.io

Structured combinators are hardware-friendly encodings that more directly represent user functions compared to fine-grained SKI combinators, meaning generated programs are shorter. Our compiler supports Haskell 2010, and employs code-gen strategies to support full laziness and minimise program size.

A list of more architectures would be great, I would happily add them to the timeline. Thanks for your interest.

If you provide me with a list of related computer architectures that I've missed entirely from this timeline, I would be very grateful to receive this to update the timeline.

And Gyula Magó's cellular's processor architecture here:

haflang.github.io/history#even...

I mention Keller's (Utah) LISP machine here:

haflang.github.io/history#even...

As for a Japanese machine, I very briefly mention the Evlis machine here, though you may have a different machine in mind:

haflang.github.io/history#even...

And the Knight Machine at MIT machine that supported LISP in 1973, but perhaps that's a different MIT machine to the one you had in mind?

haflang.github.io/history#even...

I completely agree about how important dataflow architectures were in the 1980s. I (briefly) mention the Manchester dataflow machine in the timeline:

haflang.github.io/history#even...

Tiny suggestion - I'm unsure whether the 1st edition included an example of recursive Eval monad parallelism. Performance-wise, `runEval` is free, recursive calls to it doesn't have overhead. See the attached example. Apologies if recursive `runEval` calls is discussed, I must've missed it.

Which is to ask: could a 2nd edition of the book be as clear as saying: if you're not in the habit of representing your computations as lazy data structures and you don't wish to familiarise yourself with evaluation strategies, then use the simpler Par monad API?

When I advocate for the Eval monad in lectures, my analogy is it's parallel *breadth-first* search. E.g. the sudoku solver in your book, you want to eat away at lots of possible solutions rather than going down the rabbit hole of one: if you can fully embrace laziness, the Eval monad is for you.

Any more reflections you have about Eval vs Par monads would be great. I still teach rpar/rseq, but I understand that @nishiorain.bsky.social taught using the Par monad. Could like-for-like code examples and their performance be given to demonstrate these pros/cons:

www.oreilly.com/library/view...

Perhaps expanding on your December 2018 views about distributed-process on the parallel-haskell mailing list would be offer a retrospective insight about that library.

groups.google.com/g/parallel-h...

Today I added a slide about the collapse of the LISP machine market around 1987.

haflang.github.io/history.html...

Laura's website:

lauralisabeth.academia.edu