タグ付けされた質問 「syntax」

構文は、言語で正しく構造化されたプログラムを作成する方法を定義する一連の規則を指します。プログラムの意味や解釈は明示的には扱いません。

2
配列要素に角括弧を使用する習慣はどのように発展しましたか?
多くのプログラミング言語は、構文a[i]を使用してi配列、シーケンス、またはベクトルのi番目の要素を参照します。a具体的には、CおよびPascal(1960年代後半から1970年代初頭)はこれを行います。一方、Fortran(1950年代のもの)などの一部の初期の言語では、この規則を使用していません。また、私は少し数学を研究し、数学者は間隔に角括弧、配列と行列の添え字(または配列が負でない整数の関数と考えられる場合は通常の括弧)に添え字を使用します。 だから、私の質問です:配列の添え字用のこの角かっこは、どこで、どのように、どのようなコンテキストで開発されましたか? 注:Cでの中括弧の使用に関するこの質問の真似はまったくありません。
11 history  array  syntax 

2
Forthの柔軟性が文法を不適切にするのはなぜですか?
私は最近、スタックベースのプログラミング言語を書く仕事を引き受けました。しかし、自分の言語の設計を始める前に、既存のスタックベースの言語を読んで実験するのは良い考えだと思いました。 これにより、この投稿のトピックに移動します。私は、Postfixスタイルの式を使用するスタックベースの言語であるForthに関するWikipediaの記事を読んでいました。記事では、私は次の声明を見ました: Forthの柔軟性により、静的なBNF文法が不適切になり、モノリシックコンパイラーがありません。コンパイラを拡張するには、文法を変更して基礎となる実装を変更するのではなく、新しい単語を書くだけで済みます。 私の理解では、フォースの専門用語では、「単語」という用語は基本的に「サブルーチン」と同義のようです。これを考えると、上記のステートメントは奇妙に思えます。Forthで新しい関数を作成する機能がForthの正式な文法を不適切にするのはなぜですか?定義する新しいサブルーチンごとに文法を書き直す必要があるのはなぜですか?環境で新しい単語を書くことは、コンパイラの拡張をどのように構成しますか?上記のステートメントは、新しい関数を定義できるため、正式な文法はPythonには不適切であると言っているように見えます。 実際、私は以下のForthの単純なサブセットに対してBNFスタイルの文法を書くことを試みることにしました。 program ::= stmt+ stmt ::= func | expr func ::= ':' expr+ ';' expr ::= INTEGER | word word ::= ('+' | '-' | '*' | '/' ) 上記の文法は、Forthステートメントの有効なサブセットをカバーしているように思われ、Forth言語のすべての有効なステートメントをカバーするように拡張することはそれほど難しくないと思われます。さらに、コンパイラーのパーサーが上記の文法を実装している場合、コンパイラーがどのように拡張されるかはわかりません。コンパイラは、環境に新しい単語を追加するだけです。環境のみが変更されます。まるで、上記のWikipediaからの抜粋は、コンパイラー(変更されない)を構成する下線コードとコンパイラーの環境(変更される)を融合しているようです。 要約すると、なぜ新しい単語(サブルーチン)を定義するForthの能力が、書かれた文法には不適切なのでしょうか。

6
オプションのセミコロン
ほとんどの場合、汎用の命令型言語では、ステートメント区切り文字としてセミコロンが必要か、完全に禁止されています(CやPythonなど)。 ただし、JavaScriptなどの一部の言語では、ステートメントをセミコロンで区切らずに、他の区切り文字(改行など)を優先できます。 この背後にある設計上の決定は何ですか?同じ行に複数のステートメントを記述する場合、セミコロンが不可欠であることを理解していますが、セミコロンを必須にする別の理由があります(以下のCを除く)?


3
すべての文字列が有効なプログラムであるプログラミング言語はありますか?
固定アルファベット(ASCIIなど)の場合、これらの文字の可能なすべての置換が、実行可能な意味的に有効なプログラムであるようなチューリング完全プログラミング言語は存在しますか? 無限ループも意味的に有効であると見なします。 Markdownなどの一部のデータ形式は、普遍的な意味論的有効性(すべての入力が有効)を持っていることは知っていますが、このプロパティを備えたプログラミング言語を思いのままにすることはできません。

4
科学的プログラミング言語はなぜ奇妙なのですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 科学と工学での使用を意図したプログラミング言語は、汎用言語と比較して一貫して奇妙なように思えます。私の頭の上のいくつかの例: Matlabでは、各関数を個別のファイルに配置する必要があります Rでは、他のほとんどすべての言語で=とは対照的に、<-は代入演算子です。 Matlab、R、Juliaなどはすべて1インデックスです Matlabはコメントに%を使用し、標準の#または//ではありません もちろん、これらの言語にはすべて、いくつかの設計機能があり、より自然な行列表記など、科学的アプリケーションで実際に使用しやすくなっています。それでも、これらすべてが不可解にすべての奇妙な選択を行いますが、これは何も簡単ではなく、言語設計者が他の言語の99%が行うことを選択した場合、簡単に回避できたはずです。ベンダーロックインの理由は何ですか?幅広いソフトウェア開発コミュニティとの連絡がないのですか?他に何か? 私はこのスレッドを読んで、説明が満足できるものであるとは思いませんでした。Rが科学的言語として設計されたからといって、規則を完全に無視し、=の代わりに<-を使用しなければならなかったわけではありません。

1
Haskellレコードの構文に不快な感じがします
Haskell構文のほとんどには、純粋さの美しさがあります。しかし、レコードの構文は醜く見えます。それは不快です。Cとの何らかの混合を感じます。コンマと中括弧が必要です。Haskellにはタブ、行ベースの分離があります。そのため、本来必要とするよりも冗長に見えます。なぜそのように設計されているのですか?
9 syntax  haskell 

8
構文上の砂糖の厳密な定義?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 言語の聖戦のように、人々は常に「文法上の砂糖」として特に有用であるとは思えない機能を常に否定しています。「実際の機能」と「構文上の砂糖」の間の境界線は、これらの議論では曖昧になる傾向があります。シンタックスシュガーの合理的で明確な定義は、スピーカー/ライターが役に立たないと見なす機能として定義されないようにするものだと思いますか?


1
AST形状を定量的に比較する
同様のソースコードプログラム(C、C ++、Go、またはGCCでコンパイルされたもの)の抽象構文ツリーの形状をどのように比較できますか? 私は推測するソースコードの盗用検出は、そのような技術を使用しますが、私はそれと呼ばれることだろうかの見当がつかない... たとえば、統一を使用してASTを比較できますが、それはブール値の回答しか提供しません。数値の「距離」、またはある種の数値ベクトル(たとえば、機械学習や分類アルゴリズム、またはその他のビッグデータのものに後でフィードされる)を提供するいくつかの手法を探しています。 大規模なソースコードセットでのビッグデータや機械学習アプローチへの言及も歓迎します。 (このように広範またはあいまいな質問で申し訳ありません。使用する用語がわかりません) 2つのASTまたはプログラムを単純に比較したくありません。大量のプログラム(Debianディストリビューションのソースコードの半分など)を処理し、その中に同様のルーチンを見つけたいと思っています。私はすでにMELTを使用してGCC内部表現(Gimple)に取り組んでいるため、それを活用したいので、いくつかのメトリック(どれか?循環的複雑度はおそらく十分ではない)をデータベースなどに保存し、比較して処理します... 補遺:MOSSシステムと紙について発見されましたが、構文の形はまったく気にしていないようです。ツリーの編集距離も調べます。 ソースコードの類似性を探すことについて(JérémieSalvucciに感謝)Michel Chilowi​​czの博士論文(2010年11月フランス語)も発見

3
タグ内の終了セミコロンを省略する-良いアイデアですか?
タグ内の終了セミコロンを省略できます。 例: <table> <th><td>Name</td><td>Email</td> <? foreach ($receivers as $receiver): ?> <tr> <td><?= $receiver->name ?></td> <td><?= $recevier->email ?></td> </tr> <? endforeach ?> </table> の<? endforeach ?>後にセミコロンがないことに注意してくださいendforeach。PHPのドキュメントは 言います: PHPコードのブロックの終了タグは、自動的にセミコロンを意味します。PHPブロックの最終行をセミコロンで終了する必要はありません。 なぜ私はこのテーマを取り上げるのですか? 現在、私と私の友人は、MVC(model-view-controller)を使用した独自のPHPプロジェクトで働いています。そのため、私はSmarty、MustacheなどのPHPテンプレートエンジンをいくつか評価し、独自の自家製テンプレートエンジンを設計しました。しかし、PHP自体がテンプレートエンジンであることを読んだとき、何かが「クリック」しました。テンプレートエンジンとしてPHPの限定されたサブセットを使用することにチームで同意しないのはなぜですか?そして、ルールを守るために多くのコードレビューがありますか? このサブセットは次のようになります。 短いタグを使用し<?、<?=かつ?> 副作用のない単純な式のみを使用し、特に変数を割り当てない のみを使用しif、foreachし、includeステートメントの 制御構造に代替構文のみを使用する タグ内のステートメントはそれぞれ1つだけにしてください これは、終端のセミコロン、つまりfor <? endforeach ?>と<? endif ?>を省略しているコンテキスト<? include("list-contents.php") ?>です。 ただし、終端のセミコロンを省略することは悪い習慣であることをよく読みます。どうして?それは悪い習慣ですか? PHPが終端のセミコロンを省略できることで嬉しいです。これにより、テンプレートファイルの視覚的な混乱が最小限に抑えられます。あちこちに小さなPHPフラグメントのみが含まれたHTMLファイルのように見えるはずです。上記の例は私が努力しているものです。 これについてあなたはどう思いますか?あなたがそれに反対しているなら:なぜ?あなたがそれを支持するならば:なぜそれは良い考えでしょうか?セミコロンを省略することに対していくつかのテキストを彼が私に紹介している場合、パートナーに何を伝えればよいですか? 事実、参考資料、またはあなた自身の経験であなたの意見をバックアップしてください。
8 php  syntax 

4
コードを無効にするための構文は、通常のコメントの構文と異なる必要がありますか?
開発中のいくつかの理由で、コードをコメントアウトすることがあります。私は無秩序で時々急いでいるので、これらのいくつかはそれをソース管理にします。 また、コメントを使用してコードのブロックを明確にします。 例えば: MyClass MyFunction() { (...) // return null; // TODO: dummy for now return obj; } これは「機能」し、多くの人がこのように実行しますが、コメント化されたコードとコードを明確にする「実際の」コメントを自動的に区別できないのは不愉快です。 コードを読み取ろうとするとノイズが発生します たとえば、ソース管理のon-commitフックのコメントアウトされたコードを検索することはできません。 一部の言語は、複数の単一行コメントスタイルをサポートする-例えばPHPにすることができますいずれかを使用//または#単一行コメントのために-と開発者がコメントアウトコードのためにこれらのいずれかを使用に同意することができます: # return null; // TODO: dummy for now return obj; 他の言語-私が今日使用しているC#など-は、単一行のコメントに対して1つのスタイルを持っています(そうですか?コンパイラディレクティブを使用した「コメントアウト」コードの例も見ました。これはコードの大きなブロックに最適ですが、ディレクティブには2つの新しい行が必要であるため、1行では少しやりすぎです。 #if compile_commented_out return null; // TODO: dummy for now #endif return obj; したがって、コメントアウトコードはすべての(?)言語で発生するので、「無効化されたコード」は言語仕様で独自の構文を取得すべきではありませんか?プロの(コメントの分離/無効化されたコード、エディター/ソースコントロールがそれらに作用する)は十分であり、短所(「コメントアウトはすべきではない」)であり、言語の機能的な部分ではなく、潜在的なIDEラグ(Thomasに感謝) ))犠牲に値する? 編集する 私が使用した例はばかげています。ダミーコードは実際のコードに置き換えられるため、簡単に削除できます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.