Prologのサポート

1. 関数は、複数回「戻る」ことができます。 これは、schemeのcall / ccに少し似ています。 しかし、これによって評価の単位としての機能に対する現在の固定は破られます。 Prologスタックは、これをサポートするために、ほとんどの言語の評価スタックよりも大幅に豊富です。 call / ccとは異なり、Prologの継続は再定義できないことに注意してください。
2. Prologには、変数-変数の間接参照が非常に必要です。 メモリ参照には実際の値がない場合がありますが、実際の値へのポインタがあります。 一部のシステムでは、これはPrologアプリケーションのすべてのCPUサイクルの30〜40％を占めます。
3. 効率的なバックトラッキングは割り当ての順序を知ることに依存しているため、通常の半空間ベースのGCアルゴリズムはPrologではうまく機能しません。

ガベージコレクターがスタックも収集するのは、Prologでは正常です。 Prologのcut演算子は、ガベージスタックエントリになります。

Haskellをサポートする
注：私はこれの専門家ではありません。

1. 複数の戻り点は、番兵を返し、分岐することで近似できます。 しかし、かなりのパフォーマンスコストがかかります。 このようなシステムは、Haskellをネイティブにサポートしているとは言えません。
2. 末尾再帰。 末尾呼び出しは、親呼び出しと同じ数のパラメーターなどを持つ末尾呼び出しについて仮定する必要はありません。 関数型言語の多くの場合、同じようには見えません。
3. 非線形評価スタック。 Haskellの通常の遅延評価モードでは、スタックへの実装が非常に困難になります。 私の知る限り、Haskellコンパイラは評価をスタックにマップしようとしますが、通常は失敗し、ヒープが割り当てられたスタックになってしまいます。

2015年11月29日には、午前8時46分PMで、フランク・マッケイブの[email protected]は書きました：

Prologのサポート

関数は、複数回「戻る」ことができます。 これは、schemeのcall / ccに少し似ています。 しかし、これによって評価の単位としての機能に対する現在の固定は破られます。 Prologスタックは、これをサポートするために、ほとんどの言語の評価スタックよりも大幅に豊富です。 call / ccとは異なり、Prologの継続は再定義できないことに注意してください。
必要な低レベルの機能は何ですか？ 複数の関数のエントリポイントですか？

Webでのプロローグの実装がスタックのようなデータ構造をヒープ割り当てし、それらを高レベルのスタックとして使用することを妨げるものは何もないことに注意してください。 プロローグの実装がCコードを生成するときにこれを行った場合、マシンコードを対象とし、より巧妙なことを行う実装よりも、全体的なベンチマークパフォーマンスの観点からどれほど悪いでしょうか？

Prologには、変数-変数の間接参照が非常に必要です。 メモリ参照には実際の値がない場合がありますが、実際の値へのポインタがあります。 一部のシステムでは、これはPrologアプリケーションのすべてのCPUサイクルの30〜40％を占めます。
目的のマシンコードは、Cを使用してこれを表現した場合にCコンパイラが生成するものとどのように異なりますか？
効率的なバックトラッキングは割り当ての順序を知ることに依存しているため、通常の半空間ベースのGCアルゴリズムはPrologではうまく機能しません。

ガベージコレクターがスタックも収集するのは、Prologでは正常です。 Prologのcut演算子は、ガベージスタックエントリになります。

wasmのGC機能はすべて、WebのGCセマンティクスと互換性がある必要があります。 あなたが説明することが互換性があるかどうかは明らかではありません。

リニアメモリを使用したカスタムGCの実装を妨げるものはありません。

Haskellをサポートする
注：私はこれの専門家ではありません。

複数の戻り点は、番兵を返し、分岐することで近似できます。 しかし、かなりのパフォーマンスコストがかかります。 このようなシステムは、Haskellをネイティブにサポートしているとは言えません。
末尾再帰。 末尾呼び出しは、親呼び出しと同じ数のパラメーターなどを持つ末尾呼び出しについて仮定する必要はありません。 関数型言語の多くの場合、同じようには見えません。
非線形評価スタック。 Haskellの通常の遅延評価モードでは、スタックへの実装が非常に困難になります。 私の知る限り、Haskellコンパイラは評価をスタックにマップしようとしますが、通常は失敗し、ヒープが割り当てられたスタックになってしまいます。
—
このメールに直接返信するか、GitHubで表示してください。

必要な低レベルの機能は何ですか？ 複数の関数のエントリポイントですか？

Prologプログラムは単に通常の機能に対応していません。 Prologプログラムの終了は、通常の関数の戻り値のように処理することはできません。 対応する呼び出しは、通常の関数呼び出しよりも多くのことを行う必要があります。

これをCにマッピングすると、非常に大量のコードが生成されるか、場合によっては、解釈の層が追加されます。 ほとんどのまともなPrologシステムはCにコンパイルされません。

一部のシステムでは、これはPrologアプリケーションのすべてのCPUサイクルの30〜40％を占めます。

目的のマシンコードは、Cを使用してこれを表現した場合にCコンパイラが生成するものとどのように異なりますか？

ここで重要なのは、ベリファイアに対して型違反のように見えるものを取得することです。 値へのポインターは、値へのポインターへのポインター、または値へのポインターへのポインターへのポインターである可能性があります。 またはそれは単なる値かもしれません。

Cを介してコンパイルすると、必然的にパフォーマンスが大幅に低下します。

線形メモリのチャンクを割り当ててそれで遊ぶことができるとあなたが言ういくつかの場所。 これは本当です。 しかし、それを優先戦略として同時に使用し、普遍性を主張することはできません。

極端な例が示すかもしれません：あなたはすべてのCプログラムをHaskellにマッピングすることができます。 次に、効率的なHaskellの実装があれば、Cの効率的な実装もあり、普遍性があると主張することができます。 多くの人がそれを受け入れるとは思えません。

一方、PrologまたはHaskellのいずれかをサポートする必要はありません。 その場合、普遍性を主張しないでください。

非標準の実行モデルを持つ他の言語には、SQL、Scheme、Rubyなどがあります。

リニアメモリを使用したカスタムGCの実装を妨げるものはありません。

これは一般的なことになると思います。 異なるGCモデルが多すぎるため、単一のVMですべてをサポートすることはできません（別の例として、GCファイナライザーを必要とする言語がありますが、JSにはありません）。これで問題ありません。 その他は、ネイティブ速度に近い線形メモリ（+スレッド）上に実装できます。

線形メモリのチャンクを割り当ててそれで遊ぶことができるとあなたが言ういくつかの場所。 これは本当です。 しかし、それを優先戦略として同時に使用し、普遍性を主張することはできません。

その意味で強い普遍性を主張しているとは思いません。 それは決して達成されておらず、おそらく不可能です。

WebAssemblyの主な目標はJavaScriptのアセンブラーとして機能することですか？ すでにJSが広く実装されていると思いました。

また、当初の目標は、ブラウザで配布するために任意のCプログラムをコンパイルできるようにすることだと思いました。

アンティを少し上げていたと思います。 ユニバーサルアセンブラの可能性はあると思います。

WebAssemblyの目標はここに詳しく説明されてい

FutureFeatures.mdドキュメントは、いくつかの可能なアイデア（完全に一般的な末尾呼び出しを含む）のリストであり、他のアイデアも可能です。 包括的なリストを意味するものではありません。 新しいアイデアは大歓迎です。

Haskellにとって、探索の良い出発点はGHCLLVMバックエンドかもしれません。 LLVMのどのような特別な機能に依存していますか？ その弱点は何ですか？

十分に具体的なものが特定されていないため、締めくくります。特定された場合は、新しい特定の問題を開くことがより適切であるように思われます。

芯

Haskellに関してCoreが育てられていないことに驚いています。

別のターゲット

私たちの目標は、_Haskell_をWebAssemblyにコンパイルすることではなく、_Core_をWebAssemblyにコンパイルすることです。 HaskellコンパイラGHCは、すでにHaskellをCoreにJVMバイトコードにコンパイルされているので、WebAssemblyで同様のことができなかった理由がわかりません。

GHCはさらに多くの仕事をします

さらに進んで、コンパイルの後半でGHCをインターセプトすることもできます。 たとえば、GHCはすでにCoreを少し単純なSpineless TaglessG-machineにコンパイルしています。 次に、STGコードをC--の方言に変換します。この時点で、関数呼び出しも削除されています。 全体的な説明については、ウィキペディアのGHC§アーキテクチャを参照してください。

ただそれを可能にする

もちろん、WebAssemblyチームは、Haskellのコンパイルシステムの設計のみを考慮する必要があります。 他の誰かがコンパイラを書くことができます; 比較的小さく効率的でありながら、WebAssemblyがそのようなコンパイラの適切なターゲットであることを確認する必要があります。 おそらく、Haskellを低レベル言語にコンパイルするためにGHCがすでにどれだけの作業を行っているかを考えると、それはすでにそうです。