ocaml-torchをApple Siliconのマシンにインストールし，ひとまずCPU上で動かすことはできたので，手順をメモ書き的に残します．わりと乱雑なので，適宜修正するかもしれません．

前編に続いて，後編ではSapheが裏側でどのように動いているかの設計・実装について概説します．特に，SapheとSATySFi本体とがどのように責務を分担しているかが重要な内容です．単にSapheを使いたい人は本稿で扱う内容を把握しておく必要はなく，前編のみで十分です．

昨年のSATySFi Conf 2023で発表させてもらった，SATySFi 0.1.0に向けたエコシステム Saphe（セイフ）について，設計とプロトタイプ実装が固まってきたため，そのおおよその仕組みを共有しようと思います．発表の内容とも一部オーバーラップします．

前編である本稿は，Sapheがどのように使えるツールなのかをハンズオン的に記載します．後編はSapheの詳細な設計・実装について述べる予定です．→ 追記： 後編ができました．

近年の若者には「推し」がいたりする．「推し」という語が少なくとも原義的には 自身-対象 ではなく 自身-対象-対象を勧められる第三者 という図式を有している点は2020年代の各個人と社会との関係の在り方を写すようで面白いが，まあその話自体に立ち入るのは置いておくとして，20代も終了目前で別に若くもない筆者にもその意味の「推し」の1人くらいはいる．岡本太郎だ．岡本太郎については既に多くの人が熱弁しているけれど，このベラボーな巨人について自らの言葉で書き留めておかねばならぬという欲を私も抑えがたい．だから「後から見返したら恥ずかしいだろう」などという卑しい懸念を唾棄して書くのである．

プログラミング言語を自前で創っていると，パッケージマネージャが欲しくなってくるものだ．既存パッケージマネージャやそのラッパーによる配布で事足りることも多いが，自前言語の要件とうまく合わなかったりして，真に自分で実装せねばならないこともある．そうした場合，パッケージマネージャをどんな設計にすべきだろうか？ 言語固有の都合には触れずになるべく一般に考慮すべき事項を洗い出し，簡単な設計例も提示してみたい．

どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい．

ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである．

ユニットテストとは，おそらくご存知の通り各コンポーネントが単独で操作的に意図通りの振舞いをしているかを具体例により確認する営みである．

「ユニットテストはどのように書かれるべきか」といった議論が為されるとき，もちろん言語横断的な議論が中心となるものの，しばしば特定の計算機言語やその処理系の性質を所与とした議論が含まれやすい．だが，言語仕様や処理系が天から降ってきたものではない以上，原理的にはむしろ言語こそが目的に応じて適切に設計されるべきものだ．

半ばネタOSSとして実装した tex_of_ocaml¹ について簡単に紹介します．型なしλ計算を多少程度知っていることを前提とします．

初出：

• 2020年12月9日，TeX言語で型なしλ計算を評価するVMを書いた話 - Qiita

SATySFi v0.1.0に向けてオプション引数に関する言語設計を非互換に改めつつあるので，その紹介をします．

初出：

• 2021年12月30日，SATySFi Wiki

個人のWebサイトを設けた．1年以上やらねばと思いつつ先送りしてきたのを長期休暇に合わせて整備したのでようやくの感がある．個人のWebサイトが欲しくなったのは主に以下のような理由による：