2

Haskel 風の構文と FRP を Javascript に導入しようとする「elm」という言語を使用しています。ここでは、F# からパイプライン演算子を実装することについていくつかの議論がありましたが、言語設計者は、より標準的な (少なくとも他の FP 言語では) リバース パイプライン演算子よりもコストが増加すること (コンパイル時間の増加またはコンパイラの実装の複雑さを想定しています) について懸念しています。 （elmはすでに実装しています）。誰もこれについて話すことができますか？[そのスレッドにも直接投稿してください。他に誰も投稿しない場合は、最適な回答を貼り付けます]。

https://groups.google.com/forum/?fromgroups=#!topic/elm-discuss/Kt0MbDyRpO4

ありがとう！

4

3 に答える 3

7

あなたが参照しているディスカッションでは、Evan が 2 つの課題を提起していることがわかります。

  1. それを使用する F# プロジェクトを見せてください
  2. 信頼できる F# プログラマーが、なぜそれが良いアイデアなのか、それに伴うコストについて話しているところを見つけてください (ブログ投稿など)。

私なら次のように答えます。

  1. フォワード パイプ イディオムは、F# プログラミングでは、スタイル (私たちが気に入っている) と実用的 (型の推論に役立つ) の両方の理由から非常に一般的です。ほぼすべての F# プロジェクトで、F# が頻繁に使用されます。確かに、私のすべてのオープン ソース プロジェクトで使用されています (Unquote、FsEye、NL はこちらを参照)。F# コンパイラ ソース自体を含む、Github にあるすべての F# プロジェクトで同じことが見つかることは間違いありません。

  2. Microsoft の F# コンパイラ チームの開発者である Brian は、 2008 年に F# でのパイプライン処理についてブログを書きました。これは、F# パイプを POSIX パイプに関連付ける非常に興味深く関連性のあるブログです。私自身の見積も​​りでは、パイプ オペレーターを実装するコストはほとんどありません。F# コンパイラでは、これはあらゆる意味で確かに当てはまります (これは 1 行のインライン関数定義です)。

于 2013-02-04T00:06:25.277 に答える
3

パイプライン演算子は実際には信じられないほど単純です-これが標準の定義です

let inline (|>) a b = b a

また、.スレッドで説明されている演算子は、F＃（<|）の逆パイプ演算子であり、一部の角かっこを削除できます。

パイプライン演算子を追加しても、複雑さに大きな影響はないと思います

于 2013-02-03T23:58:06.913 に答える
2

ここですでに提供されている優れた回答に加えて、さらにいくつかのポイントを追加したいと思います。

まず、パイプライン演算子が F# で一般的である理由の 1 つは、現在行われている型推論の欠点を回避するのに役立つからです。具体的には、OOP を使用するラムダ関数を使用して集計操作をコレクション型の推論に適用すると、通常は失敗します。例えば：

Seq.map (fun z -> z.Real) zs

zF# は、プロパティに遭遇したときにの型をまだ認識していないため、Realこのコードのコンパイルを拒否するため、これは失敗します。慣用的な修正は、パイプライン演算子を使用することです。

xs |> Seq.map (fun z -> z.Real)

これは厳密には醜い（IMO）ですが、機能します。

第 2 に、F# のパイプ演算子はある程度は優れていますが、現在、中間結果の推定型を取得することはできません。例えば：

x
|> h
|> g
|> f

型エラーが発生した場合、問題が実際にorにあった場合に備えfて、プログラマーは渡される値の型を知りたいと思うでしょうが、これは現在 Visual Studio では不可能です。皮肉なことに、Emacs の Tuareg モードを使用する OCaml では、識別子だけでなく、任意の部分式の推定型を取得できるため、これは簡単でした。fhg

于 2013-02-04T14:46:28.677 に答える