.構文は非常に便利なので、関数呼び出しの単なる同義語にするつもりはありません。 sum(1,2)に対する1.sum(2)の利点がわかりません。 私にはそれは物事を混乱させるようです。

例外に関する質問は別の問題ですか？ 関数本体をtry..catchでラップすることを除けば、答えはノーだと思います。

1.sum（2）の例は簡単です（私もsum（1,2）を好みます）が、関数自体がそのタイプexによって所有されていないことを示すだけです。 1は、最初のパラメーターがIntであると期待する関数だけでなく、最初のパラメーターがRealである関数に渡すことができます。

編集：私はあなたのコメントを誤解したかもしれません。 ドット関数は、構成に一般的に使用されるビルダーパターンなどの特定のデザインパターンを適用するときに役立ちます。 例

validate_for(name).required().gt(3) 
# vs 
gt(required(validate_for(name)), 3) 

私が今言及した例外は、関数が非決定論的な結果を返すためです（これはとにかく悪い習慣です）。 例として、a.sum（2）.sum（4）を呼び出す場合があります。ここで、.sum（2）はIntではなくStringを返すことがありますが、.sum（4）はIntを期待します。 コンパイラ/ランタイムは、そのような状況を評価するのに十分スマートであると思います-これは、関数sum（sum（1、2）、4）をネストする場合も同じです-しかし、機能要求では、タイプ制約を適用するために、前述の機能を拡張する必要がありますドット関数。

人々が好むと思われるユースケースの1つは、「流暢なインターフェース」です。 OOP APIでは、メソッドがオブジェクトを返すときに便利な場合があるため、 some_obj.move(4, 5).scale(10).display()ようなことができます。

私にとって、これは関数合成としてより適切に表現されると思いますが、 |>は、anonを使用しない限り、引数では機能しません。 関数、例えばsome_obj |> x -> move(x, 4, 5) |> x -> scale(x, 10) |> display 、これはかなり醜いです。

この種のことをサポートする1​​つのオプションは、 |>が評価前にRHSの最初の引数としてLHSを押し込んだ場合ですが、現在のように単純な関数として実装することはできませんでした。

別のオプションは、この種の動作を次の式に追加する、ある種の@composedマクロです。

また、これをサポートする責任をライブラリ設計者に移し、そこで定義することもできます。

function move(obj, x, y)
    # move the object
end

move(x, y) = obj -> move(obj, x, y)

したがって、オブジェクトを指定しない場合、オブジェクトは部分関数適用を実行し（1つの引数の関数を返すことにより）、通常の|>チェーン内で使用できます。

実際、 |>の定義は、おそらく今すぐに変更される可能性があります。
あなたが求めている行動。 私はそれのためになります。

2014年1月27日（月曜日）には、スペンサー・ラッセル[email protected]
書きました：

人々が好むと思われるユースケースの1つは、「流暢なインターフェース」です。 それは
メソッドがオブジェクトを返すときにOOPAPIでうまくいくことがあるので、
some_obj.move（4、5）.scale（10）.display（）のようなもの

私にとって、これは関数合成としてより適切に表現されると思いますが、
|>は、anonを使用しない限り、引数では機能しません。 関数、例えばsome_obj
|> x-> move（x、4、5）|> x-> scale（x、10）|>表示、これはきれいです
醜い。

この種のことをサポートする1​​つのオプションは、|> LHSを次のように押し込んだ場合です。
評価する前のRHSへの最初の議論、しかしそれはできませんでした
現在のように単純な関数として実装されています。

別のオプションは、これを追加するある種の@composedマクロです。
次の式に対する一種の振る舞い

これをサポートする責任を図書館に移すこともできます
デザイナー、彼らが定義できる場所

関数move（obj、x、y）
＃オブジェクトを移動する
終わり

move（x、y）= obj-> move（obj、x、y）

したがって、オブジェクトを指定しない場合、部分機能の適用が行われます。
（1つの引数の関数を返すことによって）これを内部で使用できます
通常|>チェーン。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/5571#issuecomment-33408448で表示してください
。

ssfrr私はあなたの考え方が好きです！ 関数の合成|>を知りません

kmsquire現在の関数構成を拡張して、呼び出し元の関数exでパラメーターを指定できるようにするというアイデアが好きです。 some_obj |> move(4, 5) |> scale(10) |> display 。 ネイティブサポートはクロージャが1つ少なくなることを意味しますが、ssfrrが提案したのは今のところ実行可能な方法であり、追加の利点として、実装された場合は拡張関数合成機能と上位互換性があるはずです。

迅速な対応をありがとう:)

実際、 @ ssfrrは正しかったのです。これを単純な関数として実装することはできません。

必要なのはスレッド化マクロです（例：http：//clojuredocs.org/clojure_core/clojure.core/-%3E）。 残念ながら、@-> @->> @-？>>はJuliaでは実行可能な構文ではありません。

ええ、私は中置マクロがこれを実装する方法になるだろうと思っていました。 私は、制限が何であるかを知るのに十分なマクロに精通していません。

これは@ssfrrの作成マクロで機能すると思います。

編集：これはもう少し明確かもしれません：

import Base.Meta.isexpr
_ispossiblefn(x) = isa(x, Symbol) || isexpr(x, :call)

function _compose(x)
    if !isa(x, Expr)
        x
    elseif isexpr(x, :call) &&    #
        x.args[1] == :(|>) &&     # check for `expr |> fn`
        length(x.args) == 3 &&    # ==> (|>)(expr, fn)
        _ispossiblefn(x.args[3])  #

        f = _compose(x.args[3])
        arg = _compose(x.args[2])
        if isa(f, Symbol)
            Expr(:call, f, arg) 
        else
            insert!(f.args, 2, arg)
            f
        end
    else
        Expr(x.head, [_compose(y) for y in x.args]...)
    end
end

macro compose(x)
    _compose(x)
end

julia> macroexpand(:(<strong i="11">@compose</strong> x |> f |> g(1) |> h('a',"B",d |> c(fred |> names))))
:(h(g(f(x),1),'a',"B",c(d,names(fred))))

この|>構文を使用する場合は、現在よりも便利にするために、私は確かにすべてです。 関数を左ではなく右に適用できるようにするためだけに使用することは、常に構文の膨大な浪費のように思われていました。

+1。 一般的にデータ変換パイプラインがあるデータ分析にJuliaを使用している場合は、特に重要です。 特に、PythonのPandasは、df.groupby（ "something"）。aggregate（sum）.std（）。reset_index（）のようなものを記述できるため、便利です。これは、現在の|>構文で記述するのは悪夢です。 。

：+1：これのために。

（これには..中置演算子（ obj..move(4,5)..scale(10)..display ）の使用を提案することをすでに考えていましたが、演算子|>もいいでしょう）

別の可能性は、カリー化のためのシンタックスシュガーを追加することです。
f(a,~,b)はx->f(a,x,b)変換されます。 そうすれば、 |>は現在の意味を維持できます。

ああ、それはどんな式も関数に変えるための本当に素晴らしい方法だろう。

おそらく、Clojureの無名関数リテラルのようなもので、 #(% + 5)はx -> x + 5省略形です。 これは、％1、％2などの複数の引数にも一般化されるため、 #(myfunc(2, %1, 5, %2)はx, y -> myfunc(2, x, 5, y)省略形です。

審美的には、構文が他の点では非常に読みやすいジュリアにうまく適合するとは思いませんが、一般的な考え方は気に入っています。

上記の私の例を使用するには（そして％の代わりに@malmaudのチルダに切り替える）、次のことができます

some_obj |> move(~, 4, 5) |> scale(~, 10) |> display

これはかなり見栄えがします。

これは、最初の引数に特別な扱いを与えないという点で優れています。 欠点は、この方法でシンボルを使用していることです。

おそらく、これはマクロを使用できる別の場所であるため、置換はマクロのコンテキスト内でのみ発生します。

~はすでにJuliaの標準機能であるため、これを行うことはできません。 Scalaはこれを_で行いますが、これも可能ですが、式のどの部分が無名関数であるかを理解することには重大な問題があります。 例えば：

map(f(_,a), v)

これはどちらを意味しますか？

map(f(x->x,a), v)
map(x->f(x,a), v)
x->map(f(x,a), v)

それらはすべて有効な解釈です。 Scalaは関数の型シグネチャを使用してこれを決定していることを思い出しているようです。これは、すべての型を知らなければScalaを実際に解析できないことを意味するため、残念なことに思います。 私たちはそれをしたくありません（そして私たちが望んでいたとしてもできませんでした）ので、どの意味が意図されているかを決定するための純粋な構文規則がなければなりません。

そうです、どこまで出かけるかという曖昧さについてのあなたの指摘がわかります。 Clojureでは、式全体が#(...)ラップされているため、明確です。

ジュリアでは、_をドントケア値として使用するのは慣用的ですか？ somefuncが2つの値を返し、最初の値だけが必要な場合は、 x, _ = somfunc()ようになりますか？

これを解決するには、補間のような使用法のマクロが必要だと思います。

some_obj |> @$(move($, 4, 5)) |> @$(scale($, 10)) |> display

しかし、繰り返しになりますが、その時点でかなりノイズが増えていると思います。 @$(move($, 4, 5))は、既存の構文x -> move(x, 4, 5)に勝るものはないと思います。これは、IMOがより美しく、より明確です。

これは中置マクロの良いアプリケーションになると思います。 ＃4498と同様に、マクロにも適用されるインフィックスとして関数を定義するルールがある場合、スレッド化動作を行う@->または@|>マクロを作成できます。

ええ、私は中置マクロのアイデアが好きですが、インプレースマクロのシステム全体を用意する代わりに、この用途のために新しい演算子を導入することもできます。 例えば、
some_obj ||> move($,4,5) ||> scale($, 10) |> disp
または、 |>保持するだけで、次のようなルールがあります。
x |> f暗黙的にx |> f($)変換されます：
some_obj |> scale($,10) |> disp

皆さん、それはすべて本当に醜いように見えます：|> ||>など。
これまでのところ、Juliaの構文が非常に明確であるため、上記で説明したこれらのことは、他のものと比較した場合、それほどきれいに見えないことがわかりました。

Scalaではおそらく最悪のことです-::、：、<<、>> + ::などの演算子がたくさんあります-それはコードを醜くし、数ヶ月の使用経験がないと読めなくなります言語。

アントン、提案が気に入らないと聞いて申し訳ありません。 別の提案をしていただければ助かります。

申し訳ありませんが、私は不親切になろうとはしていません。 そしてそうです-提案のない批評家
役に立たない。

残念ながら、私は言語を構築する科学者ではないので、
何を提案するかを知っている...まあ、オプションで所有するメソッドを作成することを除いて
一部の言語のオブジェクト。

「科学者が言語を構築する」というフレーズが好きです。Matlabにうんざりしている数値プログラマーよりもはるかに壮大に聞こえます。

ほとんどすべての言語には、オブジェクト指向言語で.を繰り返し適用するか、より機能的な言語（Haskell、Scala、Mathematicaなど）でその目的のためだけに特別な構文を適用することによって、関数をチェーンする方法があると思います。 後者の言語にも無名関数の引数用の特別な構文がありますが、Juliaが実際にそこに行くとは思いません。

スペンサーの提案のサポートを繰り返します- x |> f(a)はf(x, a)に変換されます。これは、 doブロックの動作と非常によく似ています（そして、の最初の引数が関数は、糖衣構文の目的でJuliaで特権が与えられます）。 x |> fは、 x |> f()省略形と見なされます。 シンプルで、新しい演算子を導入せず、関数チェーンが必要なケースの大部分を処理し、下位互換性があり、既存のJulia設計原則に適合します。

また、これがここでの最良の提案だと思います。主な問題は、I / Oリダイレクトやその他のカスタム目的で|>を定義できないように見えることです。

.は特別な関数チェーン構文ではありませんが、左側の関数が変更したばかりのオブジェクトを返す場合は、そのように機能します。これは、ライブラリ開発者が意図的に行う必要があることです。

同様に、Juliaでは、ライブラリ開発者は、ここで説明するように、N-1引数が与えられたときに1引数の関数を返すように、N引数の関数を定義することにより、 |>チェーンをすでにサポートできます。

ただし、関数で可変数の引数をサポートする必要がある場合は、問題が発生するように思われるため、引数の詰め込みを実行できる演算子があると便利です。

@JeffBezanson 、中置マクロを実行する方法があれば、この演算子を実装できるようです。 それに関するイデオロギーの問題があるのか​​、それとも単に実装されていないのか知っていますか？

最近、 ~は特殊なケースになっているため、引数を引用して呼び出します
デフォルトでは、マクロ@~ 。 |>に同じことをさせることができます。

もちろん、数か月以内に、誰かが同じことをするために<|を要求するでしょう...

2014年2月6日（木曜日）には、スペンサー・ラッセル[email protected]
書きました：

ただ注意してください、。 特別な関数チェーン構文ではありませんが、発生します
左側の関数がオブジェクトを返す場合、そのように機能します。
変更されました。これは、ライブラリ開発者がしなければならないことです。
意図的に。

同様に、Juliaでは、ライブラリ開発者はすでにチェーンをサポートできます
|>を使用して、N個の引数の関数を定義して関数を返します
前述のようにN-1引数が、与えられた1つの引数の//github.com/JuliaLang/julia/issues/5571#issuecomment：herehttpsを-33408448

関数でサポートしたい場合は、問題が発生するようです。
ただし、引数の数は可変であるため、実行できる演算子があります
引数の詰め込みがいいでしょう。

@JeffBezanson https://github.com/JeffBezanson 、これは
中置マクロを実行する方法があれば、演算子を実装できます。 あなたは
それに関するイデオロギーの問題があるのか​​、それとも単に実装されていないのかを知っていますか？

—
このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/5571#issuecomment-34374347で表示してください
。

そうです、これを特別なケースにしたくはありません。 APIデザインでそれを処理することは実際にはそれほど悪くはなく、明確にするための型アノテーションがある場合は、変数引数の制限でさえそれほど問題にはなりません。

function move(obj::MyType, x, y, args...)
    # do stuff
    obj
end

move(args...) = obj::MyType -> move(obj, args...)

この動作は、2番目の宣言を処理する@composableマクロで処理できると思います。

中置マクロのアイデアは、＃4498で説明されている中置関数の宣言と統合される状況で私にとって魅力的です。

Juliaの作成者が、オブジェクトに独自のメソッドを含めることを許可しないことに反対しているのはなぜですか？ その決定についてどこでもっと読むことができますか？ その決定の背後にある考えと理論はどれですか？

@meglioは、一般的な質問に役立つ場所は、メーリングリストまたはStackOverflow julia-langタグです。 このトピックに関する以前の議論については、 Stefanの講演とユーザーおよび開発者リストのアーカイブを参照してください。

ただチャイムを鳴らして、私にとって最も直感的なことは、いくつかのプレースホルダーを
clojureのas->マクロと同様に、作成しようとしているもののシーケンス内の前の式の値。 したがって、この：

<strong i="8">@as</strong> _ begin
    3+3
    f(_,y)
    g(_) * h(_,z)
end

次のように展開されます：

g(f(3+3,y)) * h(f(3+3,y),z)

前の行の「ドロップダウン」という表現は、次の行の下線の穴を埋めるために考えることができます。

私は、決勝週の先延ばしの試合で、この前四半期のような小さなものをスケッチた。

|>を使用してワンライナーバージョンをサポートすることもできます：

<strong i="19">@as</strong> _ 3+3 |> f(_,y) |> g(_) * h(_,z)

@porterjamesj 、私はそのアイデアが好きです！

同意する; それはかなりいいです、そして魅力的な一般性を持っています。
2014年2月7日15:19、「KevinSquire」 [email protected]は次のように書いています。

@porterjamesj https://github.com/porterjamesj 、私はそのアイデアが好きです！

このメールに直接返信するか、Gi tHubhttps：//github.com/JuliaLang/julia/issues/5571#issuecomment-34497703で表示してください
。

@porterjamesjのアイデアが好きなのは、それが新鮮な空気の息吹であるだけでなく、以前のアイデアよりもはるかに柔軟に見えるからです。 私たちは最初の引数を使用するだけではなく、中間変数を自由に選択できます。これも、言語に新しい構文や特殊なケースを追加することなく、今すぐ実装できるもののようです。

Juliaでは、 obj.method(args...)パターンをあまり実行せず、代わりにmethod(obj, args...)パターンを実行するため、エクスプレス用に操作するオブジェクトを返すメソッドがない傾向があることに注意してください。メソッドチェーンの目的。 （これはjQueryが行うことであり、JavaScriptでは素晴らしいです）。 したがって、ここでの入力はそれほど節約できませんが、関数間に「パイプ」を設定するために、これは本当に素晴らしいと思います。

clojureの->と->>は上記の特殊なケースであり、かなり一般的であるため、これらも非常に簡単に実装できます。 それらを何と呼ぶか​​という問題は少し注意が必要ですが。 たぶん@threadfirstと@threadlast ？

これがマクロであるという考えも好きです。

例に続く拡張が次のようなものである場合、それは良いことではありませんか

tmp = 3+3; tmp = f(tmp); return h(tmp, z)

同じ操作への複数の呼び出しを回避するには？ （多分それは@porterjamesjのアイデアにすでに暗黙のうちに

別の提案：マクロがショートカットfをf(_) 、 f(y)をf(_,y)でしょうか？ 多分多すぎるかもしれませんが、必要な場合にのみプレースホルダーを使用するオプションがあると思います...（ただし、ショートカットは、 g(_) * h(_,z)ような式ではなく、単独の関数呼び出しでのみ許可する必要があります上記の

@cdsousa複数の呼び出しを回避することについてのポイントは良いものです。 clojureの実装では、シーケンシャルletバインディングを使用してこれを実現しています。 letのパフォーマンスについて十分に理解していないため、これを回避できるかどうかはわかりません。

では、 @asマクロは、改行と=>を分割点として使用して、置換式と置換されるものを決定しますか？

letパフォーマンスは良好です。 今では、可能な場合は変数の割り当てと同じくらい速く、そうでない場合はかなり速くすることができます。

私のおもちゃの実装の@ssfrrは、パーサーが挿入するすべての改行関連ノードをフィルターで除外し（NB、私はこれらすべてを本当に理解していません。マニュアルにそれらに関するドキュメントがあるとよいでしょう）、置換を減​​らします残っている式のリストの上。 私は思うが、letを使用する方が良いでしょう。

@cdsousa ：

別の提案：マクロがショートカットfをf(_) 、 f(y)をf(_,y)

fからf(_)は私には理にかなっています。 第二に、私は、場所を明示的に指定する方が良いと思います。なぜなら、合理的な人々は、 f(_,y)またはf(y,_)どちらかがより自然であると主張する可能性があるからです。

clojureの->と->>は上記の特殊なケースであり、かなり一般的であるため、これらも非常に簡単に実装できます。 それらを何と呼ぶか​​という問題は少し注意が必要ですが。 多分@threadfirstと@threadlast ？

f(_,y...)またはf(y..., _)使用して場所を明示的に指定すると、コードが非常に理解しやすくなると思います。 Clojureでは追加の構文（および演算子）は意味がありますが、実際に使用できる追加の演算子はありません。追加のマクロを使用すると、通常、コードがわかりにくくなると思います。

では、 @asマクロは、改行と=>を分割点として使用して、置換式と置換されるものを決定しますか？

|>はすでにパイプライン処理に使用されているため、分割点として使用する方が自然だと思います。

ご存知のとおり、 Lazy.jlにはスレッドマクロの実装があります。これにより、次のように記述できます。

@>> range() map(x->x^2) filter(iseven)

プラス面としては、言語を変更する必要はありませんが、複数行を使用する場合は少し見苦しくなります。

興味があれば、Lazy.jlに@as>を実装することもできます。 Lazy.jlに@asマクロも追加されました。

Monads.jlを使用して（Haskellのような構文を使用して）このようなことを行うこともできます（注：現在のJulia構文を使用するには更新する必要があります）。 しかし、引数スレッド専用の専用バージョンは、一般的なアプローチのパフォーマンスの落とし穴を回避できるはずだと思います。

Lazy.jlはとても素敵なパッケージのように見え、積極的にメンテナンスされています。 これがBaseにある必要がある説得力のある理由はありますか？

関数チェーンは、複数の値を返す関数でどのように機能しますか？
連鎖の結果はどうなるでしょうか。例：

function foo(a,b)
    a+b, a*b   # x,y respectively
end

とbar(x,z,y) = x * z - yは？

bar(_1,z,_2)ような構文は必要ありませんか？

別の例で投げる：

data = [2.255, 3.755, 6.888, 7.999, 9.001]

きれいな書き方： log(sum(round(data)))はdata|>round|>sum|>log
しかし、基数2の対数を実行し、小数点以下3桁に丸めたい場合は、
次に：最初の形式のみを使用できます：
log(2,sum(round(data,3)))

しかし、理想的には、次のことができるようにしたいと考えています。
data|>round(_,3)|>sum|>log(2,_)
（または類似）

私はそれがどのように機能するかを提案するためのプロトタイプを作成しました。
https://github.com/oxinabox/Pipe.jl

@gregidのポイントは解決しませんが、現在取り組んでいます。
また、引数を拡張する必要性も処理しません

これは@ one-more-minuteのLazy.jlスレッドマクロに似ていますが、読みやすさ（個人的な好み）のために|>記号を保持しています。

ゆっくりとパッケージにします、おそらくある時点で

もう1つのオプションは次のとおりです。

data |>   x -> round(x,2)  |> sum |>  x -> log(2,x)

log(2,sum(round(data,2)))より長いですが、この表記は読みやすさを向上させる場合があります。

悪くない@shashi 、それを考えていなかった、
一般的に冗長すぎて読みにくいと思います

https://github.com/oxinabox/Pipe.jl@gregidの問題を解決するようになりました。
_[1] 、 _[2]両方を要求すると、置換に対して複数の呼び出しを行うことでこれを実行します。
私が確信していないのは、最も望ましい行動です。

部外者として、パイプラインオペレーターは、F＃による処理を採用することでメリットが得られると思います。
確かに、F＃にはカリー化がありますが、それを必要としないように、バックエンドでいくつかの魔法を実行できる可能性があります。 同様に、演算子の実装では、コア言語ではありません。

これにより、 [1:10] |> map(e -> e^2)は[1, 4, 9, 16, 25, 36, 49, 64, 81, 100]ます。

振り返ってみると、 @ ssfrrはこれをほのめかしましたが、例のobj引数は、私の例の2番目の引数として自動的にmap与えられるため、プログラマーは関数を次のように定義する必要がなくなります。それをサポートします。

それはどういう意味だと思いますか？

2015年6月5日には、17:22で、H-225 [email protected]は書きました：

部外者として、これを行うためのより良い方法の1つは、F＃による処理を適応させることだと思います。
確かに、F＃にはカリー化がありますが、それを必要としないように、バックエンドでいくつかの魔法を実行できる可能性があります。 同様に、演算子の実装では、コア言語ではありません。

これにより、[1:10] |> map（e-> e ^ 2）は[1、4、9、16、25、36、49、64、81、100]になります。

個人的には、冗長にならずにすてきでクリアだと思います。

明らかに、result = map（sqr、[1:10]）と書くことができますが、なぜパイプライン演算子があるのでしょうか。
おそらく私が欠けているものがありますか？

—
このメールに直接返信するか、GitHubで表示してください。

@StefanKarpinski
基本的に、オペレーターは次のように動作します。

• x |> y(f) = y(x, f)
• x |> y(f) = y(f, x)

おそらく、オペレーターで使用される関数が、上記のどちらがそのパターンとして選択されているかに応じて、最初または最後の引数として操作するデータを取得するインターフェイスパターンがあります。
したがって、例としてmap関数の場合、 mapはmap(func, data)またはmap(data, func)いずれかになります。

それはもっと明確ですか？

Lazy.jlはとても素敵なパッケージのように見え、積極的にメンテナンスされています。 これがBaseにある必要がある説得力のある理由はありますか？

これがここでの重要な質問だと思います。

これがベースで望ましい場合がある理由は2つあります。

1.）ジュリアンウェイであるとしてパイプライン化を奨励したい場合があります-より読みやすいという議論をすることができます
2.）Lazy.jl、FunctionalData.jl、および私自身のPipe.jlのようなものは、それが作用する式をラップするためにマクロを必要とします-それはそれを読みにくくします。

答えは、中置マクロを持つことにあると思います。
そして|>をそのように定義します。

|>（またはそのいとこであるdoブロック）がコアに属しているかどうかはわかりません。
しかし、パーサーの外部でそれらを定義するためのツールは存在しません。

そのようなパイプライン構文を持つ機能は非常に優れているようです。 Lazy.j、FunctionalData.jl、Pipe.jlが使用できるBase、つまりx |> y(f) = y(f, x)部分に追加できますか？ ：+1：

パッケージ内でこれのさまざまな実装を使用するコードを調べたところ、個人的には判読できず、非常に非ジュリアンであることがわかりました。 左から右へのパイプラインの駄洒落は読みやすさを助けません。関数の評価に括弧を使用する完全に通常のコードの残りの部分から後方にコードを目立たせるだけです。 どちらかのスタイルで記述されたコードが、もう一方のスタイルで記述されたコードに比べて裏返しに見える2つの異なるスタイルにつながる構文はお勧めしません。 すでに持っている完全に優れた構文に落ち着いて、物事をより均一に見せることを奨励してみませんか？

@tkelman
個人的に、私はそれをやや実用的な観点から見ています。
確かに、単純なことをしている場合は必要ありませんが、関数を書いている場合は、かなり複雑なことや、かなり複雑なことをします（頭から離れて：データ操作など）、それがパイプライン構文が優れているところだと思います。

私はあなたが何を意味するのか理解しています。 すべてに対して1つの関数呼び出し構文がある場合は、より均一になります。 個人的には、わかりやすい[複雑な]コードを書きやすくしたほうがいいと思います。 確かに、構文とその意味を学ぶ必要がありますが、私見では、 |>は、関数の呼び出し方法よりも理解するのが難しいことではありません。

@tkelman別の観点から見てみます。 明らかに、そのスタイルのプログラミングを好む人がいます。 Baseへのソースコードに一貫したスタイルが必要な場合もあると思いますが、これは、Juliaアプリケーションのプログラミングの好みのスタイルにパーサーサポートを追加することだけです。 ジュリアンは本当に他の人が有益だと思う何かを口述したり、さもなければ抑圧したりしたいですか？
Unixではパイプライン処理が非常に便利であることがわかったので、その言語でそれを有効にするプログラミング言語を使用したことはありませんが、少なくとも疑いの余地はあります。

関数パイピング演算子として|>がありますが、現在の実行方法には実装上の制限があり、現時点ではかなり遅くなっています。

配管は、すべてがテキストを取り込み、テキストを取り出すUNIXシェルで最適です。 より複雑なタイプと複数の入力と出力があるため、それほど明確ではありません。 したがって、2つの構文がありますが、MIMOの場合、1つはあまり意味がありません。 強力なマクロがあるため、通常、代替スタイルのプログラミングやDSLのパーサーサポートは必要ありません。

OK、ありがとう、私は@oxinaboxのコメントで行きました：

しかし、パーサーの外部でそれらを定義するためのツールは存在しません。

あなたが言及した実装上の制限を取り除くために何が行われるかは理解されていますか？

以前の提案のいくつかは、 |>引数を関数ではなくマクロとして解析させることで、実装できる可能性があります。 |>の以前のコマンドオブジェクトパイピングの意味は非推奨になっているため、これは実際には別のことをするために解放される可能性があります。0.5-devになります。

ただし、この選択は、 ~の特別な解析をかなり思い出させます。これは、他の場所で述べた理由により、間違いだと感じています。

構文解析〜は非常識です、それは基本的な機能です。 _ 、 _1 、 _2 、_もっと_合理的に見えます（特に、これらの変数がスコープ内の他の場所で定義されている場合はレイズする場合）。 それでも、より効率的な匿名関数ができるまで、これは機能しないようです...

|>引数を関数ではなくマクロとして解析することで実装されます

あなたがそれをしない限り！

構文解析〜は非常識です、それはベースの関数です

これは、ビット単位バージョンの単項演算子です。 中置バイナリ~はマクロとして解析されます。参照

@tkelman

したがって、2つの構文がありますが、MIMOの場合、1つはあまり意味がありません。

3構文。 やや。
パイプイン、通常の関数呼び出し、およびDoブロック。
マクロも異なる規則を使用するため、4でも議論の余地があります。

私のために、
Readorder（つまり、左から右）==アプリケーションの順序により、SISO関数チェーンの場合がはるかに明確になります。

私は（iterators.jlとpipe.jlを使用して）のような多くのコードを実行します：

• loaddata(filename) |> filter(s-> 2<=length(s)<=15, _) |> take!(150,_) |> map(eval_embedding, _)
• results |> get_error_rate(desired_results, _) |> round(_,2)

SISOの場合は、（私の個人的な好みでは）優れていますが、MIMOの場合はそうではありません。

ジュリアは、物事を行うための複数の正しい方法があることにすでに落ち着いているようです。
100％確信が持てないのは良いことです。

私が言ったように、Pipe andDoブロックをメイン言語から移動したいと思います。

Do-blockには非常に役立つユースケースがたくさんありますが、最初の入力を関数として使用する必要があり、多重ディスパッチの哲学に常に完全に適合するとは限りません（パンダ/もそうではありません）。接尾辞data.map(f).sum()付いたDスタイルのUFCS、人気があることは知っていますが、複数のディスパッチと効果的に組み合わせることができるとは思いません）。

パイピングはおそらくすぐに非推奨になり、Pipe.jlのようなDSLで使用するパッケージに任せることができます。

ジュリアは、物事を行うための複数の正しい方法があることにすでに落ち着いているようです。
100％確信が持てないのは良いことです。

これは、コミュニティ全体のスタイルガイドを厳密に実施できるかどうかという問題に関連しています。 これまでのところ、ここではあまり行っていませんが、長期的なパッケージの相互運用性、一貫性、および読みやすさのために、コミュニティが成長するにつれて、これはますます重要になると思います。 あなたがあなたのコードを読む唯一の人であるなら、気を抜いて、あなたがやりたいことを何でもしてください。 そうでない場合でも、均一性のために、（あなた自身の意見では）読みやすさをわずかに悪化させることには価値があります。

@tkelman @oxinabox
言語、または実際に「コア」パッケージに含めるべきではない明確な理由をまだ見つけていません。 [例：ベース]
個人的には、 |>をマクロにすることが答えかもしれないと思います。
おそらくこれのようなものですか？ （私はマスタージュリアプログラマーではありません！）

macro (|>) (x, y::Union(Symbol, Expr))
    if isa(y, Symbol)
        y = Expr(:call, y) # assumes y is callable
    end
    push!(y.args, x)
    return eval(y)
end

Julia v0.3.9では、2回定義できませんでした。1回は記号で、もう1回は式で定義しました。 Unionについての私の[限定的な]理解は、それを使用することでパフォーマンスが低下するということです。したがって、おもちゃのサンプルコードで修正する必要があると思います。

もちろん、これには使用構文に問題があります。
例えば、同等の実行にlog(2, 10) 、次のように記述する必要が@|> 10 log(2)ここでは望ましくないとすると、。
私の理解では、関数/マクロをいわば「固定不可能」としてマークして、次のように記述できるようにする必要があります： 10 |> log(2) 。 （間違っている場合は修正してください！）
不自然な例、私は知っています。 今はいいものが思いつかない！ =）

私の例でカバーしていない1つの領域を指摘することも価値があります...
だから例：

julia> for e in ([1:10], [11:20] |> zip) println(e) end
(1,11)
(2,12)
(3,13)
(4,14)
(5,15)
(6,16)
(7,17)
(8,18)
(9,19)
(10,20)

繰り返しますが、不自然な例ですが、うまくいけば、あなたはポイントを得ることができます！
私は少しいじりましたが、これを書いている時点では、それを実装する方法を自分で理解することができませんでした。

https://github.com/JuliaLang/julia/issues/554#issuecomment -110091527および＃11608を参照して

2015年6月9日には、午前9時37分PMで、H-225 [email protected]は書きました：

言語に含めるべきではない明確な理由をまだ見つけていません

これはプログラミング言語設計にとって間違った精神的スタンスです。 質問は「なぜ？」でなければなりません。 「どうして？」ではなくすべての機能には、それを含めるための説得力のある理由が必要です。正当な理由があっても、何かを追加する前に、じっくり考えてください。 あなたはそれなしで生きることができますか？ 同じことを達成するための別の方法はありますか？ 既存の機能に対してより良く、より一般的またはより直交する機能の異なるバリエーションはありますか？ この特定のアイデアが実現できなかったと言っているわけではありませんが、「なぜそうしないのか」よりもはるかに優れた正当化が必要です。 通常の構文よりも優れていないいくつかの例があります。

質問は「なぜ？」でなければなりません。 「どうして？」ではなく

+ 1_000_000

確かに。
このかなりよく知られているブログ投稿を参照してください：
すべての機能は-100ポイントから始まります。
言語に追加する価値があるためには、大きな改善を行う必要があります。

FWIW、Pyret（http://www.pyret.org/）は、数か月前にこの正確な議論を行いました。 この言語は、元々人々が|>提案しているのと同じように機能する「砲弾」表記をサポートしています。 ピレットでは、

[list: 1, 2, 3, 5] ^ map(add-one) ^ filter(is-prime) ^ sum() ^ ...

そのため、砲弾の表記は、関数に引数を追加するように脱糖されました。

この構文があまりにも紛らわしいと彼らが判断するまで、それほど時間はかかりませんでした。 sum()が引数なしで呼び出されるのはなぜですか？ 最終的に、彼らはエレガントなカリー化の代替品を選びました。

[list: 1, 2, 3, 5] ^ map(_, add-one) ^ filter(_, is-prime) ^ sum() ^ ...

これには、より明示的であるという利点があり、 ^演算子を単純な関数に単純化します。

はい、それは私にははるかに合理的なようです。 また、カリー化よりも柔軟性があります。

@StefanKarpinski私は少し混乱しています。 チェーン（カリー化ではない）よりも柔軟だと言うつもりでしたか？ 結局のところ、Pyretの解決策は、チェーンよりも一般的なカリー化を使用することでした。

たぶん、 |>構文を少し変更すると（実装がどれほど難しいかは本当にわかりません。 |や>と競合するかもしれません）、柔軟で読みやすいものを設定できます。

次のようなものを定義する

foo(x,y) = (y,x)
bar(x,y) = x*y

私たちは持っているでしょう：

randint(10) |_> log(_,2) |> sum 

(1,2) |_,x>  foo(_,x)   |x,_>   bar(_,2) |_> round(_, 2) |> sum |_> log(_, 2)

言い換えると、 |a,b,c,d>ような演算子があり、 a 、 b 、 c 、 dはの戻り値を取得します。最後の式（順番に）を次の式内のプレースホルダーで使用します。

|>内に変数がない場合は、現在のように機能します。 新しいスターダードを設定することもできます。 f(x) |> g(_, 1)は、 f(x)によって返されるすべての値を取得し、 _プレースホルダーに関連付けます。

@samuela 、つまり、カリー化では末尾の引数しか省略できないのに対し、 _アプローチでは、引数を省略して無名関数を取得できます。 つまり、カリー化でf(x,y)を指定すると、 f(x)を実行して、 y -> f(x,y)する関数を取得できますが、アンダースコアを使用すると、同じことに対してf(x,_)を実行できます。 f(_,y)を実行してx -> f(x,y)を取得します。

私はアンダースコア構文が好きですが、それが「キャプチャする」周囲の表現の量の質問に対する提案された回答にはまだ満足していません。

関数が複数の結果を返す場合はどうしますか？ タプルを_位置に渡す必要がありますか？ または、その場で分割する構文があるでしょうか？ ばかげた質問かもしれませんが、もしそうなら、ご容赦ください！

@StefanKarpinskiああ、私はあなたが何を意味するのかわかります。 同意しました。

@ScottPJonesの明白な答えは、ASCIIアート矢印を許可することです。
http://scrambledeggsontoast.github.io/2014/09/28/needle-announce/

@simonbyrneこれは、私がミススペントの青春時代に行ったように、パンチカードで

@simonbyrneそれは素晴らしいです。 これを文字列マクロとして実装すると、すばらしいGSoCプロジェクトになります。

sum（）が引数なしで呼び出されるのはなぜですか？

暗黙の引数もdo表記についてより混乱するもののひとつだと思うので、同じ規則をそれにも利用できればいいのですが（私はそれがはるかに難しいことを理解していますが、すでに言語に組み込まれているため）。

@simonbyrneあなたはそれが明白な方法で行われることができるとは思わないのですか？ もしそうなら、それをより論理的で、より一般的で、連鎖と一貫性のあるものにすることができれば、それは壊す価値があると私は思います（現在のdo表記）。

@simonbyrneええ、私は完全に同意します。 現在のdo表記の動機は理解していますが、構文体操を正当化するものではないと強く感じています。

map（f、_）とmap（f）だけに関する@samuela 。 いくつかの魔法の脱糖が混乱を招くことに同意しますが、map（f）は存在すべきものだと思います。 それは必要ではなく、砂糖はマッピングするための簡単な方法を追加するだけです。
例えば

map(f::Base.Callable) = function(x::Any...) map(f,x...) end

つまり、mapは関数を受け取り、（多かれ少なかれ）反復可能なもので機能する関数を返します。

より一般的には、 |>常にデータを最初の引数（または同様のもの）にマップするというある種の規則ではなく、追加の「便利な」メソッドを持つ関数に傾倒する必要があると思います。

同じように、

type Underscore end
_ = Underscore()

また、関数には、特定の引数でアンダースコアを使用し、より少ない引数を使用する関数を返すメソッドを含める必要がある、または含めることができるという一般的な規則があります。 n個の引数を取る関数ごとに2 ^ n個のメソッドを追加する必要があるため、これが良い考えであるとはあまり確信していません。 しかし、それは1つのアプローチです。 それほど多くのメソッドを明示的に追加する必要はなく、メソッドルックアップにフックして、引数がアンダースコア型の場合に適切な関数が返されるようにすることは可能でしょうか。

とにかく、呼び出し可能オブジェクトを取得して呼び出し可能オブジェクトを返すだけのバージョンのマップとフィルターを使用することは理にかなっていると思います。アンダースコアを使用すると、機能する場合と機能しない場合があります。

@patrickthebold
x |> map(f, _) => x |> map(f, Underscore()) => x |> map(f, x)は、あなたが提案しているように、 map(f, _)を実装する最も簡単な方法だと思いますよね？ - _を、プログラムする特別なエンティティにしますか？

ただし、自分でプログラムするよりも、Juliaが自動的に推測するよりも（おそらく|>構文を使用して）それが良いかどうかはわかりません。

また、 map提案については、ちょっと気に入っています。 確かに、現在の|> 、これは非常に便利です。 ただし、代わりにx |> map(f, _) => x |> map(f, x)自動推論を実装する方が簡単だと思いますか？

@StefanKarpinski理にかなっています。 そんなことは考えていませんでした。

私が言ったことは、決して|>に結びつくことはありません。 _に関して私が意味したのは、たとえば、 <メソッドを追加することです。

<(_::Underscore, x) = function(z) z < x end
<(x, _::Underscore) = function(z) x < z end

しかし、適切なメソッドを自動的に追加する方法がない限り、これは苦痛だと思います。

繰り返しになりますが、下線が付いているのは、上記のようにマップに便利なメソッドを追加することとは別です。 何らかの形で両方が存在するはずだと思います。

@patricktheboldアンダースコアなどのユーザー定義型を使用したこのようなアプローチは、関数を実装するときにプログラマーに重大で不必要な負担をかけます。 すべての2 ^ nをリストする必要があります

f(_, x, y) = ...
f(x, _, y) = ...
f(_, _, y) = ...
...

エレガントではないことは言うまでもなく、非常に迷惑になるでしょう。

また、 mapを使用した提案では、 mapやfilterなどの基本的な関数を使用して、 map(f)回避策の構文を提供すると思いますが、一般的には同じ問題が発生します。手動のアンダースコアアプローチとしての複雑さの問題。 たとえば、 func_that_has_a_lot_of_args(a, b, c, d, e)場合、考えられる各「カリー化」を入力するという厳しいプロセスを経る必要があります。

func_that_has_a_lot_of_args(a, b, c, d, e) = ...
func_that_has_a_lot_of_args(b, c, d, e) = ...
func_that_has_a_lot_of_args(a, b, e) = ...
func_that_has_a_lot_of_args(b, d, e) = ...
func_that_has_a_lot_of_args(a, d) = ...
...

そして、たとえそうしたとしても、関数を呼び出すときに不条理な量のあいまいさに直面するでしょう： func_that_has_a_lot_of_args(x, y, z)は、 x=a,y=b,z=cまたはx=b,y=d,z=eなどの定義を参照していますか？ ジュリアは実行時型情報でそれらを識別しますが、ソースコードを読む素人プログラマーにとっては完全に不明確です。

アンダースコアカリー化を正しく行うための最良の方法は、単にそれを言語に組み込むことだと思います。 結局のところ、コンパイラーへの非常に簡単な変更になるでしょう。 関数適用にアンダースコアが表示されたら、それを引き出してラムダを作成します。 私は数週間前にこれの実装を検討し始めましたが、残念ながら、今後数週間でそれを実行するのに十分な空き時間がないと思います。 Juliaコンパイラに精通している人にとっては、物事が機能するのにおそらく午後しかかからないでしょう。

@samuela
「ラムダを作成するためにそれを引き出す」とはどういう意味かを明確にできますか？ - 私は興味がある。 私もそれがどのように実装されるのか疑問に思いました。

@patrickthebold
ああ、分かった。 おそらく、次のようなものを使用できます： filter(_ < 5, [1:10]) => [1:4] ？
個人的には、 filter(e -> e < 5, [1:10])方が読みやすいと思います。 より一貫性があります-隠された意味は少なくなりますが、私はあなたに認めますが、それはより簡潔です。

それが本当に輝いている例がない限り？

@samuela

また、mapを使用した提案では、mapやfilterなどの基本関数を使用してmap（f）の回避策の構文を提供すると思いますが、一般に、手動のアンダースコアアプローチと同じ複雑さの問題があります。

私はこれが一般的に行われることを示唆していませんでしたが、 mapとfilter 、そしておそらくそれが明白であると思われる他のいくつかの場所でのみ行われました。 私にとって、それはmapが機能する方法です。関数を取り込んで関数を返します。 （Haskellがやっていることは確かです。）

エレガントではないことは言うまでもなく、非常に迷惑になるでしょう。

私たちはそれに同意していると思います。 一部の引数がアンダースコア型であるメソッド呼び出しを処理するために、言語に何かを追加する方法があることを願っています。 さらに考えてみると、特殊文字が自動的にラムダに展開されるか、特殊タイプが自動的にラムダに展開されることになります。 どちらにしても強くは感じません。 私は両方のアプローチにプラスとマイナスを見ることができます。

@ H-225はい、アンダースコアは構文上の便宜です。 それがどれほど一般的かはわかりませんが、Scalaには確かにあります。 個人的には好きですが、それはそのスタイルのひとつに過ぎないと思います。

@ H-225ええと、この場合、説得力のある適切な例は関数チェーンだと思います。 書く代わりに

[1, 2, 3, 5]
  |> x -> map(addone, x)
  |> x -> filter(isprime, x)
  |> sum
  |> x -> 3 * x
  |> ...

簡単に書くことができます

[1, 2, 3, 5]
  |> map(addone, _)
  |> filter(isprime, _)
  |> sum
  |> 3 * _
  |> ...

私は無意識のうちにこのアンダースコア構文（またはいくつかのわずかな変形）をそれをサポートする言語で絶えず使用していて、それをサポートしない言語で作業するように移行するときにそれがどれほど役立つかを理解するだけです。

私の知る限り、現在、ジュリアでこの問題に対処しようとするライブラリ/アプローチは少なくとも3.5あります。ジュリアの組み込み|>関数、Pipe.jl、Lazy.jl、およびジュリアの組み込みdoの0.5です。精神的に似ている

@samuelaこのアイデアの実装を試してみたい場合は、FunctionalData.jlを試してみてください。例は次のようになります。

<strong i="7">@p</strong> map [1,2,3,4] addone | filter isprime | sum | times 3 _

最後の部分は、入力を2番目のパラメーターにパイプする方法を示しています（デフォルトは引数1です。この場合、 _は省略できます）。 フィードバックは大歓迎です！

編集：上記は単に次のように書き直されます：

times(3, sum(filter(map([1,2,3,4],addone), isprime)))

Base.mapとfilterの代わりにFunctionalData.mapとfilterを使用します。 主な違いは引数の順序であり、2番目の違いはインデックス付けの規則です（ドキュメントを参照）。 いずれの場合も、Base.mapは、引数の順序を逆にすることで簡単に使用できます。 @pは非常に単純な書き換えルールです（左から右に内側から外側になり、さらに単純なカリー化のサポート： <strong i="17">@p</strong> map data add 10 | showallは

showall(map(data, x->add(x,10)))

ハックは次のようなものを導入する可能性があります： //github.com/facebook/hhvm/issues/6455。 彼らはジュリアのテーブルから外れた$$を使用しています（ $はすでに過負荷になっています）。

FWIW、私はこれに対するハックのソリューションが本当に好きです。

私もそれが好きです。私の主な予約は、変数/スロットに_を使用する可能性のあるターサーラムダ表記がまだ好きであり、これらが競合しないことを確認することをお勧めします。

__使用できません_ -> sqrt(_) ？

確かに、できます。 その構文はすでに機能しています。矢印を必要としない構文に関するものなので、 map(_ + 2, v)の行に沿って何かを書くことができます。本当の問題は、周囲の式の_はに属します。

Mathematicaには匿名の引数のための同様のシステムがありませんか？ どのように
それらはそれらの引数の境界の範囲を処理しますか？
9：09 AMステファンKarpinskiで火、2015年11月3日には[email protected]
書きました：

確かに、できます。 その構文はすでに機能しています、それは構文に関するものです
矢印を必要としないので、線に沿って何かを書くことができます
map（_ + 2、v）の、本当の問題は周囲の量です
_が属する式。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/5571#issuecomment-153383422 。

https://reference.wolfram.com/language/tutorial/PureFunctions.html 、表示
＃記号は、私が考えていたものです。
2015年11月3日火曜日午前9時34分[email protected]は次のように書いています。

Mathematicaには匿名の引数のための同様のシステムがありませんか？ どのように
それらはそれらの引数の境界の範囲を処理しますか？
9：09 AMステファンKarpinskiで火、2015年11月3日には[email protected]
書きました：

確かに、できます。 その構文はすでに機能しています、それは構文に関するものです
矢印を必要としないので、線に沿って何かを書くことができます
map（_ + 2、v）の、本当の問題は周囲の量です
_が属する式。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/5571#issuecomment-153383422 。

Mathematicaは&を使って区切ります。

短いラムダ構文（任意の式を取り、無名関数を返す可能性があります）のような一般的なことを行うのではなく、受け入れ可能な式を関数呼び出しに限定し、受け入れ可能な変数/スロットをパラメーター全体に限定することで、区切り文字の問題を回避できます。 これにより、 OpenDylnのような非常にクリーンなマルチパラメータカリー化構文が得られます。 _はパラメーター全体を置き換えるため、構文は最小限で直感的で明確になります。 map(_ + 2, _)はx -> map(y -> y + 2, x)変換されます。 ラムダ化する必要のあるほとんどの非関数呼び出し式は、おそらく長く、 ->またはdo親しみやすいでしょう。 ユーザビリティと一般性のトレードオフはそれだけの価値があると思います。

@durcan 、それは有望に聞こえます–ルールについて少し詳しく説明していただけますか？ 最初の_がmapの引数内に留まり、2番目のmap式全体を消費するのはなぜですか？ 「受け入れ可能な式を関数呼び出しに制限する」とはどういう意味か、「受け入れ可能な変数/スロットをパラメーター全体に制限する」とはどういう意味かはわかりません...

わかりました。Dylanのドキュメントをいくつか読んだことで、ルールは理解できたと思いますが、 map(_ + 2, v)機能するのに、 map(2*_ + 2, v)は機能しないのではないかと考えなければなりません。

_ + 2 + _は(x,y) -> x + 2 + y _ + 2 + _を意味するのに対し、 _ ⊕ 2 ⊕ _は+と*ため、 + y -> (x -> x + 2) + yを意味するという非常に厄介なビジネスもあります。 *は、ペアワイズ連想演算ではなく、複数引数の関数呼び出しとして現在解析されている唯一の演算子です。 さて、この不整合は修正されるべきであると主張することができますが、それは_parser_がどの演算子が結合的でどれが結合的でないかについて意見を持つことを伴うように思われますが、それは悪いようです。 しかし、パーサーがa + b + cを単一の関数呼び出しとして解析するのか、ネストされた呼び出しとして解析するのかを知る必要があるスキームは、いくぶん疑わしいかもしれません。 おそらく、中置記法は特別に処理する必要がありますか？ しかし、いや、それも魚臭い感じがします。

はい、トレードオフにぶつかりました。 一方では、演算子の長い文字列は、現在の構文解析の選択肢のいくつかを考えると最も問題のある構文です（ただし、言語の現在のセマンティクスに応じて、言語機能のセマンティクスに誤りはありません）。 一方、関数呼び出しの長い文字列は、それが優れているところです。 たとえば、問題を次のように書き直すことができます。

2*_ |> 2+_ |> map(_, v)

とにかく、私は、中置の問題がクリーンな区切り文字のないオプションを持つことの邪魔になるべきではないと思います。 これは、当面の問題の一種であるほとんどの通常の関数呼び出しに本当に役立ちます。 必要に応じて、この特定のあいまいさを解決するのに役立つオプションの区切り文字を使用できます（ここでは、その役割のために&を盗んでいます）。

_ ⊕ 2 ⊕ _    # y -> (x -> x + 2) + y
_ ⊕ 2 ⊕ _ &  # (y , x) -> x + 2 + y

これは今のところ最高の提案ですが、私は完全に売られているわけではありません。 関数呼び出しが明示的である場合に何が起こっているかはかなり明確ですが、関数呼び出しが中置構文によって暗示されている場合はあまり明確ではありません。

私はこのアプローチを、短くて甘いラムダではなく、より柔軟で一般化されたカリー化と考えるのが好きです（それでも、オプションの区切り文字を使用すると、ほとんどすべての場所に到達できます）。 もっと完璧なものが欲しいのですが、シンボリックノイズ（この問題のアンチテーゼ）を追加しないと、そこに到達する方法がわかりません。

ええ、中置以外は好きです。 その部分は修正可能かもしれません。

まあ、中置位置でのカリー化は構文エラーである可能性があります。

map(+(*(2, _), 2), v)      # curry is OK syntax, but obviously not what you wanted
map(2*_ + 2, v)            # ERROR: syntax: infix curry requires delimitation
map(2*_ + 2 &, v)          # this means what we want
map(*(2,_) |> +(_,2), v)   # as would this

それは私が推測する警告かもしれません。

これをカリー化と呼ぶと、私は混乱して間違っていると思います。

確かに、これは部分関数アプリケーション（オプションで匿名で引数が指定されたラムダになる）に似ていると思います。 名前はさておき、何か考えはありますか？

私はこのようなものの線に沿って考えています：

• _が関数呼び出し式の引数のいずれかとして単独で表示される場合、その関数呼び出しは、関数が_引数を持つのと同じ数の引数をとる無名関数式に置き換えられます。 _引数が順番にラムダ引数に置き換えられた元の式。
• _が他の場所に表示される場合、矢印の優先順位レベルまでの周囲の式または周囲の括弧（角括弧や中括弧は除く）は、 _同じ数の引数をとる無名関数に置き換えられますこの式の_インスタンスが順番にラムダ引数に置き換えられています。

例：

• f(_, b) → x -> f(x, b)
• f(a, _) → x -> f(a, x)
• f(_, _) → (x, y) -> f(x, y)
• 2_^2 → x -> 2x^2
• 2_^_ → (x, y) -> 2x^y
• map(_ + 2, v) → map(x -> x + 2, v)
• map(2_ + 2, v) → map(x -> 2x + 2, v)
• map(abs, _) → x -> map(abs, x)
• map(2_ + 2, _) → x -> map(y -> 2y + 2, x)
• map(2_ - _, v, w) → map((x, y) -> 2x - y, v, w)
• map(2_ - _, v, _) → x -> map((y, z) -> 2y - z, v, x)
• map(2_ - _, _, _) → (x, y) -> map((z, w) -> 2z - w, x, y)
• _ → x -> x
• map(_, v) → x -> map(x, v)
• map((_), v) → map(x -> x, v)
• f = _ → f = x -> x
• f = 2_ → f = x -> 2x
• x -> x^_ → x -> y -> x^y
• _ && _ → (x, y) -> x && y
• !_ && _ → (x, y) -> !x && y

これが危険にさらされ始める唯一の場所は条件文です-それらの例はちょっと奇妙になります。

これはまだ少し厄介で無原則であり、コーナーケースがありますが、私はそれがどこかになりつつあります。

これは本当に悪い考えだと思います。他のプログラミング言語を使用したことがあれば、Juliaのほとんどすべての構文はかなりなじみがあります。 このようなシンタックスシュガーを見ている人は、2、3文字を節約することの「利点」に何が起こっているのかわかりません。

私を少し幸せにさせない例：

• 2v[_] → x -> 2v[x] （良い）
• 2f(_) → 2*(x -> f(x)) （あまり良くない）
• _ ? "true" : "false" → (x -> x) ? "true" : "false"
• _ ? _ : 0 → (x -> x) ? (y -> y) : 0

ここではもっと深いことが起こっていると思います-関数オブジェクトが_意味をなす_構文上の位置の概念があります-そしてあなたはそれらの最も近いものに拡張したいと思います。 関数オブジェクトを「欲しい」という古典的な位置は、別の関数への引数ですが、割り当ての右側は、関数オブジェクトを「欲しい」と言うことができる別の場所です（または、それが好むと言う方が正確かもしれません）関数を関数の本体にする）。

おそらく、しかし、do-block構文についても同じ議論がなされる可能性があります（そして、そうされました）。これは、全体として、非常に成功し、有用であると思います。 これは、ベクトル化の構文の改善と密接に関連しています。 また、これは前例のないことではありません。Scalaは同様の方法で_を使用し、Mathematicaは同様に#使用します。

私はあなたが_なじみのない_選択をすることもできると思います
基本的に、単一ディスパッチドット演算子の代わりに複数ディスパッチ
代名詞の引数に簡潔な構文を使用するという決定を強制します
人々が精通しているSVO注文を回復します。

12:09ステファンKarpinskiで火、2015年11月17日には[email protected]
書きました：

おそらく、しかし同じ議論がdo-blockについてなされた（そしてされた）
全体として、構文は非常に成功していて便利だと思います。
これは、ベクトル化の構文の改善と密接に関連しています。 それもそうではありません
その前例のない– Scalaは同様の方法で_を使用し、Mathematicaは＃を使用します
同様に。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/5571#issuecomment-157437223 。

これは、特にBoostの複数のライブラリソリューションを使用するC ++にも存在し、引数として_1, _2, _3します（例： _1(x, y...) = x 、 _2(x, y, z...) = yなど）。たとえば、 x -> fun(x)場合fun fun(_1)を呼び出します。 funは、ライブラリと明示的に互換性を持たせる必要があります（通常、マクロ呼び出しを介して、 fun 「ラムダ型」を受け入れさせます。 「パラメータとして）。

Juliaで利用できるこの簡潔なラムダ表記が本当に欲しいです。
2f(_)が2*(x -> f(x)) 2f(_)脱糖される問題に関して：「最初のルールが適用される場合、たとえばf(_)に適用される場合は、次のようにルールを変更することは理にかなっていますか？ f(_)が_の役割を果たすルールを再帰的に評価します。これにより、たとえばf(g(_)) → x -> f(g(x))可能になり、「括弧ルール」により簡単に次のことが可能になります。目的のレベルで停止します（例： f((g(_))) → f(x->g(x)) 。

これには、「簡潔なラムダ表記」という名前がとても好きです。 （カリー化よりもはるかに優れています）。

複数の引数のラムダを渡す場合は、 _1 、 _2 、 _3の明示性を本当に好みます。 一般に、同じスコープで変数名を再利用すると混乱することがよくあります...そして、_同じ式_で_をxとyにすることは、非常に混乱しているように見えます。

これと同じ簡潔なscala _ -syntaxが少し混乱を引き起こしていることがわかりました（ scalaでの_のすべての使用法を参照

その上、あなたはしばしばしたいです：

x -> f(x) + g(x)

または同様のものであり、以下が機能しなかった場合、私は驚かれると思います。

f(_) + g(_)

また、引数の順序を切り替えることもできます。

x, y -> f(y, x)
f(_2, _1)  # can't do with other suggested _ syntax

構文で明示的な匿名引数の番号付け（ _1 、 _2 、 _3 ...など）を許可するのは問題ないと思いますが、主な問題は依然として存在します：部分的に適用された関数を簡潔なラムダに正確に昇格させるのはいつですか？ そして、ラムダ本体とは正確には何ですか？ ある種の複雑なプロモーションルールを暗黙的に使用するのではなく、（区切り文字を使用して）明示的にすることでエラーが発生する可能性があります。 どうしたら良い

foo(_1, _1 + _2  + f(_1, v1) + g(_2, v3), _3 * _2, v2) + g(_4, v4) +
 f(_2, v2) + g(_3, v5) + bar(_1, v6)

正確に意味しますか？ 区切り文字を使用すると（ λを使用します）、状況はやや明確になります。

λ(foo(_1, λ(_1 + _2)  + λ(f(_1, v1) + g(_2, v3)), _3 * _2, v2) + g(_4, v4)) + 
λ(f(_2, v2) + g(_3, v5) + bar(_1, v6))

これは明らかにMethodError: + has no method matching +(::Function, ::Function)ですが、少なくとも私はそれが書かれている方法からそれを知ることができます。

@StefanKarpinskiは、式が取ることができる一見明白な構文上の位置がいくつかあり、それらが関数本体であることを強く示唆していると彼が言ったとき、何かに

これは間違いなく、簡潔さと一般性および読みやすさの間のトレードオフです。 もちろん、既存の->表記よりも簡潔なものを導入しても意味がありません。 しかし、区切り文字は価値があるようにも思えます。

簡潔ではないかもしれませんが、 _引数をキャプチャする->プレフィックスバージョンはどうでしょうか。 例えば

(-> 2f(_) + 1)

プレフィックス形式の優先順位はかなり低いはずです。 これにより、実際には、場合によっては括弧を省略できる場合があります。

map(->_ + 1, x)

現在、 https： //github.com/JuliaLang/julia/issues/5571#issuecomment-157424665の実装をいじってい

マクロとして、それは行内のそのようなすべての出現を変換します。
トリッキーな部分は、優先順位を実装することです。

私はおそらく次の12時間でそれを終えないでしょうそれはここでのホームタイムです
（多分次の24年に、しかし私は去らなければならないかもしれません）
とにかく、それが行われると、私たちはそれで遊ぶことができます。

https://github.com/JuliaLang/julia/issues/5571#issuecomment-157424665から出てくる奇妙なもの

• f(_,_) → x,y -> f(x,y) （これは妥当です）
• f(_,2_) →??
  
  
  
  • f(_,2_) → x,y -> f(x,2y) （リーズナブル）
  
  
  • f(_,2_) → x-> f(x,y->2y) （ルールが示唆していると思うものと私のプロトタイプが生成するもの）
  
  

しかし、私はそれが正しいかどうかわかりません。

これが私のプロトタイプです。
http://nbviewer.ipython.org/gist/oxinabox/50a1e17cfb232a7d1908

実際、それは間違いなくいくつかのテストに失敗します。

現在のASTレイヤーでブラケットを検討することはできません-それらはしばしば（常に？）すでに解決されています。

それでも遊ぶには十分だと思います

役に立つかもしれないRのmagrittrからのいくつかのルール：

チェーンが。で始まる場合。 、それは無名関数です：

. %>% `+`(1)

function（x）x +1と同じです

チェーンには2つのモードがあります。
1）最初の引数として挿入することによる連鎖、および表示されるドット。
2）表示されるドットのみにチェーンします。

デフォルトのモードはモード1です。ただし、チェーンされている関数の引数としてドットが単独で表示される場合、magrittrはチェーン内のそのステップでモード2に切り替わります。

そう

2 %>% `-`(1) 

は2-1です

そして

1 %>% `-`(2, . )

も2-1です

モード2は、角かっこで囲むことによって指定することもできます。

2 %>% { `-`(2, . - 1) }

2-（2-1）と同じになります。

また、モード1とモード2をスマートに切り替えることができれば、ジュリアが最初の位置に連鎖する可能性のある議論についてあまり一貫していないという問題をほぼ完全に解決できることに注意してください。 また、角かっこでコードのチャンクを評価できることに注意することも忘れました。 magrittrマニュアルの例を次に示します。

アイリス％>％
{{
n <-サンプル（1:10、サイズ= 1）
H <-head（。、n）
T <-tail（。、n）
rbind（H、T）
}％>％
概要

これは現時点では半分の形のアイデアにすぎませんが、Tupleコンストラクターを変更して、欠落した値が次の値を返すようにすることで、「簡潔なラムダ」と「ダミー変数」の問題を同時に解決できる方法があるのではないかと思います。タプルの代わりにタプルを返すラムダ？ したがって、 (_, 'b', _, 4)は(x, y) -> (x, 'b', y, 4)を返します。

次に、 foo(a, b) 「タプル(a, b) fooを適用する」を意味するように関数呼び出しのセマンティクスを微妙に変更する場合、または引数が関数の場合は、 foo適用します関数によって返されるタプルへのfoo(_, b, c)(1)はapply(foo, ((x) -> (x, b, c))(1))と同等になります。

これでも中置記法の問題は解決しないと思いますが、個人的には、括弧で囲まれた関数呼び出しでのみ機能する簡潔なラムダに満足しています。 結局のところ、どうしても必要な場合は、 1 + _をいつでも+(1, _)書き換えることができます。

@jballancただし、タプルの構築と関数適用は、まったく異なる2つの概念です。 少なくとも、ジュリアのセマンティクスの私の理解に深刻な欠陥がない限り。

@samuelaつまり、 foo(a, b)はfoo((a, b)...)と同等です。 つまり、関数への引数は、タプルが実際に構築されていない場合でも、概念的にタプルと見なすことができます。

@私はこの議論を

|> do 「魔法」を補完するものにするための投票をしたいと思います。 私が見る限り、それを行う最も簡単な方法は、それを意味させることです

3 |> foo == foo(3) # or foo() instead of just foo, but it would be nice if the parentheses were optional
3 |> foo(1) == foo(1, 3)
3 |> foo(1,2) == foo(1,2,3)

言い換えると、 a |> f(x)は_last_引数に対して、 f(x) do; a; endが_first_に対して行うことを行います。 これにより、すぐにmap 、 filter 、 all 、 anyと互換性があります。 また、 _パラメータのスコープの複雑さを追加せずに、既存のdo構文を考えると、コードの読者に不当な概念上の負担をかけることはないと思います。

このようなパイプ演算子を使用する主な動機は、コレクションパイプライン（＃15612を参照）です。これは非常に強力な構成であり、多くの言語で普及しつつあります（これは、人々が望んでいる機能であると同時に、彼らは理解するでしょう）。

これは、 https：//github.com/MikeInnes/Lazy.jlの@>>マクロです。

@malmaudニース！ 私はこれがすでに可能であることが好きです：D

ただし、これら2つのバリアント間の読みやすさの違いは非常に大きいです。

# from Lazy.jl
@> x g f(y, z)

# if this became a first-class feature of |>
x |> g |> f(y, z)

読みやすさの主な問題は、式の境界がどこにあるかを視覚的に示す手がかりがないことだと思います。 x gとg f(x,のスペースはコードの動作に大きく影響しますが、スペースはf(x, y)はありません。

@>>すでに存在するので、この動作を0.5の|>に追加することはどの程度実現可能ですか？

（オペレーターの表記にあまり力を入れたくないので、表記だけでこの提案を却下しないでください。ただし、「配管」はこれに対する自然な概念のように思われることに注意してください（cf 「コレクションパイプライン」という用語）、たとえばF＃はすでに|>を使用していますが、F＃関数はJulia関数とは異なるため、セマンティクスは少し異なります。）

ええ、確かに私は読みやすさの面で同意します。 |>を0.5で説明しているように動作させることは、技術的に難しいことではありません。これは単なる設計上の問題です。

同様に、Lazy.jlの@>>マクロを|>チェーンされた関数を解析することも可能です。

うーん。 その後、Lazy.jlのPRに取り組み始めますが、これが0.5入らないようにしたいという意味ではありません：）Juliaパーサーについて十分に理解していないと思います。ただし、かなり広範囲にわたる指導を受けない限り、 |>の動作を変更してそれを支援する方法。

このスレッドで言及したとは思いませんが、別のチェーンパッケージChainMap.jlがあります。 常に_に置き換えられ、条件付きで最初の引数に挿入されます。 また、マッピングの統合も試みます。 https://github.com/bramtayl/ChainMap.jlを参照して

だから私たちの現在のさまざまな取り組みのリストなど
これらをチェックする価値があると思います（理想的には意見を述べる前ですが、w / e）
それらはすべてわずかに異なります。
（私は年代順に注文しようとしています）。

パッケージ

• MikeInnesのLazy.jl。
• renedのFunctionalData.jl
• oxinaboxのPipe.jl
• bramtaylのChainMap.jl （非推奨）
• bramtaylのChainRecursive.jl （非推奨）
• FNjのHose.jl
• c42fのMagicUnderscores.jl
• c42fのUnderscores.jl
• ブラムテイルのLightQuery

非パッケージプロトタイプ

• kmsquiresの作曲マルコ
• porterjamesjのスレッドマクロ
• oxinaboxの簡潔なラムダ- @StefanKarpinskiからのhttps://github.com/JuliaLang/julia/issues/5571#issuecomment -157424665
• fcardのGeneratedPartials-例

関連：

• andyferrisの関数合成演算子、PR
• MikeInnesのFlow.jl

おそらく、これはトップの投稿の1つに編集する必要があります。

更新日：2020-04-20

これは、部分適用を実装する実際の試みというよりも型システムの実験ですが、ここに奇妙なものがあります： https ：

使用法：

include("partial_underscore_generated.jl")
using GeneratedPartial

const sub = partialize(-)
sub(_,2)(1) == 1-2
sub(_,_)(1,2) == 1-2
sub(_,__)(1)(2) == 1-2
sub(__,_)(2)(1) == 1-2 #hehehe

# or
<strong i="8">@partialize</strong> 2 Base.:+ # evily inserts methods in + and allows partializations for 2 arguments
(_+2)(1) == 1+2

# fun:
sub(1+_,_)(2,3) == sub(1+2,3)
sub(1+_,__)(2)(3) == sub(1+2,3)
(_(1)+_)(-,1) == -1+1

# lotsafun:
appf(x::Int,y::Int) = x*y
appf(f,x) = f(x)
<strong i="9">@partialize</strong> 2 appf

appf(1+_,3)(2) == appf(1+2,3)
appf(?(1+_),3) == appf(x->(1+x), 3)
appf(?sub(_,2),3) == appf(x->x-2,3) # I made a method *(::typeof(?),::PartialCall), what of it!!?

# wooooooooooooooooooooooooooooooooo
const f = sub
f(_,f(_,f(_,f(_,f(_,f(_,f(_,f(_,f(_,_)))))))))(1,2,3,4,5,6,7,8,9,10) == f(1,f(2,f(3,f(4,f(5,f(6,f(7,f(8,f(9,10)))))))))
f(_,f(__,f(___,f(____,f(_____,f(______,f(_______,f(________,f(_________,__________)))))))))(1)(2)(3)(4)(5)(6)(7)(8)(9)(10) == f(1,f(2,f(3,f(4,f(5,f(6,f(7,f(8,f(9,10)))))))))

# this answers Stefan's concern (which inspired me to make this hack in the first place)
#
#    const pmap = partialize(map)
#    map(f(_,a),   v) == map(x->f(x,a), v)
#    pmap(?f(_,a), v) == map(x->f(x,a), v)
#    pmap(f(_,a),  v) == x->map(f(x,a), v)
#
# it adds a few other issues, of course...

確かに実装の提案ではありませんが、遊ぶのは楽しいと思います。おそらく誰かがそれから半分の良いアイデアを得ることができます。

PS @partializeは整数配列のリテラルと範囲でも機能することを忘れました。

<strong i="15">@partialize</strong> 2:3 Base.:- # partialized for 2 and 3 arguments!

(_-_-_)(1,2,3) == -4
(_-_+_)(1,2,3) == +2

OK、私は関数の合成について考えていました。IMOはSISOの場合は明確ですが、小さなチェーンコードブロックでJuliaのMISO（準MIMO？）をどのように使用するかを考えていたと思います。

私はREPLが好きです。 たくさん。 かわいくてかっこいいです。MATLABやPython、シェルのように実験できます。 パッケージまたはファイルからコードを取得して、複数行のコードであっても、REPLにコピーして貼り付けるのが好きです。 REPLはすべての行でそれを評価し、何が起こっているかを示します。

また、すべての式の後にans返す/定義します。 すべてのMATLABユーザーはそれを知っています（ただし、この段階では、これは悪い議論です！）。 おそらくほとんどのJuliaユーザーは以前にそれを見た/使用したことがあります。 区分的に何かで遊んでいる奇妙な状況でansを使用し、上記で書いたものに別のステップを追加したいと思います。 私はそれを使用することが一種の破壊的であることを嫌うので、可能な限りそれを避ける傾向がありますが、ここでのすべての提案は、構成の1つのステップのみのリターンライフタイムを扱っています。

私にとって、 _が魔法であるというのは_奇妙な_ですが、多くの人が反対するかもしれないことを理解しています。 したがって、パッケージからREPLにコードをコピーアンドペーストして実行を監視したい場合、そして魔法のように見えない構文が必要な場合は、次のことを提案できます。

<strong i="12">@repl_compose</strong> begin
   sin(x)
   ans + 1
   sqrt(ans)
end

関数が複数の出力を返す場合は、次の行にans[1] 、 ans[2]などを挿入できます。 これは、すでに単一レベルの構成モデルであるJuliaのMISOモデルにうまく適合しており、ファイルではなく、すでに_非常に標準的なJulia構文_です。

マクロは簡単に実装できます。 Expr(:block, exprs...)をExpr(:block, map(expr -> :(ans = $expr), exprs)変換するだけです（最初はlet ansでもあります。おそらく、入力か何か？）。 ベースに住むことは_ありません_（ただし、REPLはJuliaに組み込まれており、それには似ています）。

とにかく、私の視点だけ！ これは長いスレッドで、私は長い間見ていませんでした！

また、すべての式の後にansを返す/定義します。 すべてのMATLABユーザーはそれを知っています（ただし、この段階では、これは悪い議論です！）。

実際には、他の引数があればということである_機能連鎖に使用され、その後、REPLも返す必要があります_ではなくans （私にとっては、これは除去するのに十分だろう「魔法」）。

言語の「価値」として_を使用することには、かなりの前例があります。 もちろん、これは、割り当てを破棄する名前として、およびより簡潔なラムダに_を使用するという提案されたアイデアと矛盾します。

これはLazy.jlのどこかに<strong i="5">@as</strong> and begin ...として存在すると確信しています

チェーンに.を使用するというアイデアは、会話の早い段階で破棄されましたが、有用性の長い歴史があり、他の言語の採用者の学習曲線を最小限に抑えることができます。 それが私にとって重要な理由は

type Track
  hit::Array{Hit}
end
type Event
  track::Array{Track}
end

event.track[12].hit[43]

trackとhitが単純な配列である場合、イベントの12番目のトラックの43番目のヒットが得られます。

event.getTrack(12).getHit(43)

それらを動的に提供する必要がある場合は、同じことを私に与える必要があります。 言いたくない

getHit(getTrack(event, 12), 43)

深く行くほど悪化します。 これらは単純な関数であるため、関数チェーン（a la Spark）の引数よりも引数が広くなります。

私は今、 Rustの特性について学んだので、これを書いています。これは、同じ理由でJuliaの良い解決策になる可能性があります。 ジュリアと同じように、錆は、専用のデータがあるstructs （ジュリアtype ）が、その後、彼らはまた、持っているimpl名前に機能を結合するためにstruct 。 私の知る限り、これは純粋なシンタックスシュガーですが、上記のドット表記が可能です。

impl Event {
  fn getTrack(&self, num: i32) -> Track {
    self.track[num]
  }
}

impl Track {
  fn getHit(&self, num: i32) -> Track {
    self.track[num]
  }
}

ジュリアでは

impl Event
  function getTrack(self::Event, num::Int)
    self.track[num]
  end
end

impl Track
  function getHit(self::Track, num::Int)
    self.hit[num]
  end
end

上記の提案された構文は、 self解釈を行いません。これは単なる関数の引数であるため、多重ディスパッチとの競合はありません。 self最小限の解釈を行いたい場合は、最初の引数の型を暗黙的にして、ユーザーが::Eventと::Trackを入力する必要がないようにすることができます。各機能ではなく、任意の解釈をしていないのいいところは、「静的メソッド」は中だけで機能していることであるimpl持っていませんself 。 （Rustはそれらをnew工場で使用します。）

Rustとは異なり、Juliaにはtypes階層があります。 コードの重複を避けるために、 implsにも同様の階層を設定できます。 標準のOOPは、データtypeとメソッドimpl階層をまったく同じにすることで構築できますが、この厳密なミラーリングは不要であり、場合によっては望ましくありません。

これには1つの厄介な点があります。 getTrackとgetHitではなく、 implで関数にtrackとhitという名前を付けたとします。そのため、 typeの配列trackおよびhitと競合していました。 次に、 event.trackは配列または関数を返しますか？ すぐに関数として使用すると、明確にするのに役立ちますが、 typesはFunctionオブジェクトも保持できます。 たぶん、包括的ルールを適用するだけです。ドットの後に、最初に対応するimplをチェックし、次に対応するtypeチェックしますか？

考え直してみると、概念的に同じオブジェクト（ typeとimpl ）の2つの「パッケージ」を避けるために、これはどうでしょうか。

function Event.getTrack(self, num::Int)
  self.track[num]
end

関数getTrackをタイプEventインスタンスにバインドして次のようにします

myEvent.getTrack(12)

(myEvent, 12)適用された関数と同じバイトコードを生成しますか？

新機能は、 functionキーワードの後のtypename-dot-functionname構文とその解釈方法です。 これでも、最初の引数がバインドされているタイプと同じである場合（または上記のように暗黙的に残されている場合）、Pythonのようなself多重ディスパッチが可能であり、「静的メソッド」が可能である場合最初の引数は存在しないか、バインドされているタイプとは異なるタイプになっています。

@jpivarskiドット構文（このスレッドを読むと、多くの欠点があります）が、連鎖を可能にする他の構造よりも優れていると思う理由はありますか？ 私はまだdoようなものを作成すると思います|> ）でサポートされていることが最善の方法です。

event |> getTrack(12) |> getHit(43)

Rustのアプローチのようなものの方が優れていることがわかる主な理由は、関数の名前空間として左側を効果的に使用するため、既存のものと競合することなくparser.parseようなことができる可能性があるためです。ジュリアBase.parse関数。 Rustの提案とHackスタイルの配管の両方を提供することに賛成です。

@tlycken優先順位にもよりますが、これはあいまいな構文です。
|> vs呼び出しの優先順位を覚えていると、実際にはヒントが得られないため、混乱する可能性があります。
（提案された他のオプションのいくつかも実行しません。）

検討する

foo(a,b) = a+b
foo(a) = b -> a-b

2 |> foo(10) == 12   #Pipe Precedence > Call Precedence 
2 |> foo(10) == 8     #Pipe Precedence < Call Precedence   

@oxinabox私は実際には、それが「単なる」通常の演算子ではなく、言語の構文要素であることを示唆しています。 2 |> foo(10)はfoo(10, 2) 2 |> foo(10)脱糖し、 foo(10) do x; bar(x); endはfoo(x -> bar(x), 10)脱糖します。 これは、呼び出しの優先順位よりもパイプの優先順位を意味します（とにかく、これが最も理にかなっていると思います）。

構文に関して言えば、 .は視覚的に目立たず、確かに|>よりも標準的です。 .で区切られた流暢な関数のチェーンをスペースなし（各1文字）で書くことができ、誰でもそれを読むことができます。 |>場合、スペース（それぞれ4文字）を追加する必要があり、ほとんどのプログラマーにとって視覚的なスピードバンプになります。 シェルスクリプトの|との類似性は素晴らしいですが、 >ため、すぐには認識できません。

私はこのスレッドを正しく読んでいますか？ドットに対する議論は、 typeからメンバーデータを取得するか、 impl （私の最初の提案）または関数からメンバー関数を取得するかがあいまいであるということです名前空間（私の2番目の提案）？ 2番目の提案では、 typeによって作成された関数名前空間で定義された関数は、 typeが定義された後、定義する必要があります。これにより、メンバーデータをその場で覆い隠すことを拒否できます。

名前空間ドット（私の2番目の提案）と|>両方を追加することは私にとっては問題ありません。 どちらも流暢な連鎖に使用できるという事実にもかかわらず、目的と効果はかなり異なります。 ただし、上記の|>は、 doと完全に対称ではありません。これは、 doが関数として入力する引数を必要とするためです。 event |> getTrack(12) |> getHit(43)と言っている場合、 |>は非関数（ EventsおよびTracks ）に適用されます。

event |> getTrack(12) |> getHit(43)と言っている場合、 |>は非関数（ EventsおよびTracks ）に適用されます。

実際には、いいえ-関数呼び出しの最後の引数として左のオペランドを挿入することにより、_右側の_関数の呪文に適用されます。 event |> getTrack(12)は、左側にあるものではなく、右側にあるもののためにgetTrack(12, event)です。

これは、コールの書き換えだから）（関数呼び出しを介して）優先を意味する必要があり、そしてb）それは作るために左から右への適用順序（うgetHit(43, getTrack(12, event))ではなくgetHit(43, getTrack(12), event) ） 。

しかし、 getTrack's署名は

function getTrack(num::Int, event::Event)

したがって、 event |> getTrack(12)がeventをgetTrack's最後の引数に挿入すると、 Functionではなく、2番目の引数にEvent挿入されます。 doと最初の引数で同等のものを試したところ、Julia0.4は引数が関数である必要があると不満を漏らしました。 （おそらく、 do event endは、 event自体ではなく、 event返す関数として解釈されるためです。）

関数チェーンは、ドット（ . ）構文の周りで議論されていることの多くとは別の問題であるように私には思えます。 たとえば、 @ jpivarskiの場合、新しい機能を使用しなくても、Rust

type TownCrier
  name::AbstractString
  shout::Function

  function TownCrier(name::AbstractString)
    self = new(name)
    self.shout = () -> "HELLO, $(self.name)!"
    self
  end
end

tc = TownCrier("Josh")
tc.shout()                                #=> "HELLO, Josh!"
tc.name = "Bob"
tc.shout()                                #=> "HELLO, Bob!"

会話をあまり狂わせようとせずに、私たちが本当に解決する必要があるのは、ジュリアで効率​​的な関数カリー化を行う方法であることをお勧めします。 関数をカレーする良い方法があれば、関数チェーン内の引数の位置を指定する方法に関する質問は解消されます。 また、上記のような構造は、機能本体を指定して「自己」でカレーするだけでよりきれいになります。

@andyferris私はPythonを使用していて、前の式の結果を参照する_が本当に好きです。 ただし、関数内では機能しません。 開始ブロックや関数など、どこでも機能するようにできれば素晴らしいと思います。

これはチェーンを完全に置き換えることができると思います。 引数の順序についてあいまいさを残すことはありません。 例えば、

begin
    1
    vcat(_, 2)
    vcat(3, _)
end

# [3, 1, 2]

@MikeInnesが述べたように、これは@_ですでに利用可能です（元々はそのようには機能しませんでしたが、ChainMap.jlも現在この種のチェーンを使用しています）。

うまくいけば、これは少なくともブロック内でドットフュージョンと一緒に機能することができます

begin
    [1, 2, 3]
    .+(_, 2)
    .*(_, 2)
    .-(10, _)
end

または、 @chain_map構文を使用して、

begin
    ~[1, 2, 3]
    +(_, 2)
    *(_, 2)
    -(10, _)
end

現在、関数がコンストラクター内で定義されている場合、オブジェクトとの関数チェーンの方法があります。 たとえば、関数Obj.times：

type Obj
    x
    times::Function
    function Obj(x)
       this = new(x)
       this.times =  (n) -> (this.x *= n; this)
       this
    end
end

>>>Obj(2).times(3)
Obj(6,#3)

タイプ定義の外部で定義されたメンバー関数（特別な関数）の実装についてはどうでしょうか。 たとえば、関数Obj.timesは次のように記述されます。

member function times(this::Obj, n)
     this.x *= n
     return this
end

>>>Obj(2).times(3)
Obj(6,#3)

ここで、 memberはメンバー関数の特別なキーワードです。
メンバー関数はオブジェクトデータにアクセスできます。 後で、オブジェクト変数の後にドットを使用して呼び出されます。
アイデアは、型定義の外部で定義された「メンバー」関数を使用して、コンストラクター内で定義された関数の動作を再現することです。

このようなことは、Rustでメソッド構文を使用して行われ

私はこれといくつかの関連する問題を読みました、ここに私の提案があります：

基本的な連鎖：
in1 |> function1
と同じ： in1 |> function1(|>)

in2 |> function2(10)
と同じ： in2 |> function2(|>,10)

さらに連鎖：
in1 |> function1 |> function2(10,|>)

チェーンの分岐とマージ：
ブランチout1 、 out2 2回ブランチ：
function1(a) |out1>
function2(a,b) |out2>

ブランチout1とout2ます：
function3(|out1>,|out2>)

怠惰はどうですか？
function!(mutating_var)コンベンションのようなものが必要ですか？
怠惰な関数の場合、 function?()使用できます...

また、インデントを適切に使用することで、関連するコールグラフのデータ依存関係を視覚的に追跡するのが簡単になります。

既存の|>演算子を使用して、関数チェーンのパターンを試してみました。 たとえば、次の定義は次のとおりです。
「「ジュリア

フィルタ

不変のMyFilter {F}
flt :: F
終わり

関数（mf :: MyFilter）（ソース）
filter（mf.flt、source）
終わり

関数Base.filter（flt）
MyFilter（flt）
終わり

取る

不変のMyTake
n :: Int64
終わり

関数（mt :: MyTake）（ソース）
take（source、mt.n）
終わり

関数Base.take（n）
MyTake（n）
終わり

地図

不変のMyMap {F}
f :: F
終わり

関数（mm :: MyMap）（ソース）
map（mm.f、source）
終わり

関数Base.map（f）
MyMap（f）
終わり
enable this to work: ジュリア
1:10 |> filter（i-> i％2 == 0）|> take（2）|> map（i-> i ^ 2）|> collect
`` Essentially the idea is that functions like filter return a functor if they are called without a source argument, and then these functors all take one argument, namely whatever is "coming" from the left side of the |> . The |> ``次に、これらすべてのファンクターをチェーンします。

filterなどは、1つの引数を取る匿名関数を返すだけでもかまいませんが、これらのオプションのどれがよりパフォーマンスが高いかはわかりません。

私の例では、Baseでmap(f::Any)を上書きしていますが、 mapの既存の定義が何をするのか本当に理解していません...

私はちょうどこのパターンを思いついた、そして私の幾分大雑把な見回しはそのような何かの議論を何も示さなかった。 人々はどう思いますか？ これは役に立つでしょうか？ 人々はこれの欠点を考えることができますか？ これが機能する場合、既存の設計は実際にはかなり包括的な連鎖ストーリーを可能にするのに十分な柔軟性がありますか？

これは任意の関数では機能しないようですが、MyFが定義されている関数だけですか？

はい、これはオプトインする機能に対してのみ機能します。 明らかに非常に一般的な解決策ではなく、ある意味ではベクトル化と同じ話ですが、それでも、私たちが望むすべてが1.0になるわけではないことを考えると、このパターンは人々が頼らなければならないシナリオの全体を可能にするかもしれません現在マクロ。

基本的に、フィルターのような関数は、ソース引数なしで呼び出された場合にファンクターを返し、これらのファンクターはすべて1つの引数、つまり|>の左側から「来る」ものを取ります。

これは、ほぼ正確に、Clojureのトランスデューサーの本質です。 注目すべき違いは、Clojureがレデューサーの概念の上にトランスデューサーを構築したことです。 つまり、コレクションを操作するすべての関数は、「マッピング」関数と「削減」関数に分解できます（「削減」関数が単にconcat ）。 この方法でコレクション関数を表すことの利点は、すべての「マッピング」をパイプライン化できるように実行を再配置できることです（特に大規模なコレクションの場合に便利です）。 したがって、トランスデューサーは、操作するコレクションなしで呼び出されたときに返されるこれらの「マッピング」の単なる抽出です。

これをそれほど複雑にする必要はありません。 関数は、クロージャを使用したカリー化をオプトインできます。

Base.map(f)    = (xs...) -> map(f, xs...)
Base.filter(f) = x -> filter(f, x)
Base.take(n)   = x -> take(x, n)

もちろん、これはすべてのパッケージのこれらのメソッドの意味を変更するため、パッケージが行うべきことではありません。 そして、このように少しずつ行うのは、それほど直感的ではありません。どの引数を優先する必要がありますか？

f(a, _, b)をx -> f(a, x, b)に下げて、上で説明したような呼び出しサイトの構文ソリューションをお勧めします。 ただし、上記の長い議論で述べたように、これは注意が必要です。

これをそれほど複雑にする必要はありません。 関数はクロージャ付きのカリー化をオプトインできます

はい、私はすでに上記のように、これら2つの間にパフォーマンスの違いがあるかどうかはわかりませんでした。

どの引数を優先する必要がありますか？

ええ、実際にはfilterやtakeようなものがあります。ここでは、最初の引数としてコレクションがあり、最後の引数としてコレクションがあります...少なくともイテレータのような操作の場合、通常、その質問に対する明白な答えがあるかもしれません。

_が利用可能な特別なシンボルになると

はい、私はそこにもっと一般的な解決策があることに完全に同意します、そして@malmaudのものがそれかもしれません。

クロージャは基本的に、とにかく手動で記述したコードを生成するだけなので、パフォーマンスの違いはありません。 しかし、あなたはただカリー化しているので、あなたはあなたのためにそれをするための関数を書くことができます（ curry(f, as...) = (bs...) -> f(as..., bs...) ）。 これでマップとフィルターが処理されます。 curry(take, _, 2)ような番兵値を実装するcurryを実装する提案も過去にありました。

私は現在、D、Elixir、そして現在はJuliaの3つの言語を学んでいるので、ここに来ました。 Dには、Rustのように、統一された関数呼び出し構文があります。Elixirには、パイプ演算子があります。 どちらも基本的にここで提案されている種類の関数チェーンを実装しており、この機能は両方の言語で非常に気に入りました。把握しやすく、実装しやすく、ストリームやその他の種類のデータパイプラインを使用するコードをはるかに読みやすくすることができるからです。

これまでジュリアの構文についての簡単なチュートリアルを見ただけですが、ジュリアにもこのようなものがあることを望んでいたので、すぐにこの機能をグーグルで検索しました。 ですから、これは私の側からのこの機能リクエストの+1だと思います。

こんにちは皆さん、

この機能リクエストを+1させてください。 これは非常に必要です。 次のScala構文について考えてみます。

Array(1,2,3,4,5)
  .map(x => x+1)
  .filter(x => x > 5)
  .reduce(_ + _)

Sparkまたは他のMapReduceベースのビッグデータツールを使用したことがある人は、この構文に非常に精通しており、このように大規模で複雑なジョブを記述しているでしょう。 比較的古いRでさえ、次のことが可能です。

c(1,2,3,4,5) %>%
  {. + 1} %>%
  {.[which(. > 5)]} %>%
  sum

適切な関数型プログラミングの代わりにコードブロックを巧妙に使用していることに注意してください。最も美しくはありませんが、強力です。 ジュリアでは、次のことができます。

[1,2,3,4,5] |> 
  _ -> map(__ -> __ + 1, _) |>
  _ -> filter(__ -> __ < 5, _) |>
  _ -> reduce(+, _)

しかし、これは恐ろしくて醜いです。 Scalaでオブジェクト指向コードを作成できない場合、パイプ演算子は非常に重要になります。 最も簡単な解決策は、_などのワイルドカードが明示的に使用されていない限り、パイプが_first引数_をフィードすることですが、これは、データ構造を最初の引数および関数として取り込むようにmapが変更された場合にのみ意味があります。 2番目として。

過度の_ -> _ + 1や同様の構文を避けるために、ScalaのArray(1,2,3).map(_ + 1)に相当するものも必要です。 [1,2,3] |> map(~ + 1, _)がmap(~ -> ~ + 1, [1,2,3])変換される上記のアイデアが好きです。 見てくれてありがとう。

後者については、コンパクトな構文で放送しています[1, 2, 3] .+ 1それはかなり中毒性があります。 削減（そしておそらくフィルタリング）のためのそれのようなものはめちゃくちゃクールでしょうが、大きな質問のようです。

パイピングとdo両方が最初の関数の引数をめぐって争うことに注意するのは合理的なポイントです。

私たちが持っているスレッドに新しいものが来ることを思い出させます、
syntaxsが提案に向けて1、2ないが、5つのパッケージには、ジュリアの基本SISO配管の機能への拡張を提供していません。
次のリストを参照してください： https ：

パイピングと実際の両方が最初の関数の引数のために戦うことに注意するのは合理的なポイントです。

ベースに追加の配管機能を追加する場合、それは_などでマークされた位置ではありません
次に、最初の位置ではなく、最後の位置に引数を追加すると思います。
それは「カリー化/部分適用のふり」のようになります

上記の私の投稿は、問題の構文の問題を説明するために設計された簡単な例を意図しています。

実際には、1つのチェーンで何百もの操作が使用されることが多く、その多くは非標準です。 自然言語のビッグデータを扱うことを想像してみてください。 文字列を取得し、中国語の文字を除外し、空白で分割し、「the」などの単語を除外し、Webで使用されるブラックボックスソフトウェアツールを使用して各単語を「標準化された」形式に変換する一連の変換を記述します。サーバー、別のブラックボックスツールを介して各単語の一般性に関する情報を追加する、各一意の単語の重みを合計する、他の100の操作など。

これらは私が考えている状況です。 メソッド呼び出しやパイプを使用せずにこのような操作を実行することは、サイズが非常に大きいため、初心者ではありません。

最適な設計が何であるかはわかりません。現在実施されているものよりも、ユースケースとより複雑な構文を検討することをすべての人に勧めています。

これはJunoとJulia0.6で機能するはずです

`` `{julia}
LazyCallを使用する
@lazy_call_module_methodsベースジェネレータ
@lazy_call_module_methodsイテレーターフィルター

ChainRecursiveを使用する
start_chaining（）

```{julia}
[1, 2, 3, 4, 5]
<strong i="14">@unweave</strong> ~it + 1
Base.Generator(it)
<strong i="15">@unweave</strong> ~it < 5
Iterators.filter(it)
reduce(+, it)

この問題に関するコメントで見た構文について質問があります。
https://stackoverflow.com/questions/44520097/method-chaining-in-julia

@somedadaism 、問題は問題のためのものであり、スタックオーバーフローの質問を「宣伝」するためのものではありません。 また、Julia-人々はSOや（さらに） https://discourse.julialang.org/で非常に活発

うわあ、これがどれほど複雑になるか信じられないほどです。 いくつかのまともな構文の場合は+1。 私にとって、配管の主な用途はデータ（フレーム）の操作でもあります。 dplyrを考えてください。 個人的には、デフォルトとして最初/最後を渡すことはあまり気にしませんが、ほとんどのパッケージ開発者は、関数に最初の引数としてデータを受け入れさせると思います-そしてオプションの引数はどうですか？ +1のようなもの

1 |> sin |> sum(2, _)

前に述べたように、読みやすさとシンプルさは非常に重要です。 私はデータ分析のために物事を行うdplyr / tidyverseスタイル全体を見逃したくありません...

パイプ演算子に対してもElixirの複数行構文が非常に役立つことを付け加えたいと思います。

1
|> sin
|> sum(2)
|> println

println(sum(sin(1),2))と同等です

javascriptの世界での提案に注意_または~代わりに?演算子を使用します。これは、すでに意味があります（ _は何かを無視し、 ~はビット単位です）ないまたは公式）。 現在、JavaScriptと同じ?使用していることを考えると、カリー化プレースホルダーにも使用する可能性があります。

これは、この提案がどのように見えるかです（javascriptですが、juliaでも有効です:)

const addOne = add(1, ?); // apply from the left
addOne(2); // 3

const addTen = add(?, 10); // apply from the right
addTen(2); // 12

// with pipeline
let newScore = player.score
  |> add(7, ?)
  |> clamp(0, 100, ?); // shallow stack, the pipe to `clamp` is the same frame as the pipe to `add`.

const maxGreaterThanZero = Math.max(0, ...);
maxGreaterThanZero(1, 2); // 2
maxGreaterThanZero(-1, -2); // 0

他の理由で書き始めたのでまとめ。
関連パッケージのコメントの以前の

https://github.com/JuliaLang/julia/pull/20328のため、 _をいじることは、1.xで実行できます。

これはすべて、2つの主要なオプション（現状維持以外）に要約されます。
両方とも（すべての意図と目的のために）マクロを使用して実装し、構文を書き直すことができます。

_をいじって匿名関数を作成する

@StefanKarpinskiの簡潔ラムダ、又は存在同様の構文_ （RHS式では）、その全体式は匿名関数であることを示しています。

• これはほとんどマクロで処理でき参照してください。
  
  
  
  • できないことは、 (_)が_と同じではないことだけです。 これは単なる恒等関数なので、実際には問題ではありません
  
  
  • これはどこにでも当てはまるので、 |>でなく、たとえばmap(log(7,_), xs)やlog(7, _).(xs)ようにコンパクトに記述して、各要素の基数7でログを取得する場合にも役立ちます。 xs 。
  
  
  • 私たちが何かをしているのなら、私は個人的にこれを好みます。
  
  

|>をいじって置換を実行させる

オプションは次のとおりです。

• RHSをカレーのように振る舞わせる
  
  
  
  • 実際、これは壊れていると思います（ただし、メソッドテーブルをチェックする壊れていないバージョンがあるかもしれません。代わりに混乱していると思います）
  
  
• _特別なものにする（上記のオプション、および/または書き換えによって偽造するさまざまな方法を参照）
  
  
  
  • これを行う1つの方法は、中置マクロの作成を許可してから、 @|>@を記述し、パッケージで希望どおりに定義することです（これは、https：//github.com/JuliaLang/julia/ですでに閉じられています）。問題/ 11608）
  
  
  • または本質的にそれらの特別なプロパティをそれに与える
  
  
• 関連するパッケージのリストを参照してくださいと言ったように、これを行うためのマクロ実装がたくさんあり
• また、（他のすべての演算子とは異なり）行が終了しない前に式を生成できるように変更することを提案する人もいます。 だからあなたは書くことができます

a
|> f
|>g

現在ではなく：

a |>
f |>
g

（これをマクロで実装すると、ブロックをブラケットせずに実行することはできません。ブロックをブラケットすることで、とにかく機能するようになります）

• 私は個人的にこれらの提案が|> （すでに嫌われているオペレーター）を超魔法にするので好きではありません。

編集： @StefanKarpinskiが以下で
誰かがtypeof(|>) <: Function依存している可能性があるからです。
そして、これらの変更はそれを言語構文の要素にするでしょう。

ボーナスオプション：これまでにないオプション：どこにでもカリー化を追加＃554

カリー化を追加するには、言語では遅すぎます。
それはクレイジーな破壊であり、至る所に曖昧さの巨大な山を追加します。
そして、非常に混乱します。

これらの2つのオプションで、基本的に検討する価値のあるすべてをカバーしていると思います。
他に洞察に満ちたものは何も言われていないと思います（つまり、「+ 1はこれが欲しい」を数えない、または上記のマイクロバリアントの繰り返し）。

私は0.7で|>を非推奨にしたいと思っています。これにより、後で、配管を適切に機能させるために必要と思われる、より便利で機能に似ていないセマンティクスを導入できるようになります。

私は0.7で|>を非推奨にしたいと思っています。これにより、後で、配管を適切に機能させるために必要と思われる、より便利で機能に似ていないセマンティクスを導入できるようになります。

そのリストの唯一の分割ケースは、 |>が右側をカリー化したふりをする場合です。
引数を最初、最後の最後の引数位置（/ s）、またはその他の固定位置（2番目が意味がある場合があります）に挿入します。
挿入する引数のマーカーとして_を使用しない。

このスレッドの誰もが漠然と真剣に受け止めたという他の破滅的な提案はなされていません。|
その操作について他の賢明でありながら破れている定義があるとしたら、私は驚きます。
この4年間、誰もまだ提案していません。

とにかくそれを非推奨にすることはひどいことではないでしょう。
それを使用するパッケージは、マクロパッケージの1つを介してそれを保持できます。

別のアイデアは、 |>を現在の動作のままにして、 \\などのShiftキーの使用を必要としない別の名前で新しい機能を導入することです（これは必要ありません）。今は演算子として解析することもできます）。 これについてはSlackで一度話しましたが、おそらく歴史は時の砂に失われていると思います。

配管はインタラクティブに使用されることが多く、演算子の入力のしやすさは、使用感の「軽さ」に影響します。 単一の文字|もいいかもしれません。

単一の文字|もいいかもしれません。

インタラクティブにそうですが、それを.juliarc.jlに入れるだけで十分です（私は長い間持っていました;-p）

Shiftキーを使用する必要はありません

これはロケールに大きく依存するプロパティであることに注意してください。 たとえば、私のスウェーデン語のキーボードは、シフトする文字の数と、（かなり恐ろしい）AltGrの組み合わせを出荷して、さらに3文字のスペースを作りました。

この目的で|>を使用する伝統はありますか？ [Mathematica]（http://reference.wolfram.com/language/guide/Syntax.html）にはpostfix関数適用用の//があります。これはほとんどのキーボードで簡単に入力できるはずで、もしあれば利用できるかもしれません。コメント（C ++のように）または整数除算（Pythonのように）にはまだ使用されていません。

|れているものは、シェルスクリプトとの良好な関係がありますが、もちろん、単一の|はビット単位のORであると予想されます。 ||は論理ORに使用されますか？ |||どうですか？ 届きにくい文字を3回入力することは、1回入力するよりもそれほど難しくありません。

この目的で|>を使用する伝統はありますか？

|>の伝統は、MLファミリーの言語に由来すると思います。 オペレーターに関しては、ML / Haskellコミュニティのように、このスペースを探索したプログラミング言語コミュニティはほとんどありません。 例の小さな選択：

• http://www.mlton.org/InfixingOperators –MLのインフィックス演算子のリスト。 特に、左右のセクション/アプリケーション用の/> 、 \> 、 </ 、 <\演算子のコレクションが好きです。

• http://lambda.jstolarek.com/2012/03/function-composition-and-dollar-operator-in-haskell/ -迅速な関数合成の概要と.とし、アプリケーション$ Haskellの|>はコメントの1つに表示されます。）

• https://haskell-lang.org/tutorial/operators – >>= 、 =<< 、 >>のモナドファミリーを含む楽しい演算子の全コレクションを含むHaskell演算子用語集>=> 、および<=< 。

上記のリストに追加するために、Rは％>％を使用します-その言語は古くなっていますが、そのパイプ機能は非常にうまく設計されていると思います。 それを効果的にするものの1つは、中括弧構文です。これにより、次のようなものを書くことができます。

x %>% { if(. < 5) { a(.) } else { b(.) } }

これは、endステートメントを使用しているため、Juliaではかなり冗長になります。 上記の私の例は抽象的なものですが、多くの人がデータ前処理コードを書くときに同様の構文を使用しています。 現在議論されている提案のいずれかで、おそらく括弧を使用することによって、上記と同様の何かを達成できますか？

また、 >記号のように、引数が前方にパイプされていることを視覚的に示すパイプ演算子の使用をお勧めします。 これは、初心者や関数型プログラミングに慣れていない人に役立つ手がかりを提供します。

|>の提案された使用法は、構文的に現在の典型的な使用法と互換性がありませんが、それらのほとんどは|>はるかに多く与えることを伴うため、演算子である|>とは互換性がありません。単なる中置関数よりもパワー。 私たちは確信している場合でも、我々は維持したいx |> f |> g意味するg(f(x)) 、通常のオペレータは、おそらく任意の更なる機能強化を妨げるだろうとして、それを残して、。 |>をpostfix関数適用を行う非演算子に変更しても、連鎖関数アプリケーションの_typical_使用法を壊さないかもしれませんが、 |> _atypical_使用法を壊すので、それでも許可されません。それはそれがオペレーターであることに依存しています。 非定型の使用法を破ることはまだ破られているため、1.xリリースでは許可されていません。 私の知る限り、 |>を使用して上記の提案のいずれかを実行する場合は、1.0の関数ではなく、 |>構文を作成する必要があります。

@StefanKarpinski現在、テーブル上でも関数ではなく|>構文を作成していますか？ 1.0に間に合うようにテーブルに置くことは可能ですか？

@StefanKarpinski現在、テーブル上でも関数ではなく構文を作成していますか？ 1.0に間に合うようにテーブルに置くことは可能ですか？

0.7で非推奨になり、1.0から完全に削除する予定です。
次に、1.xの間に構文要素としてそれを戻します。
その時点で、これは重大な変更ではありません。

誰かがそれをする必要があるでしょう、しかし私はそれがそれほど難しい変更であるとは思わないので、はい、それはテーブルの上にあります。

|>は何に非推奨になりますか？ Lazy.jlでの実装？

x |> fはf(x)非推奨になる可能性があります。

l>非推奨にすると同時に、現在のl>と同じ動作をするll>を導入するのはどうですか？

いくつかの置き換えなしで非推奨にした場合、現在の動作に依存するパッケージは、基本的に適切なオプションなしで残されます。 その間に少し良くない表現が得られた場合は、現在の設計を続行できますが、将来的にl>本当に良い解決策を見つけるためのオプションをテーブルに残します。

これは、クエリとフレンドのエコシステムに大きな影響を与えます。Rtidyverseのパイプ構文と非常によく似たシステムを作成しました。 全体はかなり包括的です。現在7つの表形式のファイル形式（さらに2つは非常に近い）のファイルio、すべてのクエリ操作（dplyrなど）およびプロット（それほど遠くはありませんが、私たちができることは楽観的です）すぐにggplotのように感じる何か）。 それはすべてl>の現在の実装に基づいています...

私はすべて、テーブルにl>より良いもののオプションを保持することに賛成だと言うべきです。 これまでに作成したものでは問題なく動作しますが、より良いアプローチを簡単に見つけることができました。 しかし、非推奨にするだけでも、多くのパッケージからラグを引き出すことができる非常に急進的なステップのようです。

もう1つの選択肢は、 x |> fをf(x)代替構文にすることです。 これは、 |>をオーバーロードするコードを壊しますが、関数チェーンに|>を使用するコードは、互換性がある限り、追加の拡張機能のために開いたままにして、機能し続けることができます。

別の方法は、将来的に新しい構文チェーン構文を導入することですが、それは現在構文エラーである必要があり、現時点ではかなりスリムな選択です。

別の方法は、将来的に新しい構文チェーン構文を導入することですが、それは現在構文エラーである必要があり、現時点ではかなりスリムな選択です。

上からの私の提案はそれを許しませんか？ つまり、 |>をjulia 1.0の構文エラーにし、 ||>を今日の|>と同等にします。 ジュリア1.0の場合、これは、現在使用していること、コードのマイナーの迷惑になります|> 1がに切り替える必要があるため||> 。 しかし、それはそれほど悪くはないだろうし、さらに完全に自動化できると思います。 次に、誰かが|>良いアイデアを思いついたら、それをその言語に再導入することができます。 その時点で、 ||>と|>両方が存在し、全員が|>を採用し始めると、 ||>がゆっくりとバックグラウンドにフェードインすると思います。 そして、数年以内に、julia 2.0は||>削除する可能性があります。 私の考えでは、a）julia 1.0の時間枠内の誰にも実際の問題を引き起こさず、b）最終的に|>本当に良い解決策のために、すべてのオプションをテーブルに残します。

|>(x, f) = f(x)
|>(x, tuple::Tuple) = tuple[1](x, tuple[2:endof(tuple)]...) # tuple
|>(x, f, args...) = f(x, args...) # args

x = 1 |> (+, 1, 1) |> (-, 1) |> (*, 2) |> (/, 2) |> (+, 1) |> (*, 2) # tuple
y = 1 |> (+, 1, 1)... |> (-, 1)... |> (*, 2)... |> (/, 2)... |> (+, 1)... |> (*, 2)... # args

何度も書くのは簡単ではありませんが、左から右へ、マクロを使用しません。

function fibb_tuple(n)
    if n < 3
        return n
    end
    fibb_tuple(n-3) |> (+, fibb_tuple(n-2), fibb_tuple(n-1))
end

function fibb_args(n)
    if n < 3
        return n
    end
    fibb_args(n-3) |> (+, fibb_args(n-2), fibb_args(n-1))...
end

function fibb(n)
    if n < 3
        return n
    end
    fibb(n-3) + fibb(n-2) + fibb(n-1)
end

n = 25

println("fibb_tuple")
<strong i="8">@time</strong> fibb_tuple(1)
println("fibb_args")
<strong i="9">@time</strong> fibb_args(1)
println("fibb")
<strong i="10">@time</strong> fibb(1)

println("tuple")
<strong i="11">@time</strong> fibb_tuple(n)
println("args")
<strong i="12">@time</strong> fibb_args(n)
println("fibb")
<strong i="13">@time</strong> fibb(n)

fibb_tuple
  0.005693 seconds (2.40 k allocations: 135.065 KiB)
fibb_args
  0.003483 seconds (1.06 k allocations: 60.540 KiB)
fibb
  0.002716 seconds (641 allocations: 36.021 KiB)
tuple
  1.331350 seconds (5.41 M allocations: 151.247 MiB, 20.93% gc time)
args
  0.006768 seconds (5 allocations: 176 bytes)
fibb
  0.006165 seconds (5 allocations: 176 bytes)

|>(x, tuple::Tuple) = tuple[1](x, tuple[2:endof(tuple)]...)はひどいです。
|>(x, f, args...) = f(x, args...)はより多くの文字を必要としますが、高速です。

私は可能だと思いますsubject |> verb(_, objects)として構文のようにverb(subject, objects)手段はSVOをサポートするために（ただし、ジュリアのデフォルトはVSOまたはVOSです）。 ただし、Juliaはmutltidipatchをサポートしているため、サブジェクトをサブジェクトにすることができます。 SVO構文を導入する場合は、 (subject1, subject2) |> verb(_, _, object1, object2)ような構文をverb(subject1, subject2, object1, object2)として許可する必要があると思います。
@oxinaboxが指摘したように、パイプラインとして把握されている場合はMIMOです。

(x)fをf(x)として使用するの(x)fどうですか？
(x)f(y)はf(x)(y)とf(y)(x)両方として読み取ることができるため、最初に評価を選択してください。

(x)f # f(x)
(x)f(y) # f(y)(x)
(x)f(y)(z) # f(y)(z)(x)
(x)(y)f(z) # f(z)(y)(x)
(a)(b)f(c)(d) # f(c)(d)(b)(a)
1(2(3, 4), 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
1 <| (2 <| (3, 4), 5 <| (6, 7), 8 <| (9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10)), but 2 <| (3, 4) == 2((3, 4)) so currently emit error
3 |> 2(_, 4) |> 1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
((3)2(_, 4))1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
(3, 4) |> 2(_, _) |> 1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))
((3, 4)2)1(_, 5(6, 7), 8(9, 10)) # 1(2(3, 4), 5(6, 7), 8(9, 10))

これにより、varargを明確に操作できます。
ただし、スペースなしの二項演算子は壊れます。

(a + b)+(c + d) # +(c + d)(a + b) == (c + d)(a + b): Error

代替オプション：スプラッティング構文の別のケースを追加します。 f ...（x）を（args ...）-> f（x、args ...）に脱糖します

これにより、構文的に軽量な（手動の）カリー化が可能になります。

#Basic example:
f(a,b,c,d) = #some definition
f...(a)(b,c,d) == f(a,b,c,d)
f...(a,b)(c,d) == f(a,b,c,d)
f...(a,b,c)(d) == f(a,b,c,d)
f...(a)...(b)(c,d) == f(a,b,c,d) # etc etc

# Use in pipelining:
x |> map...(f) |> g  |> filter...(h) |> sum

カリー化はいつやめますか？ Julia関数には固定アリティがありません。

ジュリアにはすでにスプラッティングオペレーターがいます。 私が提案しているのは、現在のスプラット演算子とまったく同じ動作です。

I、e：f ...（x）==（args ...）-> f（x、args ...）は、スプラッティングでラムダを作成するための砂糖です。

その定義は常に関数オブジェクトを提供します。 おそらくあなたは時々答えが欲しいです。

最後にオブジェクトを明示的に呼び出すことでそれを取得します。 たとえば、最後の例の最後の括弧のセットの前に...がないことに注意してくださいf ...（a）...（b）（c、d）== f（a、b、c、d） 。

返された関数オブジェクトを|>で呼び出すこともできます。これにより、パイピングに適しています。

@saolof

基本的な例：

f（a、b、c、d）=＃いくつかの定義
f ...（a）（b、c、d）== f（a、b、c、d）
f ...（a、b）（c、d）== f（a、b、c、d）
f ...（a、b、c）（d）== f（a、b、c、d）
f ...（a）...（b）（c、d）== f（a、b、c、d）＃など

機能連鎖でスプラットを使用するための良い直感ですが、私の意味では複雑すぎます。
チェーンの1つのポイントで複数のアプリケーションを作成しました。
関数チェーンでは、チェーン全体で1つのアプリケーションを段階的に作成します。

そして、 @ StefanKarpinskiは正しいです。関数を適用するのをいつ停止するかはわかりません。それ自体で、最終的にはよりスカラーなアイテムに適用します。

-（クリップ）-

申し訳ありませんが、それはかなり無意味で読めないものです。
より明確な説明を得るために、以下の私の2番目のメッセージを参照してください（私は願っています）。

ジュリアがすでにどれほど機能的であるかを考えると、私は@saolofの関数カレー演算子のアイデアがとても好き

自分の担当者の快適さからプロトタイプを作成することもできます。

ctranspose(f) = (a...) -> (b...) -> f(a..., b...)

map'(+)(1:10)

map'(+)'(1:10, 11:20)(21:30)

(+)'(1,2,3)(4,5)

1:10 |> map'(x->x^2) |> filter'(iseven)

ちょっといい感じだと思います。

編集：これは、これをさらに一般化するための道でもあるように感じます。 map∘(+, 1:10)書くことができれば、 map∘(_, 1:10)と書いてカレー引数を最初に配置し、カレーオペレーターがラムダのスコープを決定して、このような一般的なカレーの最大の問題を解決します。

ええ、それは賢いです、@ MikeInnes。

ジュリアの極端な拡張性がここでもどのように発揮されるかが大好きです。 機能チェーンの非常に幅広い要件に対する統合ソリューションは、 ctranspose悪用していることが判明しました...

（説明：この提案で1:10 |> map'(x->x^2) |> filter'(iseven)を受け取っているので、💯％です！）

明確にするために、これに実際にadjoint演算子を悪用する必要はないと思いますが、簡潔な関数カリー化表記を使用できることは概念実証の良い例です。

たぶん、新しいユニコード演算子を導入する必要がありますか？ http://www.fileformat.info/info/unicode/char/1f35b/index.htm

（ごめんなさい...）

_はラムダを作成するためのはるかに柔軟な方法であるように感じます

@bramtayl MikeInnesの彼の投稿への編集のアイデアは、2つが共存できるということだと思います— @stevengjのプルリクエストのような標準的なアンダースコアが機能し、上記のMikeのアイデアのようなスタンドアロンのカリー化が機能し、2つを組み合わせるまた、カリー化演算子を使用して、その中の_のスコープを区切ることができます。

ああ、わかった

それはそれをLazyCall.jlとあまり変わらないようにします

またはここでの提案： https ：

もっと深刻なことに：

明確にするために、これのために実際にadjoint演算子を悪用するべきではないと思います

おそらく適切な選択です。 しかし、そのようなソリューションが実装されれば、入力しやすい演算子が与えられることを願っています。 1:10 |> map'(x->x^2)ようなことをする機能は、 '置き換える文字がユニコードテーブルで検索する必要がある場合（またはLaTeX拡張をサポートするエディターを使用する場合）、大幅に役に立ちません。

随伴作用素を乱用するのではなく、スプラットを再利用することができます。

• （線形）配管コンテキストで
• 内部、関数呼び出しで
  
  
  
  • 後ではなく前にスプラットを行う
  
  

そう

• スプラットはイテレータ引数の欠落を引き起こす可能性があります

一種の高次の感嘆符（そこにミュージシャンがいる場合は伴う）。
それが言語をあまり揺さぶらないことを望んでいます。

例

1:10
    |> map(...x->x^2)
    |> filter(...iseven)

例2

genpie = (r, a=2pi, n=12) ->
  (0:n-1) |>
      map(...i -> a*i/n) |>
      map(...t -> [r*cos(t), r*sin(t)]) 

を表すことができます

elmap = f -> (s -> map(f,s))

genpie = (r, a=2pi, n=12) ->
  (0:n-1) |>
      elmap(i -> a*i/n) |>
      elmap(t -> [r*cos(t), r*sin(t)]) 

これがここに属するかどうかはわかりません。議論がより高度で柔軟なチェーンと構文に進化したためです...しかし、冒頭の投稿に戻ると、ドット構文を使用した関数チェーンは、少し追加の設定で今は可能のようです。 構文は、構造体のドット構文とファーストクラスの関数/クロージャを使用した結果です。

mutable struct T
    move
    scale
    display
    x
    y
end

function move(x,y)
    t.x=x
    t.y=y
    return t
end
function scale(c)
    t.x*=c
    t.y*=c
    return t
end
function display()
    @printf("(%f,%f)\n",t.x,t.y)
end

function newT(x,y)
    T(move,scale,display,x,y)
end


julia> t=newT(0,0)
T(move, scale, display, 0, 0)

julia> t.move(1,2).scale(3).display()
(3.000000,6.000000)

構文は従来のOOPと非常に似ているように見えますが、「クラスメソッド」の癖は変更可能です。 パフォーマンスへの影響が何かわからない。

@ivanctongあなたが説明したことは、関数チェーンよりも流暢なインターフェースに似たものです。

とは言うものの、関数チェーンの問題をより一般的に解決することには、流暢なインターフェースにも使用できるという追加の利点があります。 現在、ジュリアの構造体メンバーを使用して流暢なインターフェースのようなものを作成することは確かに可能ですが、それはジュリアの精神とデザインの美学に非常に反していると私は

パイプ演算子が常に最初の引数として左側を通過し、後で追加の引数を許可するエリクサーの方法は非常に便利"elixir" |> String.ends_with?("ixir")第一級市民として

他の言語では、これを統一関数呼び出し構文として定義しています。
この機能にはいくつかの利点があります（ウィキペディアを参照）。Juliaがサポートしてくれると便利です。

それで、この時点でジュリアへの流暢なインターフェースはありますか？

ジュリア談話ディスカッションフォーラムに質問を投稿してください。

ハッキング（および疑わしい判断！？）に合わせて、関数プレースホルダーのバインドの緊密さに対する別の可能な解決策を作成しました。

https://github.com/c42f/MagicUnderscores.jl

https://github.com/JuliaLang/julia/pull/24990で述べたように、これは、特定の関数の特定のスロットで_プレースホルダー式を緊密にバインドする必要があるという観察に基づいています。他の人は大まかに。 MagicUnderscoresは、これをあらゆるユーザー定義関数に拡張可能にします（放送機械の精神に非常に近い）。 したがって、私たちは次のようなものを持つことができます

julia> <strong i="12">@_</strong> [1,2,3,4] |> filter(_>2, _)
2-element Array{Int64,1}:
 3
 4

julia> <strong i="13">@_</strong> [1,2,3,4] |> filter(_>2, _) |> length
2

「ただ働く」。 （これを一般的な解決策にすることが可能であれば、 @_明らかになくなります。）

いくつかのバリエーション@MikeInnesの提案は、私のニーズに適しているように思われます（通常、 do構文を使用したフィルター、マップ、リデュース、列挙、zipなどの長いチェーン）。

c(f) = (a...) -> (b...) -> f(a..., b...)

1:10 |> c(map)() do x
    x^2
end |> c(filter)() do x
    x > 50
end

これは機能しますが、 'を機能させることはできません。 それはよりわずかに短いです：

1:10 |> x -> map(x) do x
    x^2
end |> x -> filter(x) do x
    x > 50
end

また、私は1つができると思います

cmap = c(map)
cfilter = c(filter)
cetc = c(etc)
...

1:10 |> cmap() do x
    x^2
end |> cfilter() do x
    x > 50
end |> cetc() do ...

1.0以降では、 ctransposeではなくadjointをオーバーロードする必要があります。 次のこともできます。

julia> Base.getindex(f::Function, x...) = (y...) -> f(x..., y...)

julia> 1:10 |> map[x -> x^2] |> filter[x -> x>50]
3-element Array{Int64,1}:
  64
  81
 100

apply_typeオーバーロードできれば、 map{x -> x^2}取得できます:)

@MikeInnes私はそれを盗んだ

遅くて少し軽薄な貢献-左右のカレー演算子の組み合わせを使用して、引数リスト内の任意の場所にデータをパイプするのはどうですか？

VERSION==v"0.6.2"
import Base: ctranspose, transpose  
ctranspose(f::Function) = (a...) -> ((b...) -> f(a..., b...))  
 transpose(f::Function) = (a...) -> ((b...) -> f(b..., a...))

"little" |> (*)'''("Mary ")("had ")("a ") |> (*).'(" lamb")

Clojureにはいくつかの素晴らしいスレッドマクロがあります。 ジュリアのエコシステムのどこかにそれらがありますか？

Clojureにはいくつかの素晴らしいスレッドマクロがあります。 ジュリアのエコシステムのどこかにそれらがありますか？

https://github.com/MikeInnes/Lazy.jl

Clojureにはいくつかの素晴らしいスレッドマクロがあります。 ジュリアのエコシステムのどこかにそれらがありますか？

少なくとも10個あります。
スレッドのさらに上にリストを投稿しました。
https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539

リストを編集して、他の2つのパッケージの代わりにLightQueryを使用できますか？

|>演算子はエリクサーから来ているので、匿名関数を作成する方法の1つからインスピレーションを得てみませんか？
Elixirでは、 &exprを使用して新しい無名関数を定義し、 &nを使用して位置引数をキャプチャできます（ &1が最初の引数、 &2が2番目の引数です。等。）
elixirには、書くべき余分なものがあります（たとえば、無名関数&(&1 + 1).(10)を呼び出すには、括弧の前にドットが必要です）。

しかし、これがジュリアでどのように見えるかです

&(&1 * 10)        # same as: v -> v * 10
&(&2 + 2*&5)      # same as: (_, x, _, _, y) -> x + 2*y
&map(sqrt, &1)    # same as: v -> map(sqtr, v)

したがって、 |>演算子をより適切に使用できます

1:9 |> &map(&1) do x
  x^2
end |> &filter(&1) do x
  x in 25:50
end

の代わりに

1:9 |> v -> map(v) do x
  x^2
end |> v -> filter(v) do x
  x in 25:50
end

2行目と3行目を.|> &(&1^2)または.|> (v -> v^2)置き換えることができることに注意してください

_プレースホルダーを使用した命題との主な違いは、ここでは位置引数を使用できることです。式の前にある&は、プレースホルダーの範囲を明確にします（読者とコンパイラ）。

私の例では&を使用しましたが、代わりに? 、 _ 、 $などを使用しても、場合。

Scalaは最初の引数に_ 、2番目の引数に_などを使用しますが、これは簡潔ですが、適用できる状況がすぐになくなります（繰り返したり逆にしたりすることはできません）。引数の順序）。 また、関数を式から明確にする接頭辞（上記の提案では& ）もありません。これは、実際には、その使用を妨げるもう1つの問題です。 開業医として、意図したインライン関数を余分な括弧と中括弧で囲み、認識されることを期待します。

したがって、このような構文を導入する際の最優先事項は、明確であることです。

しかし、引数のプレフィックスに関しては、 $はシェルスクリプトの世界で伝統があります。 使い慣れた文字を使用することは常に良いことです。 |>がElixirからのものである場合、ユーザーがすでにそのモードで考えているという考えで、それはElixirからも&を取得するための議論になる可能性があります。 （以前のElixirユーザーがたくさんいると仮定して...）

このような構文ではおそらくキャプチャできないことの1つは、N個の引数を取り、N未満を使用する関数を作成することです。本文の$1 、 $2 、 $3は3つの引数が存在しますが、これを4つの引数（最後に無視される）で呼び出される位置に配置したい場合、それを表現する自然な方法はありません。 （すべてのNに対して恒等関数を事前定義し、式をそれらの1つでラップすることを除いて。）ただし、これは、引数が1つしかない|>後に置くという動機付けの場合には関係ありません。

関数が配列であるかのようにColonを使用して、 getindexをオーバーロードする

struct LazyCall{F} <: Function
    func::F
    args::Tuple
    kw::Dict
end

Base.getindex(f::Function,args...;kw...) = LazyCall{typeof(f)}(f,args,kw)

function (lf::LazyCall)(vals...; kwvals...)

    # keywords are free
    kw = merge(lf.kw, kwvals)

    # indices of free variables
    x_ = findall(x->isa(x,Colon),lf.args)
    # indices of fixed variables
    x! = setdiff(1:length(lf.args),x_)

    # the calling order is aligned with the empty spots
    xs = vcat(zip(x_,vals)...,zip(x!,lf.args[x!])...)
    args = map(x->x[2],sort(xs;by=x->x[1]))

    # unused vals go to the end
    callit = lf.func(args...,vals[length(x_)+1:end]...; kw...)

    return callit
end

[1,2,3,4,1,1,5]|> replace![ : , 1=>10, 3=>300, count=2]|> filter[>(50)]  # == [300]

log[2](2) == log[:,2](2) == log[2][2]() == log[2,2]()  # == true

ラムダやスレッドマクロよりもはるかに遅いですが、とてもクールだと思います：p

ここでコメントしている人々に思い出させるために、 https：//github.com/JuliaLang/julia/pull/24990で関連するディスカッションを見て

また、 https：//github.com/c42f/Underscores.jlを試してみることをお勧めします_構文の関数チェーンに適した実装を提供します。 @jpivarskiはあなたの例に基づいていますが、かなり馴染みがあり快適だと思うかもしれません。