Design: 重複インポートを禁止しますか？

この変更を行わなかった場合、モジュールリンクの提案でどのような悪いことが起こりますか？ それは、この脱糖が完全に機能せず、したがって輸入品の仕様の説明がより複雑になることを意味するのでしょうか？ それとも、提案をリンクするモジュールの機能をより根本的に妨害しますか？ （私はこの変更にまったく反対していません。動機をよりよく理解しようとしているだけです。）

ルークのプレゼンテーションで覚えているように、現在、重複したエクスポートは許可されていません。

この制限を解除し、重複エクスポートを許可するとどうなりますか？ これにより、この問題を別の方法で解決するためのモジュールリンクの設計スペースが開かれます。

現在、エンジンは2つの理由でインポート/エクスポート名を検査するだけで済みます。UTF-8の整形式性と重複したエクスポートチェックです。 UTF-8の制限を解除することについてオフラインで話しましたが、両方を解除できるかもしれません。

エクスポートが重複すると、名前ベースのリンクがあいまいになります。

@tlively重複インポートを許可しない場合、 module-linking /＃7で説明した代替ソリューションは、検証とリンクの実装にかなりの複雑さを追加するように思われ

@titzer重複するエクスポートを追加すると、ソースと言語の統合ごとに非常に複雑です。 このJS関数をwasmから（ WebAssembly.instantiate経由で）インポートしようとするとどうなりますか？ 不可能な設計上の問題だと言っているわけではありませんが、N言語の統合について、これらの難しい/厄介な質問を完全に回避するオプションがある場合は、それが望ましいと思われます。

重複インポートは、同じ関数がさまざまな署名を持つことができるJSのような動的言語からのインポートを呼び出すのに非常に便利です。境界の型システムが豊富になると、使用される量が少なくなることはないと思います。数値または文字列引数、あるいは1つまたは2つの引数を持つ同じ関数。 この機能を削除することは、JSとの相互運用にとって非常に残念なことだと思います。

@lukewagner 、これはモジュールリンクの提案に精通していないため悪い考えかもしれませんが、MVPインポートとインスタンスインポートを区別することは別のオプションではないでしょうか？ それらが統合されていない場合でも、MVPインポートは複製される可能性があり、複雑な交差タイプは必要ありません。

重複インポートは、同じ関数がさまざまな署名を持つことができるJSのような動的言語からのインポートを呼び出すのに非常に便利です。境界の型システムが豊富になると、使用される量が少なくなることはないと思います。数値または文字列引数、あるいは1つまたは2つの引数を持つ同じ関数。 この機能を削除することは、JSとの相互運用にとって非常に残念なことだと思います。

この。 これの千倍。 私は、assemblyscript開発者にテストフレームワークを提供するプロジェクトの主要な開発者であり、これはおそらく現時点でWebアセンブリの最も重要な部分の1つであると考えています。

0.00014％には、 @ jtennerによるAssemblyScriptのテストランナーであるれています。これは、成長するAssemblyScriptエコシステムの重要な部分です。

重複インポートは、同じ関数がさまざまな署名を持つことができるJSのような動的言語からのインポートを呼び出すのに非常に便利です。

WebAssemblyの起源はJavaScriptを備えたブラウザーにあるため、少なくともこれに代わるものがあれば、それは素晴らしいことです。 そのターゲットのために物事を簡単に保ちましょう。

@tlivelyそれは可能な代替オプションの1つです、はい、しかしそれはほぼ同じことをする2つの方法があるという不幸な結果をもたらします、それは一般的に避けるのが良いことです、そしてそれはまた実装が気にするより多くのケースを作成します検証、サブタイプのチェック、およびインスタンス化中。

@jtenner @trusktr明確にするために、同じJS関数を複数回インポートすることもできます。唯一の違いは、インポートに使用した個別の署名ごとに異なる名前が必要になることです。 したがって、たとえば、放出する代わりに：

(module
  (import "env" "log" (func (param i32)))
  (import "env" "log" (func (param f32)))
  (import "env" "log" (func (param i64)))
  (import "env" "log" (func (param f64)))
  ...
)

を介してインスタンス化：

WebAssembly.instantiate(module, { env: { log:log } });

あなたが放出する可能性があります：

(module
  (import "env" "log_i32" (func (param i32)))
  (import "env" "log_f32" (func (param f32)))
  (import "env" "log_i64" (func (param i64)))
  (import "env" "log_f64" (func (param f64)))
  ...
)

インスタンス化：

WebAssembly.instantiate(module, { env: { log_i32:log, log_f32:log, log_i64:log, log_f64:log } })

それはあなたが行うことができる可能性のある変更ですか、それとも何らかの方法で法外なものですか？

それはあなたが行うことができる可能性のある変更ですか、それとも何らかの方法で法外なものですか？

禁止？ いいえ。リンク先の関数の名前を変更するだけであれば問題ありません。 迷惑ですが、問題ありません。 正しく聞こえていることを確認したいだけです。

そのターゲットのために物事を簡単に保ちましょう。

JavaScript開発者は、この変更によって最も影響を受けます。 そして、私たちは「Webアセンブリ」であるため、このような将来の問題に関してWeb開発者をどのように扱うかについては非常に注意する必要があります。

それが物事をより良くするなら、私はすべて変化を求めています。 ですから、私が最も重要だと思うものから最も重要でないものの順に、次の質問があります。

1. これはウェブを開発のためのより良い場所にしているのでしょうか？

私が見る限り？ 多分。 これにより、開発者はインポートについてより明確になり、JavaScript開発者がjavascriptyを少なくすることを思いとどまらせます。 たぶん、より多くの制限はより多くの創造性につながります。 これがC＃およびJava開発者にどのように影響するかということは、決して行われていないように思われる会話です。 これは、Webアセンブリコンパイラを作成するC＃開発者にも悪影響を与える

1. これにより、WebAssemblyの実装、保守が容易になり、実行が速くなりますか？

これに対する答えはわかりません。 コンパイラ開発者は、この種のことに精通しているでしょう。 私の推測では、wasmエンジンを保守しようとしている開発者にとってはより便利だと思います。 そして、ええ、それはより速くなるでしょう、あるいは少なくともそれはより明確で、モジュールの状態を検証するのがより簡単になるでしょう。

1. この変更は、以前は変更されていない動作に依存している開発者に悪影響を及ぼしますか？

私の知る限り、この機能を使用している少数の人々は、自分たちのものが壊れてしまい、戻ってソフトウェアを修正する方法を見つけなければならないことに不満を抱くでしょう。

AssemblyScriptのテストフレームワークソフトウェアを保守した後、このような小さな変更が一般的なエンド開発者に影響を与えないことに気付きました。 これらの変更は、エコシステムソフトウェア、開発ツール、およびコンパイラを保守する人々に影響を与えます。 このような仕様の微妙な変更により、非常に大きなプルリクエストが発生し、処理に数日または数週間かかる場合があります。

私の最後のtl; drの意見：私はこの変更が好きではありませんが、変更を加える場合は、すでにバンドエイドを外してください。 今すぐ連鎖反応を開始し、それを数えます。

これにはもう1つの欠点があります。

(module
  (import "env" "log_i32_f32_f64" (func (param i32 f32 f64)))
  (import "env" "log_f32_i32_f64" (func (param f32 i32 f64)))
  ...
)

（デマングリングのために）元のインポート名を保持する必要があり、インポート名を圧縮するbinaryenのパスを適用できない場合、バイナリサイズが大きくなる可能性があります。

ただし、一般的なケースではそれほど大きな問題ではありません

私が見ている主要な問題は、ユーザーがインポートオブジェクトを手動でマングルするために、すべてのアリティと引数のタイプを事前に知っている必要があることですが、現在、コンパイラは、たとえばMathが全体としてインポートされていると想定し、インポートを生成できますコンパイル中にインポート呼び出しが発生したときに、名前は同じですが、アリティまたは引数のタイプが異なります。 ここでの簡単な例はMath.max 。少し複雑なのは、署名が

CGミーティングで表現できなかったのは、モジュールリンクの提案が名前ベースのリンクからエンジンに要件を押し下げようとしていることだと思います。ここにレイヤーがあるのは当然のことです。押し下げられないでください。 たとえば、コアwasmのバイナリ形式を制限する場合、エンジンは準拠していないモジュールをチェックして拒否する必要があることを宣言しています。 型安全性、妥当なサイズ制限、およびエンジンにとって重要なその他の事項については、これは完全に理にかなっています。

名前はエンジンにとって重要ではないと私は主張します。 それらは埋め込みをホストすることだけが重要であり、エンジンは実際には名前を調べる必要はありません（拒否することははるかに少ないです）。 これは、他のコメント提供者が言及したJSの過負荷状況で証明されています。

UTF-8についての私のコメントはその方​​向にありました。 エンジンは、不正な名前を拒否することを除いて、文字通りUTF-8処理を必要としません。 重複するエクスポートについても同じです。 突然UTF-8バリデーターを最初から実装しなければならなかったので、これはウィザードを実行するのに非常に面白いにおいがしました...うーん。 また、重複エクスポートチェックは、ウィザードがハッシュテーブルを使用する唯一の場所です。 100行ほどのコードが危機であるというわけではありませんが、それ以外の場合は計算指向のVM演習では奇妙なことです。

モジュールリンク提案の目標は、Wasmに標準の名前ベースのリンクソリューションを提供することであることを理解していますが、いくつかの理由から、一般的に十分に機能しないリスクがあるため、禁止することに頼る必要があると思います。エンジンレベルで、エンジンの観点から見事に完璧です。

ですから、私は以前の提案を支持し、むしろもっとリベラルにすべきであり、おそらく重複輸出の制限を解除すべきです。

モジュールリンクの提案で、名前の問題のためにリンクできないモジュールを今すぐ拒否したい場合は、コアwasmの上のレイヤー制限として完全に問題ないようです。 しかし、私が言ったように、モジュールリンクの提案が非常に多くのプログラミング言語のリンクの問題を解決しないリスクがあり、代わりにファーストクラスのモジュールのAPIを含むよりプログラム可能なソリューションが必要になります。 しかし、それはおそらくより長い会話であり、これはかなり狭い問題です。 それがここでの私の考えの文脈です。

ああ、面白い@titzer。 私も同じような考えを持っています。 要するに、コンパイルとリンクは接続されていますが、それでも別個のものであり、この問題は、それらがあまりにも密接に結合されているというカナリアです。

WebAssemblyのすべてのリンク関連の側面を取り上げて、別のセクションに配置することを想像できます。 「コンパイル」セクションには引き続きインポートがありますが、名前は付けられていません（インデックス以外）。「リンク」セクションが埋める穴だけです。 「コンパイル」セクションにはまだエクスポートが含まれている可能性がありますが、ここでも名前がなく、「リンク」セクションが名前の提供を担当します。

したがって、セクションをリンクすると、埋め込み者固有のコンテンツが含まれる可能性があります。 たとえば、インターフェイスタイプのリンクセクションはadapter_func提供できますが、JSのリンクセクションは@tebbiのWebAssembly / gc＃132のようにrttディクショナリをインストールできます。どちらの場合も、この追加コンテンツは、特定の埋め込みのために理にかなっていると、その特定の埋め込みのために極めて有用です。 モジュールタイプの提案は本質的に別のリンク埋め込みであり、緊張の一部は、そこで最も意味のあるもの（たとえば、単純なリンク解決の単一の名前）がJSで最も意味のあるもの（たとえば、オーバーロードされた名前）ではないということです。

補遺：これは、ジッティングをサポートするのに役立つ可能性があります。 モジュールは、それらの関数を組み込みリンクシステムに公開することなく、動的に生成する追加のモジュールから関数を直接呼び出すことができることを望んでいます。

@titzerが言ったように、これもこの議論の範囲を超えていますが、私は自分の考えをアイデアにも混ぜたかったのです。

@dcodeIOこれまで見てきたすべてのシナリオで、wasmモジュールをインスタンス化するJSコードは、wasmモジュールを生成するのと同じツールチェーンによって生成されます（b / cインスタンス化には、一般に多数のグルーコードが必要になる傾向があります）。この暗黙の詳細がユーザーにバブルすることを認識していません。 しかし、あなたは違った見方をしましたか？

明確にして強調したいことの1つは、純粋なJSエコシステムPOVからの重複インポートは危険です。これは、JS APIとESM統合の両方に、Bに重複インポートがある2つのwasmインスタンスAとBを接続する方法がないためです。 Aは適切な署名で2つの関数をエクスポートできる可能性がありますが、Bはそのうちの1つしかインポートできません（1つの署名では、通常、両方のインポートを満たすことはできません）。

@titzer名前を遠ざけたいという願望を理解していますが、現在提案されているようにモジュールをインポートするのではなく、目標を実現するためです。

(module
  (import "other" (module
    (import "foo" (func))
    (export "bar" (func))
  ))
)

代わりに、インポートタイプから"foo"と"bar"を削除して、純粋に位置的なものを残す必要があります。

(module
  (import "other" (module
    (import (func))
    (export (func))
  ))
)

個別のコンパイルシナリオ（たとえば、共有ライブラリを広く再利用されるモジュールに分解する）を楽しみにしている場合、位置の順序に完全に依存するため、これは古いC ++の壊れやすいベースの問題のwasmバージョンにつながります。 これは、インポート/エクスポート名が修正するものです。 それはあなたが提案していることですか？ （ファーストクラスのモジュール参照および/またはファーストクラスのインスタンス/インスタンス化にはすべてこれと同じ問題があることに注意してください。直交しています。）

しかし、それがあなたが提案しているものではない場合、モジュールリンクの重要な部分である名前、したがって重複したインポート/エクスポートによって引き起こされるあいまいさからどのように逃れることができるかわかりません。

いいえ、私は位置リンクを提案していません。 私はそれが確かに非常に壊れやすいであろうことに同意します。

しかし、Jawaのユースケースとインターフェイスの種類を考えると、目立つのは、実際にロジックを解析してインポートに適用する必要があることです。 Jawaでは、インポート名は文字列ではなく、実際には言語の式であり、インポート引数を使用すると、型と関数をインポートとして受け取ることができます。 Javaや高級言語のIMHOとの遅延バインディングに対する純粋なwasmソリューションはありません。 低レベルの名前ベースのリンクソリューションは、非常に限られた言語のセットで構築されたニッチなwasmエコシステムに役立つ可能性がありますが、長期的には高レベル言語のユースケースを解決しません。 つまり、IMOは、より高いレベルでリンクを構築するのに十分な一般的なメカニズムを追加するのではなく、新しい非常に限定されたエコシステムの作成を可能にするメカニズムを構築しています。

したがって、ファーストクラスのモジュールについての私のコメント。 長期的には、完全にプログラム可能なリンクを可能にするリフレクションおよびJITing APIが必要になります。非常に厳格な名前ベースのマッチングシステムでは、言語の実際の問題を実際に解決したり、十分なロープを提供したりすることはできません。

また、名前ベースのマッチングも非常に脆弱です。 インポート用のパラメーター化メカニズムがまだないため、言語は名前マングリングに頼る必要があります。これは醜くて壊れやすく、サブタイプやオーバーロードなどの単純なものでもサポートできません。

コメントが長くなってすみません。 私たちは今、より大きな問題について実際に議論していますが、それはおそらくここのような狭い問題ではないはずです。

私が見たすべてのシナリオで、wasmモジュールをインスタンス化するJSコードは、wasmモジュールを生成するのと同じツールチェーンによって生成されます（b / cインスタンス化には、一般に、多数のグルーコードが必要になる傾向があります）

たとえば、AssemblyScriptはモジュール固有のグルーコードを生成しませんが、生成を回避しようとします。 単に「ローダー」と呼ぶ小さな汎用コンパニオンJSライブラリ（JSからのより便利な使用法のために高レベルのエクスポート名をデマングルすることができます）で使用するためのタイプ定義（開発目的）のみを出力しますが、それを使用することは多くの場合オプションです特に、ASを使用して、最小限のWasmモジュールを生成するためのわずかに優れた構文として使用する場合、たとえば、圧縮アルゴリズム（たとえば、Cのような関数のエクスポート）の場合、またはWASI用にコンパイルする場合。 最終的にはMyClass#myMethodような名前を変更する必要がなくなることを願っていますが、これがこの問題に関連しているかどうかはわかりません。

JS APIとESM統合の両方に、2つのwasmインスタンスAとBを接続する方法がないため、重複インポートは危険です。ここで、Bには、Aで満たす必要のある重複インポートがあります。

おそらく、WasmエクスポートをWasmインポートにリンクしているときに、このケースでエラーが発生し、署名の不一致が満たされなくなると予想していましたが、実行時に多くの楽しい動作が発生します。 JSインポートとの不一致の署名、または他の動的言語からのインポート。

Wasm関数には固定署名があるため（すべての引数を強制して指定された署名に型を返すJSホスト関数とは異なり）、同じ名前を使用して異なる署名を持つ複数のWasm関数をインポートする必要がある理由はわかりません。 私はその前提を誤解しましたか？

指定されたインポートがWasm関数である場合、自動強制を呼び出す異なるシグネチャを持つ関数を指定できるように標準が拡張されていない限り、このシナリオでエラーが発生するのは完全に正常なようです。

私は当初、重複するインポートを削除することに慎重でしたが、現在はこの変更を強く支持しています。

重要な観察は、 @ lukewagnerが指摘しているように、重複したインポートはさまざまな環境で処理できないということです。 そして彼が言うように、それはJSのユースケースでも問題があります。

最も重要なことは、基本的なモジュラープロパティを壊すことです。つまり、すべてのインポートをWasmまたはホストモジュールで等しく実装できるということです。 これは、仮想化などのユースケースにとって重要です。

重複インポートは、クライアント側でオーバーロードまたは動的型付けメカニズムのいずれかを効果的に強制します。これは、すべてのクライアントがそれをサポートする手段を持っているわけではないためです（他のWasmモジュールを含む）。

そして、テストスイートの歴史が示しているように、これは実際には実際の問題です。

@titzer 、私はフォローしていないのではないかと思います。 明確な命名は、パラメータ化と直交する問題のように思われます。 後者があったとしても、名前が（パラメーター化された）エンティティーを一意に決定することを確認したいと思います。 他の手段でオーバーロードされたインポート名を解決することは、これらの他の手段がより複雑になるとさらに複雑になるので、おそらくさらにそうですか？

私が言ったように、名前はエンジンにとって重要ではないので、それらの一意性もエンジンにとって重要ではありません。 それらは_linkers_にとって重要であるため、インポート名（またはそのことについてはエクスポート名）に一意性を適用する場合は、特定のリンクソリューションを選択します。 そして、限界にあるリンカーは、最終的には完全にプログラム可能なソリューションを必要とします。これは、ファーストクラスのモジュールとインスタンスだけでなく、JITとそれらを段階的に構築する機能でもあります。

すべての問題は、名前に基づいてインポートからエクスポートまで、モジュールを静的に型指定されたファンクター[*]にしようとすることから来ていると思います。 その結果、名前は型の一部になり、その型をwasmの言語に導入するには、型チェックが必要になるため、名前の一致ルールが必要になります。 しかし、それに関する問題は、これらの名前が低レベルの名前であり、マングルされたC / C ++名に似ていることです。 その最終結果は3つの悪いことです：

1. すでに見ました：wasmはオーバーロードがあるホスト環境に接続することさえできません
2. リンクは、低レベルの名前だけを使用して表現できるものとできないものによって常に制約され、すべての新しいwasm機能で常に設計上の問題が発生します。
3. それは、プログラム可能とJITingソリューションが必要になります任意の低レベルの名前マングリングスキームを使用することはできません言語を提供していません。

これらの問題は、静的モジュールタイプを導入したいという願望から直接生じています。これは、エンジンに単純なリンクソリューションの名前ベースのマッチングを実行させることによって動機付けられているためです。 しかし実際には、エンジンは決して名前を見るべきではありません。 もう1つ、リンカーは名前を調べて、エンジン用に名前を解決する必要があります。 はい、その問題を解決する1つの方法は、APIがリンカーにインポートのベクトルを提供し、エクスポートのベクトルを返すことです。これは、ウィザードで行ったことであり、C埋め込みAPIの動作方法です。

[ ]私もこれを考えていました。wasmモジュールはインポートからエクスポートまでの機能でした。 しかし、それは重要な何かを欠いています：より高いレベルの言語から来るリンクのための論理。 説明が

@titzer 、モジュールリンクの提案が多くのユースケースに十分な強力なリンクモデルを提供しないことに同意します（たとえば、Cオブジェクトファイルを置き換えることはできません）が、汎用リンクを提供するとは思いませんモデルは提案の目標です。 これは、現在の文字列ベースのインポート/エクスポートシステムの拡張であり、Webで一般的で、Wasmのモジュール構造にある程度組み込まれているバンドラースタイルのリンクに十分かつ有用であると考えています。 とにかくモジュール性をWebAssemblyの上に階層化する必要があるため、高水準言語固有のリンカーは、命名に関して必要なことを何でも実行し続けることができます。

@titzerインポートとエクスポートの名前がモジュールのタイプの一部ではない場合、回避したいと言った脆弱性の問題を回避することをどのように提案しますか？

また、仮想化の問題にどのように対処しているのかもわかりません。 @rossbergのコメントを読んで、仮想化はここで解決すべきより基本的な既存の問題であり、実際にはモジュールリンクの提案とは何の関係もないことを理解しています。

私はこの変更に共感していますが、WebAssembly / module-linking＃7を見ると、考慮されているオプションはあまりないようです。 交差型については多くの議論がありますが、交差型を使用した変換がJS APIなどの強制リンクシステムでは機能しないことについては言及されていません。これは、ここで言及されているユースケースの一部が依存しているものです。 考慮されるすべてのオプションは、表面言語のモジュール構造に基づいているようです（主に、Andreasの特に関数型言語のモジュールに関する知識に基づいています）が、低レベルのモジュール構造についてはあまり考慮されていないようです。 低レベルのモジュールシステムは、モジュールリンクの提案（名前ベースの解決を含む）の目標を果たしながら、ここでの問題を簡単に解決します。 同時に、いくつかの重要な拡張機能を構築する方が簡単です。

@RossTate 、ここで「低レベルモジュールシステム」と呼んでいるものや、すでに説明したものとどのように違うのかわかりません。 さまざまなソリューションのアイデアがある場合は、 https：//github.com/WebAssembly/module-linking/issues/7で議論して、重複インポートを禁止する特定の提案されたソリューションにこの問題を集中させることができます。

https://github.com/WebAssembly/module-linking/issues/7#issuecomment -791063260にメモを残しました。これは、既存のコードの下位互換性の問題を引き起こすことなく、モジュールリンクの検証の一部になり得るかどうかを尋ねてい

これはまさに私が直面するのにとても時間がかかった問題です。 モジュールには、インポートに関連付けられた名前と制約に意味を与えるインポートプロセッサを考慮しないタイプはありません。つまり、インポート（名前付き）からエクスポートまでの純粋関数です。 それらは輸入に意味を与えるためにリンクシステムを必要とします。 私たちがそのポイントを通過するまで、私が言っていることの残りのどれも意味がありません。 これは、モジュールリンクの提案における非常に基本的な仮定であり、議論のために明らかにされていないと思います。 そして、私たちはそれを本当に疑っていないと感じています。 丁寧に思えるよりも深く質問しているので、繰り返しているようです。 もちろん、失礼なことを意味するわけではありませんが、モジュールがファンクターのように見える必要があることに挑戦するつもりです。 そして、私たちはそれを疑っていません。

モジュールがファンクターであることが明らかにそうではない理由について、例を次々と挙げることができます。

1. wasmモジュールをJavaScriptにリンクするには、importsオブジェクトを経由します。importsオブジェクトは、実際にはプロキシであるか、チューリング完全ロジックを名前に適用する動作（たとえば、名前のデコード）を持つことができ、状態もあるため、ファンクターとしてキャストします。 これは文字通り、JavaScriptオブジェクトのインポートをインポートによって問い合わせるアルゴリズムとして操作上定義されています。 そのリンクエコシステム全体をモジュールリンクで表現することはできません。

2. C埋め込みAPIも同じ方法です。 これは、完全に検査可能なエンティティとして埋め込みにモジュールを提供し、検査用の名前、種類、および署名を備えています。 モジュールをインスタンス化するために、埋め込み者は、インスタンス化のためにエンジンへのバインディングを（はい、位置的に）提供するだけである限り、好きなロジックを適用できます。 また、完全にプログラム可能で、モジュールリンクで表現されていないエコシステム。

3. ジャワもピワもこんな感じです。 Jawaは完全に静的に型指定されていますが、そのインポートは、単純な名前の一致が適切でない方法でインポート言語でエンコードされています。 Jawaランタイムは、エンジンに提供する新しい関数、型、およびその他のバインディングを合成（JIT）する必要があります。 Pywaは完全に動的に型指定されており、そのJS実装は同様の方法でオーバーロードを使用します。

モジュールとそのインポートは、リンクスキーム、言語、インポートプロセッサなど、何と呼びたいかというコンテキストでのみ意味があります。 繰り返しますが、それらはファンクターではありません。 モジュールのインポートは、エンジンが理解できない、または理解できない外国語で書かれた、外部から必要なものの説明です。 モジュール自体はWasmの型システムに従ってインポートとは無関係に個別にタイプチェックできるように、またインポートはインポート制約に記述されている仮定に照らしてチェックできるように、Wasmタイプのみがあります。 ここでも、モジュールをwasm-y型のファンクターにしようとするまで、名前については何も表示されません。 しかし、それらの名前は紫色です！ ここで、すべてのソース言語が存続します。 もちろん、文字列の比較でそれをいじくり回すことはうまくいきません。

それを念頭に置いて、「飾り気のない」リンクソリューションを作りたいという願望は悪いものではありません。 名前があまりクレイジーでない場合、それは理にかなっています。 これは、名前が非常に単純で、単純なマッチングで十分な小さなエコシステムを作成するようなものです。 それは正しいプリミティブではないので、プリミティブである必要はありません。 完全にプログラム可能なリンクAPIである本当に必要なものに到達したときに、つまずきや奇妙な疣贅になるリスクがある方法で、その仮定を直接wasmのコアに焼き付けているので、それは明らかです。 リンク用のプログラム可能なAPIがあれば、モジュールリンクの提案は単なるライブラリである可能性があります。 したがって、C埋め込みAPIをより標準的なwasm APIに変換し、そのAPIに対するライブラリとしてモジュールリンクを作成する方法を検討する必要があります。

@lukewagner 「脆弱性」の問題：名前を破棄することを

そして、ええ、この問題については、私がしばらく考えていた重複インポートの優れたユースケースがあります。そうです、重複インポートは、インラインキャッシュを共有する（または共有しない）という議論まであります。 たとえば、JavaScriptプロパティアクセスを実行する関数をインポートする場合は、「GetProperty [foo]」という名前を付けることができます。 一度だけインポートする場合、エンジンはどのインラインキャッシュを使用する必要がありますか？ wasmコードを検査して、新しい呼び出しサイトを生成する必要がありますか？ モジュールがまったく同じ名前で同じ関数を複数回インポートできるが、毎回新しいICを取得できる場合、モジュールは、エンジンがさまざまなポリモーフィズムにどのように適応するかを制御する手段を備えています。 （もちろん、文字列の最後に愚かな一意のジャンクを貼り付けることはいつでもできますが、なぜわざわざするのですか？これは、wasmで使用していないまったく異なるものからの制限を回避するだけです。

@titzerあなたが

独立して、ここで根本的な質問であると私が学んだことは残っています：wasmモジュールはwasmエクスポートを仮想化できるべきですか？ 「wasmモジュールはどのようにリンクされるのか」という質問を完全に脇に置いて、これはCGに提唱する原則の基本的な質問のようです。 リンクに関する質問とは関係なく、この質問だけに焦点を当てるのは、別の設計上の問題に値するのではないかと思います。

仮想化は重要であり、プログラム可能なリンクは確実にそれをサポートする必要があります。

実際、私が話していることは、今日のwasmとそれほど変わらないと思います。そして、私が話していることは、ジャワだけに向けられたものではありません。 .NETまたは他の言語ランタイムのリンクについて考えるときにも同じことが起こります。 上記の3つの例を挙げましたが、そのうちの2つは現存する埋め込みであり、別の言語に埋め込まれているため、完全なプログラム可能性が得られます。

CGのプレゼンテーションをまとめたいと思います。

Fwiwは、Wasmをより少ないユースケースではなくより多くのユースケースで実行可能にするというtitzerの提案を理解しているため、他の方法よりもはるかに私の期待に沿っています。 他の場所でも同様の理由で同様の問題ですでに起こっているすべての論争を考えると、Wasmの方向性についてのより一般的な議論が必要になる可能性があることを示唆するところまで行きます。

たとえば、私は次のようなステートメントを見つけます

あなたが築いている見解は、wasmが指定され、実装され、今日広く話題になっている方法からかなり離れているので、この視点の変更をCGに提案し、ある程度の賛同を得ることはあなたの負担だと思います。それは、wasmの性質であると主張できるものだとは思わないでください。

文脈の中で深く懸念している。 ここでは、wasmの指定方法にさらに広範な問題がある可能性があり、どちらの側が出発するのかは私にはわかりません。

@titzer私は主にあなたが言っていることのこの部分（そしてすべての結果）に言及していました：

モジュールには、インポートに関連付けられた名前と制約に意味を与えるインポートプロセッサを考慮しないタイプはありません。 これは、テキストファイルの種類を尋ねるようなものです。

これは、現在の仕様（たとえば、この部分）からの大幅な逸脱になります。

@lukewagnerそれを指摘してくれてありがとう。

その定式化では（モジュールのリンクに関する議論が指摘しているように）、インポートとエクスポートはベクトルであり、したがって位置的です。 あるモジュールの（位置）エクスポートを別のモジュールの（位置）インポートにバインドするには、マッピング関数が必要です。 「飾り気のない」正確な名前照合関数は1つの選択肢にすぎず、そのマッピング関数がホスト言語で完全にプログラム可能である他の2つの埋め込みがすでにあることを指摘しています。

@titzerそれは本当ですが、注意してください：JS APIは完全にプログラム可能であるにもかかわらず、（異なるタイプの）重複したインポートを持つwasmモジュールを提供すると、JSAPIを使用してそれらのインポートをwasmエクスポートで実装することはできませんWebAssembly.instantiate()で名前ルックアップを使用しているため。 同じことがESM統合にも

したがって、私たちが尋ねなければならない質問は、「wasmエコシステム全体で必然的に出現する無数のwasmリンクスキームが、重複インポートの仮想化をサポートすることになるのでしょうか？」ということだと思います。 そして、私たちの現在のサンプルセットに基づくと、それはありそうもないように見えます。

WebAssemblyのインポートとエクスポートに関連付けられた文字列がなかったと想像してください。 JS APIは、純粋に位置インデックスを使用して、インポートとエクスポートにアクセスします。 私の知る限り、既存のツールチェーンをそのような設定で機能させるのは（相対的な意味で）簡単です。 （場合によっては、emscriptenのようなものが「インライン」JSコード（ EM_ASM ）をフックアップするために任意の名前を生成する必要がないため、より簡単な場合があります。）

このような世界では、仮想化の問題はありません。 つまり、仮想化の問題は、位置インデックスではなく名前を使用することを選択したことが原因で発生します。 両方をJSAPIで使用できるようにすることで、下位互換性のある方法でこれを解決することもできます。

重要なのは、非位置のインポート/エクスポートは、実際には、wasmモジュールのエコシステムへの統合を容易にするために使用される埋め込み固有の装飾であるということです。 これらの装飾がどのように指定されるかは、生態系の（既存または予想される）規範に実際に適合させる必要があります。

たとえば、ESM統合では、他のモジュールによってエクスポートされたJS値がオーバーロードされる可能性がありますが、WebAssemblyはオーバーロードをサポートしていないため、ESMインポート/エクスポート装飾デザインはこのギャップを埋めて、WebAssemblyモジュールが多くのJSの代わりになるようにする必要があります可能な限りモジュール。 これは、別のJSモジュールからインポートされた関数のさまざまなオーバーロードを抽出するために、重複したインポートと型指定の強制を行うことで実行できます。 エクスポートされたタイプがすべて、十分に分離/区別可能なパラメーターを持つ関数であり、単一のオーバーロードされたJS関数に結合できる限り、重複エクスポートを許可することもできます。 そしてもちろん、それぞれ長所と短所を持つ他のデザインオプションがあります。

対照的な例として、WebAssemblyの主要な埋め込み言語が、位置パラメーターではなく関数の名前付きパラメーターを主に使用していると仮定します。 その場合、インポートとエクスポートの装飾はかなり異なり、関数のエクスポートによってすべてのパラメーターに名前が割り当てられます。 しかし、低レベルでは、WebAssemblyモジュールは依然として位置のインポートとエクスポートにすぎません。

だからこそ、一歩下がって問題を解決することを提案したのです。 「コア」WebAssemblyモジュールリンク、つまり同じファイル内で定義されたWebAssemblyモジュールをリンクするために使用するもの（たとえば、インターフェイスタイプアダプタモジュールをそれが適応するモジュールにリンクするため）は、定位置である必要があります。 「埋め込み」WebAssemblyモジュールリンク、つまり、特定のエンベッダー内の別々のファイルで定義されたWebAssemblyとエンベッダー固有のモジュールの両方をリンクするために使用するものは、エンベッダー固有のセクションであり、エンベッダー間の変換を定義する主な役割を果たします。強制関数、エクスポートされた関数/インスタンス/モジュールへの装飾の追加、（シングル/ダブル/リストオブ）名前と位置インポートの関連付けなど、特定のコンストラクトとWebAssemblyコンストラクト。 そうすれば、「コア」WebAssemblyは数と位置以外のことを心配することはなく、重複インポートなどの問題は「コア」問題ではなく、埋め込み者固有の問題になります。

その考え方で、この問題は「JS APIまたはESモジュールの場合、2つのインポートを同じ文字列に関連付けることを許可する必要がありますか？」と書き直すことができます。 答えはモジュールリンクの提案には意味がありません。 これは有用な質問ですが、主な議論は（私が思うに）存在してはならない結合に基づいているため、現時点では良い答えを得るのは難しいです。

私は、位置のインポート/エクスポートが質問全体の重複を回避することに同意します。 ただし、避けたい問題は、別々の時間に別々のコンパイルを行う場合、バージョン管理に注意を払う必要がある場合、位置のインポート/エクスポートには、コンポーネントシステムで具体的に感じられる古典的な脆弱な基本クラスの問題があります。 （位置）C ++ vtableレイアウトに基づくCOMのようなものです。

@RossTateと@titzerが何を提案しているのかを理解した場合、これはホストレイヤーで解決する必要のある問題であり、ホストがそのホストに適切な名前を導入できるようにします。 私が見ている問題は、その答えに残っているということです。それは、wasmツールのエコシステムをホストごとに本質的に分割しているということです。 たとえば、clangが何らかの形のリンクを実行したい場合（たとえば、一般的なlibcを除外するため）、「clangターゲティングwasm」を使用することはできません（これは、この新しいカテゴリの高度な最適化で重要です。マルチモジュールwasm実行プラットフォーム））-ターゲットとしているすべての異なる具象ホストについてclangに教え、ホストをclangのパラメーターにする必要があります。 さらに、生成された出力はそのホストでのみ実行できるようになり、ホスト間で再利用可能な.wasmモジュールを生成できなくなりました。 共有ツールと再利用可能なモジュールを実現するには、リンクに対応するある種の共通の抽象コンパイルターゲットが必要です（特に、名前とインスタンスの間に1：1の関連付けを想定していないもので、多くのユースケースには不十分です）） -これはまさにモジュールリンクの提案が確立することを望んでいたものです。

そうは言っても、モジュールリンクがホストに依存しないスペックレイヤーとしてコアwasmの上とJSAPIの下に追加されるハイブリッドソリューションを想像することができます。 これにより、ホストに依存しないツールとモジュールを作成でき（このホストに依存しないスペックレイヤーをターゲットに）、ホストの埋め込みでこのレイヤーを完全に回避し、特殊なリンクスキームを使用してコアモジュールを直接インスタンス化できます。

それは、これらの相反する目標を解決するための合理的な方法のように聞こえますか？

@lukewagner 、私と一緒にいてくれてありがとう！ あなたが言ったことは、私がどこから来たのかをより正確に理解しているように聞こえますが、同時に、脆弱性とツール/エコシステムについてのあなたの懸念も聞いています。

ハイブリッド/ 2層ソリューションは私が提案しようとしてきたものだと思います。2層は「内部」と「外部」のリンクに対応しています。 内部リンクは定位置であり、モジュールを構築/接続/インスタンス化するための指示を指定します。これは、すべてのWebAssemblyエンジン（モジュールリンクを使用）が実装する必要があるものです。 外部リンクはエンベダー固有であり、他のファイルなどから（位置）モジュールを構築する方法を指定します。たとえば、ファイル名や文字列名をインポート/エクスポートに関連付ける方法を指定します。これは、WebAssemblyエンベダーが実装する必要があるものです。 この関心の分離により、WebAssemblyプログラムの「コア」の側面とWebAssemblyエンジンの「コア」の側面を複数のエコシステム間で再利用しやすくなります。 （また、この分離により、内部モジュールのリンクの側面がクリーンアップされる可能性があると思います。）

しかし、あなたが言及するように、2つの多くの「外部」カスタマイズがあると、深刻な破砕につながる可能性があります。 私は分離する必要があるリンク「内部」と「外部」と考えながら、そう、私はまた、「普通」の外部リンクの標準があると便利だと思います。 特定のエコシステムの詳細にうまく適合または活用するために、より専門的な外部リンクシステムを開発する場合もありますが（そうするために、より専門的なツールを使用）、多くのプログラムのニーズは単純な共通の標準に適合します。

したがって、要約すると、1つの「内部」リンクシステム（低レベル、たとえば位置）が必要であり、その上に複数の「外部」リンクシステムが存在

さて、この種の変更が短期的に具体的に何を意味するかを考えると、モジュールリンクをコア仕様の上の「共通リンク」レイヤーとして（必要に応じて、JS / Web仕様の下で）再構成することは、コアスペックに何も追加する必要はありません。 特に、コアモジュールのインポート/エクスポートは定位置のままである可​​能性があり、モジュールリンクレイヤーはインスタンス化を実行するときにこれらの名前を完全に無視します。 これに基づいて、「いいえ」という答えでこの問題を解決できます。その場合、その上の@titzerのポイントに"" 、 "a" 、 "b"を含めるように強制することはありません。 "c" ...検証を容易にするためだけに名前をエクスポートします。

（将来的には、モジュール/インスタンスの位置バージョンを使用してコアwasmを拡張することについて話すこともできますが、モジュールリンクの提案で焦点を当てた最初の一連のユースケースと要件に追加で必要になるとは思いません。）

@rossberg @titzer @tlively思考？

コアWasmのインポートとエクスポートが厳密に定位置でなければならないことをコード化すると、 https：//github.com/WebAssembly/gc/issues/148のドアが閉まるのではないかと心配していimportexportメカニズムの導入を示唆しています。輸入と輸出の問題は必然的に非対称である。 提案されたメカニズムは、基本的にコアWasmレベルで型の弱いリンケージを導入し、文字列識別子なしでどのように位置的に機能するかはわかりません。

GC提案をその方向に進めるためのコンセンサスがないため、これは明らかに仮説ですが、個人的には、GC提案にとって十分に魅力的なオプションであり、このような無関係な開発によって実現可能性が低下するのを見るのは悲しいことです。たった今。 その提案された変更が位置的に機能する方法、またはこの問題を誤解する方法がありませんか？

ああ、興味深いつながり、@ tlively！ それは私にいくつかのアイデアを考えさせます。

1つのアイデアは、静的リンクに関連しています。 名前付きインポートが外部にリンクされたモジュールの変更可能性に役立つのと同じように、デフォルトのインポートも同様

別のアイデアは、ダイナミックリンクに関連しています。 ここでは、文字列がグローバルキーとして使用されます。 importexport基本的に、「このキーに関連付けられた値をインポートし、その値がまだ定義されていない場合は、そのキーに対応する値として以下をグローバルに登録する」と言います。 （繰り返しますが、これはすべて外部リンク層にあります。）

WebAssemby / gc＃148は名目型に関するものですが、上記の両方の考え方が例外にも当てはまることに注意してください。 静的リンクの場合、モジュールの一般的なパターンは、デフォルトで新しく生成される例外イベントをインポートすることですが、非ローカル制御を共有するために他のモジュール（インスタンス？）と同じイベントを使用するようにインスタンス化できます。彼らと一緒に。 ダイナミックリンクの場合、中央のランタイムモジュール（人々はすでに私の考えを知っています）がないことを本当に望んでいる場合、例外のある言語は、ダイナミックリンクされたモジュールとimportexport間で例外イベントを調整する必要があります

きちんとした！ 私が正しく理解していれば、 importexportメカニズムは、定義されたタイプをインポートするための「デフォルト」エクスポートモジュールを暗黙的に作成することにより、位置のインポートとエクスポートにデシュガーするモジュールリンクレイヤーの一部と考えることができます。 それは私には理にかなっているように思われるので、私はこの方向性についてこれ以上心配する必要はありません。

階層化の議論は両方の道を切り開くと思います。 同様に、im / exportsを明確にするために採用する（高レベル名、追加情報）ペアスキームを低レベル名の明確なスキームにマッピングするのは、上位層の責任であると主張できます。

下位レベルの場合、可能な限り明示的かつ明確であることが常に望ましいように思われます。 これにより、システムとシステムとのインターフェースがシンプルに保たれ、すべての人ではなく、システムを必要とするエコシステムでより複雑なスキームを処理する負担がかかります。

別のレイヤーとしてのリンクの提案については、抽象的には良いように聞こえますが、それをスムーズに機能させることができるかどうかについては少し懐疑的です。 たとえば、この提案では現在、内部モジュールがモジュールや型などの静的エンティティの外部名前空間を参照できるようになっていますが、これはかなり中心的であり、コア仕様にマッピングできません（ラムダリフティングと同等の変換を除いて、壊れます）インポートの部分適用/インスタンス化、つまり「モジュールクロージャ」の形式も導入しない限り、意図された構成パターン。

たとえば、この提案では現在、内部モジュールがモジュールやタイプなどの静的エンティティの外部名前空間を参照できるようになっています。

これは、いくつかの単純化を使用できると私が感じた側面の1つでした。

インポートの部分適用/インスタンス化、つまり「モジュールクロージャ」の形式も導入しない限り

これは、その単純化を実現するのに役立つと私が考えた手法の1つでした。

私は一般的に、リンク仕様をレイヤーの上に移動するという考えを支持します。 それは基本的に私が主張してきたことです。 エンジンは名前を知る必要はありません。

@rossberg私は一般的に、「明確で曖昧さのない」は下位層に最適だと思いますが、このインスタンスは規範的であるかどうかに関するものであり、下位層はそれらに関係のないことについて規範的ではないようにうまくいくはずです。 IMO。

https://github.com/WebAssembly/design/issues/1399#issuecomment -808401005に関連する所見がありi64引数を省略してWasmエクスポートを呼び出すときに呼び出しが失敗する問題を説明しています。 JSからWasmに呼び出すときに、重複したエクスポートを許可し、一致するアリティを持つものを選択することは、コンテキストでの推奨されるソリューションです。