kmizuの日記

プログラミングや形式言語に関係のあることを書いたり書かなかったり。

Fortressのお話（あるいは、2007年1月のとあるWeb日記）

昨日、内輪でチャットしているときに、ふと、学部生～修士時代の自分のWeb日記（tDiary）を見てみたくなって、色々発掘してたら、面白いものが出てきてので、張り付けていこうと思います（ほとんどが駄文なので、なんか考古学的に（？）意味があるやつだけ載せる予定です）。で、今日載せるのはFortressの話。当時の日記の文面の原文をそのまま貼っただけなのであれですが、ポシャっちゃったFortressがどういう試みをしていたかという観点で興味深いかなと思います。なお、今の自分に比べて考察とか未熟なところがありますがご容赦を。あと、ツッコミは歓迎ですが、いかんせん当時の自分の考えなので、細かい理由は忘れてる可能性があります。

Fortressは、普通のプログラミング言語ですから、当然配列を使えるわけです。配列型の変数の宣言構文は次のような感じで、これはまあ全然すごくないというか普通です。ちなみに、ZZ32は32bit整数型です。Fotressの言語仕様をちゃんと読んだわけじゃないので、間違ってる可能性もありますが、とりあえず整数型であることは間違いないようです。

arr :ZZ32[3, 3] (* 3*3の2次元配列を宣言 *)

さて、配列をあらかじめ決まった要素で初期化するのにいちいち順番に代入していくのは面倒ですから、Fortressでも他言語のように配列のリテラル表記を使うことができます。

arr :ZZ32[3, 3] = [ 9 8 7
                    6 5 4
                    3 2 1 ]

改行によって配列の行の終わりを示せるというのは、まあ良いでしょう。面白いのは、配列の要素のセパレータとして空白を使うことができるところです。え、面白く無い？いやいや、前回のFortressに関するエントリに書いたのですが、Fotressではx yのように空白で区切って式を並べて書くことで、乗算を書くことができるのです。Fortressの配列リテラルの中では、通常の計算式を書くことができますから、単純に考えて文法を設計したら、

arr :ZZ32[3, 3] = [ (9 8 7)
                    (6 5 4)
                    (3 2 1) ]

のように解釈されてしまうと思うわけです。で、こんな文法になっているということは、「配列リテラルの中に出現する式」だけを特別扱いしているに違い無いと思い、Rats!で書かれたFortressの文法を読んでいたら、案の定そうなっていました。Literal.ratsファイルから該当すると思われる箇所を引用すると、

Expr Literal =
     openparen w closeparen
     { yyValue = new VoidLiteral(createSpan(yyStart,yyCount)); }
   / yyValue:NumericLiteral
   / yyValue:CharLiteral
   / yyValue:StringLiteral
   / opencurly w a1:Entry a2s:(w comma w Entry)* w closecurly
     { List<com.sun.fortress.interpreter.useful.Pair<Expr,Expr>> elements =
           new ArrayList<com.sun.fortress.interpreter.useful.Pair<Expr,Expr>>();
       elements.add(new com.sun.fortress.interpreter.useful.Pair<Expr,Expr>(a1.getKey(), a1.getValue()));
       for (Entry e : (List<Entry>)a2s.list()) {
           elements.add(new com.sun.fortress.interpreter.useful.Pair<Expr,Expr>(e.getKey(), e.getValue()));
       }
       yyValue = new MapExpr(createSpan(yyStart,yyCount), elements);
     }
   / opensquare w yyValue:RectElements w closesquare ;


/* RectElements ::= NoSpaceExpr MultiDimCons* */
MultiDim RectElements =
     a1:NoSpaceExpr a2s:MultiDimCons*
     { if (a2s == null || a2s.isEmpty())
           yyValue = new MultiDimElement(a1.getSpan(), a1);
       else
           yyValue = FortressUtil.multiDimCons(a1, a2s.list());
     };


/* MultiDimCons ::= RectSeparator NoSpaceExpr */
com.sun.fortress.interpreter.useful.Pair<Integer,Expr> MultiDimCons =
     a1:RectSeparator a2:NoSpaceExpr
     { yyValue = new com.sun.fortress.interpreter.useful.Pair<Integer,Expr>(a1,a2); };

赤字で強調したところがポイントで、おそらく配列リテラル中では「NoSpaceExpr」だけが出現できるということなんでしょう。で、この「NoSpaceExpr」が一体何なのかということですが、これは定義が複雑なのでとりあえず置いておきますが、ただ単に「スペースを含まない式」では無いようです。というのは、スペースで区切った式でも()で囲むことで配列リテラル中に書けるからです。

私なりのオブジェクト指向プログラミングの定義

きしださんの以下のツイート

を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは

  • サブタイピングを活用したプログラミング手法の総称

と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型がない言語（Ruby、JavaScript、などなど）についても、実際にプログラミングをしているときは、たとえば「あるオブジェクトはメソッドm1, m2, ...を持っている」と仮定してコードを書いているはずだと思うので、それらは構造的部分型のようなものを使っているものとして考えます。

ここで、クラスもインタフェースも状態のカプセル化も一切でてこないことに違和感を抱かれる方もいると思うので説明します。まず、いわゆるオブジェクト指向プログラミング言語（言語の中でオブジェクトシステムを定義しているもの含む）には非常に様々なものがある、というのが重要です。簡単に分類しただけでも

といったものが思い浮かびます。３番目のものは、いわゆるオブジェクト指向プログラミングの主流派からは外れていますが、個人的にはそれらも含めて考えたいところです。これらの言語のすべてに共通する特徴を考えたときに残るのがサブタイピング（ないし極めて近い概念）を持っているということが挙げられます。というわけで、最大公約数を取ったときにはそうなるだろう、というのが私の結論です。

もちろん、主流のオブジェクト指向プログラミング言語（C++、Javaなど）ではクラスを活用すると思いますが、今やTypeScript（オブジェクトベースかつ、構造的部分型を使った型付け）も非常によく使われるようになってきていますし、それを無視してオブジェクト指向プログラミングを論じるのも無理筋だと思います。さらに、Scalaでよく行われるような、不変オブジェクトとメソッドを組み合わせたプログラミングスタイルも珍しいものではないわけで、可変状態ですら必須でないと言えます。

このように考えたときに、どうしても最後まで残らざるを得ないのがサブタイピングだと考えます。私が挙げた上記の言語すべてがそれらの概念（あるいは極めて近い概念）を持っています。とはいえ、普段、私がオブジェクト指向プログラミングとして意識するのは、クラスベースのオブジェクト指向プログラミング（特にできるだけ状態を不変にする）だったりするのですが、それはおいておきます。また、ここでは、私が思うオブジェクト指向プログラミングの定義について述べましたが、他の人がそれと違った定義をもっていてもいいと思います。

ただ、万人に共通するオブジェクト指向プログラミングのイメージというのは、おそらくもはや存在しないので、それぞれが違うイメージを持っていると認識した上で、定義をすりあわせた上で議論することが重要かなと思います。

Scala, Scala 2, Scala 3, Dotty, DOTの違い：処理系と言語を区別する

はじめに

昨日、 ScalaMatsuri 参加者の一人から、タイトルの用語について、どういう使い分けをされているのかがわからない、といった質問があったので、処理系と言語の区別という観点も踏まえてちょっと整理しておきます。Eugene Yokotaさんから聞いた話としては、Scala 3という用語についてちょっと違う意味合いもあるようなのですが、その辺はツッコミ入れてくださるのではないかと期待しています。

Scala

2019年6月30日現在、普通にScalaといったらプロダクションで普通に使われているScalaの処理系（scalacなど）を指す場合と、その処理系が対象とする言語そのものを指す場合の用法の大まかに二通りがあります。この辺の使い分けは話の文脈に多分に依存していて、たとえば、「Scalaはコンパイルが遅い」「Scala 2.12でコンパイル速度が15%（詳細な数値は忘れました）向上」といったとき、意識していなくても、処理系の方を指していることになります。なぜなら、このとき、Scala「言語」の変化について言っているわけではないですから。一方、「Scala 2.12でSAM type conversionが入った」という話をするとき、主に、言語そのものを指していることになります。標準ライブラリの変化については扱いが難しいですが、どちらかというと言語自体に近いコンテキストになるのではないかと。

Scala 2

これは、1～2年後にリリース予定（要出展）のScala 3と区別する文脈で用いられることが多いです。このときも、「Scala 3ではコンパイルがかなり早くなる」といったときは処理系の話をしていますし、「Scala 3でenumが」とか「implicitについて書き方が変わった（改善された）」というとき、Scala 3（予定）の言語（仕様）について言及しています。

Dotty

これについては若干扱いに困るのですが、基本的には、

github.com

で開発されている、Scala 3（予定）の処理系の現在の実装であるものを指すことがほとんどです（Dottyでコンパイルが大幅に早くなった、Dottyでは将来的にTASTYが入る、など）。ただ、「Dottyでenumが入った」「Dottyでimplicit function typeが入った」「Dottyでhogehoge機能が削られた」という話をしているときは、主に言語の話をしているわけです。ちょっとややこしいのは、DottyはScala 3の処理系になることが既に確定していて、おそらくリポジトリ名なども変更されるかと思います。DottyはまだScala 3になっていないので、「Scala 3でenumが入った」というと未来の仕様の話について過去形で話すというおかしなことになってしまいます。「enumが入った」という過去形で言うならDottyというキーワードを使う方が伝わりやすいのかな、という気がします。

DOT calculus

これについては、上記のよりもだいぶわかりやすいです。元々、Odersky先生（および共同研究をしている人たち、あるいは、研究室の大学院生、そこ出身の研究者）は設計の初期段階から、core calculusの研究を同時に進めていました。発表で話したのですが、

  • vObj calculus: 2003
  • Featherweight Scala: 2006
  • DOT calculus 2012-

といった感じです。そして、DOT calculusについては、各論文において、という形ではありますが、明確に定義されているので、それほどややこしいことはありません。ただ、DOTというcore calculusが開発されはじめて、もう10年近くになるわけですが、その間に、望ましい性質を証明できるように細かい部分に手を加えたり、ということがあり、DOTには複数のバージョンがあります（OOPSLA'16におけるDOT、ECOOP'17におけるDOTみたいな表現が妥当かなと思います）。ただ、基本的にはDOTそのものでプロダクションコード開発するわけではないので、最新のDOTに関する論文を追っかけておけばいいです。私は、説明するときには、どの時点でのDOTの話をするのか明記しましたが。

さらに脇道にそれると、本来のDOTより強い性質を証明したいとか色々な動機によって、μDOTとか、kDOTとか。興味があったら調べてみてください。ところで、全然関係ないのですが、ECOOP'17の論文では、Strong Normalizationについて証明されていたのですね（やはりCoqで証明が書かれている模様）。ただ、これはDOTのvariantであるD<:>についてであって、再帰関数や再帰型（など？）を取り除いたもののようです。

さらにさらに脇道にそれると、Scalaのcore calculusについては変遷があったものの、ようやくDOTが決定版になって（性質を証明するための基盤になったというか）、それのvariantで色々証明するということが行われているようです（この辺はもう全然追えていないですが、DOT関連の論文、プログラミング言語系の国際会議に査読通ってるものも少なからずあるので（OOPSLA、ECOOP、POPL、その他？）、その辺によく出席する研究者の方々の方が詳しいのではないかと思ったり）。

https://2017.ecoop.org/details/ecoop-2017-papers/11/Strong-Normalization-for-Dependent-Object-Types-DOT-

というわけで、ざっくりとその辺について説明してみましたが、参考になれば幸いです。

ScalaMatsuri 2019に参加しました

もう日をまたいでしまいましたが、6/27～6/29にかけて行われた、ScalaMatsuri 2019に参加してきました。まず、総評というかざくっとした感想ですが、とても楽しかったです。特に、アンカンファレンスDayは完全に学生気分に戻っていました。日本のScalaコミュニティに関する活動に関わり始めて、もう10年超になりますが、ここまで規模の大きなコミュニティになるとは思っていなかったなあと感慨深いです（もちろん、比較的初期には、私が貢献した部分があるとはいえ、ある程度成長した後は、その他の方の活動による部分が大きいと思います）。記憶が薄れないうちに、とりあえず備忘録として簡単な記録を残しておきます。

0日目 - ワークショップ DAY

この日は、OSS ハッカソン@ScalaMatsuri 2019に参加しました。この、OSS ハッカソンは、

scalaconfjp.doorkeeper.jp

に説明があるように、Scalaに関係のあるOSSについて、pull requestを送ることを目指すという趣旨のものです。メンテナの方ともうちょっとコミュニケーション取ればよかったかなという思いもあるのですが、scala/scalaのコードを読んだことがないわけでもないし、まあもくもくとやろうという感じで作業をしていました。今回、時間内にpull request送るにあたって、確実にできる単純作業として、標準ライブラリのpublicなclassのpublicなメソッド、可能な限り全てに返り値の型を明記して回るということをやっていたのですが、それに没頭するあまり、買ったばかりのThinkPad A485のEnterキーのキートップが外れるというアクシデントもありました（正確には、Enterキーの調子が途中でおかしくなったのに気づいて、外してもどせば直るんじゃね？という、今おもえばなんでそんなことをした、という暴挙によって壊れたのですが、似たようなものです）。

で、とりあえず pull reqを作ることができました。

github.com

実のところ、この作業、InttelliJ IDEAの、型アノテーションを付けるquick fixにある程度頼りました。その結果、一部コンパイルが通らないというミスがあったりして、修正しました。まだ、修正リクエストがありますが、コメントを見る限り、指摘された点を修正すれば受け入れてもらえそうな気がします。しかし、意外にまだ型を明記してない箇所が多かったことにはちょっと驚きました。中には、結構推論結果が微妙なものになっているケースも見られたので、やはり、少なくともScalaではpublicなメソッドの返り値の型を明記すべきだなと再認識しました。

1日目 - カンファレンスDay

この日は、私が午後一でセッションがあったため、午前中に準備してから家を出たのですが、行く途中に、修正したくなった箇所がでて急遽修正を入れたせいで、同時通訳の方との打ち合わせが長引き、結果セッションに遅刻するという失態を犯してしまいました。大変申し訳ないです。

さて、肝心の私の発表ですが、Scalaの形式化の最新の成果であるDOT計算を説明するというものだったのですが、40分で納めるというのはあまりにも無謀であるということに早めに気づくべきでした。もちろん、操作的意味論とはとか、型付け規則とはとか、抽象構文とは、とか、そのあたりの解説すっとばせばいけた気がするのですが、いきなりDOT計算の説明に入るのもアレですし。

結果として、DOT計算を説明するにあたって必要な前提知識の説明で時間の大半を消費してしまい、DOT計算についてはかなり駆け足になるという結果に終わりました。

ただ、その後、参加者の一人から、アンカファレンスで、説明しきれなかった部分を説明して欲しいという要望があり、私としても中途半端に終わるのは不本意だったので、アンカンファレンスボードに書くことにしました。その結果、翌日のアンカンファレンスDayで本当に続きを発表することになったのですが、それは後にして。

私の発表が終わった後は、他の参加者と技術談義や雑談などをしているうちに時間がどんどん過ぎていき、気が付いたら懇親会の時間になっていました。しかし、なんで、転職する情報がこんなにすぐ伝わっているのか…（もちろん、publicに書いたので知られることがまずいわけじゃないのですが）。

懇親会は例年通りに立食形式で、色々雑談をしながら楽しんで過ごしました。しかし、私は人の顔を覚えるのが相変わらず苦手なため、一方的に私のことを覚えてくださっている方が多数いてなんだか申し訳ない気持ちでいっぱいになりました。なお、翌日に聞いた話によると、有志による二次会、三次会があったらしく、最長で26:00まで残っていた人もいたのだとか。

2日目 アンカンファレンスDay

私にとって、今年のScalaMatsuriはある意味この日が本番だったのではないか、と思います。アンカンファレンスDayでは、朝会というものがあり、10:00に参加者が集まって、アンカンファレンスボードの中から、人気があるものを司会者が選び、スケジューリングをするのですが、DOT計算については大変要望が多く、割と早めに決まりました（前日の投票数見た時点で、おそらくやることになるだろうなと思ったので、絶対に朝寝坊しないぞという強い決意がありました）。そして、ここでなにかが吹っ切れたのか、他の方が書いたネタのセッションについても私の方から、「その話なら俺も乗った！」というノリでどんどん挙手した結果、最終的には計4セッションしゃべるという羽目になりました。今思えば無茶をしたものです。

新卒の参加者に皆でScalaを教える

確か、ボードに書かれていたネタは「新卒ScalaエンジニアなんだけどScala教えてくれ」みたいな話だったと記憶していますが、朝会で「じゃあ、私が教えます」とかノリで言った結果、私もしゃべることになりました。ちょっと私が進行役がうまくなかったせいで「具体的にここがわからない」という話にもっていけなかったのは、ちょっと反省するところです。ただ、初学者がsbtでつまづくポイントとかの一部を伝えられたのはよかったのかなと思います。

DOT計算の話の続き

ある意味前日のリベンジみたいなものですが、完全にとはいえないものの、伝えたいものはなんとか伝えられたかなと思います。ただ、DOT計算の型付け規則で構成される型システムのややこしさについては、私はちょっと甘くみていたというか、細かく説明する段になって、自分の理解が深くなかった（特に、型メンバ関連のサブタイプ関係の定義）のでつまづいたのは反省ポイントですね。あと、DOTの操作的意味論の部分に話がうつった段階で、「まあ、（DOTの）操作的意味論はみればわかるように簡単ですねー」とか軽く言っちゃったったんですが、その「簡単さ」の感じは伝わっていなかったような気がします。

Go VS. Scala

ボードでは「From Go to Scala」だったかなんだかで、Simple VS. Easyという話が主題でした。このセッションは、パネル形式でしたが、たぶんアンカンファレンスの中でもかなり盛り上がったのではないかと思います。当初、GoとScalaの比較だったはずだったのが、KotlinとかSwiftとかC++とか話が広がっていくあたりの（良い意味での）ぐだぐだ感は、アンカンファレンスらしく、非常に楽しいものでした（アンカンファレンスは、盛り上がりをコントロールできないところがひとつの醍醐味だと思っています）。どういう話だったのかは、 #ScalaMatsuri とかでTwitterを検索するとなんとなくわかるかもしれません。

面白論文を紹介するよ

空いた枠があったので、急遽スポット参戦した感じなのですが、とりあえず久しぶりに論文解説でもしてみよー、というノリでやってみました（すでにScalaが関係なくなっている辺り、アレですね）。ちょっと反応が薄かったのが気になったのですが、Twitterの反響を見る限り、つまらないとかいうわけではなく、話の内容を噛み砕くのに精いっぱいだったのかな、という気もしました（これは、私があんまりうまく説明できなかったなと思うところですが）。

そんなこんなで、この日はほとんど発表で埋まっていたので、あまり合間に雑談する余裕はなかったのですが、テンションで乗り切った感じです（笑）。

最後に

今年のScalaMatsuriも「祭り」にふさわしい盛り上がりがあって良かったです（スタッフの方、特に座長は大変だったと思いますが）。来年は久しぶりにスタッフとして復帰できたら、と思っています。ではでは。

株式会社ドワンゴを退職します

はじめに

当初、ScalaMatsuri 2019が終わった次の日の、6月30日に書く予定だったのですが、最終出社日も終わっていることだしよいかということで、エントリを書くことにします。 2019年6月30日をもって、5年と3か月勤めた株式会社ドワンゴを退職します。最終出社日は6月26日でした。

これまで2回転職してきましたが、ドワンゴに居た期間が最長です（なお、5年で最長でというのに違和感感じる人もいるかもですが、博士卒で就職したので、まあそんなもんかと思っています）。

何やってたの

1年目こそプロダクト開発に携わっていたものの、2年目以降は、

  • Scala研修テキストの執筆やメンテナンス
  • 新入社員研修の中のScala研修講師
  • ドワンゴ社員として各種イベントやカンファレンスで発表
  • 論文の査読や情報処理学会関連のイベント（主にPRO（プログラミング研究会））への参加
  • 自分主催の勉強会（テーマは気分によってころころ変わっていましたが）
  • 国内Scalaコミュニティへの貢献（できていたかは自信がありませんが）
  • その他色々

という感じで、あまりプロダクトコードを書いていると胸を張って言えるものではなかったです。

おそらく、当時の自分では、他の会社でこういった雑多な行為が業務として認められることはおそらく稀だと思うので、これはとても幸運でした。理由としては、当初から、ある程度そういった採用につなげる（広報や宣伝）役割を期待されていた、というのが大きかったというのがあります。一方で、しばしば体調を崩すことのある私への配慮という面もあったのではないか、と感じています。副業で（ドワンゴでは申請すれば副業（兼業）が許可されています）なにがしかを書いていることはありましたが。実際のところ、この役割（採用につなげる）についてはあまり定量化できてはいなかったのですが、私がいるということが入社の動機の一つになった人は思ったより居たようだ、というのを最近になって実感しています。

最近はかなりよくなったとはいえ、体調を崩すことがしばしばあった私が勤務できたのは、ひとえにドワンゴの環境と、特に所属部署の上長の柔軟な対応があってこそだと思います。とても感謝しています。

退職理由

人間関係が悪かったわけでもなく、問題行動を起こしたわけでもなく、評価が下がったわけでもなく、モチベーションが下がったわけでもなく、上司と折り合いが悪かったわけでもなく、体調が悪くなったわけでもなく、…と書けば、想像はつくかと思いますが、ドワンゴ「自体」を取り巻く環境の変化によるものです（その辺はなんとなく察していただければ）。

ただ、これは副要因というか後付けなのですが、一人のエンジニアとして、ドワンゴに入社して2年目以降、プロダクト開発から多少距離ができていたことに後ろめたさがついてまわっていました。簡単にいうと、「俺はなんだかんだ勉強会でたいそうなことをいっているけど、自分はどれだけプロダクトコードを書いているのだい？」という自分の中での葛藤です（ドワンゴの前は普通以上にはプロダクト開発に関わっていましたが）。もちろん、途中のどこかで、開発メインのチームに復帰するという道はあったかと思いますが、私がすでにそれなりに対外的な知名度が上がってしまった（らしい）のと、体調を崩して迷惑をかけたら、という懸念があり、動きづらく感じていた、ということはあります。。これは、上長が悪い、とかいう話ではなくて、基本的には自分の問題だと認識しています。むしろ、上長はとても配慮してくれていました。

主要因に加えて、そういった副要因もあり、転職を決意することにしました。

転職先

次の職場は既に決まっており、7月1日から、株式会社オプトさんでエンジニアとして働くことになっております。

https://opt-technologies.jp/

引き続き、Scalaコミュニティへの貢献は続けていきますし、所属会社のアピールという、これまでドワンゴで担っていた役割も担うと思いますが、Scalaにとらわれず、教育やこれまで避けてきた技術の習得、マネジメントについても積極的に挑戦してみたいと考えています。エンジニアでありたいという願望は強いので、再び普通にプロダクト開発にも携わると思います。ただ、同時に、私は研究への思い入れがとても強く（そのため、博士号を取った後は査読付き論文を一本も執筆していないにも関わらず、ICFPに参加したり、PROに参加したり、論文査読を引き受けたり、学会の運営委員を引き受けたりしていました）、そろそろ色々温めていたアイデアを論文としてアウトプットすることを考えているところです。この両立がどこまでうまくいくかどうかは入社してみないとわかりませんが、基本的には楽観視しています。

最後に

5年と3か月、ドワンゴには大変お世話になりました。ありがとうございます。ドワンゴにまだ残っているエンジニアの友人たちとも交流を続けたいと思っています。

おまけ

いい機会なので、主にこれから学んでみたいことやあまり学んでこなかった事に関する本をウィッシュリストにしてみました。もしよければお祝いください。

https://www.amazon.jp/hz/wishlist/ls/2W4BD3FUNVD4H?ref_=wl_share

これから、また会う機会の会う人も多いかと思いますが、これからもよろしくお願いします。

自作パーザコンビネータライブラリを集めたリポジトリ mlcombinators を公開しました

私がプログラミング言語を学ぶときには、パーザコンビネータライブラリを作る、ということはScala福岡2019の講演とかでも他のところでもよく言っていることなのですが、せっかくなので、これまで私が作ってきたミニパーザコンビネータライブラリ集をひとつのリポジトリにまとめて公開することにしてみました。もちろん、これだけでは到底実用に耐えないことは言うまでもないです。

github.com

なお、mlはプログラミング言語のMLとはあまり関係なくて、multi-languagesくらいの意味です。それはともかく、このリポジトリには、私がそれらのプログラミング言語を学びたての頃（一部例外あり）にどのようにしてパーザコンビネータライブラリを組み立てたのか試行錯誤の跡が残っており、ひょっとしたらどなたかの参考になるかもしれません。

実は、これ以外にもC#とかCとかもっと色々なものについてパーザコンビネータライブラリを作った気がするのですが、その辺はGitHub以前（？）だったせいか、残っていないようです。

ではでは。

（追記）その言語のプロからみると、ここがいけてないとか色々言いたいことはあると思いますが、その辺はIssue立てるなりPull Requestしていただけたらベストエフォートで対応します。

実践Scala入門（共著）が発売されます

https://www.amazon.co.jp/dp/4297101416

企画自体は2015年くらいから始まっていたんですが、紆余曲折あって、約3年経ってしまいました。ともあれ、ようやく出版までこぎつけられてほっと一息です。 実際には多少遅れる可能性がありますが、10月27日から技術評論社さんから発売予定なので、この機会にScalaを勉強してみたい方は、是非予約していただければと思います。 さて、書いてる間の紆余曲折書いても意味がないので、このエントリでは、この書籍のウリを簡単に書きたいと思います。

現状の日本語のScala書籍は、大半が新しいバージョンのScalaに追随できてなくて、新しくScalaに入門する人に勧められるいい書籍が ほとんどないという問題意識がありました。いわゆるコップ本はScala書籍の中でもかなり売れていることもあってか、2.12対応の第三版まで出版されているものの、 重厚長大であるために敬遠する人が多いという課題があります。というわけで、もうちょっと「コンパクトなコップ本」があるといいなということで、それが今回の 実践Scala入門のコンセプトになっています。

「コンパクトなコップ本」というのが何を指しているのかですが、コップ本の中で特に重要だと私たち（共著者）が考えたものをピックアップして、もうちょっと 手軽に読めるものを作ろうといったところです。ページ数もコップ本に比べてだいぶ少なめなので、コップ本に挫折した人にも比較的気軽に手に取ってもらえる とうれしいと思っています。ちなみに、Scalaのバージョンは2.12.7対応です。

もう一つのウリは、入門本でありながら、単に言語の解説に終始するのではなく、sbtの使い方やテストの書き方、コレクションライブラリの使い方など、ある程度 実践寄りの内容も盛り込んだところです。この書籍だけで実践のための知識が十分に身につくとは、もちろんいいがたいですが、「おわりに」で今後のための参考文献 も示してあるので、リストアップした参考文献を元によりステップアップしていってもらえればと思います。

ただ、実践寄りの内容「も」あるとはいえ、あくまで入門書であるので、Scalaでプロダクションコードを書くためのノウハウががっつり詰まった本を期待されると ミスマッチが発生するかもしれません。

ちなみに、目次はこんな感じです。

  • はじめに
  • 第1章「Scalaひとめぐり」
  • 第2章「Scalaの基礎」
  • 第3章「Option/Either/Tryによるエラー処理」
  • 第4章「コレクション」
  • 第5章「並行プログラミング」
  • 第6章「Scalaプロジェクトのビルド」
  • 第7章「ユニットテスト」
  • 第8章「知っておきたい応用的な構文」
  • 第9章「よりよいコーディングを目指して」
  • おわりに

なお、実践Scala入門はScala入門書ではあっても、プログラミング入門書ではない（最低1つのプログラミング言語を習得していることを前提とする）のでその点は注意していただければと思います。

そのあたりを踏まえた上で、購入を検討していただければ幸いです。