kmizuの日記

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

Macro PEG再考:名前呼び出しと値呼び出し

Macro PEGは、私が2016年頃に、PEGに対する拡張として提案したものです。2016年のプログラミング研究会で発表したスライドが

kmizu.github.io

にあります。さて、当時考えたMacro PEGは、Macro PEGの引数付き規則を名前呼び出し(call by name)として評価するものでした。たとえば、

S = Twice("a")*;
Twice(A) = A A;

というMacro PEGがあったとき、Sから開始して、引数付き規則 Twice を引数 "a" で呼び出すと、Aは式"a"をそのまま束縛し、呼び出され側に展開される形になります。このため、これが受理する言語は、

L = {"aa", "aaaa", "aaaaaa", ...}

といったものになります。当時、値呼び出し(call by value)を検討したものの、あまり面白いことができなさそうだったので、名前呼び出しを採用したという経緯があったのですが、最近、改めて値呼び出しにした場合にどのようなことができるかを考えてみることにしました。

まず、PEGにおける「値」とは何かが曖昧なのですが、ここでは、ある式(parsing expression)に対してマッチした文字列だということにします。たとえば、

S = "a"*;

を入力 aaa に対して評価した場合、Sを評価した値はaaaになるものとします。このような考えに基づいて、Macro PEGの評価戦略として値呼び出しも選べるようにしました。

簡単な例で説明すると、

S = Twice("a")*;
Twice(A) = A A;

というMacro PEGは、値呼び出しの場合、先に、引数"a"と現在の入力文字列とのマッチが行われ、Aがその結果の文字列"a"を束縛して、Twiceを呼び出すものとします。ここで、さらに、

    1. 引数の評価の際に消費された文字列の続きから評価を続けるか
    1. 引数の評価の際に消費された文字列はいったん戻してから評価を続けるか

の二通りが考えられますが、まず、1.について考えてみます。

入力aaaに対して、1.の戦略で評価した場合、まず、引数の評価でaが消費され、残りの入力がaa、Aに"a"が束縛された状態で、評価が継続されます。その後、A Aとのマッチを続けるので、結果として、値はaaaになります。

一方、2.の戦略で評価した場合、まず、引数の評価の結果、A"a"が束縛された状態で、かつ、入力が消費されていない状態で、評価が継続されます。その後、A Aとのマッチを続けるので、結果として、値はaaになります。

さて、これだけだと値呼び出しにしてもあまり面白いことがないように思えますが、この「消費した文字列と引数を結びつけて、呼び出し先で使える」という性質を使って、XMLのタグの対応を書くことができます。

1.と2.のどちらでも実装できるのですが、1.の戦略だと、次のような感じになります。

S = F("<", [a-zA-Z_]+, ">"); 
F(LT, N, GT) = F("<", [a-zA-Z_]+, ">")* LT "/" N GT;

入力<a><b></b></a>に対して、マッチを試みてみます。

まず、XMLの開きタグをチェックするために、引数に "<", [a-zA-Z_]+, ">" を渡してマッチを行います(複数の引数がある場合は、前から順番に評価が行われるものとします)。引数の評価が終わった時点で、残りの文字列は<b></b></a>になります。

この状態で、LT=<N=aGT>としてFが呼び出されます。Fの中では再帰的にFを呼んでいます。一見左再帰のようにみえますが、引数の評価が失敗した場合、呼び出し自体も失敗するために左再帰になりません。F("<", [a-zA-Z_]+, ">")*の評価が終わった時点で、残りの入力文字列は</a>になっています。これは、LT "/" N GTとマッチするので全体が成功します。

このようにすることで、値呼び出しではXMLのタグの対応をチェック可能なことがわかりました。ちなみに、2.の戦略の場合でも、

S = "<" F([a-zA-Z_]+); 
F(N) = N ">" ("<" F([a-zA-Z_]+))* "</" N ">";

とすることで、同じことを表現することができます。これをもう少し一般化した表現で考えると、Macro PEGの値呼び出しは、実質的に後方参照とほぼ等しい機能をもっていると言えそうに思います。

ちなみに、値呼び出しと名前呼び出しを組み合わせることで、次のように、「未宣言の変数の出現を構文エラーにする」といった強力な記述が可能になります(のはずです)。*は名前呼び出し、!は値呼び出しを表すプレフィックスとします。

Id <- [a-zA-Z_]+
Int <- [0-9]+

Statements(*table) <- "val " ValCont(table, Id) | Expression(table) ";" Statements(table)

ValCont(*table, !id) <- id "=" Expression ";" Statements(table | id)?

Expression(*table) <- &table Id | Int

このMacro PEGは、val x=1;x;1;val x=1;val y=2;x;y;のような文字列を受理しますが、val x=1;z;のように、まだvalで宣言されていない変数が出現するような列を受理しません。

Macro PEGは名前呼び出しを使うことによって、引数に変数表のような役割を持たせることが可能で、一方で、値呼び出しによって、出現した名前を変数に入れておけるため、このような表現をすることが可能になりました。

名前呼び出しと値呼び出しを注釈によって使い分けられるMacro PEGの表現力はかなり強いのではないかと思えますが、どのくらいの言語が表現できるかはまだ未知ですが、色々面白い言語が表現できそうです。ちなみに、注釈はまだなものの、名前呼び出しと値呼び出し(2種類)は既に

GitHub - kmizu/macro_peg: Macro PEG: PEG with macro-like rules

実装してあり、ことができます(名前呼び出しの方は、パーザコンビネータ版しかテスト書いてませんが)。

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」が一体何なのかということですが、これは定義が複雑なのでとりあえず置いておきますが、ただ単に「スペースを含まない式」では無いようです。というのは、スペースで区切った式でも()で囲むことで配列リテラル中に書けるからです。

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

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

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

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

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

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

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

もちろん、主流のオブジェクト指向プログラミング言語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していただけたらベストエフォートで対応します。