タグ付けされた質問 「type-systems」

最近、コードの可読性に問題が生じました。 操作を実行し、将来の参照のためにこの操作のIDを表す文字列を返す関数がありました（WindowsのOpenFileがハンドルを返すようなものです）。ユーザーは後でこのIDを使用して、操作を開始し、その終了を監視します。 相互運用性の問題のため、IDはランダムな文字列である必要がありました。これにより、次のような非常に不明確なシグネチャを持つメソッドが作成されました。 public string CreateNewThing() これにより、戻り型の意図が不明確になります。この文字列を、次のように意味を明確にする別の型でラップすると思いました。 public OperationIdentifier CreateNewThing() タイプには文字列のみが含まれ、この文字列が使用されるたびに使用されます。 この操作方法の利点は、型の安全性と明確な意図であることは明らかですが、より多くのコードとあまり慣用的ではないコードも作成します。一方で、私は追加された安全性が好きですが、それはまた多くの混乱を作成します。 安全上の理由から、クラスで単純型をラップすることは良い習慣だと思いますか？

141 type-systems 

静的に型付けされた言語と動的に型付けされた言語の有効性に関する研究はありますか？ 特に： プログラマーの生産性の測定 不良率 単体テストが採用されているかどうかの影響も含まれます。 私はどちらの側の長所についても多くの議論を見てきましたが、だれかがそれについて研究したかどうか疑問に思っています。

69 productivity  comparison  type-systems  dynamic-typing  static-typing 

ある言語では他の言語よりも簡単/難しいこともありますが、興味があるのは、ある言語では可能で、別の言語では不可能/無関係なタイプ関連の機能だけです。より具体的にするために、Haskell型の拡張機能を無視しましょう。あらゆる種類のクレイジー/クールなことを行うものが非常に多くあるからです。

66 java  haskell  type-systems  static-typing 

これを「アカデミック」な質問と考えてください。私は時々NULLを避けることについて疑問に思っていましたが、これは満足のいく解決策を思い付かない例です。 測定が不可能（または欠落）であることがわかっている場合に測定値を保存するとします。NULLを避けながら、変数にその「空の」値を格納したいと思います。また、値が不明な場合もあります。そのため、特定の時間枠の測定値がある場合、その期間内の測定値に関するクエリは3種類の応答を返す可能性があります。 その時点での実際の測定値（たとえば、を含む数値0） 「欠落」/「空」の値（つまり、測定が行われ、その時点で値が空であることがわかっている）。 不明な値（つまり、その時点で測定は行われていません。空になることもありますが、他の値になることもあります）。 重要な説明： get_measurement()「空」、「不明」、および「整数」型の値のいずれかを返す関数があると仮定します。数値があるということは、戻り値（乗算、除算など）で特定の操作を実行できることを意味しますが、そのような操作をNULLで使用すると、キャッチされないとアプリケーションがクラッシュします。 NULLチェックを回避して、コードを記述できるようにしたいと思います。たとえば（擬似コード）： >>> value = get_measurement() # returns `2` >>> print(value * 2) 4 >>> value = get_measurement() # returns `Empty()` >>> print(value * 2) Empty() >>> value = get_measurement() # returns `Unknown()` >>> print(value * 2) Unknown() printNULLが使用されていないため、どのステートメントも例外を引き起こしていません。したがって、空の値と不明な値は必要に応じて伝播し、値が実際に「不明」または「空」であるかどうかのチェックは、本当に必要になるまで遅らせることができます（値の保存/シリアル化など）。 サイドノート：NULLを避けたい理由は、主に頭の体操です。何かをやりたい場合、NULLを使用することに反対しませんが、それらを回避することでコードがより堅牢になる場合があることがわかりました。

57 data-structures  type-systems  data-types 

なぜこれが大丈夫であり、ほとんど期待されているのですか： abstract type Shape { abstract number Area(); } concrete type Triangle : Shape { concrete number Area() { //... } } ...これはOKではなく、誰も文句を言いません： concrete type Name : string { } concrete type Index : int { } concrete type Quantity : int { } 私の動機は、コンパイル時の正当性検証のために型システムの使用を最大化することです。 PS：はい、私はこれを読んでおり、ラッピングはハッキングの回避策です。

53 type-systems  static-typing  strong-typing 

固有の型安全性を備えた言語（たとえばJavaScriptではない）を想定： を受け入れるメソッドを考えるSuperTypeと、ほとんどの場合、アクションを選択するために型テストを実行するように誘惑される可能性があることがわかります。 public void DoSomethingTo(SuperType o) { if (o isa SubTypeA) { o.doSomethingA() } else { o.doSomethingB(); } } 通常は、常にではありませんが、単一のオーバーライド可能なメソッドを作成し、SuperTypeこれを行う必要があります。 public void DoSomethingTo(SuperType o) { o.doSomething(); } ...ここで、各サブタイプには独自のdoSomething()実装が与えられます。アプリケーションの残りの部分は、与えられたものSuperTypeが実際にaであるSubTypeAかa であるかを適切に無視できますSubTypeB。 素晴らしい。 しかし、is aすべてではありませんが、ほとんどのタイプセーフ言語で-のような操作が与えられています。そして、それは明示的な型テストの潜在的な必要性を示唆しています。 だから、何で状況は、もしあれば、必要があります我々たりはしなければならない我々は、明示的な型のテストを実行しますか？ 私の不在や創造性の欠如を許してください。私は前にそれをやったことを知っています。しかし、正直なところ、私がやったことが良いかどうか覚えていません！そして最近の記憶では、カウボーイJavaScriptの外部で型をテストする必要に遭遇したとは思いません。

53 type-systems 

Eric Lippertは、C＃が型nullではなくaを使用する理由についての彼の議論でMaybe<T>非常に興味深い点を述べました。 型システムの一貫性が重要です。null不可の参照が無効であると判断された状況下では決してないことを常に知ることができますか？参照型のnull不可フィールドを持つオブジェクトのコンストラクターではどうでしょうか？そのようなオブジェクトのファイナライザでは、参照を埋めるはずのコードが例外をスローしたためにオブジェクトがファイナライズされますが、どうでしょうか？その保証についてあなたに嘘をついている型システムは危険です。 それは少し驚くべきものでした。関連する概念に興味があり、コンパイラや型システムをいじくり回しましたが、そのシナリオについては考えませんでした。nullの代わりにMaybe型を持つ言語は、初期化やエラー回復など、想定される非null参照が実際には有効な状態にないエッジケースをどのように処理しますか？

53 type-systems  null 

バックグラウンド 私はサイドプロジェクトとして言語を設計しています。動作するアセンブラー、静的アナライザー、それに仮想マシンがあります。構築したインフラストラクチャを使用して、重要なプログラムを既にコンパイルおよび実行できるため、大学でプレゼンテーションを行うことを考えました。 私の話の中で、私はVMが型システムを提供することについて言及しました、「あなたの型システムは何のためにあるのですか？」答えた後、私は質問をする人に笑われました。 したがって、この質問をすることで評判を失うことはほぼ確実ですが、プログラマーに頼ります。 私の理解 私が理解しているように、型システムはプログラム内のエンティティに関する追加情報の層を提供するために使用されるため、ランタイム、コンパイラー、またはその他の機械は、操作対象のビット文字列をどう処理するかを認識します。また、コントラクトの維持にも役立ちます。コンパイラ（またはコードアナライザー、ランタイム、またはその他のプログラム）は、プログラマーが期待する値でプログラムが動作することをいつでも検証できます。 タイプは、それらの人間のプログラマーに情報を提供するためにも使用できます。たとえば、次の宣言を見つけます。 function sqrt(double n) -> double; これよりも便利 sqrt(n) 前者は多くの情報を提供します：sqrt識別子は関数であり、double入力として単一のものを取り、double出力として別のものを生成します。後者は、おそらく単一のパラメーターを取る関数であることを示しています。 私の答え それで、「あなたのタイプシステムは何のためですか？」私は次のように答えました： 型システムは動的です（型は値を保持する変数ではなく値に割り当てられます）が、意外な強制ルールがなければ強力です（互換性のない型を表すため、文字列を整数に追加できませんが、浮動小数点数に整数を追加できます） 。 タイプシステムは、命令のオペランドが有効であることを確認するためにVMによって使用されます。また、プログラマーは、関数に渡されたパラメーターが有効（つまり、正しい型）であることを確認するために使用できます。 型システムは、サブタイピングと多重継承をサポートしています（プログラマーは両方の機能を使用できます）。オブジェクトのメソッドの動的ディスパッチが使用される場合、型は考慮されます。 次の質問は、「タイプは値にどのように割り当てられますか？」でした。そこで、すべての値がボックス化され、タイプの名前、応答するメッセージ、および継承するタイプに関する情報を提供するタイプ定義構造を指すポインターがあることを説明しました。 その後、私は笑われ、「それは本当のタイプシステムではない」というコメントで私の答えは却下されました。 だから-私が説明したものが「実際のタイプシステム」として適格でない場合、どうなりますか？その人は、私が提供するものを型システムと見なすことができないということは正しいのですか？

50 programming-languages  language-design  inheritance  type-systems  virtual-machine 

ボトムタイプは、数学タイプ理論に主に現れる構成です。空のタイプとも呼ばれます。値を持たないタイプですが、すべてのタイプのサブタイプです。 関数の戻り値の型がボトム型の場合、それは戻り値がないことを意味します。期間。永久にループするか、例外をスローする可能性があります。 プログラミング言語でこの奇妙なタイプを持つことのポイントは何ですか？それほど一般的ではありませんが、ScalaやLispなどの一部に存在します。

49 programming-languages  type-systems 

JavaScriptを：良い部品ダグラス・クロックフォードによると、彼は彼の継承の章に言及し、 古典的な継承のもう1つの利点は、型システムの仕様が含まれることです。これにより、プログラマは明示的なキャスト操作を記述する必要がなくなります。これは、キャスト時に型システムの安全性の利点が失われるため、非常に良いことです。 それではまず、実際に安全とは何ですか？データ破損、ハッカー、システムの誤動作などに対する保護 型システムの安全上の利点は何ですか？これらの安全性の利点を提供できるように、型システムの違いは何ですか？

47 type-systems  type-safety 

私たちのほとんどが知っているように、PHPには弱い型付けがあります。そうでない人のために、PHP.netは次のように述べています。 PHPは、変数宣言で明示的な型定義を必要としません（またはサポートしません）。変数のタイプは、変数が使用されるコンテキストによって決まります。 好きでも嫌いでも、PHPはその場で変数を再キャストします。したがって、次のコードは有効です。 $var = "10"; $value = 10 + $var; var_dump($value); // int(20) PHPでは、次のように変数を明示的にキャストすることもできます。 $var = "10"; $value = 10 + $var; $value = (string)$value; var_dump($value); // string(2) "20" それはすべてクールです...しかし、私の人生にとって、これを行うための実用的な理由を考えることはできません。 Javaのような、それをサポートする言語での強い型付けの問題はありません。それは大丈夫で、私はそれを完全に理解しています。また、関数パラメーターの型ヒントを認識し、その有用性を完全に理解しています。 型キャストに関する問題は、上記の引用文で説明されています。PHPで型を自由に交換できる場合は、型を強制的にキャストした後でも可能です。また、操作で特定のタイプが必要な場合にオンザフライで実行できます。これにより、次のことが有効になります。 $var = "10"; $value = (int)$var; $value = $value . ' TaDa!'; var_dump($value); // string(8) "10 TaDa!" …

45 php  type-systems  weak-typing  type-casting 

私はいつも、Javaが言語であり、そのVMが非常に成熟していることを考えると、Javaが型推論を行わない理由を常に疑問に思っていました。GoogleのGoは、優れた型推論を備えた言語の例であり、必要な入力の量を減らします。この機能がJavaの一部ではない背後に特別な理由はありますか？

44 java  programming-languages  type-systems  data-types 

一貫してコードをリファクタリングして存在型への依存を排除​​するために使用できるテクニックは何ですか？通常、これらは、あなたのタイプの望ましくない構造を不適格にし、特定のタイプに関する最小限の知識で消費を許可するために使用されます（または私の理解もそうです）。 誰もがいくつかの利点を維持しているコードのこれらへの依存を削除するためのシンプルで一貫した方法を考え出しましたか？または、少なくとも、変更に対処するために重要なコードチャーンを必要とせずにそれらを削除できる抽象化をすり抜ける方法はありますか？ 存在タイプの詳細については、こちらをご覧ください（「あえて」。）。

43 functional-programming  haskell  type-systems 

これは友人との話し合いの中で出てきたもので、良い議論を考え出すのは難しいと思いました。弱いタイピングはどのような利点をもたらしますか？

40 type-systems  type-safety  weak-typing 

私はコードを書くよりも頻繁にコードを読みますが、産業用ソフトウェアに取り組んでいるプログラマーのほとんどがこれを行うと仮定しています。型推論の利点は、冗長性が少なく、コードが少ないことです。しかし一方で、コードをより頻繁に読む場合は、おそらく読み取り可能なコードが必要になります。 コンパイラーは型を推測します。これには古いアルゴリズムがあります。しかし、本当の質問は、プログラマーがコードを読むときに変数のタイプを推測したいのはなぜですか？誰がタイプを読むだけで、どのタイプがあるかを考えるよりも速くないですか？ 編集：結論として、なぜそれが役立つのかを理解しています。しかし、言語機能のカテゴリでは、演算子がオーバーロードしているバケツの中にあります-場合によっては便利ですが、乱用された場合は読みやすさに影響します。

37 programming-languages  type-systems