問題タブ [language-design]

私は最近、Java や C# のような言語で、メソッドのパラメーターの型として「ダック」型を含めることは、構文糖衣の良い形になるだろうかと考えていました。これは次のようになります。

これは、リフレクションを介して doStuff() を呼び出すためのシンタックス シュガーになるか、別の方法で実装される可能性があります。Foo はどのタイプでもかまいません。foo に doStuff() メソッドがない場合、実行時例外がスローされます。要点は、必要なときに、つまりほとんどの場合、事前に指定されたより厳密なインターフェイス パラダイム (パフォーマンス、エラー チェック) の利点が得られるということです。同時に、ダッキング タイピングへのシンプルできれいに見えるバックドアができ、大規模なリファクタリングを行わなくても、初期設計では予期されていなかった変更をきれいに行うことができます。さらに、100% 後方互換性があり、既存の言語構造と完全に調和する可能性があります。これは、API を混乱させ、乱雑にする原因となる過度に設計された場合に備えたプログラミング スタイルを削減するのに役立つと思います。

しばらく前に、新しい C++ 開発者と一緒に仕事をしていたときに、彼が「なぜ変数名を数字で始められないのですか?」という質問をしました。

一部の数値にはテキストを含めることができ（123456L、123456U）、コンパイラがアルファ文字を含むすべてのものを変数名と見なしていた場合、それは不可能であることを除いて、答えを思いつくことができませんでした。

それは正しい答えでしたか？他に理由はありますか？

自分の言語を作成しようとしている場合、私を助けるツールはありますか？yaccのことを聞いたことがありますが、必要な機能をその言語でどのように実装するのか疑問に思っています。

Unicode 文字列が処理されるときに、メモリ内で最も優先される Unicode 文字列の形式は何ですか? なぜ？

実行可能ファイル イメージを作成してプログラミング言語を実装しています。明らかに、実用的なプログラミング言語の実装には、文字列を処理するためのプロトコルが必要です。

動的配列は実装が非常に簡単で、短い文字列に対して非常に効率的であるため、動的配列を文字列の基礎として使用することを考えました。この方法で文字列を使用する場合、文字の最適な形式についてはわかりません。

この質問に触発されて、私は次の例がすべてc＃で違法である理由を疑問に思い始めました：

と

言語がこのように設計された正確な理由を誰かが知っているかどうか疑問に思っていますか？悪いプログラミング慣行を思いとどまらせるためですか？もしそうなら、パフォーマンス上の理由（コンパイル時と実行時）または理由は何ですか？

Standard ML、F＃、OCaml、Haskellなどの静的に型付けされた関数型プログラミング言語では、関数は通常、パラメーターを互いに分離し、関数名から空白で区切って記述されます。

ここでの型は" int -> (int -> int)"です。つまり、intを受け取り、その順番がintを取り、最後にintを返す関数を返す関数です。これによりカリー化が可能になります。

タプルを引数として取る同様の関数を定義することもできます。

この場合、タイプは「(int * int) -> int」になります。

言語設計の観点から、型代数でこれら2つの型パターンを単純に識別できない理由はありますか？つまり、「（a * b）->c」が「a->（b-> c）」になり、両方のバリアントを同じように簡単にカレーできるようになります。

私が言及した4つの言語のような言語が設計されたとき、この質問が浮かび上がったに違いないと思います。では、これら4つの言語すべてがこれら2つのタイプのパターンを「統合」しないことを選択した理由を示す理由や調査を知っている人はいますか？

ここでは、静的型付けと動的型付けについて興味深い議論が見られます。私は通常、コンパイル型チェック、より適切に文書化されたコードなどの理由から、静的型付けを好みます。ただし、たとえば Java のように行うと、静的型付けがコードを乱雑にすることに同意します。

それで、私は自分自身の関数型スタイル言語の構築を開始しようとしています。型推論は、私が実装したいものの 1 つです。私はそれが大きな主題であることを理解しています。私はこれまでに行われたことのないものを作成しようとしているのではなく、基本的な推論にすぎません...

これに役立つ何を読むべきかについての指針はありますか？より理論的な圏論/型理論のテキストとは対照的に、より実用的/実用的なものが望ましいです。データ構造/アルゴリズムを使用した実装に関する議論のテキストがあれば、それは素晴らしいことです。

タスクを自動化したり、特定の複雑さを隠したりする、より高度なコンパイラ、言語、およびフレームワークは、最終的に私たちを愚かなプログラマーにしますか?

Jim Cは、次の電卓のアナロジーを示しています。

最近、紙と鉛筆を使って平方根を引いた人はいますか? 計算機を使用するか、お気に入りのプログラミング言語で関数を呼び出すだけです。電卓の機能や機能を知っている人はどれくらいいますか?

では、子供たちに数学の学習を忘れるように言ってみませんか? そのために電卓があるのです。それは本質的に私たちの子供たちを愚かにするのではないでしょうか?

Javaに符号なし整数のサポートが含まれていないのはなぜですか？

予想外に大きな入力でオーバーフローが発生する可能性が低いコードを記述できることを考えると、奇妙な省略のように思われます。

さらに、unsigned inintを使用することは、unsigned intが保持することを意図した値が負になることは決してないことを示しているため、自己文書化の形式になる可能性があります。

最後に、場合によっては、除算などの特定の操作では、符号なし整数の方が効率的です。

これらを含めることの欠点は何ですか？

新しい演算子がC＃やJavaなどの現代言語に存在するのはなぜですか？それは純粋に自己文書化コード機能ですか、それとも実際の目的に役立ちますか？

たとえば、次の例：

よりPython風の書き方と同じくらい読みやすいです：

編集：コーワンは質問の明確化で頭に釘を打ちました：なぜ彼らはこの構文を選んだのですか？