全てのデータをフラグメントごとに32bitID化して管理するデータ構造は、 華和梨が持つ最大の特徴の一つである。 等しいデータには必ず同じIDが与えられるため、 実行時の各種演算が極めて高速となる一方、 データ読み込みコストは高い(一回の単語格納コストはstd::mapの検索コストに比例)。
華和梨データ構造(辞書)はString-<KISコード配列>マップ (実際はID-<ID配列>)であり、 さらにキー文字列はドット('.')を区切り文字としたツリー構造として別管理される。 これが華和梨の唯一のデータ構造・データ空間である。 つまり、通常用いられるメモリアドレスの代わりに、 キー文字列(実際はキーID)を用いた検索によってのみ、データ(KISコード)を取得できる。
辞書には、華和梨エンジン一つに対して一つ用意される静的なグローバル辞書のほか、 履歴参照や一時変数などに用いるいわゆるスタックフレームとして、 動的に生成廃棄されるものが存在する。 華和梨ではこのスタックフレーム辞書を「コンテキスト」と称している。
また、華和梨7までは一度ID化された文字列は二度と削除されなかったが、 華和梨8でガーベジコレクションもどきが導入された。 GCは、中間コード評価終了時に、評価中、辞書から一度でも削除されたIDをテストする。 等しいデータを同じIDとする性質から、複数のキーによって参照されるIDが存在するため、 全ての削除予定IDについて、他のキーが参照しているかどうかのチェックが行われる。
wordcollection: データのID化構文コマンドのほとんどは実行時にパースされるため、kawari_codeに記述される。
KISと、いわゆる台詞・単語は、同じようにKIS中間コードオブジェクトとして扱われる。 通常の文字列は「副作用無しに文字列を返す中間コード」となる。 KISのユーザ関数は、関数名に特別なprefixのついた通常のエントリに格納される。 従って、辞書表記や呼び出し方こそ異なるが、 スクリプトと台本は華和梨内部の格納形式は同じである。
kawari_code: スクリプト、エントリ配列呼び出しVMと言っているが、構文木をそのまま実行するので、全然VMではない。 VMが行うのは評価開始時およびユーザ関数呼び出し時の、 コンテキスト生成管理ぐらいである。 それすらnativeスタックを消費してそのまま呼び出すので、 KISのスタックはまともに管理されていないと言える。
TKawariEngineは「華和梨エンジン」オブジェクトであり、 他のモジュールの生成・管理責任を負う。 KISコマンドの多くは、Engineのメソッドによって華和梨機能にアクセスする。 細かい制御が必要な場合は、Engineから各モジュールオブジェクトを得て、操作する。
kawari_vm: 中間コード実行