FPS camera やっと実装できた……

This account is not set to public on notestock.

Σ計画 (ﾎﾞｿｯ

This account is not set to public on notestock.

進捗です

RubyとHaskell、Scalaが混ざった感じ--「Rust」を学ぶべき7つの理由 - ZDNet Japan
https://japan.zdnet.com/article/35135701/

Rust はいいぞ

最近の言語はだいたいマルチパラダイムだしいろいろな系譜の言語のいいとこ取りしがちなので、実際雑に混ざった感じの説明しても間違ってなさそうというのはある。「最近の」言語は。

go は知らんが

This account is not set to public on notestock.

これはド正論

Rust について言うなら、イテレータみたいな (今となっては) ありふれたものはさておき、 trait について説明すると方々で「(Haskell の) 型クラスみたいなもの？」と言われるので、まあ Haskell っぽさが強い一要素があるよというのはそれなりの強度で言える

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

そのあたりは existential type などのあれこれもあるのでまあﾊｲみたいな場合もあるにはある

「私は『成功したら [f64; 3] が返されるイテレータ』が欲しいのであって、具体的な何らかの型が欲しいわけではない」みたいな文脈が確かにある

型推論、部分的に推論させるときこそ映えるのよね。 Result<Vec<[f64; 3]>, ControlPointError> の代わりに Result<Vec<_>, _> と書けるのはかなり良質な抽象に見える (特に ? 演算子でエラーハンドリングを呼び出し元に任せる場合には)

This account is not set to public on notestock.

「具体的に何であるかはユーザに教えたくないが、とにかく何らかの特徴を持つ何らかの型」という型指定を可能にするのが existential type (存在型) で、これは通常の generics における「どのような型についても○○」という全称型と対照的なものとされている

典型的には「この関数は i64 のイテレータであるような何らかの型を返すことは保証するけど、それが具体的にどのような型であるかは教えたくないよ (i64 のイテレータであること以外の一切の保証を与えたくないよ)」というケースなどで有用。ある種のカプセル化、内部表現の隠蔽ですね

引数の位置での存在型は、 Interface や基底クラスと関数テーブルのようなものとかなり近く見えますね。
対して戻り値の位置では、 interface そのものを返すことはできない(と思う)し、基底クラスのポインタを返すにせよ「基底クラスのポインタである」という具体的な内部実装は漏れるわけです。
加えて、こういった実行時の多相だとオーバーヘッドが出てしまうけど、存在型ならユーザが名前を示せないだけでコンパイラは具体的な型を知っているので、実行時オーバーヘッドがない

たとえば C++ のクロージャは型名を指定できないので、 auto で雑に受けるか std::function で受けるわけですが、前者では関数であると縛りをつけられないし、後者だと実行時オーバーヘッドがあります。
Rust で同じことをすると let による型指定なしの束縛と Box<dyn Fn()> などが相当するわけですが、これ以外にも impl Fn() という指定もできます。
たとえばクロージャを返す
fn f() -> impl Fn() {
|| println!("hello")
}
は、「何度でも呼べる関数として振る舞う何かを返す」ということは述べるけど、 std::function のようなオーバーヘッドはない (わざと付けることもできるけど)

めっっっっちゃ雑に言うなら、存在型は「引数の型としては型パラメータとして振る舞い、戻り値の型としては『コンパイラにしか指定できない内部的な名前』として振る舞う」みたいなｲﾒｯｼﾞでとりあえず困らないかも

https://mastodon.cardina1.red/@lo48576/101920508524525423
この説明はちょっと違ったかも、存在型はたとえば「ユーザが指定した Interface を実装する何らかの型」とかであって、ポインタ+仮想関数テーブルとはまた別の意味になっているので

動的ディスパッチだと、型消去が入るので基本的には存在型より表現力が弱そうなんだけど、それ自体が問題になることはない気がするので、まあ結局はﾊﾟﾌｮｰﾏﾝｽの問題になるんですかね

たとえば E が existential type で D が動的ディスパッチする系の型だとして、 Vec<E> だとベクタの要素は同じ型 (同じ内部表現の値) であることがたぶん確信できるけど、 Vec<D> だと要素の型は実はバラバラかもしれない、みたいな。
とはいえ、そういった内部表現を隠蔽するのが目的で existential type や動的ディスパッチを使うなら、それ自体は問題にならなくて、結局は動的であることのオーバーヘッドが気になるというだけの話になりそう

This account is not set to public on notestock.

NeruPointerException

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

This account is not set to public on notestock.

人間関係のこまめなメンテナンスが苦手なので、話題があるときに雑に話すとか、何か機会があったら顔を合わせるというくらいが丁度よくて、恒常的に優先度の高いメンテナンスが必要になる親密な関係の維持ができない (無理だった)

なんなら一緒に飯食ってても喋らないこともあるし (それで問題ない程度のユルい関係がたぶん一番安定する)

で、そういう人間が実在の人間に対して自分の欲望と向き合うことを要求しようというのは、いささか身勝手が過ぎるのではないかという感じがするので、性欲にせよ他の何かにせよ、自分で完結させて発散しろよ、ということになるわけ

考えてみましょう: あなたの欲求には本当に他人の自我が必要ですか？

This account is not set to public on notestock.

＞ failure::Error ＜

セルフホスティングCコンパイラを書いた - 茅の下
https://ryooooooga.hateblo.jp/entry/2019/04/14/162547

セルフホスティングコンパイラいいなぁ……

This account is not set to public on notestock.

vulkano のために winit 使ってるだけなのに、 smithay-client-toolkit → andrew → rusttype という経由で何故かフォントラスタライザへの依存が入っていた、こういうのやめてほしい