About  Capabili,es  for    Uniqueness  and  Borrowing  

水島　宏太  日本Scalaユーザーズグループ  

自己紹介  •  水島　宏太    

–  Twi;er:  @kmizu  –  本日、アラサー最後の歳になりました  –  Github:  h;ps://github.com/kmizu/    

•  株式会社ユビレジ  •  愛  

•  (プログラミング|形式)言語  •  静的型付け  •  メタプログラミング  •  Scala,  Nemerle  

Capabili,es  for  Uniqueness  and  Borrowing  

•  著者：Phillip  Haller,  Mar,n  Odersky  –  ※CSの論文ではFirst  Authorが最重要です    

•  ECOOP2010に採録  –  European  Conference  on  Object-­‐Oriented  Programming  

•  コンパイラプラグインとしてちゃんと実装がある！  –  h;p://lampwww.epfl.ch/~phaller/readme_uniqueness.html  

Abstract  

•  動機  –  並行プログラミングでのメッセージパッシング  – Mutable  Objectがあると安全じゃない  –  既存の提案手法は制限が強過ぎる  

•  貢献  –  参照の一意性を保証するための新しい手法を提案  –  そのための型システムの健全性を証明  

•  Scalaのコンパイラプラグインとして実装  

何が問題なのか  

•  Actorライブラリでのプログラミング  –  Actor間でのメッセージ通信  –  mutableなオブジェクトを送信すると：  

•  race  condi,on発生の可能性  •  複数Actor間でオブジェクトの共有(別名付け)  

–  immutableなオブジェクトのみを送れば安全  •  immutableオブジェクト万歳  

待って欲しい  

•  本当にmutableなオブジェクトを送信してはだめ？  

•  Actor間でオブジェクトが共有されなければOK  –  val  buffer  =  Buffer[Int]()          buffer  ++=  (1,  2,  3,  4)          anActor  !  buffer          //  bufferに触れるな危険  

•  オブジェクトが共有されない事を静的に保証したい  –  オブジェクトの参照の一意性  

寄り道：一意型  

•  代表的な言語：Clean  •  基本：誰にも見破れなければimmutableと同じ！  –  裏側でオブジェクトを破壊的に更新しても関係ない  

•  Scalaっぽい疑似コードで表現  –  val  oldArray:  *Array[Int]  =  Array(1,  2,  3)          /*  oldArrayへの参照を「消費」  */          val  newArray  =  oldArray(0)  =  4            //  oldArrayに触れるとコンパイルエラー  

•  変種が色々ある  

単純な一意型があればOK？  

•  ダメダメ    •  送信できるオブジェクトの形式が制限される  –  木構造はOKだけどグラフは駄目  –  オブジェクトのシリアライズが必要になって…あれ？    

•  もうちょっと制限を緩める必要がある  

先行研究  

•  色々ある(↓)けどばっさり略  

External  Uniqueness  Separate  Uniqueness  

Capability  

•  この研究における中心的な概念    •  p▷T  :  型Tはcapability  pによって守られている    •  Capabilityの二つの役割  –  ヒープ上の(disjointな)異なる領域の表現  –  領域内にあるオブジェクトへのアクセス権  

•  オブジェクトの一意性を細かく制御できる  •  次ページ以降、コード例中心の説明  

登場人物(アノテーション)  

•  @unique  –  (参照が)一意な変数であり、capabilityを持つ  

•  @transient  –  capabilityを消費しない  

•  @peer(this)  –  thisと同じヒープ領域を指す  

例：LogList(1)  

例：LogList(2)  

感想  

•  Capabilityベースの領域単位の一意性が面白い  

•  型アノテーションの型推論が弱い…  –  記述が冗長になりそう  

•  captureはad  hoc過ぎる気が…  

•  コンパイラプラグインとして実装したのは良い