Erlang構文について少し

最初、このopusを「 Learn You Some Erlang 」という本の追加としてリリースする予定でしたが、その内容は参考資料よりも編集資料との整合性が高いため、ブログにそれを書くことにしました。



Erlangの世界の多くの新参者は、Erlangの学習に成功し、Erlangをよく知ることなくプレイを開始しました。 私は、構文とこれらの「 ヤギボール 」（ アリタード-orig 。）-キャラクターを呼び出す「楽しい」方法について多くの苦情を読みました。 、 。 。 たとえば、「彼らはどのように怒りますか」など。



本の中で、ErlangはPrologに由来すると述べました。 これにより、これらすべての句読点がどこから来たのかを理解できますが、悲しいことに、これは人々がそのような句読点に愛を染み込ませることはありません。 確かに、なんらかの理由で誰も私に言ってくれません。 プロローグ！ 「これを前に言ったことはありません！」これを考慮して、世界をより良い場所にするために、Erlangコードを人間が読むための3つの可能な方法を提案します。

模様

最愛の人。 この方法を理解するには、コードを一連の行として見るのをやめて、式で考え始める必要があります。 式は、何かを返す任意のコードです。



Erlangコマンドラインでは、ピリオド（ 。 ）記号は式の終わりを示します。 2 + 2式を実行するには、実行して何かを返すようにピリオドを入力する（そしてEnterを押す）必要があります。

ただし、モジュールを記述するとき、ドット文字はFormsで終わります。 フォームは、モジュールまたは関数宣言の属性です。 フォームは何も返さないため、式ではありません。



これらの機能を考慮して、ピリオド（ 。 ）の使用について長い間議論することができます。 しかし、コマンドラインをハンマーで打って、このメソッドを使用しないことをお勧めしますが、代わりにポイントでフォームを完成させる必要があることを覚えておいてください。



しかし、続けましょう。 さらに2つのルールが必要です。

1. コンマ（ 、 ）は式を区切ります：
   
   

   C = A+B, D = A+C
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   まるでナッツのようですね。 ただし、
   
   

    if ... end case ... of ... end begin ... end fun() -> ... end try ... of ... catch ... end
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   -表現のすべての本質。 たとえば、次のことができます。
   
   

    Var = if X > 0 -> valid; X =< 0 -> invalid end
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   そして... endの場合、出力で値を取得します。 これは、これらの言語構成の後にコンマ（ 、 ）が表示されることがある理由を説明します。これは、実行する必要がある別の式があることを意味します。
   
   
2. セミコロン（ ; ）には2つの機能があります。
   
   
   1. 彼女は関数のさまざまな定義を共有しています。
      
      

       fac(0) -> 1; fac(N) -> N * fac(N-1).
            
            
      
              
              
              
            
      
          
              
              
              
            
            
      
              
              
              
            
      
          
           

      
      
      
   2. if ... end、case ... of ... endなどの式のさまざまなブランチを分離します。
      
      

       if X < 0 -> negative; X > 0 -> positive; X == 0 -> zero end
            
            
      
              
              
              
            
      
          
              
              
              
            
            
      
              
              
              
            
      
          
           

      
      
      式の最後の分岐が分離しない（ ; ）のは奇妙に思えるかもしれません。 しかし、実際には（ ; ） はブランチを分割しますが、それぞれを終了しません。 行ではなく式で考える必要があります。 次のように区切り文字を配置すると、コードを読みやすい人もいます。
      
      

       if X < 0 -> negative ; X > 0 -> positive ; X == 0 -> zero end
            
            
      
              
              
              
            
      
          
              
              
              
            
            
      
              
              
              
            
      
          
           

      
      
      このようなフォーマットは、セパレータとしての（ ; ）の役割をより強調します。 この記号は、ブランチと条件の間を行き来し、それらの後ではありません。
      
      
   
   
   

上記のすべてを要約すると、式（たとえば、case ... of ... end）の後にコンマ（ 、 ）が続く場合、次の式が続く必要があると安全に結論付けることができます。 セミコロン（ ; ）は関数ブランチの最後に配置され、ピリオド（ 。 ）は関数の最後のブランチに配置されます。



通常の表現では、行を（ ; ）文字（たとえば、CまたはJava）で区切りましたが、今はそれを取り出してウィンドウから外すだけです。 代わりに、コードを入力可能なテンプレートと見なします（メソッドの名前）。

 head1(Args) [Guard] -> Expr11, Expr12, …, Expr1N; head2(Args) [Guard] -> Expr21, Expr22, …, Expr2N; headM(Args) [Guard] -> ExprM1, ExprM2, …, ExprMN. %%  ExprIJ -  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのルールは実際に機能しますが、脳をコード読み取りの異なるモードに切り替える必要があります。 ここが最も難しい移行です。ラインとブロックから定義済みのパターンに移行する必要があります。 説明してみましょう：あなたがそれについて考えるなら、そのような構造

 for (int i = 0; i >= x; i ++) { … } //   for (...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他の言語の他の多くの構造と比較して、非常に奇妙な構文を持っています。 私たちはそのような構造に非常に慣れているため、非常に冷静に考えています。

申し出

私の好きな方法ではありませんが、私は人々が論理構造を異なって知覚することを理解しています。 さらに、この方法はしばしば賞賛されます。



ここでは、アーランと言語（英語が可能、ロシアが可能）を比較します。 旅行するもののリストを編集していると想像してください。 いいえ、表せませんが、ここにあります：

      :   ,    , , ;   ,  , ;   ,   , .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これをErlangに翻訳すると、すべてが非常によく似たものになります（残念ながら、Erlangはソースコードではなく文字列変数のフレームワーク内でのみUTFをサポートしているため、この形式では機能しません。 -1。-約。

 () -> , , ; () -> , ; () -> , .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわかりのように、オブジェクトを式で簡単に置き換えることができます。 しかし、if ... endという形式の式は、そのようなもののネストされたリストとして単に表されるべきです。

そして、または、終わり

#erlangで提供された別の方法。 この方法では、（ 、 ）が表示されたら、「AND」を読む必要があります。 （ ; ）それは「OR」（オプションとして、「MORE」-約Per。）になります。 したがって、関数宣言はネストされた論理述語と条件のセットとして読み取ることができます。

結論として...

些細なことをせずに2行のコードを取得してスワップできないため、「ヤギボール」を取得するのは非常に困難です。 私は、人間レベルで言語を解釈する多くの方法を考え出すことは難しいように思えます（そして、それはほとんど必要ありません）が、この記事が誰かに役立つことを願っています。 最後に、「構文は複雑ではなく、ただ怖いです。」