Design: call_indirectと抽象化

この詳細な記事をありがとう、ロス！ 小さな質問があります。「 call_indirectとタイプのインポート」セクションに、次のように記述します。

テクニック1を好む場合は、型付き関数参照を追加すると、再び機能しないことに注意してください。

これは、型付き関数参照にバリアントサブタイプを追加した場合にのみ問題が発生するという、前のセクションの警告の対象にもなりますか？

そうではない。 サブタイプセクションのすべての問題はタイプインポートから独立しており、タイプインポートセクションのすべての問題はサブタイプから独立しています。 あなたが尋ねている特定の問題に関して、タイプref ([] -> [capability])の値は、エクスポートされた関数によってタイプref ([] -> [$handle])値として返される可能性があり、それを次のように変換できることを考慮してください。 funcrefおよび間接的に呼び出されます。 エクスポートされた関数とは異なり、この値の視点の変更はリンク時ではなく実行時に発生します。したがって、関数参照自体がインポートされたことがないため、インポートシグネチャと比較して解決することはできません。

module instance IC defines a type capability and exports the type but not its definition as $handle
これはどのように機能しますか？ ICがそれを処理する方法を知ることができるように、 capabilityと$handleを接続する何かが必要ですか？
また、 https：//github.com/WebAssembly/proposal-type-imports/blob/master/proposals/type-imports/Overview.md#exportsに基づいて、インポートされた型は完全に抽象的です。 したがって、 $capabilityがエクスポートされたとしても、それは抽象的です。 おそらく私は何かを誤解しています。

module instance IC exports a function $do_stuff that was defined with type [capability] -> [] but exported with type [$handle] -> []のエクスポートに関する同様の質問。

これに使用されるある種のサブタイプ関係を想像することができます。たとえば、 $capability <: $handle場合、 export $capability as $handleです。 しかし、このセクションの冒頭では、サブタイピングを脇に置くことが言及されていたので、私はそれを脇に置いています...しかし、私はそれについてもう少し考えました：
$capability <: $handle場合、 export $capability as $handleは可能ですが、関数は引数で反変であるため、 export ([$capability] -> []) as ([$handle] -> [])は「失敗」するはずです。

タイプエクスポートでは、モジュールはtype $handle; func $do_stuff_export : [$handle] -> []ように署名を指定し、次にtype $handle := capability; func $do_stuff_export := $do_stuffように署名をインスタンス化します。 （特定の構文は完全に無視してください。）次に、タイプチェッカーは「 $handle capabilityがこのモジュールのfunc $do_stuff_export := $do_stuffはこのモジュールで有効ですか？」をチェックします。 $do_stuffのタイプは[capability] -> []であるため、 $handleをcapabilityでインスタンス化した後、その署名は$do_stuff_export署名と正確に一致します。チェックは成功します。 （ここではサブタイプは含まれず、変数置換のみが含まれます。）

ただし、署名自体は$handleについては何も述べていないことに注意してください。 これは、他のすべての人が$handleを抽象型として扱うことになっていることを意味します。 つまり、署名はモジュールの実装の詳細を意図的に抽象化し、他のすべての人はその抽象化を尊重することになっています。 この問題の目的は、 call_indirectを使用してその抽象化を回避できることを説明することです。

うまくいけば、それは問題を少し明確にします！

おかげで、それは物事を明確にします。 サブタイピングセクションについて質問があります（ジャンプして申し訳ありません）：

call_indirect 「定義署名ではなくインポート署名と比較する」ことにより、IBがcall_indirect[ -> tsuper](ref.func($fsuper))を実行して成功させるシナリオに従います。

そして、あなたはそれを追加しました（型付き関数参照のために）私たちも必要です

1. 期待されるシグニチャと定義シグニチャのサブタイプの互換性について、少なくとも線形時間の実行時チェックを実行します。

これは「期待される署名とインポート署名」の間の互換性である必要がありますか？ call_indirectを作成したと想定しているため、インポート署名と期待される署名を比較します。

期待されるものとインポートされるものの間で互換性がチェックされた場合、後でcall_indirect[ -> tsub]($fsuper)は失敗するはずです。

テクニック1と2は、その間接的な呼び出しを機能させるための2つの直交する方法として提供されています。 残念ながら、テクニック1は型付き関数参照と互換性がなく、テクニック2は高すぎる可能性があります。 したがって、これらはどちらもうまくいかないようです。 したがって、このセクションの残りの部分では、これらのどちらも使用せず、期待される署名と定義された署名の単純な同等性の比較に固執した場合に何が起こるかを検討します。 混乱させて申し訳ありません; 計画されたセマンティクスがないということは、3つの潜在的なセマンティクスについて議論する必要があることを意味します。

あまりにも多くの結論にジャンプしないように注意してください。 ;）

私の仮定では、 call_indirectは今日と同じ速さを維持する必要があるため、言語にサブタイプをいくら追加しても、型の同等性テストのみが必要になります。 同時に、ランタイムチェックは静的型システムと一貫している必要があります。つまり、サブタイプの関係を尊重する必要があります。

call_indirect使用できる型が常にサブタイプ階層のリーフにあることを確認する限り、これらの一見矛盾する要件は実際にはかなり簡単に調整できます。

それを実施するための確立された方法の1つは、型システムに_exact_型の概念を導入することです。 正確な型にはサブタイプはなく、スーパータイプのみがあり、 (exact T) <: Tます。

これにより、 call_indirectのターゲットタイプを正確なタイプにする必要があります。 さらに、関数自体のタイプは当然、その関数の正確なタイプです。

モジュールは、意図されたランタイムチェックに成功する関数でのみインスタンス化できることを確認したい場合は、関数のインポートで正確な型を要求することもできます。

正規化された関数型での単純なポインター比較の現在の実装手法が引き続き有効であることを確認するために必要なのは、これだけです。 これは、他にどのようなサブタイピングがあるか、または関数のサブタイピングをどれほど凝ったものにするかとは無関係です。 （FWIW、私はしばらく前にルークとこれについて話し合い、PRを作成することを計画しましたが、サブタイピングストーリーへの保留中の変更、および現在どの提案に移行するかでブロックされました。）

（1つの欠点は、関数定義をサブタイプに絞り込むことは、少なくともその正確なタイプがどこかで使用されている場合は、一般的に下位互換性のある変更ではなくなることです。しかし、その欠点は、どのように正確に適用するかに関係なく、制約の下では避けられません。彼ら。）

いくつかの側面：

別の方法は、call_indirectとfunc.refをそのままにしておくことです。

AFAICS、参照型を含む関数でref.funcを禁止することは現実的ではありません。 これは、多くのユースケース、つまりexternref動作するファーストクラスの関数（コールバック、フックなど）に関連するすべてのものをひどく損なうことになります。

これは、到達したソリューションによっては、externrefがTrue Typeインポートのようにインスタンス化できない場合や、externrefが（皮肉なことに）スーパータイプを持つことができない場合があることを意味する可能性があります（たとえば、最終的にanyrefを追加することにした場合は、anyrefのサブタイプになることができます）。

詳細を教えていただけますか？ 接続が表示されません。

あまりにも多くの結論にジャンプしないように注意してください。 ;）

あなたがどのような結論を指しているのかわかりません。 私が述べた結論は、 call_indirect 、認識しておく必要があり、計画を開始する必要のある問題がいくつかあるということです。 あなたは解決策を考えているので、これらの問題は重要ではないと示唆しているようです。 しかし、その解決策はCGによってレビューまたは承認されていないため、承認されるまで計画を立てるべきではありません。 解決策の評価と比較には時間がかかり、それらの評価と比較を適切に行う前に決定を下す必要があるため、特に解決策について話し合わないように要求しました。 しかし、この問題が解決されたという認識を人々が形成するのを防ぎ、その結果、差し迫った決定を回避するために、私はあなたの解決策について迅速に議論するために少し時間がかかります。

それを実施するための確立された方法の1つは、型システムに正確な型の概念を導入することです。

正確なタイプは、確立されたソリューションではありません。 どちらかといえば、正確なタイプは、その支持者がまだ対処しようとしている問題を確立しています。 興味深いことに、ここに）あなたがしている提案は、いくつかの問題を解決することができるか、正確なフォームの種類活字チームもともとのこぎりスレッドですが、その後、彼らは最終的に[実現（https://github.com/microsoft/TypeScript/issues/12936 ＃issuecomment-284590083）正確なタイプは、解決したよりも多くの問題を引き起こしました。 （コンテキストに関する注意：その議論は、実際には（理論的な意味で）正確なタイプの形式ではなく、プレフィックスサブタイプのオブジェクトアナログを単に許可しないFlowの正確なオブジェクトタイプによって促されました。）私たちはそのスレッドを再生することを想像できましたここ。

これらの種類の問題がWebAssemblyでどのように発生するかを示す例として、サブタイピングを延期しなかったとします。 ref.nullタイプexact nullref 、正確なタイプを使用するとexact nullrefはexact anyrefサブタイプではありません。 実際、正確な型の通常のセマンティクスによれば、値の実行時型が正確にanyrefある可能性が低いため、 exact anyref属する値はない可能性がcall_indirectはanyrefの間完全に使用できなくなります。

正確なタイプのいくつかの異なるバージョンを念頭に置いているかもしれませんが、この異なるバージョンが正確なタイプに関する多くの未解決の問題に何らかの形で対処していることを確認するには時間がかかります。 このソリューションを投げるために、それは、これが解決策であることは明らかではないことを認識し、その期待して意思決定をしないことではない、ここで私のポイントはそう。

詳細を教えていただけますか？ 接続が表示されません。

あなたは長い文を参照しています。 そのどの部分について詳しく説明してほしいですか？ 1つの推測では、 call_indirectとタイプのインポートに関する全体的な問題を見逃している可能性があります。 あなたの正確なタイプの提案はサブタイプの問題にのみ対処しますが、 call_indirectはサブタイプがなくても問題があることを上記で確立しました。

これは、多くのユースケース、つまりexternref動作するファーストクラスの関数（コールバック、フックなど）に関連するすべてのものをひどく損なうことになります。

ええ、これは私がもっと情報を得たいと思っていたものです。 私の理解では、 call_indirectの主な使用例は、C / C ++関数ポインターとC ++仮想メソッドをサポートすることです。 私の理解では、このユースケースは現在、数値署名に制限されています。 call_indirectのより多くの潜在的な使用法を知っていますが、私が述べたように、一時的な制限を提案していたので、重要なのはcall_indirectの現在の使用法です。 call_indirectは、単なるfuncrefではなく、テーブルとインデックスが必要であることを考えると、コールバックをサポートするために特に適切に設計されているようには見えません。 現在この目的で使用されていないためかどうかはわかりませんでした。

この機能を対象とするコードベースは私よりもはるかによく知っているので、この機能を必要とする実際のプログラムを知っている場合は、ここで必要な使用パターンの例をいくつか提供すると非常に役立ちます。 この機能を今すぐサポートする必要があるかどうかを判断するのに役立つだけでなく、機能が今必要な場合、これらの例は、上記の問題に対処しながら、この機能を迅速に提供する最善の方法を通知するのに役立ちます。

@RossTate ：

どちらかといえば、正確なタイプは、その支持者がまだ対処しようとしている問題を確立しています。 興味深いことに、TypeScriptチームは、提案しているフォームの正確なタイプがいくつかの問題をどのように解決できるかを最初に見たスレッドですが、最終的に、正確なタイプが解決するよりも多くの問題を引き起こすことに気付きました。 （コンテキストに関する注意：その議論は、実際には（理論的な意味で）正確なタイプの形式ではなく、プレフィックスサブタイプのオブジェクトアナログを単に許可しないFlowの正確なオブジェクトタイプによって促されました。）私たちはそのスレッドを再生することを想像できましたここ。

ここでは括弧が重要です。 そのスレッドで彼らが正確に何を考えているのかはわかりませんが、同じことではないようです。 それ以外の場合、「タイプT & Uは常にTに割り当て可能であると想定されますが、 Tが正確なタイプである場合、これは失敗します」のようなステートメントは意味がありません（これは意味がありません。 T & Uが無効またはボトムになるため、失敗します）。 他の質問は主に語用論に関するものです。つまり、プログラマーが（オブジェクトに対して）それらをどこで使用したいかということですが、これは私たちの場合には当てはまりません。

低レベルの型システムの場合、あなた自身の論文のいくつかでさえ、正確な型は重要な要素ではありませんでしたか？

これらの種類の問題がWebAssemblyでどのように発生するかを示す例として、サブタイピングを延期しなかったとします。 ref.nullのタイプは、正確なタイプを使用した正確なnullrefになります。 ただし、正確なnullrefは、正確なanyrefのサブタイプにはなりません。

ここで意見の相違はありません。 サブタイプを持たないことが正確なタイプの目的です。

実際、正確な型の通常のセマンティクスによれば、値の実行時型が正確にanyrefである可能性が低いため、正確なanyrefに属する値はない可能性があります。

そうです、anyrefの唯一の目的がスーパータイプであることを考えると、 (exact anyref)の組み合わせは有用なタイプではありません。 しかし、なぜそれが問題なのですか？

これにより、call_indirectはanyrefに対して完全に使用できなくなります。

あなたは今レベルを混乱させていないと確信していますか？ 関数型(exact (func ... -> anyref))は完全に便利です。 たとえば、 (func ... -> (ref $T))タイプとは互換性がありません。 つまり、 exactは、関数型の重要なサブタイプを防ぎます。 しかし、それが要点です！

たぶんあなたは(exact (func ... -> anyref))と(func ... -> exact anyref)ますか？ これらは無関係なタイプです。

正確なタイプの提案はサブタイプの問題にのみ対処しますが、call_indirectにはサブタイプがなくても問題があることを上記で確立しました。

抽象データ型を定義する手段として、定義なしで型をエクスポートできるとどういうわけか想定しています。 明らかに、そのアプローチは動的型キャスト（call_indirectまたはその他）の存在下では機能しません。 そのため、MLスタイルの型抽象化ではなく、newtypeスタイルの型抽象化が必要になると私は言い続けています。

私の理解では、call_indirectの主な使用例は、C / C ++関数ポインターをサポートすることです。

はい。ただし、提案された制限に含めたため、これは私が言及したref.funcの唯一のユースケースではありません（おそらく不必要にそうですか？）。 特に、タイプチェックを含まないcall_refがあります。

抽象データ型を定義する手段として、定義なしで型をエクスポートできるとどういうわけか想定しています。 明らかに、そのアプローチは動的型キャスト（call_indirectまたはその他）の存在下では機能しません。 そのため、MLスタイルの型抽象化ではなく、newtypeスタイルの型抽象化が必要になると私は言い続けています。

さて、あなたは正確な型がcall_indirectと型のインポートの問題に対処するために何もしないことに同意しているようです。 しかし、実行時のキャストが原因でとにかく問題になるため、その問題に対処する意味がないとも言っています。 この問題を防ぐ簡単な方法があります。抽象型に対して実行時のキャストを実行できないようにします（抽象型がキャスト可能であると明示的に指定している場合を除く）。 結局、不透明（OPAQUE）型なので、キャストに必要な構造を持っているとは思えません。 したがって、正確な型がサブタイピングの問題に対処する可能性があるとしても、問題の残りの半分を無視するのは時期尚早です。

私が言ったように、すべてのソリューションにはトレードオフがあります。 あなたは、あなたのソリューションにはあなた自身が特定したトレードオフしかないと推測しているようであり、CGは他のソリューションよりもあなたのソリューションを好むと推測しているようです。 私も、この問題に対する潜在的な解決策を持っています。 一定時間のチェックを保証し、仮想マシンですでに使用されているテクノロジーに基づいており、ここでのすべての問題に対処し（私は信じています）、新しいタイプを追加する必要はなく、実際に既知のアプリケーションを使用してWebAssemblyに機能を追加します。 しかし、私はそれが私が期待するように機能するとは思いませんし、あなたや他の人がそれを見る機会がなかったので、私はいくつかの欠点を見逃していません。 また、CGが代替オプションのトレードオフよりもトレードオフを好むとは思いません。 代わりに、私だけでなくCGがこの分野横断的なトピックについて十分な情報に基づいた決定を下せるように、オプションを分析する時間を与えるために何ができるかを考えようとしています。

特に、タイプチェックを含まないcall_refがあります。

あなたの文のキーワードは意志です。 私は、人々がサポートしたいと思うでcall_indirectアプリケーションがあることを十分に承知しています。 そして、私たちはそのサポートは、上記の機能とアドレスの問題というデザインを考え出すことを期待しています。 しかし、私が言ったように、理想的には、それらの影響を調査する機会を得る前に、横断的な影響を伴う機能を迅速に出荷しないように、その設計を開発する時間があります。 だから私の質問は、今その機能を必要とする主要なプログラムがあるかどうかです。 ある場合は、仮説を立てる必要はありません。 いくつかを指して、現在この機能にどのように依存しているかを説明してください。

抽象データ型を定義する手段として、定義なしで型をエクスポートできるとどういうわけか想定しています。 明らかに、そのアプローチは動的型キャスト（call_indirectまたはその他）の存在下では機能しません。 そのため、MLスタイルの型抽象化ではなく、newtypeスタイルの型抽象化が必要になると私は言い続けています。

これは私には根本的な問題のように思えます。 エクスポートされたタイプの定義の機密性を有効にすることは、タイプインポート提案の目標ですか？ 私は@RossTateはそれが目標とすべきと考えていることを、このスレッドから収集し@rossbergは、それが現在の目標ではないと考えています。 ソリューションについて説明する前に、この質問について話し合い、同意して、すべての人が同じ一連の仮定から作業できるようにします。

@RossTate ：

さて、あなたは正確な型がcall_indirectと型のインポートの問題に対処するために何もしないことに同意しているようです。

はい、それが抽象データ型を定義するための機能を追加する方法の問題を意味する場合はそうです。 型の抽象化が一貫して機能する方法はいくつかありますが、そのような機能はさらに先にあります。

あなたの文のキーワードは意志です。 私は、人々がサポートしたいと思うであろう非数値型のcall_indirectのアプリケーションがあることを十分に承知しています。

call_ref命令は、関数refの提案に含まれているため、いずれにせよ、潜在的な抽象データ型メカニズムの前にかなり近いものになっています。 それまで保留にすることを提案していますか？

@tlively ：

エクスポートされたタイプの定義の機密性を有効にすることは、タイプインポート提案の目標ですか？ 私は@RossTateはそれが目標とすべきと考えていることを、このスレッドから収集し@rossbergは、それが現在の目標ではないと考えています。

これは目標ですが、抽象データ型メカニズムは別の機能です。 そして、そのようなメカニズムは、輸入品の設計に影響を与えないように設計されなければなりません。 もしそうなら、私たちはそれを非常に間違って行うでしょう-抽象化は使用サイトではなく定義サイトで保証されなければなりません。 幸いなことに、これはロケット科学ではなく、デザインスペースはかなりよく整備されています。

ありがとう、 @ rossberg 、それは理にかなっています。 型のインポートとエクスポートの後にフォローアップ提案に抽象化プリミティブを追加することは私には問題ないように思えますが、それをどのように行う予定かについての詳細を近いうちに書き留めることができれば素晴らしいと思います。 型のインポートとエクスポートの設計は、抽象型のインポートとエクスポートの設計を制約して通知するため、初期設計を完成させる前に、抽象化が将来どのように機能するかをよく理解しておくことが重要です。

その計画の詳細に加えて、 call_indirectに関するこの問題は、差し迫った決定に影響を与えることを示しているので、抽象型をキャスト可能にすべきではないという私の提案を拒否しているように見える理由を説明できますか（キャスト可能に明示的に制約されていない限り） ）？ それらは不透明であるため、提案は抽象型の一般的な慣行に沿っているようです。

@tlively 、はい、同意しました。 それに加えて、私がしばらくの間書くつもりだった他のさまざまなこと。 ＃69からのすべてのフォールアウトを処理したら実行します。 ;）

@RossTate 。これは、抽象データ型がキャストと互換性が

@rossbergあなたが考えているこの中心的なユースケースが何であるかを明確にできますか？ あなたの例を解釈する上での私の最善の推測は簡単に解決できますが、おそらくあなたは何か他のものを意味します。

@RossTate 、ポリモーフィック関数を検討してください。 Wasm-genericsを除いて、anyrefからのアップ/ダウンキャストを使用してコンパイルする場合、別のオブジェクトに余分にラップすることなく、他の抽象型の値でそれらを使用できるはずです。 通常、抽象型の値を他の値と同じように処理できるようにする必要があります。

さて、ポリモーフィック関数を考えてみましょう。インポートされた型がHandleあると仮定しましょう。

1. Javaにはポリモーフィック関数があります。 そのポリモーフィック関数は、すべての（Java参照）値がオブジェクトであることを想定しています。 特に、Vテーブルが必要です。 Handleを使用するJavaモジュールは、おそらくインターフェースを実装するJavaクラスCHandle指定します。 このクラスのインスタンスには、タイプHandle （wasmレベルの）メンバーと、さまざまなクラスおよびインターフェイスメソッドの実装への関数ポインターを提供するvテーブルがあります。 表面レベルのポリモーフィック関数（wasmレベルではオブジェクトの関数）に指定すると、モジュールは他のクラスへのキャストに使用するのと同じメカニズムを使用してCHandleにキャストできます。
2. OCamlにはポリモーフィックな機能があります。 そのポリモーフィック関数は、すべてのOCaml値が物理的な同等性をサポートすることを期待しています。 wasmはOCamlの型安全性について推論できないため、そのポリモーフィック関数もキャストを多用する必要があります。 特殊な鋳造構造により、これがより効率的になる可能性があります。 これらの理由のいずれかのために、OCamlモジュールは、これらの規範に適合し、タイプHandle （wasmレベルの）メンバーを持つ代数的データ型またはレコード型THandleを指定する可能性があります。 そのポリモーフィック関数は、他の代数的データ型またはレコード型と同じように、OCaml値をTHandleキャストします。

言い換えると、モジュールはポリモーフィック関数などを実装するためにサーフェスレベルの値がどのように表されるかについての規範に依存しており、Handleのような抽象インポート型はこれらの規範を満たさないため、値のラップは避けられません。 これは、 anyrefの元のアプリケーションの1つがインターフェイスタイプに置き換えられたのと同じ理由です。 また、ポリモーフィック関数をサポートするためにanyrefが必要ではなく、適切でもないことを示すケーススタディを開発しました。

一方、キャスト可能なanyrefを使用して、静的な抽象化メカニズムを回避できることを示しました。 あなたがほのめかした抽象化メカニズムの計画は、動的な抽象化メカニズムを通じてこの問題にパッチを当てる試みです。 しかし、動的な抽象化メカニズムには多くの問題があります。 たとえば、 i31refタイプを抽象的なHandle i31refタイプとしてエクスポートするには、他のモジュールがanyref 、ハンドルを偽造するためにキャストするリスクがあります（機能など）。 代わりに、標準の静的抽象化を保証しただけでは不要な追加のフープとオーバーヘッドを飛び越える必要があります。

また、（私が思うに）正確な型をどのように使用するつもりかがよくわかったので、あなたの意図は、 call_indirectとサブタイプで注意を喚起した2つの主要な問題のどちらにも対処していないことに気付きました。

1. call_indirectサブタイピングを尊重するのに役立ちません（これはすでに明示的に言っていると思います）
2. call_indirectを使用して、エクスポートされた署名ではなく、定義された署名でエクスポートされた関数を使用することを妨げません。

したがって、これは解決すべき簡単な問題ではありません。 そのため、時間の制約を考えると、適切に解決するための時間を与える方法の評価に焦点を当てたいと思います。 anyrefが静的な抽象化を捨てる価値があるかどうかについて、最初に議論する必要はないと思います。 それは、物事をさらに遅らせないために避けたいと思っていた一種の大きな議論です。

一方、キャスタブルanyrefを使用して静的抽象化メカニズムを回避できることを示しました。

静的型の抽象化は、動的型キャストを使用する言語では不十分です。 静的抽象化はパラメトリシティに依存しており、キャストはそれを破るからです。 それについて新しいことは何もありません、それについての論文が書かれています。 このような状況では、他の抽象化メカニズムが必要です。

抽象型の使用を制限することによってそれを回避しようとすると、その目的が無効になります。 WASIのユースケースを考えてみましょう。 WASIモジュールとそれがエクスポートするタイプがホストによって実装されているかWasmに実装されているかは関係ありません。 ユーザー定義の抽象型を任意に制限すると、Wasm実装は一般にホスト実装と互換性がなくなります。

1. call_indirectがサブタイピングを尊重するのに役立ちません（すでに明示的に言っていると思います）

は？ これはサブタイピングルールの一部であるため、定義上も同様です。

1. call_indirectを使用して、エクスポートされたシグニチャではなく、定義されたシグニチャでエクスポートされた関数を使用することを妨げません。

私はそうは言わなかった。 これはcall_indirect自体の問題ではなく、キャストのある言語に適した型抽象化メカニズムを選択することの問題だと言いました。

余談ですが、OCaml（または同様の言語）をコンパイルするためにバリアントタイプの導入が必要になる理由はありません。 理論的にはそれがわずかに速い可能性があるとしても（現在の世代のエンジンの場合はそうではない可能性が高いですが、逆の可能性が高いです）、バリアントタイプは重大な問題であり、MVPには必要ありません。 時期尚早の複雑さに対するあなたの欲求を完全には共有していません。 ;）

関数の平等性：HaskellやSMLなど、それをサポートしていない言語があるため、関数参照から直接恩恵を受ける可能性があります。 OCamlは構造的な同等性をスローし、物理的なものに対して実装定義の動作を明示的に持っています。 それが常にfalseを返すことを許可するか、関数をスローすることを許可するかどうかは開いたままですが、実際にはどちらでも十分であり、コストのかかる余分なラッピングを行う前に調査する価値があります。

[メタコメントとして、講義を控えめにして、おそらくこれは有能な人々のセットがシングルトンではなく、脳の痕跡が以前に時々適用された世界であるという考えを検討していただければ幸いです。]

メタコメントとして、講義をトーンダウンしていただければ幸いです。

聞いた。

そしておそらく、これはおそらく有能な人々のセットがシングルトンではなく、脳の痕跡が以前に時々適用された世界であるという考えを考慮しました。

ここでの私のアドバイスは、複数の専門家との協議に基づいています。

静的型の抽象化は、動的型キャストを使用する言語では不十分です。 静的抽象化はパラメトリシティに依存しており、キャストはそれを破るからです。 それについて新しいことは何もありません、それについての論文が書かれています。 このような状況では、他の抽象化メカニズムが必要です。

私が相談したこれらの専門家には、いくつかの論文の著者が含まれています。

さて、私が彼らのアドバイスを正しく統合したことを確認する試みとして、私はこのトピックについてこれまで議論したことのない、いくつかの論文の別の著者に電子メールを送りました。 これが私が尋ねたものです：

ポリモーフィック関数fがあるとします。（...）。 私の型付き言語には、（包含的）サブタイピングと明示的なキャストがあります。 ただし、t1からt2へのキャストは、t2がt1のサブタイプであるかどうかをタイプチェックするだけです。 Xのような型変数には、デフォルトでサブタイプやスーパータイプがないとします（もちろんそれ自体以外に）。 fがXに関して関係的にパラメトリックであると思いますか？

これが彼らの反応でした：

はい、これはパラメトリックになると思います。これにより得られる唯一の機能は、すでに関係的にパラメトリックである恒等関数と同等のキャストをXに書き込むことです。

これは私のアドバイスと一致しています。 もちろん、これは目前の問題を単純化したものですが、WebAssemblyに対してより具体的に問題を調査するように努力してきました。これまでの調査では、この期待はWebAssemblyの規模でも維持されることが示唆されています。 call_indirectを除いて、したがってこの問題。

参照している定理は、すべての値がキャスト可能な言語に適用されることに注意してください。 この観察結果から、キャスタビリティを制限するというアイデアが浮かびました。

WASIのユースケースを考えてみましょう。

私はあなたがしている主張を理解していません。 WASIのユースケースを検討しました。 私たちには、セキュリティ、特に機能ベースのセキュリティの専門家が複数含まれています。

メタコメントとして、私の提案を聞くために当局やCGに訴える必要がないことを本当に感謝します。 キャストを制限することで、キャストが存在する場合でも静的なパラメトリシティを確保できるようになることを提案しました。 あなたはすぐにその提案を無視し、その却下を正当化するために以前の論文に訴えました。 しかし、私がそれらの論文の著者にこれと同じ提案をしたとき、彼らは私がしたのと同じ結論にすぐに到達しました。 その前に、私は潜在的な解決策を評価することは長いプロセスになるだろうと提案しました。 あなたはその提案を無視し、あなたは（すべてあなた自身で）問題を解決したと主張し、私たち両方をこの長い会話に引き込みました。 提案がさりげなく繰り返し却下されると、進歩を遂げ、イライラしないようにすることは非常に困難です。 （私はここで可能な解決策としてあなたの提案を却下しようとしているのではないことを明確にする必要があります。私はそれが唯一の解決策ではないことを実証しようとしているので、他のさまざまなものと一緒に評価する必要があります。）

この問題で提起された懸念に対処するための詳細な設計を明確にし、精査することは重要でタイムリーだと思います。実際には、抽象型をより遠い機能と見なすべきではないと思います。 WASIは今それらを必要としています。

また、 exact + newtypeが懸念に対処できることを期待していますが、現時点では、時期尚早に設計にコミットすることによって、この時点でファームに単純に賭けることはできないことに同意します。私たちは（まもなく）参照型を出荷します。 それについて適切に話し合うには時間が必要です。

そうは言っても、参照型の提案でcall_indirect署名にexternrefを許可しても危険はないと思います。 はい、モジュールがexternref値を（constグローバルとしてまたは関数から返す...）エクスポートする場合、そのexternrefダウンキャストできるかどうかは明確にされていません。 しかし、 call_indirectはexternrefダウンキャストしていません。 funcrefダウンキャストしており、 externrefは、funcref-type-equalityチェックでi32と同じ役割を果たします。 したがって、 call_indirectで型のインポート、型のエクスポート、およびサブタイピングが行われていない場合、MVPでまだコミットしていない新しいデザインの選択にどのようにコミットしているかわかりません。 。

ハザードがない場合は、この激しい議論を、Type Imports提案（適切な抽象型サポートを含める必要があると私はまだ考えている）のそれほど激しくない議論にダイヤルダウンすることができますか？

もちろん。 ハザードがあるかどうかを調べるのは良い考えだと思います。

WASIに関しては、設計はまだ非常に流動的ですが、まだ実行可能と思われる1つのオプションは、動的メモリ割り当てを必要としないため、「ハンドル」にi31refようなものを使用することです。 WASIは他のオプションを決定するかもしれませんが、要点は現時点では誰も知らないので、今後そのような決定に影響を与えないように今行われた決定があればよいでしょう。

現在、 externrefが利用可能な唯一の抽象型であるため、WASIベースのホストはi31ref （またはWASIの「ハンドル」が何であれ）でexternrefをインスタンス化します。 しかし、私の理解では、WASIは、ホストに依存するコードを減らすために、その実装を可能な限りWebAssemblyに移行したいと考えています。 これを容易にするために、ある時点で、WASIシステムはexternref他のタイプのインポートと同じように扱い、WASIの抽象エクスポートされたHandleタイプでインスタンス化する場合があります。 ただし、 Handleがi31ref場合、モジュールの境界を越えて機能できるようにするために必要な上記のcall_indirect実装を使用して、 externrefを介してハンドルを偽造することもできます。

それで、私の質問の1つは、元の投稿で明確に述べられていないことに気づきましたが、他の抽象型のインポートと同じように、 externrefをインスタンス化できるようにしたいですか？

それで、私の質問の1つは、元の投稿で明確に述べられていないことに気づきましたが、他の抽象型のインポートと同じように、 externrefをインスタンス化できるようにしたいですか？

この質問を明示的に提起していただきありがとうございます。 FWIW、私はexternrefがWebAssemblyモジュール内からインスタンス化可能であることを理解したことがありません。 これは、WASIがexternrefをハンドルとして使用したい場合、仮想化へのホストの参加を意味しますが、それは私には問題ないように思えるか、少なくとも分離可能な議論のようです。

うーん、はっきりさせてくれないか見てみましょう。 あなたはすでに次のようなものをたくさん持っていると思いますが、私にとっては最初から始めるほうが簡単です。

wasmモジュールの観点からは、 externrefはホスト参照を意味するものではありません。 モジュールが何も知らないのは不透明（OPAQUE）型です。 むしろ、それをホスト参照として解釈するのはexternref周りの規則です。 例えば、使用してモジュールの規則externref DOMと対話するためには、関係する機能には明らかであろうexternrefのように、モジュールの輸入ものをparentNode : [externref] -> [externref]とchildNode : [externref, i32] -> [externref] 。 ホスト自体などのモジュールの環境は、ホスト参照としてexternrefの解釈を実際に提供するものであり、その解釈を裏付けるインポートされたメソッドの実装を提供します。

ただし、モジュールの環境はホストである必要はなく、 externrefはホスト参照である必要はありません。 環境は、予想される規則を示すホスト参照のように見えるいくつかのタイプの機能を提供する別のモジュールである可能性があります。 モジュールEがモジュールMの環境であり、そのモジュールMが上記のようにparentNodeとchildNodeをインポートするとします。 EがモジュールMを使用したいが、DOMへのMのアクセスを制限したいとします。たとえば、EはMの信頼を制限しているため、またはEはMが持つ可能性のあるバグを制限したいと考えており、Mのニーズがこれらの制限を超えてはならないことを知っています。 Eができることは、Mのexternrefとして「MonitoredRef」を使用してMをインスタンス化することです。 特に、EがM個のDOMノードを提供したいが、MがDOMツリーの上位に移動しないようにしたいとします。 その場合、EのMonitoredRefは具体的にはref (struct externref externref)になります。ここで、2番目のexternref （Eの観点から）はMが操作しているDOMノードですが、最初のexternrefはの祖先です。 Mが通り過ぎることを許可されていないそのノード。 次に、EはMのparentNodeインスタンス化して、これら2つの参照が同じである場合にエラーが発生するようにすることができます。 E自体が独自のparentNodeおよびchildNode関数をインポートし、Eを効果的にDOM相互作用のランタイムモニターにします。

うまくいけば、それは適切な絵を描くのに十分具体的でしたが、詳細に迷うほど具体的ではありませんでした。 明らかに、このようなパターンはたくさんあります。 ですから、質問を言い換える別の方法は、 externrefがホスト参照のみを正確に表すようにしたいのかということです。

私にとって疑わしいと思われる唯一の部分は、「Eができることは、Mのexternrefとして「MonitoredRef」を使用してMをインスタンス化することです。」です。 抽象化したものを他のモジュールでexternrefとして表示できるようにする計画があるという印象はありません。 私の理解では、 externrefは抽象化ツールではありません。

私もそのような計画を知りません。 誰かがそのオプションを検討したかどうかもわかりません。 つまり、 externref 、たとえばi32ような「プリミティブ」型にする必要がありますか、それともインポートされた型などの「インスタンス化可能な」型にする必要がありますか？

私の元の投稿では、どちらの方法でも管理できることを示しました。 「プリミティブ」な解釈を採用することのトレードオフは、インポートされたタイプよりもexternref有用性/構成可能性が大幅に低いことです。これは、インポートされたタイプが上記のパターンと同様にexternrefのユースケースをサポートするためです。 そのため、「プリミティブ」 externrefは痕跡的になる可能性が高く、下位互換性のためにのみ存在します。 しかし、それが特に問題になる可能性は低く、迷惑なだけです。 私が見ることができる最大の問題は、よくbehavednessと同じように、つまりcall_indirect数値型には、彼らが何のスーパータイプを持っていないので、のよくbehavednessうまくいくcall_indirect依存終わる可能性がexternrefにもスーパータイプはありません。

ああ、そうです、これは理解の違いを説明しています。 externrefはまったく抽象的ではなく、「 externrefを型でインスタンス化する」という概念がないことに@tlivelyに同意します。これからはかなり自信が持てると思います。 （ externrefは、明示的に宣言された型パラメーターとは対照的に、プリミティブ型であるため、モジュールごとにインスタンス化を試みる方法さえ明確ではありません。）

ダウンキャストがない場合には、この事実はWASIのための計画はからの遷移になっている理由であるWASIのAPIを仮想化/実装するためのほぼ役に立たないwasmを作るi32直接ハンドルタイプ輸入（と、なぜ私が提出するタイプ-輸入を/＃6 、b / cもう少し必要です）。

externrefは、明示的に宣言された型パラメーターとは対照的に、プリミティブ型であるため、モジュールごとにインスタンス化を試みる方法さえ明確ではありません。

タイプインポートを追加すると、タイプインポートなしで、 externrefが先頭にimport type externrefがあるモジュールを扱うことができます。 他のプリミティブ型とは異なり、 externrefは（デフォルト値以外に）関連するプリミティブ操作がないため、すべてがまったく同じように型チェックされます。 しかし、その暗黙的なインポートにより、仮想化、サンドボックス化、実行時監視などを実行できるようになりました。

しかし、それを行ったり来たりする前に、私たち全員が何かについて同じページにいるかどうかを判断するのに役立つと思います。 次のステートメントに同意するか同意しないか、およびその理由をお知らせください。「タイプインポートが利用可能になると、モジュールはexternrefを使用する理由がなくなり、代わりにタイプインポートを使用すると、より再利用可能/構成可能になります。」

次のステートメントに同意するか同意しないか、およびその理由をお知らせください。「タイプインポートが利用可能になると、モジュールはexternrefを使用する理由がなくなり、代わりにタイプインポートを使用すると、より再利用可能/構成可能になります。」

私は要約のこの声明に同意します。 実際には、externrefは、インスタンス化時に追加の構成を必要としないため、外部JSオブジェクトを参照するためのWebコンテキストでは引き続き一般的であると思います。 しかし、それは単なる予測であり、私が間違っていることが判明し、結局、誰もが型インポートの使用に切り替えてもかまいません。 externrefの価値は、型のインポートなどのより豊富なメカニズムよりも早く取得できることです。 externrefをシンプルに保ち、後でよりエレガントな選択肢があるときに、厄介に靴べらを使ってより強力なものにするよりも、使用されなくなることを確認したいと思います。

@tlively 、

FWIW、私はexternrefがWebAssemblyモジュール内からインスタンス化可能であることを理解したことがありません。

そうです、externrefは「プリミティブ」タイプの外部ポインタであるという考えです。 参照型の実装の詳細を抽象化するには、anyrefや型インポートなどの他の何かが必要になります。

@lukewagner 、必要に

@RossTate ：

私が相談したこれらの専門家には、いくつかの論文の著者が含まれています。

優秀な。 それから、あなたがより多くの権威を探している場合に備えて、あなたは本当にあなたがこれらの論文のいくつかの著者であることに気づいたと思います。 :)

これが私が尋ねたものです：

ポリモーフィック関数f（...）があるとします。 私の型付き言語には、（包含的）サブタイピングと明示的なキャストがあります。 ただし、t1からt2へのキャストは、t2がt1のサブタイプであるかどうかをタイプチェックするだけです。 Xのような型変数には、デフォルトでサブタイプやスーパータイプがないとします（もちろんそれ自体以外に）。 fがXに関して関係的にパラメトリックであると思いますか？

はぁ。 その特定の質問にも同じ回答をします。 しかし、この質問は、キャストの性質や、プログラミング言語にはめったに存在しない有界と非有界の定量化のかなり珍しい区別など、いくつかの特定の仮定を具体化しています。 そして、それは理由があると思います。

「静的型の抽象化が不十分である」と言ったとき、それが_技術的に_不可能であるという意味ではありませんでしたが（もちろん可能です）、それは_実際的に_適切ではありません。 実際には、型の抽象化とサブタイピング/キャスト可能性の間（またはパラメトリック型とノンパラメトリック型の間）の分岐は、キャストに基づく構成を人為的に壊してしまうため、望ましくありません。

私はあなたがしている主張を理解していません。

抽象型の値を受け取った場合でも、その正確な型を忘れて、たとえば、ある種の和集合に入れて、後でダウンキャストによって回復したい場合があります。 他の参照型の場合と同じ理由で、これを実行することをお勧めします。 型の抽象化は、同じ種類の通常の型で有効な特定の使用パターンの邪魔にならないようにする必要があります。

あなたの答えは次のように思われます：それで、それぞれの使用サイトですべてを補助タイプに、たとえばバリアントにラップします。 しかし、それはかなりのラッピング/アンラッピングのオーバーヘッドを意味する可能性があり、より複雑なタイプのシステム機能が必要であり、使用するのがより複雑です。

これが私たちの意見の相違のいくつかに帰着すると思います：MVPが参照型の結合をサポートするべきかどうか、または明示的なバリアント型の導入とエンコードを必要とするかどうか。 良くも悪くも、ユニオンは一般的なエンジンのヒープインターフェイスに自然に一致し、今日のサポートは簡単で安価です。 バリアントはそれほど多くはありませんが、少なくとも既存のエンジンでは、余分なオーバーヘッドと予測不可能なパフォーマンスを引き起こす可能性が高い、はるかに研究的なアプローチです。 そして私は、型システムの人として、ユーザー向け言語などの他の状況では、ユニオンよりもバリアントを非常に好むと言っています。 ;）

メタコメントとして、私の提案を聞くために当局やCGに訴える必要がないことを本当に感謝します。

さまざまな提案についての会話は、明確でないことについてそれぞれのチャンピオンに尋ねることによって開始された場合、よりうまくいくかもしれないことを親切に提案できますか？これらの仮定に基づいて答えを出し、幅広い主張や提案をしますか？

優秀な。 それから、あなたがより多くの権威を探している場合に備えて、あなたは本当にあなたがこれらの論文のいくつかの著者であることに気づいたと思います。 :)

はい、それは、私の提案がそれらの主張がなされた条件に具体的に対処していることを知っていても、私の提案が機能しないと主張する論文があることを提案するとき、非常に問題になります。

実際には、型の抽象化とサブタイピング/キャスト可能性の間（またはパラメトリック型とノンパラメトリック型の間）の分岐は、キャストに基づく構成を人為的に壊してしまうため、望ましくありません。

これは意見であり、事実ではありません（私たちが同意しないことは完全に合理的なことです）。 多言語システムには、言語にとらわれない業界タイプのアセンブリ言語がないため、実践について主張することは不可能だと思います。 これは、徹底的な（個別の）議論に値するものです。 その議論のために、CGがトレードオフを比較できるように、最初にいくつかの詳細なケーススタディを提供することが役立ちます。

さまざまな提案についての会話は、具体的な根拠や将来の計画（必ずしも明確ではない、またはまだ書かれていない）など、明確でないことについてそれぞれのチャンピオンに尋ねることから始めた方がうまくいくかもしれないことを親切に提案できますか？これらの仮定に基づいて答えを出し、幅広い主張や提案をしますか？

WebAssembly / proposal-type-imports＃4、WebAssembly / proposal-type-imports＃6、およびWebAssembly / proposal-type-imports＃7はそれぞれ、基本的にこの計画の詳細を要求しました。 これらの最後のものは問題をGCにパントしますが、WebAssembly / gc＃86は、現在のGC提案が実際には動的抽象化メカニズムをサポートしていないことを指摘しています。

メタレベルでは、この議論を脇に置き、目前のトピックに焦点を当てるよう求められました。 私の質問に対する@tlivelyの回答は非常に役に立ちました。 私は実際、その質問について具体的にあなたの考えを得ることに非常に興味があります。

@RossTate ：

私の質問に対する@tlivelyの回答は非常に役に立ちました。 私は実際、その質問について具体的にあなたの考えを得ることに非常に興味があります。

フム、私はすでにそれについてコメントして思った以上。 それとも何か他のことを意味しますか？

いいえ。 コメントは彼の回答に同意することを意味しているのではないかと思いましたが、最初に確認したいと思いました。 ありがとう！

@lukewagner 、あなたはどう思いますか？

externrefは永久にプリミティブ型であり、型パラメーターとしてさかのぼって再解釈されないことに同意します。 それを考えると、参照型はそのままでよいと思います。

@rossbergを取り上げて、Type Imports提案の範囲を拡大し、wasmが抽象型を実装する機能をカバーできるようにしたいと思います。 それを突き止めることができれば、関数参照とサブタイプに関するさらなる議論のブロックを解除できると思います。

素晴らしい。 次に、私たちはすべて同じページにいます（そして、私も、関係するトレードオフと決定の根拠の素晴らしい要約を@tlivelyが提供すると思います）。

したがって、 externrefはインスタンス化できず、タイプインポートの追加の柔軟性を探しているモジュールは、機能がリリースされたときにタイプインポートに変換されることが期待されます。 その移行をスムーズにするために、インスタンス化が提供されていない場合、（いくつかの？）タイプのインポートがデフォルトでexternrefによってインスタンス化されるようにする必要があると思います。

また、タイプインポートの範囲を拡大するという申し出も受けたいと思います。 型インポートの主要なアプリケーションの多くは抽象化を必要とするため、抽象化がその提案の一部になるのは自然なことのように思えます。

その間、 externrefに関する差し迫った質問に対処しましたが、 call_indirectについてより一般的に何をすべきかは、解決方法についての有益な議論はあるものの、まだ解決されていません。問題は未解決のままにしておきます。

ありがとう！