関数やIOモナド，スレッド間通信などがからむので，”Parallel and Concurrent Programming in Haskell”を電子書籍で購入して並行プログラミング関係だけ読み，初歩はマスターできました。このプロジェクトではマルチスレッド間の資源の取り合いはほとんどないので，できるだけ例外をマスクして，Eitherなどで把握・対処するようにしています。STMを利用したチャンネルで，スレッド間の通信をおこなうようにしました。
Haskell用TUIライブラリを使ってみた
Brickを使ってみました。GUIの基礎概念は知ってはいましたが，使ってみたのはほぼ初めて。プログラミングをよくやっていたのは学生時代で，まだGUIが一般的でない時代にPascalやModula II でPOSシステム，パソコン通信プログラム（端末エミュレータ）などを作っていました。まだオブジェクト指向という考えが広まる前で，インタフェースもGUI普及前。ユーザーとしては，まわりがワープロを使っている時代にMacintosh Plusで卒業論文を書いていたのでまさにエバンジェリストといった感じでしたが，イベント処理とか，GUIやオブジェクト指向でのクラスとかいった概念は，Smalltalkでちょっと触ったくらい。学び直しました。とはいえ，Brickのドキュメントを読むと一通り書いてあるので，それで済ませましたが。
Rover Mini の ECUデータ読み出しプログラムを動作させるためにRaspberryPiを用意したのだが，Haskellのコンパイルがstackを使ってはできなかった。stackが使えないと，ライブラリの準備とかが大変。
発生していた問題
stack buildすると，アセンブラが，この機械語はARMでは使えないとのたまうエラー発生。
/tmp/ghc2452_0/ghc_6.s:44:0: error:
Error: selected processor does not support `movt r7,:upper16:stg_bh_upd_frame_info' in ARM mode
|
44 | movt r7, :upper16:stg_bh_upd_frame_info
| ^
コマンド7Dで得られるデータ数が，ずいぶん少ない14バイトであることが判明（MEMS Gaugeは32バイトを設定している）。MEMS Gaugeのサイトはある程度年式の新しいモデルに対応していたが，こちらは1992年に買った，クーラー付きの日本モデルであり，別のサイトで見るとECUのモデル番号も桁数からして違っている（うちのMiniのECUモデルを表す4バイトの値は39 00 00 5Cという値であり，おそらく部品番号 MNE10078 の， Manual SPI – Japan – Cooper 向け）。
ECUのログを見ると2016年4月3日のものが残っていたので，遅くともその頃から実際に試行錯誤していたはずだが，記事として出てくるのは2016年から。Amazonの注文履歴では2013年に入門Haskellを，2014年にはReal World Haskellを，2016年にはRaspberry Pi 2Bとディスプレイを発注した記録が残っている。MEMS Gaugeのタイムスタンプは2016年2月。また，非公開の書きかけ記事で関数型言語プログラミングのデザインパターンに関するものが2015年5月2日付けで見つかった。HaskellをECUデータ読み出し用に使おうとしだしたのは2015年から2016年にかけてか。
かつて学生時代，パソコン通信華やかりし頃の1980年代後半，PC-9800シリーズなどのDOS上でTurbo Pascalや，Pascalを開発したWirthが後継として開発した言語，Modula-2を使って端末エミュレーションプログラムなどを作っていました。ですのでシリアル通信の大枠は理解しているのですが，今回はmacOSというUnix系のOSで，しかもUSBポートを通じてのシリアル通信ですので，いろいろよくわからない点があります。そこでまずはLinux Serial HOWTOなどであらためて基礎から勉強してみました。
これは，関数の型シグネチャである。意味するところは，「square は，整数型の引数 x をとり，整数型の結果を出力する関数」である。 square が int を出力すると特定されているのは，掛け算が特定のいくつかの型のみに有効な演算だとコンパイラがわかっているので，このことをもとに，この時点では int を選んでいる。だが，引数の型を別の型，例えば float に変えたとしたら，関数の型シグネチャも自動的に変わる。
HTML + JavaScript ユーザインタフェースを作成する際、HTMLの機能をすべて使用することができる。これは素晴らしいことではあるが、うっかりするとはまり込んでしまうことにもなりかねない。それゆえ、このライブラリには、CSSを使用しなくてもユーザインタフェースを素早く構築できるよう、レイアウトコンビネータが含まれている。またFFI（Foregin function interface; 他言語接続機能）を利用してブラウザの中でJavaScriptを走らせることも可能である。
ウェブのフロントエンドではない。サーバはローカルホストで稼働することを想定している。（ネットを経由する）ウェブアプリとして使用するには遅延が問題となるだろう。つまり、ローカルネットワークの多数のユーザーを想定した場面には向いているということ。サンプルコードの Chat.hs example を参照。
JavaScript や HTML のライブラリではない。Threepenny-gui は Haskell の API を備える GUI フレームワークであり、ドキュメント・オブジェクトモデルについて様々なことを抽象化している。Threepenny-gui を使うにあたっては、 HTML については多少の知識が必要だが、JavaScript の知識は必要ではない。もっとも、外部クライアントライブラリを活用とする場合はその限りではないが。
ウェブアプリを作ろうとしているなら、他のプロジェクト（たとえばFay, GHCJS, Haste など)を参照のこと。Threepenny の API はこれらのプロジェクトにいくらか影響を与えている、もしくは将来与えることになるかもしれないが、現時点ではそこ（ウェブアプリ開発向きの機能）に焦点はあたっていない。
