食べすぎた
— うたがわきき🔰💊 (@utgwkk) 2019年1月29日
また食べすぎた、飲酒翌日にラーメン食べないほうがいいのではないか
— うたがわきき🔰💊 (@utgwkk) 2019年1月31日
絶対に卒業してやるという強い意志をごはんに込めた結果，食べすぎました
— うたがわきき🔰💊 (@utgwkk) 2019年2月4日
ここ1週間ぐらいずっと食べすぎている気がする． 卒論のストレスのことを考えると，試問会が終わるまでは食べすぎる傾向にあると思うので，終わったら運動のこととか考えたい．
今年もYAPCに参加しました．学生支援プログラムのおかげで気軽にYAPCに参加することができており，スポンサー企業の皆様やスタッフの皆様には頭が上がりません．次回もよろしくお願いします．
トークの合間にGMOインターネット様のPerl6チャレンジに取り組んでいました． ふだんはPerl6とも正規表現とも遠い生活を送っており，Perl6の正規表現は初めて書きました． 記法に慣れないところもありましたが，なんとか午前の部でTシャツを入手することができてよかったです．
Perlチャレンジ午前の部がクローズ！
— inamoly (@inamoly) 2019年1月26日
速度チャレンジは @titsuki ＠ kawa. fm @utgwkk @sekai67 の4名の皆さん。
名回答賞は rfcまで意識された @dankogai さん。 皆さんおめでとうございます！！
Tシャツをプレゼントしたいので、ブースまでお越しください！午後の部は14:00から #yapcjapan pic.twitter.com/iY8JszUbze
今回はトークに関するメモはScrapboxに取っていました．
id:dankogaiさんによるトーク．context-orientedな動的型というのはPerl以外では見たことない*1ので驚きがありました． 人類さんサイドもそろそろ静的型に寄せていったほうがいいのではないかというのをいつも思っているけど，いきなり全部寄せることができるのなら苦労しないわけで……．
id:mackee_wさんによるトーク．毎回使うスニペットぐらいの規模感のコードを正規表現を使ってうまく静的検査するといった向きで，正規表現ぐらいだと手軽に使えてニーズがあるのだろうなと思うなどしました． ちゃんとやるとパーサとか書かないといけないと思うけど，定型のコードを書くことが保証されているなら正規表現でいける？ 「括弧の対応を正規表現で取る」と聞くと一瞬ぎょっとしますね*2．
id:anatofuzさんによるトーク．古いPerlのほうがいがいとビルドしやすいというのは驚きがあって面白かったです． 前夜祭のLTでもそうだけどPerl6の処理系の話なんかもあってよかった． 懇親会のときにいろいろ話して，研究のこととか，継続を基本とするC言語のこととか話したり聞いたりした末に正体が明らかになるみたいな展開がありました．
id:karupaneruraさんによるトーク．ISUCONの作問の心構えが詰まっていました． 複数人で作業するときはオフラインで集まる機会を作るのがよいというのがなるほどとなって，自分がやるととりあえずオンラインでなんとかならないか，と考えてしまいそう．
tokuhiromuさんによるキーノート．コミュニティに対する貢献のためにはどうしたらいいか，とか，気負いすぎるのもよくない，みたいな話でした． 検索エンジンに引っかかる形でアウトプットをすることがコミュニティへの貢献につながる，という話に背中を押された方がいっぱいいたと思います． ところで私はさいきん研究のコードぐらいしかまともに書いてないですね．卒業確定したら考えたい……．
今回聞いたトーク，かなり処理系とか静的解析とかそっちに寄ってるなーというのにじぶんの興味分野が見えてくるような気がしますね． なんかいろいろなところで正規表現を見たような気がしていて，Perlの人はほんとうに正規表現が好きなんだなあとなった記憶があります．
そろそろサークルの外でも人前に立って話せるぐらいのことがあるのではないか，みたいな気持ちが出てきて，まずはLTからでもやってみるか？ となったので，卒論が片付いたら考えてみようかな……．
繰り返しになりますが，スタッフの皆様，スポンサー企業の皆様，参加者の皆様，そしてさまざまな皆様に感謝の意を申し上げて記事の締めとさせていただきます．
ここ数日よく絵を描いている． 描いているといっても記号の切り取りぐらいのようなものだが，それでも限定された構図ぐらいならなんとかなっているような気がしている． いろいろな描き方とか構造への理解とかをやっていくとだんだんマシになっていくのではなかろうか．
ちょっと前までは，紙に絵を描くときは，ペンとしてフリクションを使い，紙としてはなにかのノベルティでもらった付箋や大学ノートを使っていた． フリクションで濃淡を付けるのはとても難しいし，紙にロゴや罫線が入っているとどうしても気になる． 思い立って鉛筆と自由帳を買った．なぜ自由帳なのかというと近所のスーパーにスケッチブックがなかったから．
どちらかというと白い紙のほうが効能があったような気がする． じぶんの手元にあるノートに罫線などを気にしないで描けるのはすばらしい体験で，これを小学校低学年のうちに終わらせてしまうのは勿体ないのではないか．
ところで構造への理解の話に戻ると，マグロナちゃんが先日の配信でいいことを言っていた．
この配信では，一貫して「実際の頭蓋の構造を頭に入れておく」「実際の頭蓋をベースにどうデフォルメするか考える」ということを言っている． すごく大事なことで，リアルの頭蓋の構造が理解できていないと，どうデフォルメしたのか・してないのか分からないまま描いていくことになって，たまたまうまくいくと作品になるけどうまくいかなかったらなんかおかしいで終わってしまう．
私が所属するサークル「KMC(京大マイコンクラブ)」では，2013年から毎年アドベントカレンダーを開催しています．また，イラストを投稿するアドベントカレンダーも2016年から開催しています．
さて，今年のアドベントカレンダーに関してこっそり始めた取り組みとして，表題にあるような自動ツイートを仕込んでみた，というのがあります．
KMC Advent Calendar 2018 21 日目の記事です！ https://t.co/3SKHAfnrTz
— 京大マイコンクラブ (@KMC_JP) 2018年12月21日
KMC お絵描き Advent Calendar 2018 23 日目のイラストです！ https://t.co/3OARKZMeqm
— 京大マイコンクラブ (@KMC_JP) 2018年12月22日
これ自体を仕込む方法はそんなに難しくないので具体的な手順は省きます．IFTTTのUIが今と同等ぐらいであるうちはぽちぽち押していくとできると思います．
一番大事なポイントだけ紹介しておきますと，AdventarのRSSフィードは記事の情報を次のようにして保持しています．
<item> <title>KMC Advent Calendar 2018 21 日目</title> <description>電子工作系なにか 間に合わなかったらポエム</description> <pubDate>21 Dec 2018</pubDate> <link>http://www2.hatenadiary.jp/entry/uart-kobanashi</link> <guid>57819</guid> </item>
したがってTweet textを次のように設定すると，先述したように日付入りで宣伝ツイートをしてくれる，という仕組みになっています．
{{EntryTitle}}の記事です！ {{EntryUrl}}
かつてはアドベントカレンダーの宣伝のために，広報担当者*1が手で記事の一覧を更新したり，更新があるごとに手で宣伝ツイートをしたりしていました． このうちAdventarで枠の管理をし，宣伝ブログ記事にも枠を作る，という二度手間は解消されました． しかし宣伝ツイートのほうは今までどおりのままでした．
ところでAdventarにはRSSフィードがあるし，IFTTTでレシピを仕込めば自動でツイートしてくれるじゃん，と思って今年から始めたのが先述した取り組みでした． いろいろ思うところがあって，いちばん思っていたこととして「人間の手間を最小にしたい」とか「簡単に自動化できるならやればよい」というのがあります． というわけでこの取り組みを仕込んでみた次第です．
この方法には1つ欠点があり，それは遅刻への対応が不十分である，ということです． これは想像なのですが，RSSの最新よりNアイテム前に新しいアイテムが追加されても検知されないのでしょう． したがっていくつかツイートできなかったものがあったので，手で予約ツイートを仕込むなどの行いが発生しています． まあまあうまくいっていると思っているのですがこれはどうにかしたいですね．
団体としてアドベントカレンダーをやる目的っていろいろあると思うんですけど，まあどういう経緯で行われたのかはさておき，うちの部員ってめちゃくちゃおもしろそうなことをやっていても外部向けのアウトプットをやっている人が少ない印象があるんですよね． アドベントカレンダーはそういうおもしろいことを外部向けに公開するちょうどよい機会だと思っており，たぶんそういう気持ちがあって続けられてきているんじゃないでしょうか． 12月だけに固まってしまうというのはあるけどちょうどよい機会が設けられているのはよいことだと思います．
あたしはきみのアドベントカレンダーの記事を読んでいるし，心待ちにしているよ
— うたがわきき🔰💊 (@utgwkk) 2018年12月23日
これは こふ語 / ﾌﾞﾁﾐﾘ Advent Calendar 2018 - Adventar 12/18の記事です．気がついたら2015年から毎年書いてる．
あっ 自分（わたし（由持もにです！））のことです
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月16日
2018年はバーチャルユーチューバー各位がどんどん登場し，あっという間にYouTubeのsubscribeが埋まってしまいました．
えーやば
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月16日
けんこふさんはﾏｽﾖﾖﾝでしか見かけなくなってしまい，たまに見かけてはﾌﾞｯｽﾖしたりしなかったり，という生活を送っています．
元気 よく眠れる
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月14日
ところでツイッターのオタク各位はどこで共通の文法を得ているのでしょうか．なんもわからん，わたしには……
クリスマスイブ配信するぞ！ちゅたのに「24時間配信してくれないと信用できない」つったオタク そういうとこだぞ
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月14日
でもまあわかる
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月14日
由持のツイを見てからずっと，あっオタクじゃん，となり続けており，しかもフォローイング各位と似た文法を用いているのです．なにこれ
助けてくれ
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月16日
ややきびしい
— 由持もに♎🔰 (@moni_yoshimochi) 2018年12月8日
えーやば なんもわからん 助けてくれ
これは KMC Advent Calendar 2018 - Adventar と 言語実装 Advent Calendar 2018 - Qiita 4日目の記事です．
3日目はそれぞれ，
でした．
id:utgwkk (うたがわきき) です．学部4回生になり，プログラミング言語に関する研究をすることになりました*1．
KMC部員としての生活もついに4年目です．ふだんはお酒を飲んでいます．
この記事では，大堀先生の多相レコード理論の論文[1] *2について，(数学的な議論は控えめに)どういうことをやっているのかについて紹介します． また，リファレンス実装のSML# と私が書いた実装について紹介します．
さて，読者のみなさまの中には record polymorphism と聞いて「ああ，アレね」とすぐに理解される方もいらっしゃるかと思われますが，わたしの理解の再確認も兼ねて，それぞれの要素に分解して説明していこうと思います． すなわち，
の順に説明していきます．
なお，
といったことについて掘り下げていくといくら時間があっても足りなくなる*3ため，ここでは参考となるサイトをいくつか挙げるにとどめておきます． この記事を読んでいて分からないことがあれば適宜あたっていくとよいでしょう．
レコードは，MLのような言語でよく用いられるデータ構造です．
{name = "utgwkk" ; age = 17}
のように書くことでレコードをつくることができ，たとえばOCamlでは x.name のように書くことでフィールドの値を取り出すことができます．
イメージとしては構造体に近いです．
多相性について説明する前に，もしも多相性がなければなにが起こるのかについて考えていきましょう．
もしもOCamlに多相性がなければ，次の式は型エラーになります．
let id = fun x -> x in if id true then id 2 else id 3
何が起こっているのでしょうか？ 順番に見ていきましょう．
let で関数 id を定義する．型は 'a -> 'a ( 'a は未知の型変数)if の条件節の id true という式を見て 'a = bool という代入をすればいいことがわかった．やったね！id 2 という式もあるので 'a = int でなければいけない？？？多相性がない型システムでは，型変数は「いずれ型が確定するかもしれない」「使い方が確定したら即座に置き換えられる」というものになります． 多相性があれば，「この型変数の使い方はなんでもよい」ということを表現することができるようになります．
ここでは論文で取り上げられている「カインド」についてざっくりと説明していきます．
さて，多相性があると書けるプログラムが多くなるという実感を前節で得てもらえたと思いますが，残念ながらレコードに対してはこの多相性ではまだ柔軟性が足りません．
たとえば，レコードの name というフィールドの値を取得する関数について考えてみましょう*4．OCaml風に書くならば次のように書けると思います．
let name x = x.name
ところがこの関数はStandard MLでは*5定義することができません． x のレコードとしての型を決定することができないためです．
型を明示すれば name を定義することができます*6が，その型に ぴったりはまる レコードしか受け付けてくれなくなります．
われわれは name 以外のフィールドには関心を持たないつもりでいるのに，これでは不便です．
この問題を解決するために，論文ではカインドという仕組みを使っています．
カインドはざっくり言うと，型変数のとりうる範囲の制約です．
nameというstring型のフィールドを含むレコードを表すカインドを {{name:string}} のように書きます．たとえば {name:string, age:int} や {name:string, roomno:int} のようなレコードはこのカインドが付けられます．
カインドを使うと，先述した関数nameについて forall 'a,'b::{{name:'a}}.'b -> 'a のような型を付けることができます．
この関数nameは {name = "utgwkk", age = 21} や， {name = "hoge", roomno = 404} のような，nameというフィールドを含むあらゆるレコードに対して適用することができます．便利ですね．
論文では，ここまで述べてきたレコード多相の計算体系を，より低レベルな計算体系*7にコンパイルする手法を与えています． 基本的なアイデアは次の2つです．
型情報を用いることによってこれらの変換を実現しています．
論文のリファレンス実装は SML# として公開されています． 2018/12/4現在，ビルドにはやや古いバージョンのLLVMが必要とされています．バージョンさえ揃えればビルドできます*8．
SML#では，
fun name (x) = #name x;;
のように書くことで先述のname関数を実装できます．
SML# にはレコード多相のほかにもさまざまな拡張機能が実装されています．詳しくはドキュメントをご覧ください．
私の実装はGitHubで公開されています．
menhirを入れて make すると prog が生成されます．
./prog を実行するとREPLが立ち上がります．
変換ステップは次のようになっています．
./prog --debug を実行すると，各変換ステップ後の内部表現を見ることができます．
文法はOCaml寄りになっています．READMEのBNFを参照してください． この処理系では，
let name x = x.name in name;;
のように書くことで先述のname関数を実装できます．
レコード多相を実現するための理論についてざっくりと触れてきました．
日頃，とくに動的型の言語では何気なく書いている x.name といった式に型を付ける方法としてこのようなものがあるといったことを知ったとき，目から鱗が出ました．
この記事では触れていない部分(型推論)や，数学的な定式化などについては論文を参照してください．
この直観はさすがにずれているのではないか，などの指摘がありましたら id:utgwkk までよろしくお願いします．
京都大学工学部情報学科計算機科学コースでは，学生実験として3回生のうちに言語処理系を実装する機会が2回あります．
どちらも実験資料がインターネット上に公開されています．
明日は @opepeman_FE さんで「たぶん聖地巡礼記2018」です．
明日は @h_sakurai さんで Prologによる多相レコード計算の実装(2) - Qiita です．
KMCでは，プログラミング言語の実装がどうなっているのか気になって夜も寝られない部員を募集しています．KMCに入部制限はありません．どなたでも入部できます．詳しくは入部案内ページをご覧ください．
また，KMCはコミックマーケット95にも出展します．ゲーム・音楽CDの頒布を予定しています．ぜひお越しください．
◎あなたのサークル「京大マイコンクラブ」は、日曜日 東地区“タ”ブロック－31a に配置されました。
— 京大マイコンクラブ (@KMC_JP) 2018年11月2日
さらに，去年に引き続き部員がイラストを描いて投稿するアドベントカレンダーが動いております．こちらもどうぞ．
わたしはもともと作業に没頭するとなかなか抜け出せないタイプだった． そのため研究室でコードを書いていたところ気がついたら20時を過ぎていたとか，あるいは家で続きを書いていたら朝になっていた，ということがあった．
/remind me 定時です at 18:00 every weekday
ここでは定時の概念はSlackのリマインダーとして顕現する． 平日の18時には必ず定時が知らせられ，気持ちに対する割り込みが起こる． 作業が終わりつつあるときには，それでは今日はここまでやってしまって終わりにしようとなり，あるいは定時近くになると，とりあえずあのタスクぐらいはやってしまおうとなる．
これは時間的な区切りの概念だいたいについて同じようなことが言えるのではないかと思う． 大きな区切りは遠くに見えるけど，どれくらい遠いのかが分からない． したがって小さな区切りによって少しずつ近づいていくのがいいのではないか．
いまは可変でない「定時」という区切りを導入し，まあうまくいっているのではないだろうかという段階． まだ運用を開始して1週間も経過していないので引き続き経過を見ていこうと思う．
