Fix typo in preprocessed-site/posts/2019/hiw-gibbons.md

各言語 -> 書く言語

Co-Authored-By: Kazuki Okamoto <kakkun61@gmail.com>

Author: igrep

preprocessed-site/posts/2019/hiw-gibbons.md

@@ -81,7 +81,7 @@ Gibbonはこの特性を活かすべく、我々Haskellerが好んで使うよ
 例えば[unordered-containers](http://hackage.haskell.org/package/unordered-containers)にある`HashMap`型は探索木を使った頻繁に使われるデータ構造ですが、`HashMap`を使う場合に行う処理の多くは、ランダムアクセスや要素の追加・削除でしょう。
 
 なので、Gibbonが最適化したい「木構造」というのは、どちらかというと探索木のような木ではなく、構文木のような、要素をまとめて処理することを前提とした木のことなのかもしれません。  
-確かに人間が各言語の構文木程度であれば、すべてメモリー上で処理できる程度のサイズに収まる<small>（という想定でなければコンパイラー作りがものすごく難しくなる）</small>でしょうし、構文木の処理を高速化できれば、遅い遅いと言われるGHCのコンパイル速度も高められるはずです。それはそれでありがたい。
+確かに人間が書く言語の構文木程度であれば、すべてメモリー上で処理できる程度のサイズに収まる<small>（という想定でなければコンパイラー作りがものすごく難しくなる）</small>でしょうし、構文木の処理を高速化できれば、遅い遅いと言われるGHCのコンパイル速度も高められるはずです。それはそれでありがたい。
 
 もう一つは、これまた例えば`HashMap`型のような木をベースにした連想配列も、配列ベースのハッシュテーブルに変換することができるのでしょうか？  
 もしそうだとすると、ランダムアクセスに対する計算量のオーダーもO(log n)からO(1)に変わるわけですし、要素をまとめて処理する以外の演算についても劇的な改善が見込めるかもしれません。