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過ぎる気が…	
  

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

About Capabilities for Uniqueness and Borrowing

  • 1.
    About  Capabili,es  for     Uniqueness  and  Borrowing   水島 宏太   日本Scalaユーザーズグループ  
  • 2.
    自己紹介   •  水島 宏太     –  Twi;er:  @kmizu   –  本日、アラサー最後の歳になりました   –  Github:  h;ps://github.com/kmizu/     •  株式会社ユビレジ   •  愛   •  (プログラミング|形式)言語   •  静的型付け   •  メタプログラミング   •  Scala,  Nemerle  
  • 3.
    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  
  • 4.
    Abstract   •  動機   –  並行プログラミングでのメッセージパッシング   –  Mutable  Objectがあると安全じゃない   –  既存の提案手法は制限が強過ぎる   •  貢献   –  参照の一意性を保証するための新しい手法を提案   –  そのための型システムの健全性を証明   •  Scalaのコンパイラプラグインとして実装  
  • 5.
    何が問題なのか   •  Actorライブラリでのプログラミング   –  Actor間でのメッセージ通信   –  mutableなオブジェクトを送信すると:   •  race  condi,on発生の可能性   •  複数Actor間でオブジェクトの共有(別名付け)   –  immutableなオブジェクトのみを送れば安全   •  immutableオブジェクト万歳  
  • 6.
    待って欲しい   •  本当にmutableなオブジェクトを送信してはだめ?   •  Actor間でオブジェクトが共有されなければOK   –  val  buffer  =  Buffer[Int]()          buffer  ++=  (1,  2,  3,  4)          anActor  !  buffer          //  bufferに触れるな危険   •  オブジェクトが共有されない事を静的に保証したい   –  オブジェクトの参照の一意性  
  • 7.
    寄り道:一意型   •  代表的な言語:Clean   •  基本:誰にも見破れなければimmutableと同じ!   –  裏側でオブジェクトを破壊的に更新しても関係ない   •  Scalaっぽい疑似コードで表現   –  val  oldArray:  *Array[Int]  =  Array(1,  2,  3)          /*  oldArrayへの参照を「消費」  */          val  newArray  =  oldArray(0)  =  4            //  oldArrayに触れるとコンパイルエラー   •  変種が色々ある  
  • 8.
    単純な一意型があればOK?   •  ダメダメ     •  送信できるオブジェクトの形式が制限される   –  木構造はOKだけどグラフは駄目   –  オブジェクトのシリアライズが必要になって…あれ?     •  もうちょっと制限を緩める必要がある  
  • 9.
  • 10.
    External  Uniqueness   Separate  Uniqueness  
  • 11.
    Capability   •  この研究における中心的な概念     •  p▷T  :  型Tはcapability  pによって守られている     •  Capabilityの二つの役割   –  ヒープ上の(disjointな)異なる領域の表現   –  領域内にあるオブジェクトへのアクセス権   •  オブジェクトの一意性を細かく制御できる   •  次ページ以降、コード例中心の説明  
  • 12.
      登場人物(アノテーション) •  @unique   –  (参照が)一意な変数であり、capabilityを持つ   •  @transient   –  capabilityを消費しない   •  @peer(this)   –  thisと同じヒープ領域を指す  
  • 13.
  • 14.
  • 15.
    感想   •  Capabilityベースの領域単位の一意性が面白い   •  型アノテーションの型推論が弱い…   –  記述が冗長になりそう   •  captureはad  hoc過ぎる気が…   •  コンパイラプラグインとして実装したのは良い