Rustで真に安全なプログラムを書く方法 - かとじゅんの技術日誌
この記事はRust Advent Calendar 2021の12/8日の記事です。 Rust前提の記事として書きましたが、他の言語にも適用できる考え方なので、ほかの言語勢の方々もよければお付き合い下さい。 今回のテーマは「Rustで真に安全なプログラムを書く方法」についてです。 「真に安全なプログラム」の定義は以下とします。 挙動が安定し、結果が予測可能となる 正しさの基準に基づき、プログラムの間違いを検知することができる 「真に」とはドメイン知識に基づく正しさという意味です。詳しくは後述します。 それと「そもそもRustで実装されるプログラムは安全じゃないのか」という想定質問については「メモリの操作は安全。だが、それだけでは真に安全なプログラムにはならない」が答えになります。これについて興味がある方、ぜひ最後までお付き合いください。 「真に安全なプログラム」を実現するレシピとしては「関
データ制約に統一され得る、型、契約、バリデーション - たなかこういちの開発ノート
◆まとめ◆ プログラミング言語では「型」がドメインモデルを表現する重要ツールである。一方、モデリング観点からはデータ値に対する制約こそがある意味本質で、（主にNominal Subtypingが想定されるところの）型も制約の一手段なのだと気付く。 制約一般を型として扱う上でのツールとしては、Nominal Subtypingに限られること無く、依存型やStructural Subtypingを用いることができる。もう少しカジュアルには（＝動的評価でよいなら）、型にDbC不変条件を常にセットしたものを考えられる。実装的には、バリデーションの一般的な仕組みをDbCを担うものとして扱う方式が取れる。目下の実現手段（＝動的評価するフレームワーク）と理論的なところ（＝依存型など静的評価を目指す）とを、宣言的プログラミングによる静的なセマンティックスと実行モデルの分離を以って繋いでみる。 〜・〜・〜
翻訳: Parse, don’t validate (バリデーションせずパースせよ)
これまで、型駆動設計を実践することが何を意味するのか、簡潔でシンプルな説明を見つけるのに苦労してきました。誰かに「どうやってこのアプローチを思いついたのですか？」と尋ねられることが多いのですが、満足のいく答えを出せないことがよくあります。そのアイデアが突然のひらめきで浮かんだわけではなく、正しいアプローチを空から引っ張り出す必要がない、反復的な設計プロセスがあると分かってはいるのですが、そのプロセスを他の人にうまく伝えることができていませんでした。 しかし、およそ1ヶ月前、JSON を静的型付け言語で、そして動的型付け言語にパースしたときに経験した違いについてTwitter上で振り返っていた時、ついに私が探していたものを見つけました。そして、そのスローガンはたった3つの英単語で表せます。 Parse, don’t validate (バリデーションせずパースせよ) 型駆動設計のエッセンス
Scala 3のmatch typeで数独solverを作った - xuwei-k's blog
昨日の続き xuwei-k.hatenablog.com 昨日のcheckするだけのものは数秒で終わるのですが、これは手元で compileに2分くらい かかります。 速度に関して改善の余地があるのかどうか？はわかりません。 改善したら、問題が簡単なら数秒で終わるようになりました。 いくつかtweetしましたが、compilerの限界なのでは？と思ったけれど、頑張った結果、いくつかは自分のミスでした。例えば 割り算するべき箇所で余りを取っていた scala.compiletime.ops.any.== は、singleton同士ではないと比較不可能。例えば (1, 2) と (3, 4) といったTupleのまま比較不可能なので、自前でsingletonになるまで必要に応じて再帰的に分解しつつdeepなequalsを実装する必要がある(つらい) 複雑になり過ぎると、上記のようなミスをした場
Scala 3のmatch typeで数独チェッカーを作った - xuwei-k's blog
なんかtweet流れてきたので TypeScriptの型がどれほど強力かというと、コードエディタ上で直接数独ができるほどの複雑な型を作成した方がいるほどです。このSudoku型を使用すると、TypeScriptの型チェッカーが間違いを正確に指摘してくれます。 pic.twitter.com/mCXXjGqK9D— Jeffry Alvarado (@jalva_dev) September 7, 2024 github.com Scala 3のmatch type自体の詳細な説明は省略しますが、compile時計算的なことができて、チューリング完全です https://tarao.hatenablog.com/entry/lambda-scala3 あくまで答えがvalidか？のcheckerだけで、プレースホルダー部分実装してない それも実装しました。下記に貼った 少なくともIntell
【エフェクトシステムとは一体なんなのか？】なぜ私はHaskellでエフェクトシステムのライブラリを作るに至ったか
はじめに 本記事は、今回筆者が作成したHaskellのエフェクトシステムライブラリの背景を説明するものです。Haskellに触れたことがない読者のために、理解に必要な事柄や文法等は記事中で簡単に説明します。Haskellやライブラリ自体に興味がなくとも、エフェクトシステムの紹介だけでも今後の参考にしていただければ幸いです。 エフェクトシステム エフェクトシステムというプログラミングパラダイムが以前より研究されていました。 これは、プログラムのコード内で起こりうる副作用を分類、タグ付けし、実行時より前に分かるようにするというものです。ここでは、副作用を分類して名前を付けて型として表したものをエフェクト型と呼び、あるコード片が発生させうるすべてのエフェクト型の集合をエフェクト集合と呼ぶことにします。 例えば 1+1 このプログラムのエフェクト集合は空集合{}です。なぜなら、一切の副作用（入出力
Object.groupBy で作られるオブジェクトの prototype は null - Object.create(null)
おさらい: prototype JavaScript のオブジェクトはみんな prototype というのを持っていて, この prototype からプロパティを継承, より正確には, プロパティアクセス時にそのプロパティがオブジェクトに存在しなければ prototype を辿って見つけにいくことになっている. あるオブジェクトを prototype とした別のオブジェクトを作るには Object.create を使う (あるいは new 演算子や __proto__ を使っても良い). const x = {}; x.foo = "foo"; const y = Object.create(x); y.bar = "bar"; const z = Object.create(y); z.baz = "baz"; console.log(z.foo); // => "foo" conso
neverthrow で局所的に Result 型を使い、 try-catch より安全に記述する
Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で
Tagged Type(Branded Type)を使って飛行機の不時着や人工衛星紛失を防ごう / Scala 3ではTagged Typeを簡単に作れる - Lambdaカクテル
Tagged Type というテクニックがある（TypeScript界隈などではBranded Typeと呼ばれているようだ）。実行時の型としては同じだが、型システム上はこれを区別して別物として扱い、混同できなくする仕組みを作るためのものだ。 AIくん！サムネイラスト作って！と頼んで作ってもらった画像 Tagged Type 単位の取り違えによる事故は後を絶たない。世の中には、キログラムとポンドを混同して飛行機があわや墜落しかけたり、メートルとヤードを混同して人工衛星がどっかに行ったりしている。尊い人命や国民の血税と比べるといささか霞むかもしれないが、ユーザIDとペイロードを間違えて送信したり、金額と口座番号を取り違えて送金したり、秘密鍵と公開鍵を間違えて表示したりしてしまえば、プログラマが大変な苦労をするか、会社そのものが傾くだろう。 しかしながら、データとしてはどちらも同じDouble
Freeモナドで領域特化言語を作るとプリティミューテーション - Qiita
多くのプログラミング言語が用途を限定しない汎用の言語として設計されているのに対して、領域特化言語(ドメイン固有言語, domain-specific language, DSL)は何らかの目的に特化して設計された言語のことをいいます。領域特化言語を導入する利点のひとつは、プログラムの各部分の役割が明確になり、ソフトウェア全体の設計がよりわかりやすくなるというものがあります。たとえば、ゲームソフトウェアではゲームの描画とゲームの状態更新は完全に分離されているべきです。ゲームで一時的に処理が重くなり、描画を何フレームかスキップして速度を維持したいとしましょう。もし状態更新と描画がきちんと分離されていなければ、描画だけをうまくスキップするということはできなくなってしまいます。もし描画専用の領域特化言語を導入すると、ソフトウェアのコードをその内容に沿って完全に分離するのを強制し、それに違反するよう
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
A Neighborhood of Infinity: Cofree meets Free
> {-# LANGUAGE RankNTypes, MultiParamTypeClasses, TypeOperators #-} Introduction After I spoke at BayHac 2014 about free monads I was asked about cofree comonads. So this is intended as a sequel to that talk. Not only am I going to try to explain what cofree comonads are. I'm also going to point out a very close relationship between cofree comonads and free monads. At the beginning of the talk the
Comonads are objects
Haskell programmers popularized the use of monads to structure imperative computations, complete with syntactic sugar in the form of do notation. However, category theorists predict that there is also a completely symmetric concept called a "comonad", which tickles our fancy. After all, if monads are so intriguing, then perhaps comonads are equally intriguing, and who doesn't like twice the intrig
The False Hope of Managing Effects with Tagless-Final in Scala
Tagless-final is a technique originally used to embed domain-specific languages into a host language, without the use of Generalized Algebraic Data Types. In the Haskell community, tagless-final still refers to a way of creating polymorphic programs in a custom DSL that are interpreted by instantiating them to a concrete data type. In the Scala community, however, tagless-final is used almost excl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
Functional TypeScript
Tagless Final & Scala 3
TypeScript 関数型スタイルでバックエンド開発のリアル
STANDARDIZED OPEN LADDER OF FUNCTIONAL PROGRAMMING - mrsekut-p
ゆうれい，いぞん，そんざい，ﾗｧｩﾝｸﾄｩｩﾎﾟﾘﾓｫﾌｨｼﾞｩﾑｯ - LugendrePublic