私は Haskell 201 レポートを見て、アンパサンド付きの奇妙なエスケープシーケンスに気づきました:\&
。このエスケープシーケンスの意味を説明することができませんでした。また、文字列にのみ配置される場合もあります。私は試した print "\&"
GHCiでは、空の文字列を出力します。
それはエスケープします...文字はありません。一部のエスケープシーケンスを「解除」すると便利です。たとえば、"\12" ++ "3"
を単一の文字列リテラルとして表現したい場合があります。明白なアプローチを試みると、
"\123" ==> "{"
ただし、使用できます
"\12\&3"
意図した結果のため。
また、"\SOH"
と"\SO"
は両方とも有効な単一のASCII文字エスケープであるため、"\SO" ++ "H"
を単一のリテラルとして表現するのは難しいため、"\SO\&H"
が必要です。
このエスケープトリックは、有効なリテラル構文を生成する必要がある標準のShow String
インスタンスによっても利用されます。これがGHCiで動作していることがわかります。
> "\140" ++ "0"
"\140\&0"
> "\SO" ++ "H"
"\SO\&H"
さらに、これはHaskellコードの生成を目的とする外部プログラム(メタプログラミングなど)に大きく役立ちます。文字列リテラルの文字を出力する場合、外部プログラムは、あいまいな可能性のあるエスケープ(またはすべてのエスケープ)の最後に\&
を追加して、プログラムが不要な相互作用を処理する必要がないようにすることができます。例えば。プログラムが\12
を今すぐ発行したい場合は、\12\&
を発行し、次の文字として何でも自由に発行できます。そうでない場合、プログラムは、次の文字が発行されるときに、それが数字の場合は\&
を前に付ける必要があることを覚えておく必要があります。必要がない場合でも、常に\&
を追加する方が簡単です。\12\&A
は正当であり、\12A
と同じ意味です。
最後に、\&
を説明するHaskellレポートからの引用:
2.6文字および文字列リテラル
[...]
「最大ムンク」ルールと一致して、文字列内の数値エスケープ文字はすべての連続する数字で構成され、任意の長さにすることができます。同様に、あいまいなASCIIエスケープコード
"\SOH"
は、長さ1の文字列として解析されます。エスケープ文字\&
は、"null character"
や"\137\&9"
などの文字列を構築できるように"\SO\&H"
として提供されます(したがって、"\&"
は""
と同等であり、'\&'
の文字は使用できません。文字の同等の定義については、セクション6.1.2で定義されています。