INTERCALでゴルフをする上での一般的なヒントは何ですか？私はコードゴルフの課題に適用でき、少なくともINTERCALに固有のアイデアを探しています（「コメントの削除」は有用な回答ではありません）。

エキゾチックな言語がゴルフコンテストに勝つために本当に役立つことを私は知っていますが、私はこのあたりに多くのINTERCALコードを見ていません。人々がINTERCALで競争力のあるコードサイズを得るのに役立つアドバイスはありますか？この言語は競争力がありますか？

INTERCALはあまり活用されていないため、タグもありません。とても悲しい...

空白/「ノイズ」の除去が予想以上に進む可能性がある

INTERCALは、空白を区別しない言語です。ただし、ほとんどの空白を区別しない言語とは異なり、無感覚はあなたが期待するよりもはるかに進んでいます。

たとえば、DO NOTは2つのトークンですDONOTが、パーサーが文句を言わずに（ほとんどすべての広く使用されている実装で）書くことができます。（もちろん、を書くこともできますがDON'T、簡潔ではありません。読みやすいかもしれませんが、PLEASEN'Tおそらくよりも読みにくいかもしれませんPLEASE NOT。）実際、空白文字が何かをするかどうかについては、いくつかの議論があります。少なくとも1つのINTERCALパーサーにより、数値定数の内部でも使用できます（ゴルフをするときに非常に役立ちません）。心に留めておくべきことの1つは、埋め込みから空白を取り除いて、古いINTERCALパーサーを混乱させる可能性DO READ OUTがあることですDOREADOUTDO（作成者は通常これをバグと見なしているため、現在では通常、有効なプログラムで機能しますが、このようなコードを構文エラーの近くに配置することはお勧めしません。明確にすることは非常に難しいためです）。

文字をオーバーパンチしてスペースを節約できることも覚えておいてください。ASCIIでは、これを本当に引き出すことができるのは'.→ だけですが!、それ自体は非常に便利なトリックです。（配列を使用していない場合、すべてのグループ化文字が同じであっても、スパークイヤーがあいまいになる可能性はありません。そのため、ゴルフエントリの'場合、配列の添え字が本当にを必要としない限り、固執することをお勧めし"ます。）INTERCAL-72が必要とする3 つではなく、?略語（C-INTERCAL）またはLatin-1 ¥（CLC-INTERCAL）を使用して1バイトで表されます。

1つのステートメントでできるだけ多くの作業を行うことに焦点を当てる

INTERCALのステートメント識別子はかなり冗長です。DOすべてのステートメントに2つのノイズ文字が含まれています。ステートメントの名前自体も非常に長くなる傾向がありPLEASE、パーサーを幸せに保つために、ときどき毎回スローする必要があります。（できる最善の方法は、4 DO対1の比率PLEASEです。つまり、5つのコマンドごとに識別子に14文字を使用しています。）一方、式の構文はかなり簡潔です（ばかげていますが、簡潔です）。これは、複数のステートメントを使用する方が「自然な」方法である場合でも、プログラムの一部を単一の式に適合させることが価値がある場合が多いことを意味します。

たとえば、あなたが割り当てたい場合#1に.1と#2に.2、代わりの明白なINTERCAL-72方法でそれをやって：

DO.1<-#1DO.2<-#2

ランダム変数をオーバーロードして、両方を同時に割り当てることを検討することは非常に価値があります。

DO:1<-#1$#2

（:1/!1$.2'プログラムの初期のどこかでスローされます。この表記はINTERCAL-72をかなり後の日付にするため、これを機能させるには最新のINTERCALを使用する必要があります）。これは、セットアップを考慮に入れてもわずかに長く、同時に割り当てる必要がある場合、または同時に割り当てることができる場合.1や、.2複数回割り当てる場合は短くなります。

このトリックが機能するのは、コマンドを計算するだけではありません。変数を2回隠しておく必要がある場合は、次のようにしないでください。

DOSTASH.1DOSTASH.1

しかし、このように：

DOSTASH.1+.1

（+表記法は、概念的に意味のあるほとんどのコマンドで機能します。）

すべてのINTERCAL-72スタイルで1つのRESUMEを使用します。

「if」ステートメントに相当するものを作成する必要がある場合、INTERCAL-72コードを使用する通常の方法は、NEXT2回行ってから計算されRESUMEます。（最近のコードでは、多くの場合、計算COME FROMされた方が優れていますが、このヒントでは、コードが優先することを前提としていますNEXT。）NEXT「if」の1つのブランチから別のブランチにジャンプするため、最初ののバイトを支払う必要があります。NEXTを見てすぐに同じ場所に移動する「if」ステートメントがたくさんない限り、2番目を共有することも簡単ではありません#1。ただし、はRESUMEプログラムのどこにあってもかまいません（コントロールが即座にどこにでも置くためです）。

これを処理するには2つの方法があります。「if」ステートメントが多数ある場合は、RESUMEおそらく1桁の行番号が必要であるため、2番目のNEXTステートメントをできるだけ短くすることができます。可能であれば、RESUMEコードで自然に発生する計算にしてみてください（間違いなく、コードの「通常のフロー」に表示されることはまれなので、これは難しいNEXTです）。次に、唯一のコストは行番号です。これらすべてに単一のブール変数を使用する必要がありますNEXT。ここでの普遍的なコンセンサスはを使用する.5ことです。これは主に、標準ライブラリがブール値の戻り値に使用する変数だからです。

または、標準ライブラリのドキュメント化されていない（気づいたときにINTERCALドキュメントにヒントを入れたため、技術的にはドキュメント化されていない）機能を利用することもできます。の中央の場所RESUMEは非常に便利なので、標準ライブラリは内部で1つ使用します。INTERCALにおける行番号はグローバルである（規約を名前空間を持つが、これはあなたが何をやっている知っている場合分けることができます）あなたができるので、NEXTあなたがする右の標準ライブラリの内部にしたい場合は、特に、缶NEXTにその中心RESUME場所。これは、既存のINTERCALコードで十分に普及しているため、標準ライブラリの置き換えにより、既存のプログラムの破壊を回避するために実装する必要があります。

問題の行は次のとおりです（文字どおりまたは効果的に、実装によって異なります）。

(1001) DO RESUME .5

これを使用しない主な理由は、長い行番号です。多くのINTERCAL-72スタイルのif構文を実行する必要がある場合は、独自のものを使用してより短い数を与えることをお勧めします。

もちろん、テクニックを組み合わせて、次のようなものを書くことができます

(9)DO(1001)NEXT

ほんの少しだけ長いです

(9)DORESUME.5

そして、ブール値が#2andになるという利点があります#3（これは読みにくいですが、通常は生成が簡単です）。実際に、それも価値がハンドルに余分なコードを入れてあるかもしれない#0し、#1あなたは多くのことをiffingするつもりなら（ただし、計算されたCOME FROM要件は非常に奇妙でない限り、おそらくこのケースでは、より良い動作します）。

INTERCALは優先順位を指定していませんが、あいまいな優先順位についてはエラーになりません

のような表現

#1$#2~#3

あいまいであり、

'#1$#2'~#3

または

#1$'#2~#3'

INTERCAL仕様では意図的に不明確になっていますが、一般的には標準がありません（C-INTERCALとCLC-INTERCALは、より単純なケースでは互いに一致するように努力していますが）。とはいえ、オリジナルは正しくありません。あいまいであり、量産コードでの使用はお勧めしません（ただし、量産コードでのINTERCAL自体の使用はお勧めしません）が、大部分のコンパイラーではある程度の意味があります。

つまり、グループ化文字を削除して、プログラムが引き続き機能することを期待するだけの価値があります。ほとんどのインタプリタは、あいまいな式を一貫して解析するため、グループ化文字の各ペアについて、1対2の確率で不必要です。これにより、かなりの節約になります。（残念ながら、INTERCALパーサーはルールが実際に何であるかを完全に確信しているわけではないので十分に混乱する傾向がありますが、通常は実験によって決定できます。最も単純なケースでは、演算子はすべて同じ優先順位を持ち、一貫性のある結合性を持つ傾向があります。）

C-INTERCALでは、次のコードを使用してコードを短縮することを検討してください。 CREATE

このCREATEステートメントでは、新しい構文を作成できます。これにより、ステートメントに短い名前を付けることができるため、ゴルフで特に役立ちます。これを使用して、新しい演算子を作成することで効果的に「関数を定義」することもできます（式の途中で関数を呼び出すことができるという大きな利点があります）。

ここでのセットアップコストはかなり高くなりますが、頻繁に使用する構文がある場合は、構文を短くすることをお勧めします。