契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
TypeScriptにはanyが4種類、undefinedが3種類、……
このツイートの解説をします。 TypeScriptにはanyは4種類、undefinedは3種類、nullは2種類、trueは2種類、falseは2種類、neverは5種類あるのか。普通に使ってる分にはわからないが…… TypeScriptでは表面上は同じ名前でも内部的に異なる型が割り振られている場合がいくつかあります。そのようなもののうち、プリミティブな型についてまとめました。 対象TypeScriptバージョンは4.1.3です。 2021-01-09 update: 数え方を見直しました。 any が4種類から6種類に増えました。 注意 ここに書かれていることを知らなくても、TypeScriptプログラミングにおいて全く困りません。あくまでコンパイラの機微を楽しむつもりでお読みください。 前提知識 any, undefined, null, true, false, never 型につ
Rubyと型についてのポエム - まめめも
zenn.dev matz はじめコミッターの型に対する姿勢にも疑問を持っています。 というご意見が自分に刺さった気がしたので、他の話題はともかくこの点に関してだけ、ポエムを書きます。 「Rubyに型が欲しい」というのは、「もっと速い馬が欲しい」だと思っています。意味を知らない人は ヘンリー・フォード もっと速い馬が欲しい で検索してください。 これは批判でも皮肉でもありません。みんなが馬の乗り方を知っている世界では、誰も乗り方を知らない自動車より、速い馬のほうが確実で合理的です。まして、自動車が本当に実現できるかどうかわからない段階では。なので、他言語で型注釈を書くことによるプログラミング体験が良いと思った人が、それをRubyでも享受したいと思うのは自然だと思います。実際、Steep や Sorbet は Ruby でそういうプログラミング体験を提供することを目指していて、すでにある程度
あなたの知らないKotlinのsmart cast(known as Flow-Sensitive Type) - kmizuの日記
皆さん、Kotlin触っていますか？Kotlinかわいいですよね、Kotlin（どの口がそんなことを言うかって感じですが）。Kotlinにはsmart castという機能があり、安全なキャストができます、というのは不正確で、KotlinはFlow-Sensitive Typeと呼ばれる型システムを持っています。おおざっぱに言えば、制御フローによってある変数や式の型が変わる型システムの総称（だと思います。間違ってたらご指摘願います）Kotlinではそれをsmart cast（と公式ドキュメントには書いてある）と呼んでいるという話のようです。 公式ドキュメントにある例からいくつか引用します： fun demo(x: Any) { if (x is String) { print(x.length) // x is automatically cast to String } } if (x !
なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記
How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ
Freshness | TypeScript Deep Dive 日本語版
TypeScriptはFreshness(厳密なオブジェクトリテラルチェックとも呼ばれます)という概念を提供します。それはオブジェクトリテラルや構造的に互換性がある型の型チェックを簡単にします。 構造型は非常に便利です。次のコードを考えてみましょう。これにより、型安全性のレベルを維持しながら、JavaScriptをTypeScriptに非常に便利にアップグレードすることができます： コピーfunction logName(something: { name: string }) { console.log(something.name); } var person = { name: 'matt', job: 'being awesome' }; var animal = { name: 'cow', diet: 'vegan, but has milk of own species' }
What is Gradual Typing: 漸進的型付けとは何か - Qiita
本稿は Python に型アノテーションを追加するという PEP 483 - The Theory of Type Hinting の提案で参照されている Jeremy Siek (@jeremysiek) 氏と Walid Taha 氏が開発した漸進的型付けについての入門記事の翻訳です。 What is Gradual Typing Python 3.5 で導入された型アノテーションについて興味がある方は以下を参考にしてください。 Python と型ヒント (Type Hints) と #pyconjp [翻訳] PEP 0484 -- 型ヒント (Type Hints) Revenge of the Types: 型の復讐 私自身、型システムに明るくないため、一部未訳の部分があったり、勘違いや誤訳もあると思います。そういった誤りを見つけたら編集リクエストを送ってもらえると助かります。
C++11で覚醒した共用体の話
はじめに KMC 2回生のhatsusatoです。コミケまでもう1週間もないんですね1。27日まで授業があるとか正気の沙汰じゃない。 この記事は KMC アドベントカレンダー 2013 の 23 日目の記事です。昨日の記事は DtYaZsK 君の C++11超入門 でした。 今日は昨日に引き続いてC++11に関するお話です。 C++11で覚醒した共用体の話 共用体はたいていのC言語の入門書に載っている（と思う）ので、C言語をひと通り勉強した人なら共用体を知っていると思います。共用体はC言語の持つ低レベルなメモリ操作能力の一翼を担っています。しかし、共用体を実際に利用することは非常に稀でしょう。 実はこの共用体が、C++11での仕様変更によって生まれ変わりました。今回はそんな共用体にスポットライトを当ててみます。 共用体の基本 まず、C++11で共用体がどうなったのかを見る前に、これまでの共
RustのAssociated Typeについて - Qiita
自己紹介 @tacke_jp 株式会社ノハナでエンジニアをしています 今はParse.com終了にサービスが道連れにならないように移行作業をしています 趣味でHaskellとかRustとか触っています 今日はRustを触り始めて興味を持った "Associated Type" についての話をします Associated Type (関連型) is 何? Traitに紐づく型パラメータ Traitを実装する型に対して一意に定まる (型に関連付く型 = "Associated") 他の言語だとHaskellやSwiftなどが対応してる 概念としては Type Family (型族) に近いらしい 詳しい人教えてください😭 例 グラフを表現するtraitを考える。 trait Graph<N, E> { fn has_edge(&self, &N, &N) -> bool; fn edges(
型推論について - soutaroブログ
暇をみつけては python の型推論をやっている (やろうとしている)。でも、いまだに本当にこれが「原理的に可能」なのかどうか疑問だ…。 http://www.unixuser.org/~euske/offline/memo/cur/cur.html#180812 「原理的に可能」とかについて． まず「原理的に可能」の意味を考える必要がある．「可能」ってなに?なにができたら「可能」なの? 型推論とかのプログラム解析の技術を評価する場合，二つの性質が重要になる．「健全性」と「完全性」．「型推論が健全性を持っている」というのは，「型が推論できたら，そのプログラムは正しい」ということ*1．「型推論が完全性を持っている」というのは，「正しいプログラムは必ず型が推論できる」ということ．MLなんかの型推論は，完全かつ健全である．非常に良くできた型推論アルゴリズムと言える．ただし，型推論アルゴリズムと
TypeScript で幽霊型っぽいものをつくる - Qiita
TypeScript で幽霊型（Phantom Type）っぽいものを作る場合に必要なテクニックを紹介する。 TL;DR TypeScript の型検査の仕組み上、普通の方法で幽霊型はできない が、 intersection type などをうまく用いることで、幽霊型と同じような目的を達成することはできる モチベーション たとえば URL のエンコード。次の encode() 関数は、まだエンコードしてない文字列だけを受け取りたいとする。このとき、
Rustで強めに型をつけるPart 1: New Type Pattern | κeenのHappy Hacκing Blog
このエントリはRustその2 Advent Calendar 2018 6日目の記事を時空を遡って書いています。 κeenです。頭痛い。寝れない。寝れないので空いてる日の分を埋めに行きます。 「Rustで強めに型をつける」シリーズではある程度有名なテクニックを紹介しようかと思います。 みんな当たり前のように書くと知らない人はいつまで経っても知る機会が無いですからね。まずはNew Type Patternから。 基本 例えばcrates.ioを作るとしましょう。エンティティがいくつかありますね。クレートやユーザなど。 struct Crate { id: u64, authors: Vec<User>, // ... } struct Release { id: u64, crate_id: u64, } struct User { id: u64, // ... }
言語処理系勉強会に参加してきた | κeenのHappy Hacκing Blog
κeenです。言語処理系勉強会 Vol.1 に参加してきました。そこでの@omochimetaruさんのSwiftのGenericsとProtocolの実装の話が面白かったので少し感想を。 Javaのジェネリクスは型消去で実装されており、全てのジェネリクスを1関数でまかなえます。一方で統一的に扱うために参照型しかジェネリクスに使えず、プリミティブの取り回しに苦労します。 C++のテンプレートやRustのジェネリクスは型毎に実装を作るのでどんな型でも扱えますし、高速です。代わりに関数の数が増えてバイナリサイズが大きくなりがちです。 Swiftはその中間ようなアプローチを取っていました。 Swiftのジェネリクスの話を要約すると、 ジェネリクス関数には値型も全て参照になって渡される。ただし型のメタデータ(Metatype)を渡してゴニョゴニョして失われた型情報(Value Witness Ta
私と型システムとポエム
最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti
独習 Scalaz — 多相性って何?
多相性って何? パラメータ多相 Nick さん曰く: この関数 head は A のリストを取って A を返します。A が何であるかはかまいません。Int でもいいし、String でもいいし、Orange でも Car でもいいです。どの A でも動作し、存在可能な全ての A に対してこの関数は定義されています。 scala> def head[A](xs: List[A]): A = xs(0) head: [A](xs: List[A])A scala> head(1 :: 2 :: Nil) res0: Int = 1 scala> case class Car(make: String) defined class Car scala> head(Car("Civic") :: Car("CR-V") :: Nil) res1: Car = Car(Civic) Haskell
静的解析の限界、現実世界との境界
2018年に静的解析をとにかく強力につけまくるのは多分あんまりコストに見合わないのでよくない じゃあ静的解析を窓から投げ捨ててよいかというとそれはただの愚行 (以下、静的解析を普通に使えてる人には自明なことしか言いません) 私が最初に静的解析の限界を感じたのは多分依存型で遊んでいたとき 依存型の力はすごくて、まぁそれもそのはず命題論理から述語論理に進んで元への言及ができるので見かけ上表現力はとんでもなく上がるわけです。例えば「ある方程式を満たす解のみを受け取って何かする」みたいな関数が型として表現できるようになる。 一見すると最強に見えるんだけどこれは実質定理証明をすることなので、制限の強い型をつければつけるほど実装で苦しむ羽目になるということを割とすぐ痛感することになった。 例えば head : Vect (Suc n) a -> a で長さ1以上のvectorの先頭を安全に取り出す関数
F*(F Star)の複雑な型システムの何が嬉しいのか？ - Amosapientiam
マイクロソフトが開発中のF* という依存型プログラミング言語を少し触ってみました。 この言語には強力で複雑な型システムが組み込まれています。 現状、依存型言語は世間にはあまり広まっていませんので F*とは？ 複雑な型ってなんだろう？ 複雑な型システムを組み込んで何が嬉しいんだろう？ 何が嬉しくないんだろう？ と疑問をお持ちになる方も多いだろうと思います。 この記事ではF*で使われている複雑な型の一部と、複雑な型を持つことの利点・欠点の一部を述べ、それを簡単なコード例を通じて体感してみます。 疑問に対する答え F*とは？ マイクロソフトと Inria が開発中のプログラミング言語です。 依存型や monadic effect などが組み込まれており、複雑な仕様が型で表現できます。構文は OCaml や F#などのML系関数型言語に似ています。 詳しくは下記のリンクたちを参照。 F* (プログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sindresorhus/type-fest: A collection of essential TypeScript types
Soft Typingに対するMatzの誤解とDuck TypingとStructural Subtyping