Julia: 제안: 더 이상 사용되지 않는 기능 파이핑 제거

함수 파이핑은 함수 호출을 위한 접미사 구문을 제공하며, 이는 대화형 데이터 생성 및 추가 시각화/요약을 위해 REPL에서 편리합니다.

내가 많은 사람들이 유형을 본 것을 사용 사례는

julia> somecomplicatedthingproducingarray
...

<ARROW UP>

julia> somecomplicatedthingproducingarray |> summarize

여기서 summarize 함수는 플롯 또는 히스토그램과 같은 것입니다.

@jiahao 나는 그것이 유용하지 않다고 주장하는 것이 아니라 Base 내에서 일관성을 유지하고 패키지가 이와 같은 것을 제공하도록 해야 한다고 주장합니다.

repl 사용을 위한 ans 도 있습니다.

이 제안에서 |> 는 여전히 중위 연산자로 구문 분석됩니까?

@ajkeller34 : 확실히, 패키지는 의미상으로 이전 패키지와 호환된다는 제약 없이 패키지로 원하는 모든 작업을 자유롭게 수행할 수 있습니다. 기본 정의.

존재하는 경우 Base 내에서 구문 사용 제거

다음은 제가 이 작업을 수행한 매우 오래된 시도입니다. https://github.com/tkelman/julia/commit/212727cdc4aaa3221763580f15d42cfe198bcc1c
당시 기지에서의 활용은 대부분 아주 사소한 것이었다. 테스트에서 "이것을 이 익명 함수에 파이프"를 사용하는 것이 파이프를 사용하는 것이 더 나을 수 있지만 대부분의 테스트에서 동일한 익명 함수를 여러 번 재사용했기 때문에 이름을 지정하고 다음과 같이 호출할 가치가 있을 것입니다. 그 시점에서 정상적인 기능.

궁금한 사람이 있을 경우를 대비하여 지금 ChainRecursive.jl 을 공개했습니다. ChainMap.jl과 그 다양한 자식의 분해가 완료되면 담론에 발표하겠습니다.

나는 기득권이 있고 |> 가 가능하게 하는 것에 대해 특별한 호감을 가지고 있기 때문에 여기에 약간의 저항을 제시하겠습니다.

@jiahao 와 함께 두 번째로 |> 는 REPL에서 빠르게 시도하고 싶을 때 매우 유용합니다. 게다가, 나는 당신의 주장이 너무 크거나 어느 정도 침착할 가치가 있을 때도 유용하다는 것을 알게 되었습니다. 연결된 예제의 경우 실제로 호출되는 함수보다 인수가 더 두드러지게 하는 것이 좋습니다. sum(x) 는 너무 간단한 예제이므로 실제로 sum(x) 로 작성해야 합니다. Escher.jl에서 요소에 속성을 추가하는 모든 함수에는 커리 메서드가 있습니다. 이것은 |> 와 매우 잘 어울립니다(계획된 것, map 에서도 잘 작동함). 그리고 줄 끝에서 무언가를 시도하고 UI 업데이트를 볼 수 있다는 것은 기쁨입니다. 즉시. 나는 표현의 시작 부분과 주변에 내 길을 찾을 필요가 없습니다. 적어도 Escher와 함께 사용하기 위해 제안된 대안은 padded_box_contents_aligned_right_tomato_background (또는 더 나쁜 box34 )와 같은 구성된 이름의 변수에 큰 표현식을 할당한 다음 이에 대한 함수를 호출하는 것입니다. 아름답게 읽히는 것과는 달리 <big UI expression> |> aligncontents(right) |> pad(1em) |> fillcolor("tomato")

이 후에 Escher 내 |> 를 정의할 수 있고 아마도 그렇게 할 것입니다. 그러나 WARNING: using Escher.|> in module YourPackage conflicts with an existing identifier. 패키지를 보는 것은 내 두뇌를 죽일 것입니다. 패키지는 거의 확실히 이것에 다른 의미를 줄 것입니다. 놀라운!

StefanKarpinski와 andyferris는 #17155에서 우리에게 임의의 함수 구성을 제공했으며 이는 많은 상황에서 유사한 목적을 수행할 수 있습니다.

box |> fill("orange") |> pad(2em) 가 아니라 (fill("orange") ∘ pad(2em))(box) box |> fill("orange") ∘ pad(2em) 입니까? 이 둘은 직교하는 것처럼 보입니다.

Escher가 클로저를 객체로 사용하는 것은 이 구문(단일 입력, 단일 출력이 아닌 모든 것에 심각한 제한이 있음)을 사용하기 위해 DSL을 정의하는 것처럼 보입니다. 사용 가능한 여러 연결 매크로 중 하나를 사용한 경우 더 일반화할 수 있습니다.

이에 대한 Base의 정의를 제거하면 이 구문을 좋아하는 사람들이 더 흥미로운 작업을 수행할 수 있습니다.

@shashi 귀하의 요점을 이해하지만 문제에서 언급한 패키지 중 하나를 사용하여 동일한 동작을 얻을 수 있지 않을까요? 예를 들어 Escher 예제에서 FunctionalData를 사용하여 <strong i="6">@p</strong> vbox(<really big thing>) | pad(2em) 를 수행하거나 Lazy를 사용하여 @> vbox(...) pad(2em) 를 수행할 수 있습니다.

이에 대한 Base의 정의를 제거하면 이 구문을 좋아하는 사람들이 더 흥미로운 작업을 수행할 수 있습니다.

그것을 사용할 수 있는 유일한 안전한 방법은 Escher.|>(...) 또는 Lazy.|>(...) 이므로 사용할 수 없다는 점을 제외하고는.

Base 에 정의되어 있지 않다고 가정하고 정의하고 내보내는 두 개의 다른 패키지를 사용하는 경우 |> 를 중위 연산자로 어떻게 사용할까요?

@kmsquire 사용 사례에 따라 다릅니다. |> 는 여전히 현재와 같이 중위 연산자로 구문 분석되며 Base에 값이 없을 것입니다. 매크로에서 사용하는 경우 단순히 호출 표현식의 첫 번째 인수가 되기 때문에 특정 패키지가 이를 정의하는 방법은 중요하지 않습니다.

중위 연산자로 구문 분석되지만 값이 없는 <| 를 예로 들어 보겠습니다. 비록 그것이 정의되지는 않았지만, 우리는 여전히

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

패키지는 + 로 할 수 있는 것처럼 다른 것을 의미하는 Base.:(<|) 에 대한 메서드를 정의하고 내보낼 수 있습니다.

그러나 좋은 기능을 제공하는 패키지는 매크로에서 그렇게 하므로 정확히 이러한 이유로 가정합니다.

FWIW, 연결하는 동안 모든 것이 하나의 표현식으로 압축되기 때문에 평가 중에 연결 패키지가 |> 를 사용할 필요가 없습니다. 패키지가 |> 를 정의하게 된다면 그것은 정확히 base의 정의가 될 것이라고 상상합니다. 아마도 대신 연결 매크로를 사용해야 하지만. 연결과 잘 작동하는 인터페이스를 구축하는 방법에 대한 좋은 예는 DataFramesMeta 를 참조하십시오.

이것을 더 이상 사용하지 않는 경우 문자열 연결에 대해 * 도 사용하지 않아야 합니까? string(a, b) 중복과 유사한 문제가 있으며 a 및 b 가 숫자가 아니라는 점을 감안할 때 최소 놀라움 원칙을 위반합니다.

보다 일반적으로 *(a, b) 대 a * b 와 같은 여러 호출 규칙을 사용하는 것이 혼란스럽기 때문에 모든 중위 표기법을 더 이상 사용하지 않아야 합니다. 현재 3개의 서로 다른 구문을 하나로 줄이고 완전한 일관성을 얻을 수 있습니다. 추함을 피하기 위해 함수 호출을 괄호 내부로 옮기고 중복 쉼표를 제거하는 것도 고려할 수 있습니다.

|> 는 여전히 현재와 같이 중위 연산자로 구문 분석되며 Base에 값이 없을 것입니다. 매크로에서 사용하는 경우 특정 패키지가 이를 정의하는 방법은 중요하지 않습니다.

Base에서 제거해야 하는 이유가 아직 확실하지 않습니다.

@bramtayl 은 좋은 지적을 합니다.

패키지가 정의로 이동한다면 |> 그것은 정확히 정의가 기본이 될 것이라고 상상합니다.

그리고 이것을 정의하는 둘 이상의 패키지를 사용하는 유일한 방법은 그것을 중위어로 사용하지 않는 것입니다.

매크로 내에서 |> 를 사용하려면 Base에서 정의를 제거해야 하는 이유를 모르겠습니다.

그렇지 않다. 요점은 |> 는 Base의 상황에 관계없이 매크로 내부에서 사용할 수 있다는 것입니다. 적절하게 구문 분석하는 모든 연산자도 마찬가지입니다. 제안의 요점은 Base가 함수 호출 측면에서 일관되게 만든 다음 패키지를 통해 파이핑 동작을 달성할 수 있도록 하는 것입니다. 패키지가 특히 |> 를 사용하는지 여부는 중요하지 않습니다. <| 또는 말 그대로 다른 중위 연산자를 사용할 수도 있습니다.

@ararslan 맞아요, 그건 제가 묻고 싶은 게 아니었어요. 바로 댓글을 수정했습니다. 죄송합니다.

어쨌든, 나는 "함수 호출 측면에서 자체 포함된 기본" 감정을 잘 이해하지 못합니다. 이것은 매크로가 아닌 컨텍스트에서 |> 를 사용하기 어렵게 만드는 것 같습니다. 나는 개인적으로 |> 가 놀랍긴 하지만 초보자에게 배울 가치가 있는 것이라고 생각합니다. 최소한 REPL의 노력을 절약할 수 있습니다. 나중에 |> 가 다른 중위 함수와 마찬가지로 함수라는 것을 깨닫는 것은 매우 재미있고 함수는 값일 뿐이라는 교훈을 강화합니다.

그냥 형식적인 것일 수도 있습니다. 사용 중단 및/또는 구문 변경을 마지막이 아닌 릴리스 주기의 시작 시점에 논의/결정하십시오. 현재 모든 주요 개발자와 패키지 책임자는 0.6을 완료하는 데 시간과 에너지를 소비하며 다른 (좋은) 아이디어를 생각할 시간이 없을 수도 있습니다.

"나는 그것이 유용하지 않다고 주장하는 것이 아니라 우리가 일관성을 가져야 한다고 주장합니다."

때때로 유용성이 일관성을 능가합니까? 불일치를 인식하지 못했지만 |> 구문이 유용하다는 것을 알았습니다. 그것이 제거되면 나는 아무 것도 얻지 못할 것입니다.

내가 할 수 있는 경우 내 거부 투표에 대한 설명:

현재 Base에 있는 것의 대부분은 대신 패키지에서 발생할 수 있습니다. 사전을 패키지로 옮겨야 합니까? 정렬 및 셔플과 같은 작업을 나열할 수 있습니까? 수집 작업 등? Base에 무엇이 포함되어야 하고 무엇이 포함되지 않아야 하는지에 대해 길고 자세한 논의가 있었다고 확신합니다. 그러나 몇몇 기능이 base에 포함될 수 있는 세 가지 이유가 있다고 가정합니다.
1) 해당 기능은 기본에서 다른 기능을 활성화하는 데 필요합니다.
2) 그 기능은 언어의 필수적인 부분이며 많은 Julia 프로그래머와 패키지가 이를 사용할 것이므로 많은 사람들이 스스로 롤링하는 것보다 모두가 동의하는 단일 구현/구문을 갖는 것이 바람직합니다.
3) 기본에 그 기능을 포함하면 "원시" Julia를 사용하기 더 즐겁게 만들거나 더 완전한 기능을 느끼게 하여 언어 전도 및 채택에 도움이 됩니다.

sum 와 같은 것은 아마도 3개 포인트 모두에 도달할 것이며, 저는 함수 파이핑이 두 번째 및 세 번째 포인트에 도달한다고 주장합니다.

초기(잘 작성된) 제안과 이 스레드의 논의에서 공통 주제는 Lazy.jl, Pipe.jl, ChainMap.jl 등 매크로를 통해 파이프와 같은 기능을 제공하는 여러 패키지의 존재입니다. 여러 패키지 중 많은 수는 커뮤니티의 많은 사람들이 파이핑이 유용하고 바람직한 기능임을 강력하게 시사하며, 이 토론 스레드에 이러한 패키지가 있다는 것은 여기 있는 많은 사람들이 파이핑 사용을 이해하고 지원한다는 것을 암시합니다.

배관이 Julia 커뮤니티 및 기타 언어에서 일반적이고 인기 있는 기능이라는 점을 감안할 때 이 토론에서도 사람들은 특히 REPL(Julia가 빛나는 곳)에서 많은 용도가 있고 Julia 생태계에 이미 단편화가 있다는 데 동의하는 것 같습니다. ..my 읽기는 Base에서 제거되어야 한다는 것이 아니라 Base에서 사용할 수 있는 파이핑 구문이 향상되어 조각화의 필요성이 줄어들어야 한다는 것입니다. 예를 들어 플로팅의 다른 방법을 제공하는 다른 패키지는 괜찮아 보입니다. 기능을 적용하는 다른 방법을 제공하는 다른 인기 있는 패키지는 꽤 무섭게 보입니다.

더 나아가 Base에서 파이프를 제거하고 중위 연산자를 남겨두는 것은 다소 놀라운 일이라고 주장합니다. Julia에서는 자신의 중위 연산자를 정의할 수 없지만 다음과 같이 정의할 수 있는 사용되지 않는 중위 연산자 |> 가 있습니다. 제발? 그것이 좋은 기능이라면 우리가 원하는 대로 정의할 수 있는 견고한 10개 또는 20개의 중위 연산자를 제공하지 않으시겠습니까?

마지막으로 다른 기능 응용 프로그램과 다르기 때문에 정확히 파이핑을 유지하는 것이 당연하다고 생각합니다. 기능을 적용하는 다른 규칙과 다른 점은 버그가 아니라 기능입니다. 이 차이는 일부 사용 사례에서 빛을 발합니다. 그리고 (손을 조금 흔드는) 명사가 동사 앞에 오는 다른 경우가 있으며, 이들 중 다수는 원시 함수 적용이 다루기 힘든 경우에 정확히 구문 설탕입니다. 머리 꼭대기에서 x = 5 할당은 명사(기호 x )를 동사 앞에 두는 것입니다(값에 바인딩). 마찬가지로 getfield t.a 유형의 필드에 액세스합니다. 그리고 가장 심오하게도 z[5] 배열 인덱싱은 "from z 에서 5번째 요소 가져오기"와 같이 읽히고 일반적으로 getindex(z, 5) 보다 더 자연스럽습니다.

그것이 좋은 기능이라면 우리가 원하는 대로 정의할 수 있는 견고한 10개 또는 20개의 중위 연산자를 제공하지 않으시겠습니까?

<| , ++ , ...

전체 스레드를 읽는 것이 아니라 단지 말하고 싶었습니다.
파이프 할 수 있다는 것을 좋아합니다. 나는 유용하게 투표 할 것입니다
어느 날 일관성.

나는 그것을 유지하는 것을 매우 선호하지만 중위 연산자로 남아있는 한 실제로 신경 쓰지 않습니다. 패키지 가져오기가 수반되는 경우 파이핑 기능을 사용하지 않을 것 같습니다.

즉, 이 "최소 놀라움의 원칙" 주장은 설득력이 있다고 생각하지 않습니다. 다양한 사용자 기반에 대해 몇 가지 가정을 하기 때문입니다. 주어-목적어-동사 언어의 원어민에게는 Julia의 구문 대부분이 최소 놀라움의 원칙을 위반하고 함수 파이핑이 다소 편안하다고 생각합니다...

전체 스레드를 읽지 않음

😕

나는 파이프 할 수 있다는 것을 좋아합니다.

다시 말하지만, 파이프할 수 없어야 한다고 주장하는 것이 아니라 기존의 여러 파이핑 패키지 중 하나에서 기능을 쉽게 가질 수 있다고 주장하는 것입니다. Base 파이프를 제거하면 Base가 제공하는 모든 것을 준수하거나 일관성을 유지할 필요 없이 패키지가 자체 파이프 의미를 보다 쉽게 ​​정의할 수 있습니다.

Julia에서는 자신의 중위 연산자를 정의할 수 없습니다.

그건 사실이 아니야; 중위 연산자로 구문 분석하는 모든 것은 정의하거나 재정의할 수 있습니다. martinholters가 지적했듯이 <| 및 ++ 도 유사하게 사용할 수 있습니다.

나는 이것에 대해 중립적이지만 |> 가 일반 함수 호출 구문에서 거꾸로 된 것이 요점 이라는 감정을 두 번째로 두겠습니다. 파이핑의 가장 열렬한 팬조차도 $#$1$# sin(x) 와 함께 실제로 중복되기 때문에 (AFAIK) sin <| x 를 요구하지 않습니다. |> 는 많은 괄호 없이 왼쪽에서 오른쪽으로 흐르는 데이터를 눈과 두뇌에 더 쉽게 생각할 수 있는 경우입니다.

|> 가 더 강력하기를 원합니다. 예를 들어 x |> f(_) + 2g(_) |> h 를 허용하고 단순히 연산자가 되지 않도록 합니다. 누군가 x |> f 를 f(x) 이외의 의미로 정의할 때마다 우리가 사용한 연산자의 요점은 다른 순서 호출 구문이기 때문에 정말 당황스럽습니다. 호출을 오버로드할 수 있기 때문에 x |> f 가 다른 것을 의미하는 좋은 이유를 알 수 없습니다.

@StefanKarpinski 더 강력한 파이프는 이미 매크로를 사용하여 얻을 수 있습니다. 예를 들어 설명하는 구문을 정확히 제공하는 Pipe.jl 을 참조하세요. |> 가 연산자인 한(저는 개인적으로 |> 가 특별한 경우의 가치가 있다고 생각하지 않습니다), 매크로는 중위를 구문 분석 하는 파이프 구분 기호를 사용할 수 있습니다. :call . 예를 들어 파이프에 @~ 를 유사하게 사용할 수 있습니다(적어도 이 글을 쓰는 시점에서). 이러한 수준의 유연성은 Julia에서 매크로를 사용할 때의 장점 중 하나입니다.

Pipe.jl의 기능을 언어에 추가하면 @pipe 를 작성할 필요 없이 사용할 수 있습니다.

|> 를 사용하지 않는 주된 이유는 사람들이 훨씬 더 좋아하는 다른 목적을 위해 구문을 회수하려는 경우입니다.

파이핑이 언어의 일부일 필요는 없으며 패키지에 포함될 수 있고 이미 존재한다고 주장하려고 합니다.

그러나 우리가 |> 에 대해 원하는 다른 것이 없다면 그 (사소한) 정의를 그대로 두는 것이 거의 해가 되지 않는다고 생각합니다.

현재 Base에서 |> 의 용도를 변경하려는 제안이 없다고 생각합니다. Base에서 정의하지 않는 것에 대한 내 주장은 기능 손실 없이 더 많은 일관성을 제공한다는 것입니다.

"더 강력한 파이핑" 제안이나 패키지 구현이 이 기존 정의에 대해 걱정하거나 해결할 수 없도록 함으로써 더 간단해질 수 있습니까?

@ararslan "사실이 아닙니다. 중위 연산자로 구문 분석되는 모든 것은 정의하거나 재정의할 수 있습니다."

수동 "&& 및 || 연산자"에서 구문 분석되지만 재정의할 수 없습니다(좋은 일입니다). 나는 유일한 예외를 믿습니다.

소위 "논리 연산자" && 및 || 인픽스입니다. [단항 이진 관계] "연산자"는 IMHO가 아니기 때문에 잘못된 용어입니다. Not은 논리적 비트 & 및 | 오버로딩을 허용합니다(확실하지 않은 선택이 좋은 선택입니다).

@PallHaraldsson & , | , + 등과 같은 의미의 연산자가 아니라 제어 흐름입니다.

가능하면 여기에서 주제에 머물도록 노력합시다.

@tkelman 좋은 지적입니다. 나는 우리가 미래의 파이핑 구문을 이전 버전과 호환되도록 만들 수 있다고 생각합니다. 예를 들어 _ 가 예약되어 있으면 $ |> 인수에 _ 가 포함되어 있으면 |> 가 특별한 의미를 가질 수 있고, 그렇지 않으면 지금과 동일한 작업을 수행합니다.

또 다른 문제가 있습니다. |> 가 개체에 대해 작동하도록 하려면 |> 또는 "함수 호출 연산자"(예: 메서드 추가)를 정의합니까? f(x) 및 x |> f 가 항상 동일하도록 하기 위해 $ |> 가 함수 호출에 대한 내장 구문인 경우 더 깨끗할 수 있습니다.

여기의 합의는 매우 명백히 반대이므로 이 문제를 종료하고 진행하겠습니다. 토론에 감사드립니다.

이 문제가 종료된 것으로 알고 있습니다. 교환원을 지켜줘서 고맙다는 말을 전하고 싶었습니다.