. 구문은 매우 유용하므로 함수 호출의 동의어로만 사용하지는 않습니다. 1.sum(2) 보다 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)을 중첩 할 때도 마찬가지 일 것입니다.하지만 기능 요청은 해당 기능을 확장하여 유형 제약 조건을 적용해야합니다. 도트 기능.

사람들이 좋아하는 사용 사례 중 하나는 "유창한 인터페이스"입니다. 메소드가 객체를 반환 할 때 OOP API에서 좋은 경우가 있으므로 some_obj.move(4, 5).scale(10).display() 와 같은 작업을 수행 할 수 있습니다.

저에게는 이것이 함수 구성으로 더 잘 표현된다고 생각하지만 |> 는 anon을 사용하지 않는 한 인수와 함께 작동하지 않습니다. 함수, 예를 들어 some_obj |> x -> move(x, 4, 5) |> x -> scale(x, 10) |> display , 이것은 매우 추합니다.

이런 종류의 것을 지원하는 한 가지 옵션은 평가하기 전에 |> 가 LHS를 RHS에 대한 첫 번째 인수로 밀어 넣었지만 지금처럼 간단한 함수로 구현할 수없는 경우입니다.

또 다른 옵션은 이러한 종류의 동작을 다음 식에 추가하는 일종의 @composed 매크로입니다.

이를 지원하는 책임을 라이브러리 디자이너에게 맡길 수도 있습니다.

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

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

따라서 객체를 제공하지 않으면 부분 함수 응용 프로그램 (1 인수의 함수를 반환)을 수행하고 일반 |> 체인 내에서 사용할 수 있습니다.

실제로 |> 의 정의는 지금 당장
당신이 요구하는 행동. 나는 그것을 할 것입니다.

2014 년 1 월 27 일 월요일, Spencer Russell [email protected]
썼다 :

사람들이 좋아하는 사용 사례 중 하나는 "유창한 인터페이스"입니다. 이것의
메소드가 객체를 반환 할 때 OOP API에서 때때로 좋으므로 할 수 있습니다.
some_obj.move (4, 5) .scale (10) .display () 같은 것들

저에게는 이것이 기능 구성으로 더 잘 표현된다고 생각하지만
anon을 사용하지 않는 한 |>는 인수와 함께 작동하지 않습니다. 함수, 예 : some_obj
|> x-> move (x, 4, 5) |> x-> scale (x, 10) |> 예쁜 디스플레이
추한.

이런 종류의 것을 지원하는 한 가지 옵션은 |> LHS를 다음과 같이 밀면
평가하기 전에 RHS에 대한 첫 번째 주장이지만,
지금처럼 간단한 기능으로 구현되었습니다.

또 다른 옵션은 이것을 추가하는 일종의 @composed 매크로입니다.
다음 식에 대한 일종의 동작

이를 지원하는 책임을 도서관으로 옮길 수도 있습니다.
디자이너가 정의 할 수있는

함수 move (obj, x, y)
# 개체 이동
종료

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

따라서 객체를 제공하지 않으면 부분 기능 적용을 수행합니다.
(1 인수의 함수를 반환하여) 다음 내부에서 사용할 수 있습니다
정상 |> 체인.

—
이 이메일에 직접 답장하거나 Gi tHub에서 확인하세요 .https : //github.com/JuliaLang/julia/issues/5571#issuecomment -33408448
.

ssfrr 나는 당신이 생각하는 방식을 좋아합니다! 나는 |> 함수 구성을 알지 못했습니다. 최근에 비슷한 논의가있는 것 같습니다 [https://github.com/JuliaLang/julia/issues/4963].

kmsquire 호출 함수에 매개 변수를 지정할 수 있도록 현재 함수 구성을 확장하는 아이디어를 좋아합니다. some_obj |> move(4, 5) |> scale(10) |> display 기본 지원은 폐쇄가 하나 줄어드는 것을 의미하지만 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 's 물결표로 전환하려면 다음을 수행하십시오.

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)

모두 유효한 해석입니다. 나는 스칼라가 이것을 결정하기 위해 함수의 타입 시그니처를 사용한다는 것을 기억하는 것 같다. 이것은 모든 유형을 알지 않고는 스칼라를 실제로 파싱 할 수 없다는 것을 의미하기 때문에 나에게 불행한 일이다. 우리는 그렇게하기를 원하지 않습니다 (그리고 우리가 원하더라도 할 수 없었습니다). 그래서 어떤 의미가 의도되었는지를 결정하기위한 순전히 구문 규칙이 있어야합니다.

맞아요, 얼마나 멀리 나가야하는지에 대한 모호성에 대한 당신의 요점이 보입니다. Clojure에서는 전체 표현식이 #(...) 로 래핑되어 있으므로 모호하지 않습니다.

줄리아에서 _를 신경 쓰지 않는 가치로 사용하는 것이 관용적입니까? somefunc 가 두 개의 값을 반환하고 첫 번째 값만 원하는 경우 x, _ = somfunc() 처럼?

이를 해결하려면 보간과 같은 사용법을 가진 매크로가 필요하다고 생각합니다.

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

그러나 다시 말하지만, 그 시점에서 꽤 시끄러워지고 있다고 생각합니다. 그리고 @$(move($, 4, 5)) 는 기존 구문 x -> move(x, 4, 5) 보다 더 예쁘고 더 명시적인 IMO보다 우리에게 아무것도주지 않는다고 생각합니다.

나는 이것이 중위 매크로의 좋은 응용 프로그램이라고 생각합니다. # 4498과 마찬가지로, 어떤 규칙이 함수를 매크로에도 적용되는 중위로 정의한다면, 스레딩 동작을 갖는 @-> 또는 @|> 매크로를 가질 수 있습니다.

Ya, 나는 infix 매크로 아이디어를 좋아하지만, inplace 매크로를위한 전체 시스템을 갖는 대신 새로운 연산자를이 용도로 도입 할 수 있습니다. 예를 들면
some_obj ||> move($,4,5) ||> scale($, 10) |> disp
아니면 그냥 |> 하되
x |> f 암시 적으로 x |> f($) 로 변환됩니다.
some_obj |> scale($,10) |> disp

여러분, 정말보기 흉해 보입니다 : |> ||> 등등.
지금까지 줄리아의 구문이 너무 명확해서 위에서 논의한 것들이 다른 것과 비교할 때 그렇게 예쁘지 않다는 것을 알았습니다.

Scala에서는 아마도 최악의 것입니다. 언어.

제안이 마음에 들지 않는 다니 유감입니다, Anton. 대체 제안을한다면 도움이 될 것입니다.

오 미안 해요, 불친절하게하려는 게 아니에요. 그리고 예-제안없는 비평가
쓸모가 없습니다.

불행히도 저는 언어를 만드는 과학자가 아니기 때문에
무엇을 제안해야할지 알고 있습니다.
일부 언어의 개체입니다.

나는 "언어를 구성하는 과학자"라는 문구를 좋아합니다. Matlab에 지친 수치 프로그래머보다 훨씬 더 웅장하게 들립니다.

거의 모든 언어가 OO 언어로 . 를 반복적으로 적용하거나 더 기능적인 언어 (Haskell, Scala, Mathematica 등)에서 해당 목적을위한 특수 구문을 사용하여 함수를 연결하는 방법이 있다고 생각합니다. 후자의 언어에도 익명 함수 인수에 대한 특수 구문이 있지만 Julia가 실제로 거기에 갈 것이라고 생각하지 않습니다.

나는 Spencer의 제안에 대한지지를 반복 할 것입니다- x |> f(a) get translate into f(x, a) , 이는 do 블록이 작동하는 방식과 매우 유사합니다 (그리고 이것은 a의 첫 번째 주장이 공통 주제를 강화합니다. 함수는 구문 설탕 목적을 위해 Julia에서 특권이 있습니다.) x |> f 는 x |> f() 약자로 간주됩니다. 간단하고 새로운 연산자를 도입하지 않으며 함수 체인을 원하는 대부분의 경우를 처리하고 이전 버전과 호환되며 기존 Julia 디자인 원칙에 적합합니다.

나는 또한 이것이 최고의 제안이라고 생각합니다. 주된 문제는 I / O 리디렉션 또는 기타 사용자 지정 목적과 같은 것에 대해 |> 정의를 배제하는 것 같습니다.

참고로 . 는 특별한 함수 연결 구문이 아니지만 왼쪽의 함수가 방금 수정 한 객체를 반환하면 그렇게 작동합니다. 이는 라이브러리 개발자가 의도적으로해야하는 일입니다.

마찬가지로 Julia에서 라이브러리 개발자는 여기에 언급 된 것처럼 N-1 개의 인수가 주어 졌을 때 1 개의 인수의 함수를 반환하도록 N 인수의 함수를 정의하여 |> 를 사용한 연결을 이미 지원할 수 있습니다.

그러나 함수가 가변 개수의 인수를 지원하도록 _ 원한다면 문제가 발생하는 것처럼 보이므로 인수 채우기를 수행 할 수있는 연산자가 있으면 좋을 것입니다.

@JeffBezanson , 중위 매크로를 수행하는 방법이 있으면이 연산자를 구현할 수있는 것 같습니다. 그것과 관련된 이데올로기 적 문제가 있는지 아십니까? 아니면 실행되지 않았습니까?

최근에 ~ 는 인수와 호출을 인용하도록 특수 케이스로 처리되었습니다.
기본적으로 @~ 매크로. |> 도 같은 일을하도록 만들 수 있습니다.

물론, 몇 달 안에 누군가는 <| 를 요구할 것입니다.

2014 년 2 월 6 일 목요일, Spencer Russell [email protected]
썼다 :

참고로. 특수 함수 체인 구문은 아니지만 발생합니다.
왼쪽의 함수가 객체를 반환하면 그렇게 작동합니다.
라이브러리 개발자가해야 할 일입니다.
의도적으로.

마찬가지로 Julia에서 도서관 개발자는 이미 연결을 지원할 수 있습니다.
|> 함수를 반환하기 위해 N 인수의 함수를 정의하여
여기에 언급 된대로 N-1 인수가 주어 졌을 때 1 개의 인수 중 하나가 될 것입니다 : https://github.com/JuliaLang/julia/issues/5571#issuecomment -33408448

기능이 지원하기를 _ 원 _한다면 문제가 발생하는 것 같습니다.
그러나 가변 개수의 args, 그래서 수행 할 수있는 연산자가
논증은 좋을 것입니다.

@JeffBezanson https://github.com/JeffBezanson , 이것은
중위 매크로를 수행하는 방법이 있으면 연산자를 구현할 수 있습니다. 당신은
이데올로기 적 문제가 있는지 아십니까? 아니면 실행되지 않았습니까?

—
이 이메일에 직접 답장을 보내거나 Gi tHub에서 확인하세요 .https : //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...)

이 동작은 두 번째 선언을 처리하는 @composable 매크로에 의해 처리 될 수 있다고 생각합니다.

중위 매크로 아이디어는 # 4498에서 논의되는 중위 함수 선언과 통합되는 상황에서 저에게 매력적입니다.

Julia 제작자가 객체가 자신의 메서드를 포함하도록 허용하지 않는 이유는 무엇입니까? 그 결정에 대한 자세한 내용은 어디에서 읽을 수 있습니까? 그 결정 뒤에 어떤 생각과 이론이 있습니까?

@meglio 는 일반적인 질문에 더 유용한 곳은 메일 링리스트 또는 StackOverflow julia-lang 태그입니다. 이 주제에 대한 이전 토론은 Stefan의 이야기 와 사용자 및 개발자 목록의 아카이브를 참조하십시오.

나에게 가장 직관적 인 것은 자리 표시자를
클로저의 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)

다음 줄의 밑줄 구멍을 채우기 위해 이전 줄의 "드롭 다운"식을 생각할 수 있습니다.

나는 결승전 주간 미루는 동안 지난 분기와 같은 작은 것을 스케치하기 시작했습니다.

|> 사용하여 oneliner 버전을 지원할 수도 있습니다.

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

@porterjamesj , 나는 그 아이디어를 좋아합니다!

나는 동의한다; 그것은 꽤 좋고 매력적인 일반성을 가지고 있습니다.
2014 년 2 월 7 일 오후 3:19에 "Kevin Squire" [email protected]이 작성했습니다.

@porterjamesj https://github.com/porterjamesj , 그 아이디어가 마음에 듭니다 !

이 이메일에 직접 답장하거나 Gi tHub에서 확인 하세요.
.

저는 @porterjamesj 의 아이디어가 신선한 공기를

Julia에서는 obj.method(args...) 패턴을 많이 수행하지 않고 대신 method(obj, args...) 패턴을 수행하기 때문에 Express에 대해 작동하는 객체를 반환하는 메서드가없는 경향이 있습니다. 메소드 체이닝의 목적. ( jQuery 는 일이며 자바 스크립트에서 환상적입니다). 그래서 우리는 여기에 타이핑을 많이 저장하지는 않지만, 함수 사이에 "파이프"를 설정하기 위해 이것은 정말 좋은 것 같습니다.

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 은 파서가 삽입하는 모든

@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 스레딩 매크로와 유사하지만 가독성 (개인 선호)을 위해 |> 기호를 유지합니다.

천천히 꾸러미로 만들 게요, 아마 언젠가는

또 다른 옵션은 다음과 같습니다.

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 인수는 내 예제의 두 번째 인수로 map 자동으로 주어 지므로 프로그래머가 다음과 같이 함수를 정의 할 필요가 없습니다. 그것을 지원하십시오.

그게 무슨 뜻이라고 제안합니까?

2015 년 6 월 5 일 오후 5시 22 분에 H-225 [email protected] 은 다음과 같이 썼습니다.

외부인으로서이를 수행하는 더 좋은 방법 중 하나는 F #의 처리 방식을 조정하는 것입니다.
물론 F #에는 커링 기능이 있지만이를 필요로하지 않도록 백엔드에서 일부 마법을 수행 할 수 있습니다. 핵심 언어가 아닌 연산자의 구현처럼.

이렇게하면 [1:10] |> map (e-> e ^ 2) 결과가 [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]이됩니다.

개인적으로 너무 장황하지 않고 멋지고 분명하다고 생각합니다.

분명히 result = map (sqr, [1:10])을 쓸 수 있지만 왜 파이프 라인 연산자가있는 것일까 요?
내가 놓친 게있는 건가?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

안녕하세요.
기본적으로 연산자는 다음 중 하나와 같이 작동합니다.

• 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.) 우리는 파이프 라이닝을 Julian Way로 장려하고 싶을 수 있습니다-더 읽기 쉽다고 주장 할 수 있습니다.
2.) Lazy.jl, FunctionalData.jl 및 내 자신의 Pipe.jl과 같은 것은 작동 할 표현식을 래핑하는 매크로가 필요하므로 읽기가 어렵습니다.

Infix Macros를 사용하면 답이 될 수 있습니다.
그리고 |>를 그렇게 정의하십시오.

|> (또는 do 블록의 사촌)이 코어에 속하는지 확실하지 않습니다.
그러나 파서 외부에서 정의하는 도구는 없습니다.

그런 종류의 파이프 라이닝 구문을 가질 수있는 능력은 매우 좋습니다. Lazy.j, FunctionalData.jl 및 Pipe.jl이 사용할 수있는베이스, 즉 x |> y(f) = y(f, x) 부분에 추가 할 수 있습니까? : +1 :

패키지에서 이것의 다양한 구현을 사용하는 코드를 살펴본 결과, 개인적으로 읽을 수없고 줄리안이 아닌 것 같습니다. 왼쪽에서 오른쪽으로 파이프 라인 말장난은 가독성에 도움이되지 않으며, 함수 평가를 위해 괄호를 사용하는 나머지 완벽하게 정상적인 코드와 비교하여 코드를 돋보이게 만듭니다. 차라리 두 스타일로 작성된 코드가 다른 스타일로 작성된 코드에 비해 안팎으로 보이는 두 가지 스타일로 이어지는 구문은 권장하지 않습니다. 우리가 이미 가지고있는 완벽하게 좋은 구문에 만족하고 일을 더 균일하게 보이도록 권장하는 것은 어떨까요?

뿡뿡
개인적으로 나는 다소 실용적인 관점에서 그것을 봅니다.
물론, 간단한 일을하고 있다면 그럴 필요는 없지만, 함수를 작성하는 경우 상당히 복잡하거나 긴 작업을 수행합니다. 그리고 그것이 파이프 라인 구문이 빛나는 곳이라고 생각합니다.

나는 당신이 의미하는 바를 이해합니다. 모든 것에 대해 하나의 함수 호출 구문을 가지고 있다면 그것은 _ 더 통일 될 것입니다 _. 하지만 개인적으로는 쉽게 이해할 수있는 [복잡한] 코드를 작성하는 것이 더 낫다고 생각합니다. 물론 구문과 그 의미를 알아야하지만 IMHO, |> 는 함수를 호출하는 방법보다 이해하기 더 어렵지 않습니다.

@tkelman 나는 다른 관점에서 그것을 볼 것입니다. 분명히 그런 스타일의 프로그래밍을 선호하는 사람들이 있습니다. 소스 코드에 대한 일관된 스타일을 Base에 원할 수도 있지만 이것은 선호하는 프로그래밍 스타일 _their_ Julia 응용 프로그램에 대한 파서 지원을 추가 한 것뿐입니다. 줄리아 인은 정말로 다른 사람들이 유익하다고 생각하는 것을 지시하거나 억압하기를 원합니까?
나는 유닉스에서 매우 유용한 파이프 라이닝을 발견했다. 그래서 비록 내가 언어에서 그것을 가능하게하는 프로그래밍 언어를 사용한 적이 없지만 적어도 의심의 이점을 줄 것이다.

우리는 함수 파이핑 연산자로 |> 를 가지고 있지만, 현재 수행되는 방식에 대한 구현 제한이있어 현재 매우 느립니다.

파이핑은 모든 것이 텍스트를 입력하고 출력하는 유닉스 셸에서 훌륭합니다. 더 복잡한 유형과 여러 입력 및 출력으로 인해 명확하지 않습니다. 그래서 우리는 두 가지 구문을 가지고 있지만 하나는 MIMO의 경우 훨씬 덜 의미가 있습니다. 강력한 매크로가 있으므로 대체 스타일의 프로그래밍 또는 DSL에 대한 파서 지원은 일반적으로 필요하지 않습니다.

좋아요, 감사합니다. @oxinabox 의 댓글로

그러나 파서 외부에서 정의하는 도구는 없습니다.

귀하가 언급 한 구현 제한을 제거하기 위해 어떤 조치를 취해야하는지 이해하고 있습니까?

이전 제안 중 일부는 잠재적으로 |> 인수를 함수 대신 매크로로 구문 분석하여 구현할 수 있습니다. |> 의 이전 명령 개체 파이핑 의미는 더 이상 사용되지 않으므로 실제로 0.5-dev로 다른 작업을 수행 할 수 있습니다.

그러나이 선택은 ~ 의 특수한 구문 분석을 꽤 많이 상기시켜줍니다. 제가 다른 곳에서 언급 한 이유 때문에 실수라고 생각합니다.

~ 파싱은 미친 짓이며 기본 기능입니다. _ , _1 , _2 하면 _more_ 합리적으로 보입니다 (특히 이러한 변수가 범위의 다른 곳에서 정의 된 경우 발생하는 경우). 그래도 더 효율적인 익명 기능을 갖기 전까지는 작동하지 않을 것 같습니다 ...

|> 인수를 함수 대신 매크로로 구문 분석하여 구현

그렇게하지 않는 한!

파싱 ​​~ 그냥 미쳤어, 기본 기능

비트 버전의 단항 연산자입니다. Infix 바이너리 ~ 는 매크로로 구문 분석합니다. ref https://github.com/JuliaLang/julia/issues/4882 , 이것은 ASCII 연산자 (https://github.com/ JuliaLang / julia / pull / 11102 # issuecomment-98477891).

뿡뿡

그래서 우리는 두 가지 구문을 가지고 있지만 하나는 MIMO의 경우 훨씬 덜 의미가 있습니다.

3 구문. 거의.
파이프 인, 일반 함수 호출 및 Do- 블록.
매크로도 다른 규칙을 사용하기 때문에 4에서도 논쟁의 여지가 있습니다.

나를 위해
읽기 순서 (즉, 왼쪽에서 오른쪽으로) == 응용 프로그램 순서는 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의 경우 그렇지 않습니다.

Julia는 일을하는 여러 가지 올바른 방법에 이미 정착 한 것 같습니다.
100 % 확신하지 못하는 것은 좋은 일입니다.

내가 말했듯이 나는 Pipe와 Do 블록이 주 언어에서 벗어나는 것과 비슷합니다.

Do-blocks에는 매우 유용한 사용 사례가 많이 있지만 첫 번째 입력을 함수로 사용해야한다는 점이 약간 짜증이났습니다. 접미사가 data.map(f).sum() 인 D 스타일 UFCS, 인기가 있다는 것을 알고 있지만 여러 디스패치와 효과적으로 결합 할 수 없다고 생각합니다.)

파이핑은 곧 폐기 될 수 있으며 Pipe.jl과 같은 DSL에서 사용할 패키지로 남겨질 수 있습니다.

Julia는 일을하는 여러 가지 올바른 방법에 이미 정착 한 것 같습니다.
100 % 확신하지 못하는 것은 좋은 일입니다.

커뮤니티 전체의 스타일 가이드를 엄격하게 시행 할 수 있는지 여부에 대한 질문과 관련이 있습니다. 지금까지 우리는 여기서 많이 해보지 않았지만 장기적인 패키지 상호 운용성, 일관성 및 가독성을 위해 커뮤니티가 성장함에 따라 점점 더 중요해질 것이라고 생각합니다. 당신이 당신의 코드를 읽을 수있는 유일한 사람이라면, 미쳐서 당신이 원하는 것은 무엇이든하십시오. 그렇지 않다면 균일 성을 위해 가독성이 약간 더 나빠지는 (자신의 의견으로는) 거래 할 가치가 있습니다.

트윗 담아 가기
아직 언어 나 "핵심"패키지에 포함되지 않아야하는 명확한 이유를 아직 찾지 못했습니다. [예 :베이스]
개인적으로 |> 매크로를 만드는 것이 답이라고 생각합니다.
아마도 이것과 _like_ 뭔가? (나는 마스터 Julia 프로그래머가 아닙니다!)

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에서는 두 번 정의 할 수 없었습니다. 한 번은 기호로, 한 번은 식으로 정의 할 수 없었습니다. Union 대한 나의 [제한된] 이해는 그것을 사용함으로써 성능 저하가 있다는 것입니다. 그래서 나는 그것이 제 장난감 예제 코드에서 수정해야 할 것이라고 생각하고 있습니다.

물론이를위한 사용 구문에 문제가 있습니다.
예를 들어 log(2, 10) 해당하는 항목을 실행하려면 @|> 10 log(2) 를 작성해야하는데, 여기에서는 바람직하지 않습니다.
내 이해는 함수 / 매크로를 "고정 불가능"으로 표시 할 수 있어야한다는 것입니다. 그러면 다음과 같이 작성할 수 있습니다. 10 |> log(2) . (잘못된 경우 수정!)
예를 들어, 알고 있습니다. 나는 지금 좋은 것을 생각할 수 없다! =)

내 예에서 다루지 않은 한 영역을 지적하는 것도 가치가 있습니다.
예 :

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 분에 H-225 [email protected] 은 다음과 같이 썼습니다.

언어에 포함되지 않아야하는 명확한 이유를 아직 찾지 못했습니다.

이것은 프로그래밍 언어 디자인에 대한 잘못된 정신적 입장입니다. 질문은 "왜?" "왜 안돼?" 모든 기능에는 포함에 대한 설득력있는 이유가 필요하며, 정당한 이유가 있더라도 추가하기 전에 오랫동안 열심히 생각해야합니다. 그것없이 살 수 있습니까? 동일한 작업을 수행하는 다른 방법이 있습니까? 기존 기능에 대해 더 좋고 더 일반적이거나 더 직교하는 기능의 다른 변형이 있습니까? 이 특별한 아이디어가 일어날 수 없다고 말하는 것은 아니지만 "왜 안 되는가?"보다 훨씬 더 나은 정당화가 필요합니다. 일반적인 구문보다 낫지 않은 몇 가지 예가 있습니다.

질문은 "왜?" "왜 안돼?"

+ 1_000_000

과연.
이 꽤 잘 알려진 블로그 게시물을 참조하십시오.
모든 기능은 -100 점으로 시작합니다.
언어에 추가 할 가치가 있으려면 크게 개선해야합니다.

FWIW, Pyret (http://www.pyret.org/)은 몇 달 전에이 정확한 논의를 거쳤습니다. 이 언어는 원래 사람들이 |> 로 제안하는 방식과 거의 같은 방식으로 작동했던 "캐논볼"표기법을 지원합니다. Pyret에서

[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 Fortran IV에서 천공 카드로 프로그래밍하는 것보다 훨씬 더 나빠 보입니다. _1, _2 등과 같은 일부 구문이 여러 반환을 분리 할 수 ​​있는지 궁금하거나 내 부분에서 어리석은 아이디어입니까?

@simonbyrne 훌륭합니다. 이를 문자열 매크로로 구현하는 것은 놀라운 GSoC 프로젝트가 될 것입니다.

인수없이 sum ()이 호출되는 이유는 무엇입니까?

암시 적 인수도 do 표기법에 대해 더 혼란스러운 점 중 하나라고 생각하므로 동일한 규칙을 사용할 수 있으면 좋을 것입니다 (훨씬 더 어렵다는 것을 알고 있지만, 이미 언어로 구워 졌기 때문에).

@simonbyrne 당신은 그것이 모호하지 않은 방식으로 할 수 있다고 생각하지 않습니까? 만약 그렇다면, 그것이 좀 더 논리적이고, 더 일반적이며, 연결과 일관되게 만들 수 있다면 그것은 깨질 가치가 있다고 생각합니다 (현재 do 표기법).

@simonbyrne 네, 전적으로 동의합니다. 나는 현재 do 표기법의 동기를 이해하지만 그것이 구문 체조를 정당화하지 않는다는 것을 강하게 느낍니다.

@samuela 에 관한 map (f, _) vs just map (f). 나는 어떤 마술 desugaring이 혼란 스러울 것이라는 데 동의하지만 map (f)는 존재해야한다고 생각합니다. 필요하지 않으며 설탕은 매핑에 간단한 방법을 추가합니다.
예

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

즉, 맵은 함수를 취한 다음 반복 가능한 (다소 많거나 적은) 작업을 수행하는 함수를 반환합니다.

더 일반적으로 저는 |> 항상 데이터를 첫 번째 인수 (또는 이와 유사한)에 매핑하는 일종의 규칙보다는 "편리한"메소드가 추가 된 함수에 의존해야한다고 생각합니다.

같은 맥락에서

type Underscore end
_ = Underscore()

함수는 특정 인수에서 밑줄을 사용하고 더 적은 인수를 사용하는 함수를 반환하는 메서드를 가져야 / 할 수 있다는 일반적인 규칙입니다. n 개의 인수를받는 각 함수에 대해 2 ^ n 개의 메서드를 추가해야하기 때문에 이것이 좋은 생각이라고 확신하지 않습니다. 그러나 그것은 하나의 접근 방식입니다. 너무 많은 메서드를 명시 적으로 추가하지 않고 메서드 조회에 연결하여 인수가 Underscore 유형이면 적절한 함수가 반환 될 수 있는지 궁금합니다.

어쨌든, 콜 러블을 가져 와서 콜 러블을 반환하는 맵과 필터의 버전을 갖는 것이 합리적이라고 생각합니다. Underscore가있는 것은 작동 할 수도 있고 작동하지 않을 수도 있습니다.

안녕하세요.
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는 런타임 유형 정보로 이들을 식별하지만 일반 프로그래머가 소스 코드를 읽는 것은 완전히 불분명합니다.

제대로 된 밑줄 커링을 얻는 가장 좋은 방법은 단순히 그것을 언어에 통합하는 것입니다. 결국 컴파일러에 대한 매우 간단한 변경이 될 것입니다. 함수 애플리케이션에 밑줄이 나타날 때마다 빼내어 람다를 만듭니다. 나는 이것을 몇 주 전에 구현하기 시작했지만 안타깝게도 앞으로 몇 주 동안 그것을 살펴볼 충분한 여유 시간이 없을 것이라고 생각합니다. Julia 컴파일러에 익숙한 사람에게는 작업을 수행하는 데 오후가 더 걸리지 않을 것입니다.

@samuela
"람다를 만들려면 빼내십시오"라는 의미를 명확히 할 수 있습니까? - 궁금해. 저도 그것이 어떻게 구현 될 수 있을지 궁금했습니다.

안녕하세요.
아-알겠습니다. 아마도 다음과 같은 것을 사용할 수 있습니다 : filter(_ < 5, [1:10]) => [1:4] ?
개인적으로 나는 filter(e -> e < 5, [1:10]) 더 읽기 쉽다고 생각합니다. 더 일관 적-덜 숨겨진 의미, 내가 당신에게 허락하지만 더 간결합니다.

정말 빛나는 예가 없다면?

@samuela

또한 map에 대한 제안은 map 및 filter와 같은 기본 기능을 사용하여 map (f)에 대한 해결 구문을 제공한다고 생각하지만 일반적으로 수동 밑줄 접근 방식과 동일한 복잡성 문제를 겪습니다.

나는 이것이 일반적으로 map 및 filter 및 아마도 명백해 보이는 다른 몇 곳에서만 수행되도록 제안하지 않았습니다. 저에게 map 가 작동하는 방식입니다. 함수를 받아 함수를 반환합니다. (그것이 Haskell이하는 일입니다.)

우아함은 말할 것도없고 매우 성 가실 것입니다.

나는 우리가 그것에 동의한다고 생각합니다. 일부 인수가 Underscore 유형 인 메서드 호출을 처리하기 위해 언어에 무언가를 추가하는 방법이 있기를 바랍니다. 더 생각해 보면 특수 문자가 자동으로 람다로 확장되거나 자동으로 람다로 확장되는 특수 유형이있는 것으로 귀결된다고 생각합니다. 나는 어느 쪽이든 강하게 느끼지 않습니다. 두 가지 접근 방식에 대한 장단점을 볼 수 있습니다.

@ 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 * _
  |> ...

필자는이 밑줄 구문 (또는 약간의 변형)을 지원하는 언어에서 무의식적으로 계속 사용하고 있으며이를 지원하지 않는 언어로 전환 할 때 얼마나 도움이되는지 깨달았습니다.

내가 아는 한 현재 Julia에서이 문제를 해결하려는 라이브러리 / 접근법이 최소 3.5 개 있습니다. Julia의 기본 제공 |> 함수, Pipe.jl, Lazy.jl 및 Julia의 기본 제공 do 대한 0.5 정신적으로 비슷한

@samuela 이 아이디어를 구현하고 싶다면 FunctionalData.jl을 사용해 볼 수 있습니다. 예제는 다음과 같습니다.

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

마지막 부분은 입력을 두 번째 매개 변수로 파이프하는 방법을 보여줍니다 (기본값은 인수 1이며이 경우 _ 는 생략 할 수 있음). 피드백을 대단히 감사합니다!

편집 : 위의 내용은 다음과 같이 간단히 다시 작성됩니다.

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

Base.map 및 필터 대신 FunctionalData.map 및 필터를 사용합니다. 주요 차이점은 인수 순서이고 두 번째 차이점은 인덱싱 규칙입니다 (문서 참조). 어쨌든 Base.map은 인수 순서를 반대로하여 간단히 사용할 수 있습니다. @p 은 매우 간단한 재 작성 규칙입니다 (왼쪽에서 오른쪽이 안쪽에서 바깥쪽으로 바뀌고 간단한 커링도 지원됩니다. <strong i="17">@p</strong> map data add 10 | showall

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

Hack은 https://github.com/facebook/hhvm/issues/6455 와 같은 내용을 소개 할 수 있습니다 $$ 를 사용하고 있습니다 ( $ 는 이미 너무 오버로드되었습니다).

FWIW, 나는 이것에 대한 Hack의 솔루션을 정말 좋아합니다.

나는 그것을 좋아한다. 나의 주요 예약은 변수 / 슬롯에 _ 를 사용할 수있는 더 간결한 람다 표기법을 좋아한다는 것이며, 이것이 충돌하지 않는지 확인하는 것이 좋다.

__ 사용할 수 없습니까? 당신이 생각하는 람다 구문은 무엇입니까? _ -> sqrt(_) ?

물론 가능합니다. 이 구문은 이미 작동합니다. 화살표가 필요하지 않은 구문에 관한 것이므로 map(_ + 2, v) 줄을 따라 무언가를 작성할 수 있습니다. 실제 문제는 _ 주변 표현의 양

Mathematica에는 익명 인수에 대한 유사한 시스템이 없습니까? 어떻게
그들은 그 인수의 경계 범위를 처리합니까?
2015 년 11 월 3 일 화요일 오전 9:09 Stefan Karpinski [email protected]
썼다 :

물론 가능합니다. 이 구문은 이미 작동합니다.
화살표가 필요하지 않으므로 선을 따라 무언가를 쓸 수 있습니다.
지도 (_ + 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 Jonathan Malmaud [email protected] 은 다음과 같이 썼습니다.

Mathematica에는 익명 인수에 대한 유사한 시스템이 없습니까? 어떻게
그들은 그 인수의 경계 범위를 처리합니까?
2015 년 11 월 3 일 화요일 오전 9:09 Stefan Karpinski [email protected]
썼다 :

물론 가능합니다. 이 구문은 이미 작동합니다.
화살표가 필요하지 않으므로 선을 따라 무언가를 쓸 수 있습니다.
지도 (_ + 2, v)의 실제 문제는 주변이 얼마나
_가 속한 표현식입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/JuliaLang/julia/issues/5571#issuecomment -153383422.

Mathematica는 & 를 사용하여 구분합니다.

짧은 람다 구문 (임의의 표현식을 취하고 익명 함수를 반환 할 수 있음)처럼 일반적인 작업을 수행하는 대신 허용 가능한 표현식을 함수 호출로 제한하고 허용 가능한 변수 / 슬롯을 전체 매개 변수로 제한하여 구분 기호 문제를 해결할 수 있습니다. 이것은 Open Dyln 이라는 매우 깨끗한 다중 매개 변수 커링 구문을 제공합니다. _ 전체 매개 변수를 대체하기 때문에 구문이 최소화되고 직관적이며 모호하지 않을 수 있습니다. map(_ + 2, _) 는 x -> map(y -> y + 2, x) 변환됩니다. 람다 화하려는 대부분의 비 함수 호출 표현식은 어쨌든 -> 또는 do 더 길고 더 친숙 할 것입니다. 나는 유용성과 일반성의 절충이 그만한 가치가 있다고 생각합니다.

@durcan , 유망하게 들리 네요 – 규칙에 대해 좀 더 자세히 _ 의 인수 내부에 체류 map 두 번째는 전체 소비 동안 map 표현을? "수용 할 수있는 표현식을 함수 호출에 제한"이 무엇을 의미하는지, "허용 가능한 변수 / 슬롯을 전체 매개 변수에 제한"이 무엇을 의미하는지 명확하지 않습니다.

좋아, 나는 Dylan 문서의 일부를 읽고 규칙을 얻은 것 같지만 map(_ + 2, v) 작동하지만 map(2*_ + 2, v) 작동하지 않는지 궁금합니다.

_ + 2 + _ 는 (x,y) -> x + 2 + y 하는 반면 _ ⊕ 2 ⊕ _ 는 y -> (x -> x + 2) + y 의미하는 매우 간단한 비즈니스도 있습니다. + 및 * 이기 때문입니다. 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의 거의 모든 구문은 다른 프로그래밍 언어를 사용했다면 매우 친숙합니다. 이와 같은 구문 설탕을 보는 사람들은 몇 개의 문자를 저장하는 "이점"이 무엇인지 알지 못할 것입니다.

나를 조금 덜 행복하게 만드는 예 :

• 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 명령을 복구하십시오.

2015 년 11 월 17 일 화요일 오후 12:09 Stefan Karpinski [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 등). 예를 들어 fun(_1) 대해 x -> fun(x) , 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가되는 것은 미친 혼란스러워 보입니다.

이 동일한 간결한 스칼라 _ -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과 같습니다.

연결에는 두 가지 모드가 있습니다.
1) 첫 번째 인수로 삽입하고 나타나는 모든 점에 연결합니다.
2) 나타나는 점에만 연결.

기본 모드는 모드 1입니다. 그러나 점이 연결되는 함수에 대한 인수로 단독으로 나타나면 magrittr은 체인의 해당 단계에 대해 모드 2로 전환됩니다.

그래서

2 %>% `-`(1) 

2-1,

과

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

또한 2-1입니다.

모드 2는 대괄호로 묶어서 지정할 수도 있습니다.

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

2-(2-1)과 동일합니다.

또한 모드 1과 모드 2 사이를 현명하게 전환 할 수 있다는 점은 Julia가 첫 번째 위치에 연결될 가능성이있는 논쟁에 대해 일관성이 없다는 문제를 거의 완전히 해결합니다. 또한 대괄호가 코드 덩어리를 평가할 수 있다는 점을 잊었습니다. 다음은 magrittr 매뉴얼의 예입니다.

홍채 %> %
{
n <-샘플 (1:10, 크기 = 1)
H <-머리 (., n)
T <-꼬리 (., n)
rbind (H, T)
} %> %
요약

이것은 현재로서는 반쯤 형성된 아이디어에 불과하지만, 누락 된 값이 a를 반환하도록 Tuple 생성자를 수정하여 "간결한 람다"및 "더미 변수"문제를 동시에 해결할 수있는 방법이 있는지 궁금합니다. 튜플 대신 튜플을 반환하는 람다? 따라서 (_, 'b', _, 4) 는 (x, y) -> (x, 'b', y, 4) 반환합니다.

그런 다음 foo(a, b) " foo 를 Tuple에 적용 하거나 (a, b) 인수가 함수이면 foo 를 적용하도록 함수 호출의 의미를 미묘하게 변경하면 foo(_, b, c)(1) 이 apply(foo, ((x) -> (x, b, c))(1)) .

나는 이것이 여전히 중위 표기법 문제를 해결하지 못한다고 생각하지만 개인적으로 괄호로 묶인 함수 호출에서만 작동하는 간결한 람다에 만족할 것입니다. 결국 1 + _ 는 절대적으로 필요한 경우 항상 +(1, _) 다시 작성할 수 있습니다.

@jballanc 그러나 튜플 구성과 함수 응용 프로그램은 완전히 다른 두 가지 개념입니다. 적어도 줄리아의 의미론에 대한 나의 이해가 심각한 결함이 아니라면.

@samuela 내가 의미하는 바는 foo(a, b) 이 foo((a, b)...) 와 동일하다는 것입니다. 즉, 함수에 대한 인수는 실제로 Tuple이 생성되지 않더라도 개념적으로 Tuple로 간주 될 수 있습니다.

@ 이 토론을 읽으려고했지만 말한 모든 내용을 추적하기에는 너무 깁니다. 여기에서 필요 이상으로 반복하면 죄송합니다.

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 등과 즉시 호환됩니다. al., _ 매개 변수 범위 지정의 복잡성을 추가하지 않고 이미 존재하는 do 구문을 고려할 때 코드 독자에게 불합리한 개념적 부담을주지 않는다고 생각합니다.

이와 같은 파이프 연산자를 사용하는 주된 동기는 수집 파이프 라인 (# 15612 참조)입니다. 이것은 믿을 수 없을 정도로 강력한 구조라고 생각하며, 많은 언어에서 기반을 확보하고있는 것입니다 (사람들이 원하는 기능이고 그들은 이해할 것입니다).

이것이 https://github.com/MikeInnes/Lazy.jl 의 @>> 매크로입니다 .

@malmaud 좋아요 ! 나는 이것이 이미 가능하다는 것을 좋아합니다 : D

그러나이 두 변형의 가독성 차이는 정말 큽니다.

# 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
• bramtayl의 LightQuery

비 패키지 프로토 타입

• kmsquires의 작곡 Marco
• porterjamesj의 스레딩 매크로
• oxinabox의 간결한 람다 - @StefanKarpinski에서의 https://github.com/JuliaLang/julia/issues/5571#issuecomment -157424665
• fcard의 GeneratedPartials- 예제

관련 :

• andyferris의 기능 구성 연산자, PR
• MikeInnes의 Flow.jl

아마도 이것은 상위 게시물 중 하나에서 편집되어야합니다.

업데이트 날짜 : 2020 년 4 월 20 일

이것은 부분적 응용 프로그램을 구현하려는 실제 시도보다 유형 시스템 실험에 가깝지만 여기에 이상한 것이 있습니다 : https://gist.github.com/fcard/b48513108a32c13a49a387a3c530f7de

용법:

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...

확실히 구현 제안은 아니지만 가지고 노는 것이 재미 있고 누군가가 좋은 아이디어의 절반을 얻을 수 있습니다.

추신 @partialize 는 정수 배열 리터럴 및 범위에서도 작동한다는 것을 잊었습니다.

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

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

좋아요, 저는 함수 구성에 대해 생각하고 있습니다. IMO는 SISO 케이스에서 명확하지만 작은 체인 코드 블록에서 Julia의 MISO (준 MIMO?)를 사용하는 방법을 생각하고 있었던 것 같습니다.

나는 REPL을 좋아합니다. 많이. 귀엽고 멋져요. MATLAB이나 python 또는 셸처럼 실험 할 수 있습니다. 저는 패키지 나 파일에서 코드를 가져와 여러 줄의 코드라도 REPL에 복사하여 붙여 넣는 것을 좋아합니다. REPL은 모든 라인에서 그것을 평가하고 무슨 일이 일어나고 있는지 보여줍니다.

또한 모든 표현식 다음에 ans 반환 / 정의합니다. 모든 MATLAB 사용자는이를 알고 있습니다 (이 단계에서는 잘못된 주장입니다!). 아마도 대부분의 Julia 사용자는 전에 보거나 사용했습니다. 나는 내가 위에서 쓴 것에 또 다른 단계를 추가하고 싶다는 것을 깨닫고 조각 현명한 것을 가지고 노는 이상한 상황에서 ans 를 사용합니다. 나는 그것을 사용하는 것이 일종의 파괴적인 것을 싫어하기 때문에 가능한 한 피하는 경향이 있지만 여기에서 _every_ 제안은 단지 한 단계의 구성의 반환 수명을 다루고 있습니다.

나에게 _ 마법이란 _odd_에 불과하지만 많은 사람들이 동의하지 않을 수 있다는 것을 이해합니다. 따라서 패키지에서 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 a의 이름으로 기능을 바인딩 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 를 입력 할 필요가 없습니다. 하지만 해석을하지 않는 것에 대한 좋은 점은 "정적 메서드"가 self 가없는 impl 함수라는 것입니다. (Rust는 new 공장에 사용합니다.)

Rust와 달리 Julia는 types 에 계층 구조가 있습니다. 코드 중복을 피하기 위해 impls 에 유사한 계층 구조를 가질 수도 있습니다. 표준 OOP는 type 와 impl 메소드 계층을 정확히 동일하게 만들어서 구축 할 수 있지만,이 엄격한 미러링은 필요하지 않으며 경우에 따라 바람직하지 않습니다.

이것에 대해 한 가지 끈적 거리는 점이 있습니다. getTrack 및 getHit 대신 impl 에서 함수 이름을 track 및 hit 로 지정 impl 가정하겠습니다 track 및 hit 에서 type . 그러면 event.track 가 배열이나 함수를 반환합니까? 즉시 함수로 사용하면 명확화에 도움이 될 수 있지만 types 는 Function 개체도 포함 할 수 있습니다. 그냥 포괄적 인 규칙을 적용 할 수도 있습니다. 점 다음에 해당하는 impl 를 먼저 확인한 다음 해당하는 type ?

다시 생각하면 개념적으로 동일한 객체 ( type 및 impl )에 대해 두 개의 "패키지"를 사용하지 않으려면 다음과 같이하십시오.

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)

내가 더 잘 될 수 녹의 접근 방식과 같은 무언가를 볼 수있는 가장 큰 이유는 같은 것들을 할 수있을 수 있도록이 효과적으로 기능을위한 공간으로 왼쪽을 사용한다는 것입니다 parser.parse 기존과 충돌하지 않고 Julia Base.parse 함수. Rust 제안과 Hack 스타일 파이핑을 모두 제공하는 데 찬성합니다.

@tlycken 우선 순위에 따라 모호한 구문입니다.
|> 대 호출의 우선 순위를 기억하는 것은 실제로 힌트를 제공하지 않기 때문에 혼란 스러울 수 있습니다.
(또는 제안 된 다른 몇 가지 옵션을 수행하지 마십시오.)

중히 여기다

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) desugars to foo(10, 2) 거의 같은 방식으로 foo(10) do x; bar(x); end desugars to foo(x -> bar(x), 10) . 이는 통화 우선 순위보다 파이프 우선 순위를 의미합니다 (내 생각에는 어쨌든 가장 합리적이라고 생각합니다).

구문의 주제로 볼 때 . 는 시각적으로 덜 거슬 리고 |> 보다 확실히 더 표준 적입니다. 공백없이 (각각 한 문자 씩) . 로 구분 된 유창한 함수 체인을 작성할 수 있으며 누구나 읽을 수 있습니다. |> 를 사용하면 공백 (각 문자 4 개)을 추가해야하며 대부분의 프로그래머에게 시각적 속도 향상이됩니다. 쉘 스크립팅의 | 대한 비유는 좋지만 > 때문에 즉시 인식 할 수 없습니다.

이 스레드를 올바르게 읽고 점에 대한 주장은 type 에서 멤버 데이텀을 가져와야하는지 아니면 impl (내 첫 번째 제안)에서 멤버 함수를 가져와야하는지 모호하다는 것입니다. 네임 스페이스 (제 두 번째 제안)? 두 번째 제안에서, 함수는에 의해 생성 된 함수의 이름 공간 정의 type _after_ 정의되어야 type 는 바로 멤버 데이텀을 압도하는 것을 거부 할 수 있도록 정의된다.

네임 스페이스 점 (제 두 번째 제안)과 |> 모두 추가하면 괜찮습니다. 둘 다 유창한 연결에 사용할 수 있다는 사실에도 불구하고 목적과 효과가 다소 다릅니다. 그러나 위에서 설명한 |> 는 do 와 완전히 대칭이 아닙니다. do 는 채우는 인수가 함수 여야하기 때문입니다. event |> getTrack(12) |> getHit(43) 라고 말하면 |> 는 비 함수 ( Events 및 Tracks )에 적용됩니다.

event |> getTrack(12) |> getHit(43) 라고 말하면 |> 는 비 함수에 적용됩니다 ( Events 및 Tracks ).

실제로는 아닙니다. 왼쪽 피연산자를 함수 호출에 대한 마지막 인수로 삽입하여 _ 오른쪽에있는 함수 주문에 적용됩니다. event |> getTrack(12) 은 (는) 왼쪽에있는 것이 아니라 오른쪽에있는 것이기 때문에 getTrack(12, event) 입니다.

이것은 a) 함수 호출보다 우선 순위 (호출을 다시 작성하기 때문에), 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 아닌 두 번째 인수에 Event 넣는 것입니다. 방금 do 와 첫 번째 인수로 동등한 것을 시도했고 Julia 0.4는 인수가 함수 여야한다고 불평했습니다. (아마도 때문에 do event end 함수가 반환로 해석됩니다 event , 대신 event 자체.)

나에게 함수 체인은 점 ( . ) 구문에 대해 논의되고있는 내용과는 별개의 문제인 것 같습니다. 예를 들어, @jpivarski , 새로운 기능없이 Julia의 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!"

대화를 너무 많이 방해하지 않고 우리가 정말로 해결해야 할 것은 Julia에서 효율적인 함수 커링을 수행하는 방법이라고 제안합니다. 함수를 커리하는 좋은 방법이 있다면 함수 체인에서 인수의 위치를 ​​지정하는 방법에 대한 질문이 사라질 것입니다. 또한 위와 같은 구조는 기능 본체를 지정하고 단순히 구성시 "self"로 커리 할 수 ​​있다면 더 깨끗합니다.

@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에서 메소드 구문을 사용 하여 수행됩니다. 일부 OO 언어 에서처럼 체인을 만드는 데 사용할 수 있지만 개념적으로 함수 체인과 구별됩니다. 개별적으로 문제를 해결하는 것이 가장 좋습니다.

나는 이것을 읽고 몇 가지 관련 문제를 읽었으며 여기에 내 제안이 있습니다.

기본 체이닝 :
in1 |> function1
같음 : in1 |> function1(|>)

in2 |> function2(10)
동일 : in2 |> function2(|>,10)

더 많은 연결 :
in1 |> function1 |> function2(10,|>)

체인 분기 및 병합 :
분기로 두 번 분기 out1 , out2 :
function1(a) |out1>
function2(a,b) |out2>

분기 out1 및 out2 :
function3(|out1>,|out2>)

게으름은 어떻습니까?
function!(mutating_var) 컨벤션과 같은 것이 필요합니까?
게으른 함수의 경우 function?() ...

그리고 들여 쓰기를 적절하게 사용하면 관련 호출 그래프에서 데이터 종속성을 시각적으로 쉽게 추적 할 수 있습니다.

방금 기존 |> 연산자를 사용하여 함수 연결 패턴을 가지고 놀았습니다. 예를 들어 다음 정의는 다음과 같습니다.
````줄리아

필터

불변 MyFilter {F}
flt :: F
종료

함수 (mf :: MyFilter) (소스)
필터 (mf.flt, 소스)
종료

function Base.filter (flt)
마이 필터 (flt)
종료

취하다

불변 MyTake
n :: Int64
종료

function (mt :: MyTake) (소스)
take (source, mt.n)
종료

function Base.take (n)
MyTake (n)
종료

지도

변경 불가능한 MyMap {F}
f :: F
종료

함수 (mm :: MyMap) (소스)
지도 (mm.f, 소스)
종료

function Base.map (f)
마이 맵 (f)
종료
enable this to work: 줄리아
1:10 |> filter (i-> i % 2 == 0) |> take (2) |> map (i-> i ^ 2) |> 수집
`` 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 등은 하나의 인수를 사용하는 익명 함수를 반환 할 수 있으며 이러한 옵션 중 어느 것이 더 성능이 좋은지 확실하지 않습니다.

내 예제에서 나는 덮어있어 map(f::Any) 자료, 정말 기존의 정의를 이해하지 않는 map does ...

나는 방금이 패턴을 생각 해냈고, 내 다소 피상적 인 모습은 그런 것에 대한 어떤 논의도 보여주지 않았습니다. 사람들은 어떻게 생각합니까? 이것이 유용할까요? 사람들이 이것의 단점을 생각할 수 있습니까? 이것이 효과가 있다면 기존 디자인이 실제로 매우 포괄적 인 연결 스토리를 가능하게 할만큼 충분히 유연할까요?

이것은 임의의 기능에 대해 작동하지 않는 것 같으며 MyF가 정의 된 기능에만 적용됩니까?

예,이 기능은 옵트 인 기능에만 적용됩니다. 분명히 매우 일반적인 솔루션은 아니며 어떤 의미에서는 벡터화와 같은 이야기이지만, 우리가 바라는 모든 것이 1.0에 적합하지는 않다는 점을 감안할 때이 패턴은 사람들이 의존해야하는 모든 시나리오를 가능하게 할 수 있습니다. 지금 매크로.

본질적으로 아이디어는 필터와 같은 함수가 소스 인수없이 호출되면 functor를 반환한다는 것입니다. 그러면 이러한 functor는 모두 하나의 인수, 즉 |>의 왼쪽에서 "오는"인수를받습니다.

이것이 바로 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) 낮 춥니 다. 그러나 위의 긴 논의에서 언급했듯이 까다 롭습니다.

이것이 그렇게 복잡 할 필요는 없습니다. 함수는 클로저로 커링을 선택할 수 있습니다.

예, 위에서 이미 제안했지만이 둘 사이에 성능 차이가 있는지 확실하지 않았습니다.

어떤 인수가 우선 순위를 가져야합니까?

예, 그리고 실제로 filter 및 take 와 같은 것이 있습니다. 한 경우에는 컬렉션을 첫 번째로, 다른 하나는 마지막 인수로 사용합니다. 적어도 반복자와 같은 작업의 경우 일반적으로 해당 질문에 대한 명확한 답변이있을 수 있습니다.

_ 가 사용 가능한 특수 기호가되면

예, 더 일반적인 해결책이 있다는 데 전적으로 동의하며 @malmaud가 그럴 수도 있습니다.

클로저는 본질적으로 어쨌든 손으로 작성한 코드를 생성하기 때문에 perf diff가 없습니다. 그러나 당신은 단지 커링하기 때문에 당신을 위해 그것을 수행하는 함수를 작성할 수 있습니다 ( curry(f, as...) = (bs...) -> f(as..., bs...) ). 그것은지도와 필터를 처리합니다. 또한 과거에는 curry(take, _, 2) 와 같은 센티넬 값을 구현하는 curry 구현 제안이있었습니다.

저는 현재 D, Elixir, 그리고 Julia의 세 가지 언어를 배우고 있기 때문에 여기에 왔습니다. 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

가장 예쁘지는 않지만 강력한 기능적 프로그래밍의 대체물로 코드 블록을 현명하게 사용했습니다. Julia에서는 다음을 수행 할 수 있습니다.

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

그러나 이것은 끔찍하고 추악합니다. 객체 지향 코드를 스칼라로 가질 수 없다면 파이프 연산자는 매우 중요해집니다. _ 명시 와일드 등 사용되는 않는 단순한 솔루션은 _first argument_ 피드에 파이프하지만 경우에만 나을 map 첫번째 인수 및 기능 등의 데이터 구조를 취할 변경된 두 번째로.

과도한 _ -> _ + 1 및 유사한 구문을 피하기 위해 Scala의 Array(1,2,3).map(_ + 1) 에 해당하는 것도 있어야합니다. [1,2,3] |> map(~ + 1, _) 이 map(~ -> ~ + 1, [1,2,3]) 번역되는 위의 아이디어가 마음에 듭니다. 찾아 주셔서 감사합니다.

후자의 경우 간단한 구문으로 방송하는 [1, 2, 3] .+ 1 꽤 중독성이 있습니다. 축소 (및 필터링)와 같은 것은 엄청나게 멋지지만 큰 요청처럼 보입니다.

파이핑과 do 둘 다 첫 번째 함수 인수를 위해 싸우는 점에 유의하는 것이 합리적입니다.

나는 스레드에 새로운 것이 온다는 것을 상기시킬 것입니다.
하나가 아니라 두 개가 아니라 제안 된 구문을 향해 julia의 기본 SISO 파이핑 기능에 대한 확장을 제공하는 FIVE 패키지.
목록 참조 : https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539

첫 번째 함수 인수를 위해 파이핑과 투쟁을하는 것이 합리적입니다.

베이스에서 추가 배관 기능을 얻으려면 _ 등으로 표시된 위치가 아닙니다.
그렇다면 나는 그것이 첫 번째가 아니라 최종 위치에 논쟁을 추가 할 것이라고 생각합니다.
그것은 "카레 / 부분 적용하는 척"

위의 내 게시물은 문제의 구문 문제를 설명하기 위해 설계된 간단한 예제입니다.

실제로 수백 개의 작업이 하나의 체인에서 사용되는 경우가 많으며 대부분은 비표준입니다. 자연어 빅 데이터로 작업한다고 상상해보십시오. 문자열을 취하고, 중국어 문자를 필터링하고, 공백으로 분할하고, "the"와 같은 단어를 필터링하고, 웹에서 사용하는 블랙 박스 소프트웨어 도구를 통해 각 단어를 "표준화 된"형식으로 변환하는 일련의 변환을 작성합니다. 서버, 다른 블랙 박스 도구를 통해 각 단어가 얼마나 일반적인 지에 대한 정보를 추가하고, 각 고유 단어에 대한 가중치 합계, 기타 작업 100 개 등을 추가합니다.

이것이 제가 고려하고있는 상황입니다. 메서드 호출이나 파이프를 사용하지 않고 이러한 작업을 수행하는 것은 크기 때문에 시작이 아닙니다.

나는 최고의 디자인이 무엇인지 모르겠습니다. 저는 단순히 모든 사람들이 사용 사례와 현재 존재하는 것보다 더 정교한 구문을 고려하도록 권장합니다.

이것은 Juno와 Julia 0.6에서 작동합니다.

```{줄리아}
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-people은 https://discourse.julialang.org/ 에서 SO와 (더욱 그렇다) 매우 활동적입니다

이런,이게 얼마나 복잡 할 수 있는지 믿기지가 않네요. 괜찮은 구문의 경우 +1. 나에게 파이프의 주요 용도는 데이터 (프레임) 작업이기도합니다. dplyr을 생각하십시오. 개인적으로 나는 첫 번째 / 마지막을 기본값으로 전달하는 것에 대해 신경 쓰지 않지만 대부분의 패키지 개발자가 데이터를 첫 번째 인수로 받아들이게 될 것이라고 생각합니다. 그리고 선택적 인수는 어떻습니까? 같은 것에 +1

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

앞서 언급했듯이 가독성과 단순성은 매우 중요합니다. 데이터 분석을 위해 일하는 전체 dplyr / tidyverse 스타일을 놓치고 싶지 않습니다.

파이프 연산자에 대한 Elixir의 여러 줄 구문도 매우 유용하다는 것을 추가하고 싶습니다.

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

println(sum(sin(1),2))

자바 스크립트 세계의 제안에 주목하십시오. _ 또는 ~ 대신 ? 연산자를 사용합니다.이 연산자는 이미 ( _ 를 무시하고 ~ 를 갖고 있습니다. not or formular). 현재 자바 스크립트와 동일한 ? 사용하고 있으므로 커링 자리 표시 자에도 사용할 수 있습니다.

이것은 그들의 제안이 어떻게 보이는지입니다 (자바 스크립트에 있지만 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에서 할 수 있습니다.

이 모든 것은 두 가지 주요 옵션으로 요약됩니다 (현재 상태 제외).
두 가지 모두 (모든 의도와 목적을 위해) 구문을 다시 작성하는 매크로로 구현할 수 있습니다.

_ 를 사용하여 anon 함수 만들기

@StefanKarpinski 의 Terse Lambdas 또는 유사한 구문에서 _ (RHS 표현식에서)의 존재는 전체 표현식이 익명 함수임을 나타냅니다.

• 이것은 매크로 참조로 거의 처리 할 수 있습니다.
  
  
  
  • 할 수없는 것은 (_) 이 _ 와 같지 않다는 것뿐입니다. 그것은 단지 식별 기능이므로 실제로 중요하지 않습니다.
  
  
  • 이것은 모든 곳에서 적용될 것이므로 |> 뿐만 아니라 예를 들어 map(log(7,_), xs) 또는 log(7, _).(xs) 와 같이 간결하게 작성하여 각 요소의 기본 7로 로그를 가져 오는 경우에도 유용합니다 xs .
  
  
  • 우리가 무엇이든한다면 개인적으로 이것을 선호합니다.
  
  

|> 로 엉망이되어 대체를 수행합니다.

옵션은 다음과 같습니다.

• RHS가 카레처럼 행동하게 만들어
  
  
  
  • 실제로 나는 이것이 깨지고 있다고 생각합니다. (아마도 메소드 테이블을 확인하는 non-breaking 버전이있을 수 있습니다. 대신 혼란 스럽습니다.)
  
  
• _ 특별하게 만드세요 (위의 옵션 및 / 또는 재 작성을 통해 가짜로 만드는 다양한 방법 참조)
  
  
  
  • 이를 수행하는 한 가지 방법은 중위 매크로 생성을 허용 한 다음 @|>@ 하고 패키지에서 원하는 방식으로 정의 할 수 있습니다 (이미 https://github.com/JuliaLang/julia/ 문제 / 11608)
  
  
  • 또는 본질적으로 특별한 속성을 부여합니다.
  
  
• 관련 패키지 목록에서 언급했듯이이를 수행하기 위해 수많은 매크로 구현이 있습니다.
• 어떤 사람들은 (다른 모든 연산자와는 달리) 라인이 끝나지 않기 전에 줄에 표현식을 만들 수 있도록 변경을 제안합니다. 그래서 당신은 쓸 수 있습니다

|> f
|>g

현재보다는 :

a |>
f |>
g

(블록을 괄호로 묶지 않고는 매크로로 구현하는 것은 불가능합니다. 그리고 블록을 괄호로 묶으면 어쨌든 작동합니다)

• 나는 개인적으로 이러한 제안이 |> (이미 싫어하는 연산자) 슈퍼 마술을 만들기 때문에 싫다.

편집 : @StefanKarpinski 가 아래 에서 중요한 변경 사항입니다.
누군가가 typeof(|>) <: Function 에 의존 할 수 있기 때문입니다.
그리고 이러한 변화는 그것을 언어 구문의 요소로 만들 것입니다.

보너스 옵션 : 절대 일어나지 않는 옵션 : 모든 곳에 커링 추가 # 554

카레를 추가하기에는 언어가 너무 늦었습니다.
그것은 미친 파괴가 될 것이고, 사방에 엄청난 모호함을 더할 것입니다.
그리고 매우 혼란스러워하십시오.

이 두 가지 옵션으로 기본적으로 고려할 가치가있는 모든 것을 다룹니다.
나는 다른 통찰력이 있다고 생각하지 않는다 (즉, "+1이 이것을 원한다"거나 위의 미세 변이의 반복을 계산하지 않음).

나는 0.7에서 |> 를 더 이상 사용하지 않고 나중에 파이프가 잘 작동하도록하는 데 필요하다고 생각하는 더 유용하고 아마도 비 기능적 의미론으로 도입 할 수 있기를 원합니다.

나는 0.7에서 |>를 더 이상 사용하지 않고 나중에 파이프가 잘 작동하도록하는 데 필요하다고 생각하는 더 유용하고 아마도 비 기능적인 의미로 도입 할 수 있기를 원합니다.

그 목록에서 유일한 구분은 |> 가 오른편이 카레 인 척하는 것입니다.
인수를 첫 번째 또는 마지막 마지막 인수 위치 (/ s) 또는 다른 고정 위치 (두 번째가 의미가있을 수 있음)에 삽입합니다.
삽입 할 인수의 마커로 _ 를 사용 하지 않습니다 .

이 스레드의 누군가가 막연하게 진지하게 받아 들인 다른 제안은 없었습니다. |
그 작업에 대해 다른 합리적이지만 깨뜨리는 정의가 있다면 놀랄 것입니다.
지난 4 년 동안 아무도 제안하지 않았습니다.

어쨌든 그것을 비난하는 것은 끔찍하지 않을 것입니다.
그것을 사용하는 패키지는 여전히 매크로 패키지 중 하나를 통해 그것을 가질 수 있습니다.

또 다른 아이디어는 계속 될 수 |> 현재의 행동과 같은 시프트 키의 사용을 필요로하지 않는 다른 이름으로 새로운 기능을 소개 \\ 하지 않는 ( 지금은 연산자로 구문 분석). 우리는 슬랙에서 한 번 이야기했지만 역사는 아마도 시간의 모래로 잃어버린 것 같습니다.

파이핑은 종종 대화식으로 사용되며 운영자의 입력 용이성은 사용감이 "가벼움"에 영향을줍니다. 단일 문자 | 도 좋을 수 있습니다.

단일 문자 | 도 좋을 수 있습니다.

대화식으로 예,하지만 .juliarc.jl (내가 오랫동안 가지고있는 ;-p)에있는 것으로 충분합니다.

Shift 키를 사용할 필요가 없습니다.

이것은 매우 로케일 종속 속성이라는 점에 유의하십시오. 예를 들어, 내 스웨덴어 키보드는 다른 세 글자를위한 공간을 만들기 위해 이동하기 위해 여러 문자와 AltGr 조합을 제공했습니다.

이러한 목적으로 |> 를 사용하는 전통이 있습니까? [Mathematica] (http://reference.wolfram.com/language/guide/Syntax.html)에는 접미사 기능 응용 프로그램을위한 // 가 있습니다. 대부분의 키보드에서 쉽게 입력 할 수 있고 사용할 수있는 경우 사용할 수 있습니다. 주석 (C ++에서와 같이) 또는 정수 나누기 (Python에서와 같이)에는 아직 사용되지 않았습니다.

| 가있는 것은 쉘 스크립팅과 잘 연결되어 있지만, 물론 | 가 비트 OR 일 것으로 예상됩니다. || 은 논리적 OR에 사용됩니까? ||| 어떻습니까? 손이 닿지 않는 문자를 세 번 입력하는 것은 한 번 입력하는 것보다 훨씬 어렵지 않습니다.

이 목적으로 |>를 사용하는 전통이 있습니까?

|> 의 전통은 ML 계열 언어에서 비롯된 것이라고 생각합니다. 운영자와 관련하여 ML / Haskell 커뮤니티처럼이 공간을 탐색 한 프로그래밍 언어 커뮤니티는 거의 없습니다. 몇 가지 예 :

• http://www.mlton.org/InfixingOperators – ML의 중위 연산자 목록입니다. 특히 왼쪽 / 오른쪽 섹션 / 애플리케이션에 대한 /> , \> , </ , <\ 연산자 모음을 좋아합니다.

• http://lambda.jstolarek.com/2012/03/function-composition-and-dollar-operator-in-haskell/ – . 사용한 함수 구성 및 $ 사용한 애플리케이션에 대한 빠른 개요 |> 는 주석 중 하나에 나타납니다.)

• https://haskell-lang.org/tutorial/operators – >>= , =<< , >> 의 Monad 제품군을 포함하여 재미있는 연산자의 전체 컬렉션이 포함 된 Haskell 연산자 용어집 >=> 및 <=< .

위의 목록에 추가하기 위해 R은 %> %를 사용합니다. 해당 언어는 오래되었지만 파이프 기능은 매우 잘 설계되었다고 생각합니다. 이를 효과적으로 만드는 것 중 하나는 중괄호 구문으로, 다음과 같은 것을 작성할 수 있습니다.

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> 에 대한 정말 좋은 솔루션을 찾을 수있는 옵션을 테이블에 남겨 둡니다.

이것은 쿼리 및 친구 생태계에 큰 영향을 미칩니다. 저는 R tidyverse의 파이프 구문과 매우 유사한 시스템을 만들었습니다. 모든 것이 매우 포괄적입니다. 현재 7 개의 테이블 형식 파일 형식 (2 개가 더 가까이 있음), 모든 쿼리 작업 (예 : dplyr) 및 플로팅 (멀지 않은 상태)에 대한 파일 io를 다룹니다. 곧 ggplot 느낌). 그것은 모두 l> 의 현재 구현을 기반으로합니다.

나는 테이블에 l> 에 대해 더 나은 옵션을 유지하는 데 모두 찬성한다고 말해야합니다. 지금까지 만든 것에 대해서는 잘 작동하지만 더 나은 접근 방식을 쉽게 볼 수 있습니다. 그러나 비추천하는 것은 많은 패키지에서 러그를 제거 할 수있는 매우 급진적 인 단계로 보입니다.

다른 선택은 x |> f 를 f(x) 의 대체 구문으로 만드는 것입니다. 그러면 |> 를 오버로드하는 코드가 깨지지 만 함수 체인에 |> 를 사용하는 코드는 계속 작동하는 동시에 추가 향상을 위해 해당 기능과 호환되는 한 열어 둡니다.

대안은 미래에 새로운 구문 체이닝 구문을 도입하는 것이지만, 현재 구문 오류 인 것이 필요합니다.

대안은 미래에 새로운 구문 체이닝 구문을 도입하는 것이지만, 현재 구문 오류 인 것이 필요합니다.

위의 제안이 그것을 허용하지 않습니까? 즉, 줄리아 1.0에서 |> 구문 오류를 만들고 ||> 를 오늘의 |> 만듭니다. 줄리아 1.0이 현재 사용하는 코드에 대한 사소한 성가심 것 |> 하나로 전환해야하기 때문에 ||> . 하지만 그렇게 나쁘지 않을 것이라고 생각하며 완전히 자동화 될 수 있습니다. 그런 다음 누군가 |> 대한 좋은 아이디어를 갖게되면 해당 언어로 다시 도입 할 수 있습니다. 이 시점에서 ||> 와 |> 둘 다있을 것이고, 모든 사람이 |> 를 채택하기 시작하면 ||> 가 천천히 배경으로 사라질 것이라고 가정합니다. 그리고 몇 년 안에 julia 2.0은 ||> 제거 할 수 있습니다. 내 생각에 그것은 a) 줄리아 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)

  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(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

대체 옵션 : splatting 구문에 다른 케이스를 추가합니다. f ... (x) desugar to (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 함수에는 고정 된 배열이 없습니다.

Julia는 이미 스플래 팅 연산자를 가지고 있습니다. 내가 제안하는 것은 현재 표시 연산자와 똑같은 동작을 할 것입니다.

I, e : f ... (x) == (args ...)-> f (x, args ...)는 splatting으로 람다를 만들기위한 설탕입니다.

이 정의는 항상 함수 객체를 제공합니다. 아마도 당신은 때때로 대답을 원할 것입니다.

마지막에 객체를 명시 적으로 호출하면됩니다. 예를 들어, 마지막 예에서 마지막 괄호 세트 앞에 ...가 없다는 점에 유의하십시오. 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)
f ... (a) ... (b) (c, d) == f (a, b, c, d) # 등

함수 체인과 함께 splat을 사용하는 데는 좋은 직감이지만 내 감각으로는 너무 복잡합니다.
체인의 한 지점에서 여러 번 신청했습니다.
함수 체인에서 모든 체인을 따라 단계별로 하나의 애플리케이션을 만듭니다.

그리고 @StefanKarpinski 가 옳습니다, 당신은 그들 자신에 기능을 적용하고 마침내 더 스칼라 항목에 적용하기 위해 언제 멈춰야할지 모릅니다.

-(잘림)-

미안합니다. 그것은 의미가없고 읽을 수없는 것입니다.
더 명확한 설명을 얻으려면 아래의 두 번째 메시지를 참조하십시오 (희망합니다).

Julia가 이미 얼마나 기능적인지를 감안할 때, 저는 함수 카레 연산자에 대한 @saolof 의 아이디어를 아주 좋아합니다. 나는 이것이 매우 명백한 해석을 가지고있는 것처럼 보이기 때문에 의미 론적 반대가 어디에서 오는지 정말로 이해하지 못한다.

자신의 repl에서 편안하게 프로토 타입을 만들 수도 있습니다.

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.

Julia의 극단적 인 확장 성이 여기에서도 과시되는 방식을 좋아합니다. 함수 체인에 대한 매우 광범위한 요구 사항에 대한 통합 솔루션은 ctranspose ...

(설명 :이 제안으로 1:10 |> map'(x->x^2) |> filter'(iseven) 를 받고 있으므로 💯 %입니다!)

명확하게 말하면, 실제로 adjoint 연산자를 남용해서는 안된다고 생각하지만, 간결한 함수 카레 표기법을 가질 수 있다는 좋은 개념 증명입니다.

새로운 유니 코드 연산자를 도입해야할까요? http://www.fileformat.info/info/unicode/char/1f35b/index.htm

(죄송합니다...)

_ 's가 람다를 만드는 데 훨씬 더 유연한 방법이라고 생각합니다.

@bramtayl MikeInnes의 게시물에 대한 편집 아이디어는 두 가지가 공존 할 수 있다는 것입니다. @stevengj 의 풀 리퀘스트에서와 같은 독립형 밑줄이 작동하고, 위의 Mike의 아이디어에서와 같은 독립형 커링이 작동하고 두 가지를 결합합니다. 커링 연산자를 사용하여 그 안에있는 _ 의 범위를 구분할 수도 있습니다.

아 알았다

그것은 LazyCall.jl과 크게 다르지 않습니다.

또는 여기에서 제안 : https://github.com/JuliaLang/julia/pull/24990#issuecomment -350490856

더 심각한 메모 :

명확하게 말하면 실제로 adjoint 연산자를 악용해서는 안된다고 생각합니다.

아마도 건전한 선택 일 것입니다. 그러나 이러한 솔루션이 구현되면 입력하기 쉬운 연산자가 제공되기를 바랍니다. 1:10 |> map'(x->x^2) 와 같은 작업을 수행하는 기능은 ' 대체하는 문자가 유니 코드 테이블에서 조회해야하는 경우 (또는 LaTeX 확장을 지원하는 편집기를 사용하는 경우) 훨씬 덜 유용합니다.

adjoint 연산자를 남용하는 대신 표시를 재사용 할 수 있습니다.

• (선형) 배관 맥락에서
• 내부, 함수 호출
  
  
  
  • 후보다 앞을 튀기다
  
  

그래서

• splat은 누락 된 반복기 인수를 유발할 수 있습니다.

일종의 고차원 표시 (음악가가 있다면 anacrusis 와 함께).
언어가 너무 많이 흔들리지 않기를 바랍니다.

예

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 지금까지 설명한 것은 함수 체인보다 유창한 인터페이스에 더 가깝습니다.

즉, 함수 체인 문제를보다 일반적으로 해결하면 유창한 인터페이스에도 사용할 수 있다는 추가 이점이 있습니다. 현재 Julia의 struct 멤버를 사용하여 유창한 인터페이스 와 같은 것을 만드는 것은 확실히 가능하지만 Julia의 정신과 디자인 미학에 반하는 것만 큼 저에게 충격을줍니다.

elixir가 파이프 연산자가 항상 왼쪽을 첫 번째 인수로 전달하고 나중에 추가 인수를 허용하는 방식은 꽤 유용했습니다. "elixir" |> String.ends_with?("ixir") 같은 것을 일류 시민으로보고 싶습니다. 줄리아.

다른 언어에서는이를 Uniform Function Call Syntax 로 정의합니다.
이 기능은 몇 가지 장점을 제공합니다 (Wikipedia 참조). Julia가 지원한다면 좋을 것입니다.

이 시점에서 Julia에 대한 유창한 인터페이스가 있습니까?

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 구문을 사용하여 필터, 맵, 축소, 열거, 압축 등의 긴 체인).

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

또한 하나는 할 수 있다고 생각합니다

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로서 당신은 오버로드해야합니다 adjoint 대신 ctranspose . 다음을 수행 할 수도 있습니다.

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에는 멋진 스레딩 매크로가 있습니다. Julia 생태계 어딘가에 있습니까?

Clojure에는 멋진 스레딩 매크로가 있습니다. Julia 생태계 어딘가에 있습니까?

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

Clojure에는 멋진 스레딩 매크로가 있습니다. Julia 생태계 어딘가에 있습니까?

적어도 10 개가 있습니다.
나는 스레드에 더 많은 목록을 게시했습니다.
https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539

다른 두 패키지 대신 LightQuery를 사용하도록 목록을 편집 할 수 있습니까?

|> 연산자는 elixir에서 왔기 때문에 익명 함수를 생성하는 방법 중 하나에서 영감을 얻어 보지 않겠습니까?
elixir에서는 &expr 를 사용하여 새로운 익명 함수를 정의하고 &n 를 사용하여 위치 인수를 캡처 할 수 있습니다 ( &1 는 첫 번째 인수, &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는 첫 번째 인수에 _ , 두 번째 인수에 _ 등을 사용합니다. 간결하지만이를 적용 할 수있는 상황이 빨리 사라집니다 (반복하거나 되돌릴 수 없음). 인수의 순서). 또한 표현식에서 함수를 명확하게하는 접두사 (위의 제안에서 & )가 없으며 실제로 사용을 방해하는 또 다른 문제입니다. 실무자로서 의도 한 인라인 함수를 추가 괄호와 중괄호로 묶어 인식되기를 바라면서 끝납니다.

그래서 저는 이와 같은 구문을 도입 할 때 가장 중요한 것은 그것이 모호하지 않다는 것입니다.

그러나 인수의 접두사에 관해서는 $ 는 쉘 스크립팅 세계에서 전통을 가지고 있습니다. 항상 익숙한 캐릭터를 사용하는 것이 좋습니다. 만약 |> 가 Elixir에서 나온다면, 그것은 사용자들이 이미 그 모드에서 생각하고 있다는 생각과 함께 Elixir에서 & 가져 가라는 주장이 될 수 있습니다. (이전에 Elixir 사용자가 많다고 가정하면 ...)

이와 같은 구문이 포착 할 수없는 한 가지는 N 인수를 사용하지만 N보다 적은 수를 사용하는 함수를 만드는 것입니다. 본문의 $1 , $2 , $3 는 3 개의 인수가 존재하지만 4 개의 인수 (마지막은 무시 됨)로 호출 될 위치에 놓으려면이를 표현하는 자연스러운 방법이 없습니다. (모든 N에 대해 ID 함수를 미리 정의하고 그 중 하나로 표현식을 래핑하는 것 외에는 다릅니다.) 이것은 단 하나의 인수 만있는 |> 뒤에 넣는 동기 부여 사례와 관련이 없습니다.

함수가 배열 인 것처럼 Colon 를 사용하여 getindex를 오버로드하는 @MikeInnes 트릭을 확장했습니다.

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

람다 또는 스레딩 매크로보다 훨씬 느리지 만 매우 멋지다고 생각합니다.

여기에 댓글을 남기는 사람들을 상기시키기 위해 https://github.com/JuliaLang/julia/pull/24990 에서 관련 토론을 살펴보십시오

또한 자리 표시 자에 대해 _ 구문의 함수 체인 친화적 인 구현을 제공하는 https://github.com/c42f/Underscores.jl 을 사용해 보는 것이 좋습니다. 귀하의 예제를 기반으로 @jpivarski , 당신은 상당히 친숙하고 편안 할 것입니다.