Julia: 提案：機能配管を廃止してから削除する

関数パイピングは、関数呼び出しの接尾辞構文を提供します。これは、REPLでインタラクティブなデータ生成とさらなる視覚化/要約に便利です。

多くの人がタイプするのを見たユースケースは

julia> somecomplicatedthingproducingarray
...

<ARROW UP>

julia> somecomplicatedthingproducingarray |> summarize

ここで、 summarize関数はプロットやヒストグラムのようなものです

@jiahao私はそれが役に立たないと主張しているのではなく、Base内で一貫性を保ち、パッケージにこのようなものを提供させる必要があると主張しています。

replの使用にansもあります

この提案では、 |>まだ中置演算子として解析されますか？

@ ajkeller34 ：確かに、パッケージは、古いものと意味的に互換性があるという制約をあまり受けずに、（タイプの著作権侵害と共存の点で互いにうまく機能する必要がありますが）それを使って好きなことを自由に行うことができます基本定義。

Base内の構文の使用を削除します（存在する場合）

これが私がこれを行うために行った非常に時代遅れの試みです： https ：//github.com/tkelman/julia/commit/212727cdc4aaa3221763580f15d42cfe198bcc1c
当時、ベースでの使用のほとんどはかなり些細なものでした。 「これをこの無名関数にパイプする」というテストの使用法のいくつかは、パイピングの方が良いかもしれませんが、それらのほとんどは同じ無名関数を複数回再利用していたので、名前を付けて、その時点での正常な機能。

気になる人のために、 ChainRecursive.jlをリリースしました。 完了したら、ChainMap.jlとそのさまざまな子の崩壊についての談話について発表します。

私はいくつかの既得権益と|>が可能にするものに特別な好みを持っているので、ここでいくつかの抵抗を提供させてください。

次に@jiahaoを使用して、REPLですばやく試してみたい場合に|>が非常に役立つことを説明します。 さらに、あなたの議論が大きすぎる場合や、ある程度の落ち着きに値する場合にも役立ちます（そうです、私はそう言いました） 。 リンクされた例の場合、実際には、呼び出される関数よりも引数を目立たせる方がよいでしょう。 sum(x)は単純すぎる例であり、実際にはsum(x)と記述する必要があります）。 Escher.jlでは、要素にプロパティを追加するすべての関数にカレーメソッドがあります。 これは|>と非常によく合います（これは計画されていましたが、 mapでもうまく機能します）。行の最後で試してUIの更新を確認できるのは嬉しいことです。すぐに。 表現の始まりにたどり着く必要はありません。 少なくともEscherで使用する場合、推奨される代替方法は、 padded_box_contents_aligned_right_tomato_background （またはさらに悪いことbox34 ）のような構成された名前の変数に大きな式を割り当ててからそれらの関数を呼び出すことです。 美しく読む<big UI expression> |> aligncontents(right) |> pad(1em) |> fillcolor("tomato")とは対照的に

この後、Escher内|>を定義できることはわかっていますが、おそらくそうするでしょうが、 WARNING: using Escher.|> in module YourPackage conflicts with an existing identifier.パッケージがこれにほぼ間違いなく異なる意味を与えるのを見ると、頭がおかしくなります。憂慮すべき！

StefanKarpinskiとandyferrisは、＃17155で任意の関数合成を提供しました。これは、多くの状況で同様の目的を果たすことができます。

box |> fill("orange") |> pad(2em)の代わりに、$ box |> fill("orange") ∘ pad(2em)ではなく(fill("orange") ∘ pad(2em))(box) $になりますか？ これら2つは直交しているように見えます。

Escherによるオブジェクトとしてのクロージャの使用は、この構文を使用するためだけにDSLを定義しているように見えます（単一入力、単一出力以外のものには重大な制限があります）。 、および複数の使用可能な連鎖マクロの1つを使用した場合は、より一般化できます。

Baseのこれの定義を削除すると、この構文が好きな人はそれを使ってもっと面白いことをすることができます。

@shashiあなたの意見は理解できますが、この号で引用したパッケージの1つを使用しても、同じ動作を得ることができますね。 例として、Escherの例では、FunctionalDataを使用して<strong i="6">@p</strong> vbox(<really big thing>) | pad(2em)を実行するか、Lazyを使用して@> vbox(...) pad(2em)を実行できます。

Baseのこれの定義を削除すると、この構文が好きな人はそれを使ってもっと面白いことをすることができます。

それを使用する唯一の安全な方法はEscher.|>(...)またはLazy.|>(...)であるため、使用できないことを除いて。

仮に、 Baseで定義されていないと仮定して、定義とエクスポートの両方を行う2つの異なるパッケージを使用している場合、 |>を中置演算子としてどのように使用しますか？

@kmsquireユースケースによって異なります。 |>は、現在と同じように中置演算子として解析されますが、Baseには値がありません。 マクロで使用する場合は、特定のパッケージがどのように定義するかは関係ありません。これは、呼び出し式の最初の引数になるだけだからです。

たとえば、 <|を考えてみましょう。これは、中置演算子として解析されますが、値はありません。 未定義ですが、まだあります

julia> dump(:(a <| b))
Expr
  head: Symbol call
  args: Array{Any}((3,))
    1: Symbol <|
    2: Symbol a
    3: Symbol b
  typ: Any

パッケージは、 +の場合と同じように、さまざまな意味を持つBase.:(<|)のメソッドを定義およびエクスポートできます。

しかし、優れた関数パイプを提供するパッケージはマクロでそれを行います。まさにこの理由からです。

FWIW、連鎖中にすべてが1つの式に圧縮されるため、評価中に連鎖パッケージが|>を使用する必要はありません。 パッケージが|>を定義するようになれば、それはまさにベースでの定義になると思います。 おそらく代わりに連鎖マクロを使用する必要がありますが。 チェーンでうまく機能するインターフェースを構築する方法の良い例については、 DataFramesMetaを参照してください。

これを非推奨にする場合は、文字列連結の*も非推奨にする必要がありますか？ これには、 string(a, b)が冗長であるのと同様の問題があり、 aとbが数字ではないことを考えると、驚き最小の原則に違反します。

より一般的には、 *(a, b)とa * bのような複数の呼び出し規約があると混乱するため、おそらくすべての中置記法を廃止する必要があります。現在の3つの異なる構文を1つに減らして、完全な一貫性を得ることができます。 醜さを避けるために、関数呼び出しを括弧内に移動し、冗長なコンマも削除することを検討してください。

|>は、現在と同じように中置演算子として解析されますが、Baseには値がありません。 マクロで使用する場合、特定のパッケージでどのように定義されているかは関係ありません。

Baseから削除する必要がある理由はまだわかりません。

@bramtaylは良い点を示しています：

パッケージが定義されるとしたら|>それは正確に定義が基本になると思います。

そして、これを定義する複数のパッケージを使用する唯一の方法は、それを中置で使用しないことです。

|>をマクロ内で使用するためにBaseの定義を削除する必要がある理由がわかりません。

そうではありません。 私のポイントは、Baseの状況に関係なく、マクロ内で|>を使用できるということです。 適切に解析する演算子についても同じことが言えます。 提案のポイントは、関数呼び出しに関してBaseを一貫性のあるものにすることです。そうすれば、パッケージを介して配管動作を実現できます。 パッケージが特に|>を使用するかどうかは重要ではありません。 <|または文字通り他の中置演算子を使用することもできます。

@ararslanそうですね、それは私が尋ねるつもりではありませんでした。すぐにコメントを更新しました。ごめんなさい。

とにかく、私は「関数呼び出しの観点から自己完結型のベース」という感情を完全には理解していません。 このように見えると、マクロ以外のコンテキストで|>を使用するのが難しくなるだけです。 個人的には、 |>は、驚くべきことですが、初心者にとって学ぶ価値のあることだと思います。 少なくともREPLでの労力を節約できます。 |>は他の中置関数と同じように関数であり、関数は単なる値であるという教訓を補強するものであることに後で気付くのは非常に楽しいことです。

おそらく正式なものです。リリースサイクルの最後ではなく、最初に非推奨や構文の変更について話し合ったり決定したりしてください。 現在、すべての主要な開発者と責任のあるパッケージは、0.6を完成させるために時間とエネルギーを費やしており、別の（良い）アイデアを考える時間がないかもしれません。

「私はそれが役に立たないと主張しているのではなく、むしろ一貫しているべきだと主張している」

時々有用性は一貫性を打ち負かしますか？ 不整合に気づいていませんでしたが、 |>構文が役立つことがわかりました。 それが削除された場合、私は具体的なものを何も得たとは感じません。

可能であれば、賛成票の説明：

現在Baseにあるものの多くは、代わりにパッケージで発生する可能性があります。 辞書をパッケージに移動する必要がありますか？ たぶん、並べ替えやシャッフルなどの操作を一覧表示しますか？ 回収作業等？ Baseに含めるべきものと含めないものについては、長く詳細な議論があったと思いますが、一部の機能がBaseに含まれる理由は3つあると思います。
1）その機能は、ベースで他の機能を有効にするために必要です。
2）その機能は言語の重要な部分であり、多くのJuliaプログラマーとパッケージがそれを使用します。したがって、多くの人々が自分自身を転がす断片化ではなく、全員が同意する単一の実装/構文を持つことが望ましいです。
3）ベースに機能を含めると、「生の」ジュリアがより快適に使用できるようになるか、よりフル機能であると感じられるようになります。これは、言語の伝道と採用に役立ちます。

sumのようなものは、おそらく3つのポイントすべてにヒットし、関数のパイピングは2番目と3番目のポイントにヒットすると主張します。

最初の（よく書かれた）提案とこのスレッドでの議論の両方で、共通のテーマは、マクロを介してパイプのような機能を提供するいくつかのパッケージの存在です：Lazy.jl、Pipe.jl、ChainMap.jlなど。複数のパッケージの数は、コミュニティの多くの人々がパイプを有用で望ましい機能と見なしていることを強く示唆しています。このディスカッションスレッドにこれらのパッケージが存在することは、ここの多くの人々がパイプの使用を理解してサポートしていることを示唆しています。

配管はJuliaコミュニティや他の言語で一般的で人気のある機能であるため、このディスカッションでも、特にREPL（Juliaが輝く場所）では多くの用途があり、Juliaエコシステムにはすでに断片化が存在することに人々は同意しているようです。 ..私の読み取りは、Baseから削除する必要があるということではなく、Baseで使用可能な配管構文を拡張して、断片化の必要性を減らす必要があるということです。 プロットなどのさまざまな方法を提供するさまざまなパッケージは問題ないようです。 関数を適用するさまざまな方法を提供するさまざまな人気のあるパッケージは、かなり怖いようです。

さらに、Baseから配管を削除しても、中置演算子をそのままにしておくのは意外だと主張します。Juliaでは、独自の中置演算子を定義することはできませんが、未使用の中置演算子|>がぶら下がっていて、次のように定義できます。お願いしますか？ それが優れた機能である場合は、10個または20個の中置演算子を指定して、自由に定義してみませんか？

最後に、他の関数適用とは異なるので、正確に配管を維持するのは自然なことだと思います。 これはバグではなく機能であり、関数を適用する他の規則とは異なります。 この違いが、いくつかのユースケースでそれを輝かせるのです。 また、（少し手を振る）名詞が動詞の前に来る場合もあります。これらの多くは、生の関数適用が扱いにくい場合の正確な構文糖衣です。 頭のてっぺんから、割り当てx = 5は、動詞（値にバインド）の前に名詞（記号x ）を置きます。 同様に、 getfield t.aタイプのフィールドにアクセスします。 そして最も深く、配列インデックスz[5]は「 zから5番目の要素を取る」のようになり、一般的にgetindex(z, 5)よりも自然です。

それが優れた機能である場合は、10個または20個の中置演算子を指定して、自由に定義してみませんか？

<| 、 ++ 、..のような要求されていないASCIIのものに加えて、すべてのユニコードのものを含めると、おそらくそれ以上のものがあります。

スレッド全体を読んでいない-しかしただ言いたかった
パイプできるのが大好きです。 私は賛成票を投じます
いつでも一貫性。

私はそれを維持することを非常に穏やかに好みますが、それが中置演算子のままである限り、実際には気にしません。 パッケージをインポートする必要がある場合は、関数パイピングを使用しないと思います。これは、あまり価値がないことを示しています。

そうは言っても、この「驚き最小の原則」の議論は、多様なユーザーベースについていくつかの推測をしているので、説得力があるとは思いません。 主語-目的語-動詞言語のネイティブスピーカーにとって、ジュリアの構文のほとんどは驚き最小の原則に違反していると思います。関数の配管はかなり快適です...

スレッド全体を読んでいない

😕

パイプできるのが大好きです

繰り返しになりますが、私は、パイプを使用できないようにする必要があると主張しているのではなく、いくつかの既存のパイプパッケージの1つで機能を簡単に利用できると主張しています。 Baseパイプを削除すると、パッケージは、Baseが提供するものに準拠したり、一貫性を維持したりすることなく、独自のパイピングセマンティクスをより簡単に定義できます。

ジュリアでは、独自の中置演算子を定義することはできません

それは真実ではない; 中置演算子として解析するものはすべて、定義または再定義できます。 martinholtersが指摘したように、 <|と++も同様に利用できます。

私はこれについては少し中立ですが、 |>が通常の関数呼び出し構文から逆になっていることがその要点であるという感情を2番目に説明します。 配管の最大のファンでさえ、たとえばsin <| xを要求していません。これは、実際にはsin(x)と重複しているためです。 |>は、多くの括弧なしで左から右に流れるデータを目や脳で考えやすい場合に使用します。

|>をもっと強力にしたいのですが、たとえばx |> f(_) + 2g(_) |> hなどを許可し、単なるオペレーターではないようにします。 誰かがx |> fをf(x)以外の何かを意味するように定義するたびに、私たちが使用した演算子の全体的なポイントは、それが異なる順序の呼び出し構文であるということなので、それは本当に私をつまずかせます。 呼び出しをオーバーロードできるので、 x |> fが他の意味を持つ理由がわかりません。

@StefanKarpinskiマクロを使用すると、より強力なパイプをすでに取得できます。 たとえば、 Pipe.jlを参照してください。これは、説明している構文を正確に提供します。 |>が演算子である限り（私は個人的に|>が特別な場合の価値があるとは思わない）、マクロは中置を解析する任意のパイピング区切り文字を使用できます。 :call 。 例として、同様に@~を使用してパイプすることができます（少なくともこの記事の執筆時点では）。 このレベルの柔軟性は、Juliaでマクロを使用する利点の1つです。

Pipe.jlの機能を言語に追加すると、 @pipeを記述しなくても使用できるようになります。

|>を非推奨にする主な理由は、人々がはるかに好む他の目的のために構文を再利用したい場合です。

私は、パイピングが言語の一部である必要はなく、パッケージに含まれている可能性がある（そしてすでに存在している）と主張しようとしていると思います。

しかし、 |>が必要なものが他にない場合は、その（些細な）定義をそのままにしておくことにほとんど害はありません。

現在、Baseで|>を転用する提案はないと思います。 Baseで定義しないという私の主張は、機能を失うことなく一貫性を高めることができるということです。

この既存の定義を心配したり回避したりしないことで、「より強力なパイピング」の提案やパッケージの実装が簡単になりますか？

@ararslan 「それは真実ではありません。中置演算子として解析するものはすべて、定義または再定義できます。」

マニュアルの「&&および||演算子」から、それらは解析されますが、再定義することはできません（これは良いことです）。 私は唯一の例外を信じています。

いわゆる「論理演算子」&&および|| 中置です。 [単項二項関係]「演算子」は、そうではないので、私見では間違った用語です。 Notは、論理ビット単位の＆および|と同様の方法ではありません。 それはオーバーロードを許可します（私にはわからないことが良い選択です）。

@PallHaraldssonこれらは制御フローであり、 & 、 | 、 +などと同じ意味の演算子ではありません。

できればここで話題にとどまりましょう。

@tkelmanそれは良い点です。 ただし、将来のパイピング構文には下位互換性を持たせることができると思います。 たとえば、 _が予約されている場合、 |>は、引数に_が含まれている場合に特別な意味を持つことができ、それ以外の場合は現在と同じことを行います。

別の問題があります。オブジェクトに対して|>を機能させるために、 |>または「関数呼び出し演算子」（つまり、それにメソッドを追加する）を定義しますか？ |>が関数呼び出しの組み込み構文であり、 f(x)とx |> fが常に同じであることを確認すると、よりクリーンになる可能性があります。

ここでのコンセンサスは非常に明確に反対しているので、先に進んで問題を閉じます。 皆さん、議論に感謝します。

私はこの問題が解決されたことを知っています。 オペレーターを維持してくれて「ありがとう」と言いたかっただけです。