はてなブックマーク

近年の若者には「推し」がいたりする．「推し」という語が少なくとも原義的には 自身-対象 ではなく 自身-対象-対象を勧められる第三者 という図式を有している点は2020年代の各個人と社会との関係の在り方を写すようで面白いが，まあその話自体に立ち入るのは置いておくとして，20代も終了目前で別に若くもない筆者にもその意味の「推し」の1人くらいはいる．岡本太郎だ．岡本太郎については既に多くの人が熱弁しているけれど，このベラボーな巨人について自らの言葉で書き留めておかねばならぬという欲を私も抑えがたい．だから「後から見返したら恥ずかしいだろう」などという卑しい懸念を唾棄して書くのである． 岡本太郎自体はほとんどの方がご存知だろう．「芸術は爆発だ！」などのやや奇抜な言動で知られ，“奔放なエキセントリックおじさん” のイメージが広く共有されているかもしれない．だが，そうしたイメージは全く一面的である上

プログラミング言語を自前で創っていると，パッケージマネージャが欲しくなってくるものだ．既存パッケージマネージャやそのラッパーによる配布で事足りることも多いが，自前言語の要件とうまく合わなかったりして，真に自分で実装せねばならないこともある．そうした場合，パッケージマネージャをどんな設計にすべきだろうか？ 言語固有の都合には触れずになるべく一般に考慮すべき事項を洗い出し，簡単な設計例も提示してみたい． なお，本稿はパッケージマネージャの設計に焦点を当てたものであり，効率的に依存制約を解消するアルゴリズムなど実装の詳細については解説しない．実際例えばOCamlでは 0install-solver というOPAMの裏でも使われているパッケージを利用すれば制約解消アルゴリズムそのものに踏み込まずとも制約解消処理を実装でき，（それ自体に興味があるときを除けば）必ずしもアルゴリズムを理解する必要はない