なぜ新しいプログラミング言語を作成するのですか？ すでに彼らの信じられないほどの数があります-私の確固たる信念では、必要以上のものです。 そして確かに、このような状況における最後の役割は、コンパイラの作成が信じられないほどエキサイティングなプロセスであるという事実によって果たされるわけではありません。 スイカと豚の軟骨に合わせて調整-これは一般的に、熱心なプログラマーが夢見ることができる最も「おいしい」作品の1つです。



言葉では言い表せないほど健康なのは、花candyの期間です。これは、厚手のスマートブックからコンパイラの理論を研究する最初の段階です。 -独自の言語での実際のアプリケーション。 言語の作成者がその唯一のユーザーである可能性があるという悲しい見通しでさえ、創造性の喜びを上回り、真空中のコンパイラであるクリビンを止めることはできません。 もちろん、自分の興味の満足が重要であるだけでなく、プロセス全体の唯一の原動力でもある場合、上記の視点は必然的に実現されます。 しかし、これが新しい言語を作成する唯一の理由ではない場合でも、彼の作成の孤独なユーザーになる見込みはまだ実現する機会があります。



コンパイラを使った小説のフラワーキャンディ時代と私の最初の言語を彫刻する喜びは、かなり前に終わりました。 私たちは神聖な結婚の絆によって私の関係を合法化したと言うことができます：コンパイラー、デバッガー、開発ツールはTibboでの私の主要な仕事であり、すべての結果をもたらします（はい、オブジェクトの飽和、ルーチンタスクの割合の増加など）。 e。）したがって、自分のスクリプトプログラミング言語を作成する動機は、自分の興味の平凡な満足とは異なりました。

なぜですか？

私の個人的および会社としてのモチベーションの実際的な側面をできるだけ簡潔に定式化すると、次のように聞こえます 。構造へのポインタと安全なアドレス計算を備えた組み込みスクリプトエンジンが必要でした。 これは見つかりませんでした。 そして、C互換の構造、安全な算術演算などを備えたポインターを備えたJancy言語（「JavaとCの間」）を作成しました。



ユニークな機能

• 安全なポインターとアドレス演算。
• ソースコードとC / C ++の互換性のスクリプト言語レベルで前例のない;
• リアクティブプログラミング（リアクティブプログラミング）-命令型言語での最初の実装の1つ（ライブラリの形式ではない）。
• レクサー/スキャナーの組み込みジェネレーター。

設計原則

• Cに似た構文を持つオブジェクト指向言語。
• バイナリABI（application-binary-interface）とC / C ++との互換性。
• 正確なガベージコレクションによる自動メモリ管理。
• バックエンドとしてのLLVM 。

その他の重要な機能

• エラーコードモデルに対する構文糖衣のような例外。
• プロパティ-最も完全な実装。
• マルチキャスト（マルチキャスト）およびイベント（イベント）（弱いものを含む）。サブスクライブを解除する必要はありません。
• 多重継承。
• 定数の正確さ;
• RAIIパラダイムのサポート（resource-acquisition-is-initialization）;
• ローカルスレッドメモリ（スレッドローカルストレージ）。
• 関数およびプロパティの部分的なアプリケーション。
• 特定の環境（たとえば、目的のワークフロー）で呼び出されることが保証されている関数へのポインターを作成するためのスケジュール演算子。
• ビットフラグの列挙（ビットフラグ列挙）;
• Perlのような文字列フォーマット。

使用例と機能のより完全なリストは、ここで見つけることができます： http : //tibbo.com/jancy/features.html

誰がこれを使用できますか？

まず、自分用の言語を作成しました。JancyはIO忍者プロジェクトで組み込みスクリプト言語として使用されています。 しかし、それが私たちにとって有用であることが判明した場合、私たちはそれが他の人たちを助けるかもしれないことを控えめに願っています。 この希望は、主にJancyの3つの強みに基づいています。Jancyでは、私たちの言語がアナログに比べて真の利点を持っています。



1. C / C ++との高い互換性

これは、ソースレベルでの互換性だけでなく、バ​​イナリABIの互換性にも適用されます。 多くのプラスがあります：これは、既存のCライブラリのシームレスな接続、コピーペーストとその後の表面的な変更を使用したCおよびC ++からのコードの移植（および場合によってはまったくなし）、およびJancyから使用するためのC / C ++の新しいライブラリの作成の容易さですスクリプト、C / C ++アプリケーションなどにJancyエンジンを埋め込む効率など



2. IOプログラミングのための便利なツール

ここでは、まず、バイナリパッケージの解析と生成に理想的なポインターとアドレス演算のサポートについて、そして次に、レクサージェネレーター（およびインクリメンタル、つまりIOストリームの解析に適用可能）について主に話します断片的に）。 これには、部分アプリケーションと計画演算子も含まれます。これらを組み合わせて、たとえば、キャプチャされたコンテキスト引数を使用して完了ルーチンを作成できます。 この場合、目的のワークフローで自動的に呼び出されます。



3. UIプログラミングのための便利なツール

二つの言葉： リアクティブプログラミング 。 近い将来、言語レベルまたはプリプロセッサやライブラリなどの松葉杖の形での反応性のサポートが、ユーザーインターフェイス（UI）を開発するためのシステムの不可欠な部分になると確信しています。 Jancyは、箱から出してすぐに、そして完全に直観的な方法で反応性を提供します。 Jancyは、反応性に加えて、さまざまな種類のプロパティとイベントをサポートしており、美しいユーザーインターフェイスフレームワークの構築にも役立ちます。



同時に、ポイント3の優れた機能にもかかわらず、Jancyをユーザーインターフェイス開発言語として位置付けていません。 現時点での最大のタスクは、低レベルIOプログラミング用のスクリプト言語になることです。 システム/ネットワークプログラマー/ハッカーツール 。



そして今-スライド！ ©

C / C ++とのABI互換性

互換性は常に良好であり、事実上のシステムプログラミング言語標準との互換性は非常に優れています。



JancyスクリプトはJITでコンパイルされており、C / C ++プログラムから直接呼び出したり、C / C ++関数を直接呼び出したりすることができます。 これは、JancyスクリプトとC ++アプリケーションでデータ型と関数プロトタイプを適切に記述した後、関数の引数と戻り値を使用してデータを自然に転送できるようになることを意味します。



Jancyスクリプトから関数を宣言して使用します。

bool foo ( char charArg, int intArg, double doubleArg ); bar (int x) { bool result = foo ('a', x, 3.1415); // ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実装をC / C ++で記述します。

 bool foo ( char charArg, int intArg, double doubelArg ) { // ... return true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトのJITコンパイルの前に接続します。

 class MyLib: public jnc::StdLib { public: JNC_BEGIN_LIB () JNC_FUNCTION ("foo", foo) JNC_LIB (jnc::StdLib) JNC_END_LIB () }; // ... MyLib::mapFunctions (&module);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

できた！ バリアントのようなコンテナのパッケージ化/アンパック、仮想マシンスタックへの引数の明示的なプッシュなどはありません。 -すべてが直接機能します。 現在、Jancyはすべての主要な呼び出しモデル（呼び出し規則）をサポートしています。

• cdecl（Microsoft / gcc）
• stdcall（Microsoft / gcc）
• Microsoft x64
• システムv

反対の方向-C ++からJancyを呼び出すのは簡単です：

 typedef void Bar (int); Bar* bar = (Bar*) module.getFunctionByName ("bar")->getMachineCode (); bar (100);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

システム関数と動的ライブラリ（dll / so）の呼び出しはどうですか？ 質問なし！ Jancyは、動的ライブラリとのシームレスな統合を提供します。

 library User32 { int stdcall MessageBoxA ( intptr hwnd, char const thin* text, char const thin* caption, int flags ); // ... } // ... User32 user32; user32.load ("user32.dll"); user32.lib.MessageBoxA (0, "Message Text", "Message Caption", 0x00000040);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、要求が行われるときに名前解決が実行され、見つかったアドレスがキャッシュされます（モジュール自体の明示的なロード用に調整されたDELAYLOADを思い出させます）。 名前のロードおよび解決時のエラー処理は、Jancyの標準の擬似例外メソッドによって実行されます（詳細については、次のセクションを参照してください）。



もちろん、名前による動的検索（GetProcAddress / dlsym）も可能です-以前のアプローチほどエレガントではありませんが。



JancyとC / C ++間の高度な互換性のもう1つの重要な結果は、パブリックソース（Linux、React OS、または他のオープンソースプロジェクトなど）からコピーし、Cの通信プロトコルのヘッダーの定義を使用できることです。

 enum IpProtocol: uint8_t { Icmp = 1, Tcp = 6, Udp = 17, } struct IpHdr { uint8_t m_headerLength : 4; uint8_t m_version : 4; uint8_t m_typeOfService; bigendian uint16_t m_totalLength; uint16_t m_identification; uint16_t m_flags; uint8_t m_timeToLive; IpProtocol m_protocol; bigendian uint16_t m_headerChecksum; uint32_t m_srcAddress; uint32_t m_dstAddress; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、逆バイト順の整数型（ビッグエンディアン）のサポートに注意してください。 もちろん、これは大規模なイノベーションとはほど遠いものですが、説明を大幅に簡素化し、ネットワークプロトコルのヘッダーを操作します。ここでは、バイトの逆順がどこにでもあります。

疑似例外

逆説的に、ABIとC / C ++との互換性の結果の1つは、C ++プログラマーに馴染みのある例外モデルの拒否でした。 実際、そのような例外は多言語コールスタックには完全に不適切です（もちろん、C ++に対する客観的な主張のリストはそのような例外に限定されません。 only望のみ）。



いずれにしても、Jancyはハイブリッドモデルを使用します。 戻り値のチェックに基づいていますが、コンパイラーはこれを手動で行う必要をなくします。 最終的に、すべてがC ++またはJavaの例外のように見えますが、同時に、エラーに対するプログラムの動作ははるかに透過的で予測可能です。可能な限り。

 bool foo (int a) throws { if (a < -100 || a > 200) // invalid argument { jnc.setStringError ("detailed-description-of-error"); return false; } // ... return true; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

throws修飾子でマークされた関数の戻り値は、エラーコードとして扱われます。 Jancyは、標準型の直感的なエラー条件を受け入れます。ブール型の場合はfalse、ポインターの場合はnull、符号なし整数の場合は-1、符号付き整数の場合は<0です。 残りの型はブール値に変換されます（これが不可能な場合、コンパイルエラーがスローされます）。 明らかに、このモデルでvoidを返す関数はエラーを返すことはできません。



さらに、このモデルでは、開発者はそれぞれのケースでエラーを処理する方法を自由に選択できます。 戻りコードを手動で確認することでこれを行う方が便利な場合もあれば、例外のセマンティクスを使用できる場合もあります。 Jancyで-同じ関数を呼び出すとき！ -状況に応じてこれを行うことができます。

 bar () { foo (10); // can use exception semantics... foo (-20); catch: printf ($"error caught: $(jnc.getLastError ().m_description)\n"); // handle error } baz (int x) { bool result = try foo (x); // ...or manual error-code check if (!result) { printf ($"error: $(jnc.getLastError ().m_description)\n"); // handle error } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの言語の最終的な構成は、伝統的に例外に関連付けられています。 しかし、Jancyでは、開発者の要求に応じて最終的に任意のブロックに追加できます。 最後に、エラーが発生していなくてもクリーンアップする必要がありますか？

 foo () { // nothing to do with exceptions here, just a 'finally' block to clean up finally: printf ("foo () finalization\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、例外がまだ予想される場合には、finallyコンストラクトのより伝統的な使用も許可されます。

安全なポインタとアドレス演算

スクリプト言語のアドレス演算は、すべてが実際に開始されたものです。



ポインターは、その固有のすべての不安定さとともに、明示的または暗黙的にあらゆる言語の一部です。 開発者が使用できるポインターのタイプとそれらを使用する操作を制限することにより、言語を大幅に保護し、実行中の不都合な状況の処理を簡素化し、静的分析を使用してコンパイル時に誤った操作をキャッチすることもできます。 しかし、アドレス演算が機能するようになると、分析をコンパイル段階に完全に移行することは不可能になります。



操作の正確性を常に確認できるようにするため、Jancyのポインターはデフォルトで太くなっています。 アドレスに加えて、バリデーターも含まれます。これは、アドレスの許容範囲、データのタイプ、および整数のネストレベル（スコープレベル）に関する情報を取得できる特別なメタデータ構造です。



Jancyのポインターとアドレス演算の安全公式は次のとおりです。

1. ポインターへの間接アクセスの範囲を確認します。
2. ポインターを割り当てるときにネストのレベルを確認します。
3. ポインター割り当ての還元性テスト。

有効なアドレス範囲チェックは、ポインターを明示的に使用する場合と、インデックス演算子の場合の両方で実行されます。

 foo ( char* p, size_t i ) { p += i; *p = 10; // <-- range is checked static int a [] = { 10, 20, 30 }; int x = a [i]; // <-- range is checked }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スタック変数とストリーム変数へのポインタの場合、ネストレベルのチェックも必要です-寿命の境界を超えてアドレスが漏洩するのを防ぐため。 このメカニズムは、構造体へのポインターから構造体へのポインターなど、マルチレベルポインターの場合でも機能します。

 int* g_p; bar ( int** dst, int* src ) { *dst = src; // <-- scope level is checked } baz () { int x; bar (g_p, &x); // <-- runtime error: scope level mismatch }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に、還元性チェックは、バリデータ自体の破壊を防ぐように設計されています。 確かに、ポインターへのポインターを作成し、charへのポインターに持ってきて、バイトごとに、バリデーターをガベージで上書きするとどうなりますか？ Jancyはこれを許可しません。コンパイラとランタイムは、安全な場所でのみキャストを許可します。



親愛なるhabrovchanieが私たちのオンラインコンパイラを試してみて、実際にすべてがどのように機能するかをテストしてください（読んでください：コンパイラで、ダンプするポインタを備えたサンプルスクリプトを試しましょう）



Jancyポインターの詳細については、 http ：//tibbo.com/jancy/features/pointers.htmlをご覧ください。

自動機能

安全なポインタとアドレス演算は、バイナリパッケージの解析と生成に最適です。

 dissectEthernet (void const* p) { io.EthernetHdr const* hdr = (io.EthernetHdr const*) p; switch (hdr.m_type) { case io.EthernetType.Ip: dissectIp (hdr + 1); break; case io.EthernetType.Ip6: dissectIp6 (hdr + 1); break; case io.EthernetType.Arp: dissectArp (hdr + 1); break; // ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、別のクラスのプロトコルがあります。バイナリヘッダーに依存せず、代わりに何らかの種類の要求/応答言語を使用するプロトコルです。 この場合、IOフローの分析のために、この言語のパーサーを作成する必要があります。 同時に、予備のデータバッファリングに注意する必要があります。多くの場合、トランスポートがメッセージを分割して送信するのではなく、全体を送信するという保証はありません。



このタスクはIOプログラミングでは一般的であるため、Jancyはそれを解決する組み込みツールを提供しています。 Jancyの自動機能は、パーサーを作成する最初の最も日常的な段階（レクサー/スキャナーの作成）を容易にするように設計されています。 これは、 Lex 、 Flex 、 Ragelなどの有名なLexerジェネレータの原理で動作します：

 jnc.AutomatonResult automaton scanRx (jnc.Recognizer* recognizer) { %% "getOption" createToken (Token.GetOption); %% "setOption" createToken (Token.SetOption); %% "exit" createToken (Token.Exit); %% [_\w][_\w\d]* createToken (Token.Identifier, recognizer.m_lexeme); // ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オートマトン関数内には、認識可能なトークンのリストが正規表現の形式で記述されています。 各トークンの説明の後、入力ストリームで検出されたときに実行する必要があるコードブロックが続きます。 このキッチン全体がテーブルDFAにコンパイルされ、その状態は外部jnc.Recognizerオブジェクトに保存されます（このオブジェクトへのポインターは認識エンジンの引数で渡されます）。 潜在的なトークンのシンボルがその中に蓄積され、暗黙的に自動関数を呼び出して、状態間の必要な遷移を実行します。



オートマトン関数とこの制御オブジェクト認識機能の全体がレクサーです。 同時に、このレクサーはインクリメンタルになります。つまり、部分的に到着するメッセージを解析できます。

 jnc.Recognizer recognizer (scanRx); // create recognizer object try { recognizer.write ("ge"); recognizer.write ("tOp"); recognizer.write ("tion"); recognizer.eof (); // notify recognizer about eof (this can trigger actions or errors) catch: // handle recognition error }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ragelの場合と同様に、異なる自動機能を切り替えることができます。これにより、特に状況依存キーワードを作成できます（または、別の言い方をすると、多言語入力を解析できます）。



オートマタは一方で機能し、他方ではアドレス演算を備えた安全なポインタにより、あらゆるタイプのプロトコルおよびIOストリームを簡単に解析できます。

おわりに

現時点ではユーザーインターフェイス（UI）のプログラミングはJancyの主な目的ではないという事実にもかかわらず、Jancyが使用するリアクティブプログラミングへのアプローチを実証したいと考えています。リアクティブプログラミングで開始。 これについての話は、次の記事で説明します。



それまでの間、 ライブコンパイラのデモページでJancy言語の可能性（この記事や他の多くの記事で説明）を試してみてください。 また、Jancy JITコンパイラライブラリとその使用例をダウンロード、ビルド、およびプレイすることもできます。これらはすべて、 ダウンロードページで入手できます。