julia-dev 스레드를 반영하여 이 제안에 대한 Stefan의 주요 의견을 인용하는 것이 유용할 것이라고 생각합니다.

여기에 기대치를 설정하기 위해 Julia 1.0 이전에는 "구문 혁신"에 큰 지장이 없을 것이라고 생각합니다. (내가 생각할 수 있는 유일한 예외는 새로운 f.(v) 벡터화된 호출 구문입니다.) 임의의 함수가 중위 연산자처럼 작동하도록 하는 방법이 있으면 좋겠지만 언어에서 시급한 문제는 아닙니다.

Julia 개발 역사의 상당 부분에 참여했던 사람으로서, 나는 통사론적 변화보다 의미론적 변화에 에너지를 집중하는 것이 더 낫다고 생각합니다. Julia가 1.0에 도달하기 전에 해결해야 할 매우 중요한 의미론적 문제가 많이 남아 있습니다.

특히 이 기능을 구현하는 것은 작성자만 생각할 필요가 있는 일회성 차이가 아니라는 점에 유의하십시오. 모든 사람은 앞으로 자신의 작업이 이 기능과 상호 작용하는 방식에 대해 생각해야 하므로 변경 사항은 실제로 장기적으로 파서에서 일하는 모든 사람의 작업량.

나는 johnmyleswhite의 의견이 제안된 "장기" 파서 변경 사항과 관련하여 매우 적절하다고 생각합니다. 그러나 "사소한 변경" 및 "선택적" 그룹은 내가 볼 수 있는 한 꽤 독립적이고 영향이 적습니다.

즉: 이 제안의 최소 버전을 활성화하는 데 필요한 파서 변경은 일반 이진 연산자에 대한 우선 순위 및 그룹화, 다른 경우에는 다소 일상적인 변경 종류만 포함합니다. 관련 없는 작업을 하는 파서 개발자는 이미 존재하는 수많은 연산자의 의미를 모두 추적해야 하는 것보다 더 이상 이를 추적할 필요가 없습니다.

개인적으로 이 구문은 매우 보기 흉하고 입력하기 어렵습니다. 그러나 더 일반적인 중위 구문을 사용하는 것이 좋다는 데 동의합니다.

이에 대해 생각하는 올바른 방법은 구문 전용 문제라고 생각합니다. 원하는 것은 중위 구문과 함께 op 를 사용하는 것이므로 이를 얻기 위해 다른 함수와 연산자를 정의하는 것은 원형 교차로입니다. 즉, 모든 것은 파서에서 수행되어야 합니다.

실제로 이것을 위해 | 를 회수하고 a |op| b 를 사용하는 것을 고려할 것입니다. 틀림없이 일반적인 중위어 구문이 비트 or보다 더 중요합니다. (우리는 이전에 비트 연산자를 회수하는 것에 대해 이야기했습니다. 그것들은 있는 그대로 구문 낭비처럼 보입니다.)

a f b 는 배열 연결 및 매크로 호출 구문 외부에서 사용할 수 있습니다.

a f b 는 작동할 수 있지만 꽤 취약해 보입니다. a^2 f b^2 f c^2 는 합법적이지만 a f b c 및 a+2 f b+2 f c+2 $는 합법적이지 않은 이유를 누군가에게 설명하려고 한다고 상상해 보십시오. (마지막 것은 우선 순위가 prec-times라고 가정하지만 우선 순위가 무엇이든 상관없이 이러한 일반적인 종류의 문제는 관심사입니다.)

a |op| b 에 관해서 : 처음에는 Google 그룹 스레드에서 볼 수 있듯이 비슷한 제안인 a %op% b 를 선호했습니다. 그러나 제안된 |> 및 <| 의 좋은 점은 각각 이진 연산자로 개별적으로 유용하고 원하는 대로 자연스럽게 결합하여 작동한다는 것입니다(올바른 우선 순위 및 그룹화, 즉. ) 이것은 기존의 파서 메커니즘을 사용하여 단기적으로 이것을 구현할 수 있다는 것을 의미하며, 위의 johnmyleswhite에 대한 나의 응답에서 말했듯이 미래에 파서 개발자에게 골칫거리를 만드는 것을 피할 수 있습니다.

그래서 저는 a |op| b 를 좋아하고 확실히 반대하지는 않겠지만, 필요한 파서 변경을 단순화하기 위해 두 개의 다른 연산자를 갖는 방법을 찾아야 한다고 생각합니다. 최대 타이핑 가능성을 추구하고 | 가 "bitwise or"가 아닌 "pipe"를 의미하는 것을 반대하지 않는다면 a |op\\ b 또는 a |op& b 는 어떻습니까?

"파서 개발자의 두통"은 가능한 가장 낮은 우려입니다.

"파서 개발자의 두통"은 가능한 가장 낮은 우려입니다.

파서 개발자로서 나는 이것에 분명히 동의합니다.

|> 및 <| 는 둘 다 완벽하게 좋은 중위 연산자이지만 두 개의 다른 연산자를 사용하여 일반 연산자 구문을 구현하는 데에는 아무런 이점이 없습니다. 그리고 그 구문이 얼마나 장황하고 매력적이지 않은지에 대해 훨씬 더 말해야 합니다.

두 개의 다른 연산자를 사용하여 일반 연산자 구문을 구현하면 아무런 이점이 없습니다.

분명히 하자면, 장기 비전은 이진 f <| y , 이진 x |> f 및 삼항 x |> f <| z 가 있는 것입니다. 여기서 첫 번째는 함수이지만 두 번째는 두 개는 파서에서 변환으로 구현됩니다.

|> 및 <| 두 가지 일반 함수를 사용하여 이것이 구현될 수 있다는 아이디어는 그 비전에 대한 임시 다리일 뿐입니다.

그리고 그 구문이 얼마나 장황하고 매력적이지 않은지에 대해 훨씬 더 말해야 합니다.

그것은 정당한 지적입니다. |> 및 <| 를 | 및 & 로 바꾸는 것은 어떻습니까? 하키 선수에게는 다소 거슬릴 수 있지만 쌍으로 또는 개별적으로 모두 의미가 있습니다.

이를 | 및 & 를 모두 훔치는 것은 ASCII의 좋은 할당이 아니며 많은 사람들이 구분 기호가 대칭인 것을 선호할 것이라고 생각합니다.

사람들이 다른 이유로 x |> f <| y 삼항 연산자를 원하면 괜찮지만 별도로 고려해야 한다고 생각합니다. 파서가 |> 를 뒤집힌 <| 로 변환해야 하는지 잘 모르겠습니다. < 와 같은 다른 유사한 연산자는 그런 식으로 작동하지 않습니다. 하지만 그것은 별개의 문제이기도 하다.

둘 다 훔치는 | 및 &는 ASCII의 좋은 할당이 아니며 많은 사람들이 구분 기호가 대칭인 것을 선호할 것이라고 생각합니다.

확인.

> 및 < 입력하기 어렵다는 것을 알고 있습니다. 표준 키보드의 대칭성과 타이핑성 측면에서 가장 쉬운 것은 &% 및 %& $ 와 같을 수 있지만 R 병렬이든 아니든 심각하게 추악합니다. /| 및 |/ 도 고려할 가치가 있습니다.

...

파서가 |>를 뒤집힌 <|

잘못 이해하신 것 같아요. a |> b 는 b(a) 로 구문 분석되어야 합니다. (특별한 구문 분석이 없는 버전은 ((x,y)->y(x))(a,b) 이며 동일한 것으로 평가되지만 더 많은 오버헤드가 있습니다.)

a |> b는 b(a)로 구문 분석해야 합니다.

아, 알겠습니다.

나는 우리가 몇 년 동안 어떤 캐릭터를 사용할지에 대해 자전거를 탈 수 있다고 생각합니다. 나는 @StefanKarpinski (지금까지 이 대화에서 가장 고위 인사)가 결정을 내릴 것이라고 신뢰하고 그것에 대해 괜찮을 것입니다. 그것이 내가 반대하는 것(예: a f b )일지라도

다음은 어필할 수 있는 몇 가지 옵션입니다.
a |>op<| b (현재 |> 변경되지 않음)
a |{ op }| b (많은 일반적인 키보드에서 가깝고 동일한 시프트 상태, 너무 추하지 않습니다. 독립 실행형으로 약간 이상합니다.)
a \| op |\ b 또는 a /| op |/ b 또는 이들의 조합
a $% op %$ b (상대적으로 타이핑 가능, R에서 영감을 얻었지만 다소 못생겼습니다.)
a |% op %| b
a |- op -| b
a |: op :| b
a | op \\ b
a | op ||| b
a op b

스테판은 나보다 나이가 많지 않다.

이 문제에 대한 BDFL 권한으로 자신을 지명한 것 같습니다! ;)

a @op@ b ?

내 투표는 \| , |\ , /| 및 |/ 중 4개를 모두 사용하는 것 같습니다. 평가를 위해 아래로, 카레를 위해 위로; 기능쪽으로 바. 그래서:
a \| f (또는 f |/ a ) -> f(a)
a /| f (또는 f |\\ a ) -> (b...)->f(a,b...)
f |\ b (또는 b //| f ) -> (a...)->f(a...,b)
따라서:
a \| f |\ b (또는 a /| f |/ b ) -> f(a,b)
a \| f |\ b |\ c (또는 a /| b /| f |/ c ) -> f(a,b,c)

|/ 를 제외한 4개의 주요 연산자 각각은 그 자체로 유용합니다. 중복성은 확실히 비파이썬적이지만 논리적 깔끔함은 Julian이라고 생각합니다. 그리고 실용적인 문제로, 입력하기 더 쉬운 중위 관용구 버전을 사용할 수 있습니다. 둘 다 똑같이 읽을 수 있습니다. 일단 하나를 배우면 자연스럽게 둘 다 이해하게 됩니다.

분명히 모든 슬래시를 바꿔서 위쪽 화살표는 평가용이고 아래쪽 화살표는 커링용으로 바꾸면 동일한 의미가 됩니다.

나는 여전히 On High의 소식을 기다리고 있습니다. 그러나 이 자전거 보관소보다 키가 큰 사람이 이 버전이나 최소 두 개의 새 기호가 있는 다른 버전에 대해 결정을 내리면 단기 패치(함수 사용) 및/또는 적절한 패치(변환 사용)를 기꺼이 작성하겠습니다.

우리는 가능한 한 BDFL을 사용하지 않으려고 노력합니다. :)

나는 단지 몇 가지 간단한 사항을 기록할 것이라고 생각했습니다.

첫째, 제안되고 있는 표기법의 다른 이점("독립 실행형 사용")은 <| 가 가독성을 향상시키는 방식으로 다른 컨텍스트에서 사용될 수 있다는 것입니다. 예를 들어, A 문자열 배열이 있고 왼쪽에 있는 모든 문자열을 10으로 채우려면 지금 당장 map(i->lpad(i,10),A) 를 작성해야 합니다. 이것은 읽기가 상대적으로 어렵습니다. 이 표기법을 사용하면 map(lpad<|10,A) 가 됩니다.

둘째, 이 이면의 아이디어는 표기법을 일관되게 유지하는 것입니다. 함수 호출의 "수정"을 접두어에서 접미사로 변경하기 위해 존재하는 |> 연산자가 이미 있습니다. 이것은 단지 표기법을 확장합니다.

셋째, 직접 중위어를 a f b 로 사용할 가능성이 더 큰 문제입니다. a + b 및 a * b 는 결국 동일한 우선 순위를 가져야 합니다 + 및 * 는 함수 이름이고 시스템에서 실행 불가능하기 때문입니다. 가변 우선 순위를 갖습니다. 그렇지 않으면 기존 중위 연산자를 다르게 처리해야 하므로 혼동을 일으킬 수 있습니다.

예를 들어 A 문자열 배열이 있고 왼쪽에 있는 모든 문자열을 10으로 채우려면 지금 당장 map(i->lpad(i,10),A) 를 작성해야 합니다. 이것은 읽기가 상대적으로 어렵습니다. 이 표기법을 사용하면 map(lpad<|10,A) 가 됩니다.

나는 단호하게 동의하지 않습니다. 제안된 구문은 – 실례합니다 – ASCII 샐러드로, 일반 독자에게 무슨 일이 일어나고 있는지 단서를 제공하기 위해 다른 언어에서는 전례가 없는 Perl 및 APL의 최악의 공격에 가깝습니다. 현재 구문은 몇 자 더 길지만(5?), i->expr 가 람다 구문이라는 것을 아는 사람에게는 매우 명확합니다.

a + b와 a * b는 결국 같은 우선 순위를 가져야 합니다. +와 *는 함수 이름이고 시스템이 가변 우선 순위를 갖는 것은 실행 불가능하기 때문입니다. 그렇지 않으면 기존 중위 연산자를 다르게 처리해야 하므로 혼동을 일으킬 수 있습니다.

나는 이것이 진짜 문제라고 생각하지 않는다. a f b infix의 우선 순위가 무엇인지 말하고 모든 기존 우선 순위 수준도 유지할 수 있습니다. 이것은 우선 순위가 함수의 이름에 의해 결정되기 때문에 작동합니다. "+"라는 함수는 "+" 우선 순위를 갖습니다.

예, 이미 1+2 in 1+2 구문에 대해 이 작업을 수행했으며 문제가 되지 않았습니다.

나는 이것이 진짜 문제라고 생각하지 않는다. afb infix의 우선 순위가 무엇인지 말하고 기존의 모든 우선 순위 수준도 유지할 수 있습니다. 이것은 우선 순위가 함수의 이름에 의해 결정되기 때문에 작동합니다. "+"라는 함수는 "+" 우선 순위를 갖습니다.

나는 그것을 작동시키기 위해 파서를 작성하는 것이 어렵다는 것을 의미하지 않았다. 일관성 문제로 이어지므로 "또는 기존 중위 연산자를 다르게 처리해야 혼란을 일으킬 수 있습니다"라고 말했습니다. 무엇보다도 ¦ 및 ∥ 는 개념상 크게 다르지 않지만 하나는 미리 정의된 중위 연산자이고 다른 하나는 그렇지 않습니다.

나는 단호하게 동의하지 않습니다. 제안된 구문은 – 실례합니다 – ASCII 샐러드로, 일반 독자에게 무슨 일이 일어나고 있는지 단서를 제공하기 위해 다른 언어에서는 전례가 없는 Perl 및 APL의 최악의 공격에 가깝습니다. 현재 구문은 몇 자 더 길지만(5?), i->expr이 람다 구문이라는 것을 아는 사람이라면 누구에게나 매우 명확합니다.

아마도 내가 말하는 것에 대해 더 명확해야 할 것입니다. 작업을 "lpad by 10"으로 설명할 수 있다는 것이 i->lpad(i,10) 보다 훨씬 더 명확하다는 것입니다. 그리고 제 생각에는 lpad<|10 가 컨텍스트와 관련이 없는 형식으로 얻을 수 있는 가장 가까운 것입니다.

내가 어디에서 왔는지 설명하면 도움이 될 것입니다. 저는 수학자이자 수학 물리학자입니다. 무엇보다도 "람다 구문"은 프로그래밍 관점에서 합리적이지만 프로그래밍 경험이 적은 사람들에게는 가장 명확하지 않습니다. Julia는 내가 이해하는 바와 같이 주로 과학 컴퓨팅 언어가 되는 것을 목표로 하므로 MATLAB과 매우 유사합니다.

lpad<|10 x|>sin|>exp 더 "ASCII 샐러드"인 이유는 무엇입니까? 그러나 |> 표기법이 추가되었습니다. 예를 들어, | 를 사용하여 왼쪽에 있는 인수를 오른쪽에 있는 명령으로 전달하는 데 사용되는 bash 스크립팅과 비교해 보십시오. "파이프"라는 것을 안다면 _약간_ 더 이해가 되지만, 프로그래밍에 능숙하지 않으면 말이 안 됩니다. 그런 면에서 |> 는 화살표처럼 어렴풋이 보이기 때문에 실제로 더 의미가 있습니다. 그리고 <| 는 표기법에 대한 자연스러운 확장입니다.

%func% 와 같은 다른 제안과 비교하십시오. 다른 언어에서는 _전례가 있지만 언어 프로그래밍에 대한 광범위한 지식이 없는 사람들에게는 완전히 불투명합니다.

참고로, 저는 더 오래된 토론 중 하나를 다시 살펴보았고, 이론적으로 꽤 좋은 다른 언어에서 사용된 표기법이 있다는 것을 알았습니다. Haskell은 $#$ b(a,c,d) a |> b c d 를 사용합니다. 함수 이름 뒤에 공백이 있으면 이러한 방식으로 "매개변수"를 지정할 수 있습니다. map(lpad 10,A) . 단항 연산자에서 유일한 문제가 발생합니다. 예를 들어 i->+(i,10) 대신 "+10"에서 해석하기 때문에 map(+ 10,A) 는 오류를 생성합니다.

a f b 에서 : 우선 순위 문제는 Glen-O가 제안한 것만큼 나쁘지 않을 수 있지만 사용자 정의 중위 함수가 가장 낮은 우선 순위를 갖지 않는 한 존재합니다. 논쟁을 위해 우리는 그들에게 사전 시간을 제공합니다. 그 경우,
a^2 f b^2 => f(a^2,b^2)
a+2 f b+2 => a+f(2,b)+2
a^2 f^2 b^2 => (f^2)(a^2,b^2)
a f+2 b => 구문 오류?

이것은 모두 파서를 작성하는 방법의 자연스러운 결과이므로 그런 의미에서 특별히 골치 아픈 것은 아닙니다. 그러나 관용구의 일반 사용자에게는 특히 직관적이지 않습니다.

카레 관용구의 유용성
(i)->lpad(i,10) 가 lpad<|10 (또는 선택하는 경우 lpad |\ 10 등)보다 나쁘다는 Glen-O의 의견에 동의합니다. i 는 완전히 관련 없는 인지 부담이며 오류의 잠재적 원인입니다. 사실, 나는 지금 그것을 입력할 때 처음에 의도치 않게 (i)->lpad(x,10) 를 입력했다고 맹세합니다. 따라서 중위 카레 연산을 하는 것이 좋은 생각인 것 같습니다.
그러나 그것이 의도라면 우리가 정하는 중위 관용구가 무엇이든 우리는 우리 자신의 카레 연산을 만들 수 있습니다. a f b 이면 lpad rcurry 10 와 같은 것이 좋습니다. 요점은 키 입력이 아니라 가독성입니다. 그래서 나는 이것이 <| 에 대한 약한 주장이라고 생각합니다.

a |> b c d
나는 이 제안을 아주 좋아한다. |> 이 양쪽에 공백을 허용하도록 만들 수 있다고 생각합니다. 따라서 a b |> f c d => f(a,b,c,d) .

(참고: a b |> f c d map(lpad 10,A) 의 Glen-O가 모두 있다면 (a b) |> f c d => f((x)->a(x,b),c,d) 라는 모서리 케이스가 생성됩니다. 하지만 저는 견딜 수 있다고 생각하십시오.)

이것은 a f b 와 같은 연산자 우선 순위 측면에서 여전히 유사한 문제가 있습니다. 하지만 |> #$26$#$ 의 삼항 연산자의 우선 순위가 아니라 의 우선 순위 측면에서 적어도 그것에 대해 말할 수 있다면 어떻게 든 그들은 더 견딜 수 있다고 생각합니다.

0.5에서 lpad.(["foo", "bar"], 10) 을(를) 시도하십시오. 기존의 |> 는 모두에게 사랑받는 것은 아닙니다.

@tkelman : 문제는 알겠는데 요점은 무엇입니까? 추가 용도를 추가하기 전에 기존 |> 를 수정해야 한다고 생각하십니까? 그렇다면 어떻게?

개인적으로 기존 |> 을 제거해야 한다고 생각합니다.

0.5에서 lpad.(["foo", "bar"], 10) 을(를) 시도하십시오. 기존의 |> 는 모두에게 사랑받는 것은 아닙니다.

요점을 놓치신 것 같아요. 예, func.() 표기법이 좋으며 일부 상황에서는 문제를 우회합니다. 하지만 map 함수를 간단한 데모로 사용합니다. 함수를 인수로 사용하는 모든 함수는 이 설정으로 이점을 얻을 수 있습니다. 예를 들어, 순전히 제 요점을 설명하기 위해 참조 번호가 있는 최소 공배수를 기반으로 일부 숫자를 정렬할 수 있습니다. sort(A,by=i->lcm(i,10)) 또는 sort(A,by=lcm 10) ?

중위 연산자를 정의하는 어떤 방법이든 Glen-O가 <| 를 원하는 것을 수행하는 연산자를 생성할 수 있으므로 최악의 경우 sort(A,by=lcm |> currywith 10) . 이 페이지의 요점은 a ... f ... b => f(a,b) 를 만드는 방법을 논의하는 것입니다. 기존 |> 또는 제안된 <| 연산자가 가치가 있는지 여부는 그 점에서 약간의 관계가 있다는 것을 이해하지만 너무 편향되지 않도록 합시다.

개인적으로 a |> b c 제안이 지금까지 나온 제안 중 최고라고 생각합니다. Haskell의 기존 규칙을 따릅니다. 기존 |> 연산자와 논리적으로 관련이 있습니다. 그것은 합리적으로 읽기 쉽고 합리적으로 입력하기 쉽습니다. 자연스럽게 다른 용도로 확장된다고 느끼는 것은 부차적인 것입니다. 동의하지 않는 경우 제안된 2차 용도뿐만 아니라 핵심 관용구에 대한 귀하의 느낌을 최소한 언급하십시오.

일관성 문제로 이어지므로 "또는 기존 중위 연산자를 다르게 처리해야 혼란을 일으킬 수 있습니다"라고 말했습니다.

a f b 의 우선 순위를 결정하는 것이 어렵다는 데 동의합니다. 예를 들어 in 는 비교 우선 순위의 이점이 분명히 있지만 중위로 사용되는 많은 함수가 비교 우선 순위를 원하지 않을 가능성이 큽니다. 그러나 일관성 문제는 보이지 않습니다. 연산자마다 우선 순위가 다릅니다. a f b 를 추가해도 $ + 및 * 에 동일한 우선 순위를 부여하지 않습니다.

|> 는 이미 비교에 인접한 우선 순위를 가지고 있습니다. 다른 우선 순위에 대해서는 솔직히 괄호가 좋다고 생각합니다.

당신이 나와 동의하지 않고 우리가 a |> f b 를 사용했다면 유사한 연산자 |+> , |*> 및 |^> 가 있을 수 있습니다. |> 와 동일하게 작동하지만 중앙 연산자보다 우선합니다. 과하다고 생각하지만 가능성이 있습니다.

우선순위 문제를 해결하기 위한 또 다른 가능성은 (a f b) 와 같이 일종의 괄호를 포함하는 사용자 지정 중위 연산자에 대한 구문을 사용하는 것입니다.

관련 토론: https://github.com/JuliaLang/julia/issues/554 , https://github.com/JuliaLang/julia/issues/5571 , https://github.com/JuliaLang/julia/pull/14476 , https://github.com/JuliaLang/julia/issues/11608 및 https://github.com/JuliaLang/julia/issues/15612.

나는 묻고 싶다 - 어떻게 lpad<|10이 x|>sin|>exp보다 더 "ASCII 샐러드"인가? 그러나 |> 표기법이 추가되었습니다.

나는 @tkelman 가 주장한다고 상상한다.

기존 |>를 제거해야 합니다.

부분적으로는 _ lpad<|10 및 x|>sin|>exp 가 ASCII 샐러드 영역으로 진출하기 때문입니다. :).

필수 괄호가 있는 @toivoh 의 (a f b) 가 지금까지 최고의 제안이라고 생각합니다.

https://github.com/JuliaLang/julia/issues/11608 관련(따라서 https://github.com/JuliaLang/julia/issues/4882 및 https://github.com/JuliaLang/julia/pull /14653): (a f b) => f(a,b) 이면 (a <strong i="8">@m</strong> b) => (<strong i="10">@m</strong> a b) 이면 의미가 있습니다. 이렇게 하면 y ~ a*x+b 에 대한 기존의 특수한 경우 매크로 논리를 일반(따라서 훨씬 더 투명함) (y @~ a*x+b) 로 대체할 수 있습니다.

또한 "요구되는 괄호"는 간결한 중위어 정의에 대해 선호되는 관용구일 수 있습니다. (어리석은 예를 사용하여) a + b = string(a) * string(b) 라고 말하는 대신 (lint 도구 또는 컴파일러 경고에 의해) (a + b) = string(a) * string(b) 라고 말하는 것이 좋습니다. 나는 이것이 실제로 infix에 대해 "parens required" 옵션을 선택한 직접적인 결과가 아니라는 것을 알고 있지만, LHS에서 infix를 사용하는 사람들에게 실수로 경고하지만 그것을 하는 사람들을 해고할 수 있는 편리한 관용구입니다. 목적.

내 생각에는 현재 (접두어가 아닌) 함수 중위를 적용하는 경우,
그러면 연산자이며 연산자처럼 보이고 작동해야 합니다.

그리고 유니코드를 사용하여 정의된 중위 연산자를 지원합니다.
https://github.com/JuliaLang/julia/issues/552 이후

원래 제안에서와 같이 키워드를 추가할 수 있도록 확장된 것이 좋을 것 같습니다.
예를 들어 1 ⊕₂ 1 == 0
중위어에 대해 임의의 이름을 가질 수 있다는 것은 약간 과도한 것처럼 보입니다.

운영자처럼 보이고 행동해야 합니다.

중위 연산자에 대한 강력한 명명 규칙이 있어야 한다는 데 동의합니다. 예: 유니코드의 한 문자 또는 전치사로 끝납니다. 그러나 그것들은 컴파일러에 의해 강제되는 요구 사항이 아니라 유기적으로 발전하는 규칙이어야 합니다. 확실히, 나는 #552가 이야기의 끝이라고 생각하지 않습니다. 수십 개의 하드 코딩된 연산자가 있는 경우 새 기능을 프로토타이핑하는 경우에만 프로그래밍 방식으로 더 추가할 수 있는 방법이 있어야 합니다.

...

나에게 (a f b) (및 (a <strong i="10">@m</strong> b) ) 제안은 이 버그의 나머지 제안보다 중요합니다. 나는 거의 패치를 만들고 싶은 유혹을 느낀다.

(a f b) => f(a,b)
(a f b c d) => f(a,b,c,d)
(a f) =>구문 오류
(a+2 f+2 b+2) => (f+2)(a+2,b+2)
(t1=a t2=f t3=b) => (t1=f)((t2=a),(t3=b)) (공백은 매크로에서와 같이 가능한 가장 낮은 우선 순위를 가짐)

...

패치를 제출하는 것이 부적절합니까?

나는 마지막 두 가지 경우를 이해하지 못했습니다.

(a+2 f+2 b+2)=>(f+2)(a+2,b+2)
(t1=a t2=f t3=b)=>(t1=f)((t2=a),(t3=b))

(a f b c d) 구문이 매우 이상합니다. 1 + 2 + 3 는 +(1,2,3) 로 쓸 수 있으므로 f(a,b,c) 는 (a f b f c) 로 쓰면 안 됩니까?

전반적으로 나는 개인적으로 Julia가 현재 허용되는 것 이상으로 사용자 지정 중위 연산자를 지원해야 한다고 확신하지 않습니다.

(a f b c d) 에 두 가지 문제가 있음을 알 수 있습니다.

첫째, 더 복잡한 표현을 사용하면 읽기가 어려울 것입니다. 대괄호가 답답할 수 있는 이유 중 하나는 어떤 대괄호가 다른 대괄호와 쌍을 이루는지 한 눈에 알기 어려울 수 있기 때문입니다. 이것이 중위 및 후위( |> ) 연산자가 처음에 바람직한 이유입니다. 후위 고정은 매번 대괄호를 처리할 필요 없이 멋지고 깔끔한 왼쪽에서 오른쪽으로 읽을 수 있기 때문에 특히 선호됩니다.

둘째, 요소별로 만드는 것과 같은 일을 멋지게 할 수 있는 방법이 없습니다. 내 이해는 f.(a,b) 가 0.5의 표기법이 되어 f 가 브로드캐스팅에 대한 인수에 대해 요소별로 작동하도록 한다는 것입니다. (a f b) 인 경우 중위 표기법으로 동일한 작업을 수행하는 깔끔한 방법은 없습니다. 기껏해야 (a .f b) 이어야 합니다. 제 생각에는 .( 가 .+ 및 .* $ 에서 제공하는 대칭의 멋을 잃습니다.

예를 들어 Haskell의 예제를 사용하려는 경우를 비교하십시오. #6946의 shashi는 여기에 상응하는 요점을 만들었습니다. Haskell에서는 circle 10 |> move 0 0 |> animate "scale" "ease" 라고 작성합니다. 이 표기법을 사용하면 ((circle(10) move 0 0) animate "scale" "ease") 가 됩니다. 이는 animate(move(circle(10),0,0),"scale","ease") 보다 명확하지 않습니다. |> 표기법을 사용하여 서클을 여러 위치에 복사하려는 경우 circle 10 .|> copy [1 15 50] [3 14 25] 가 있을 수 있습니다. 제 생각에는 이것이 아이디어를 구현하는 가장 깔끔한 방법입니다. 그런 다음 브래킷은 작업 순서 문제를 처리하는 일반적인 역할을 합니다.

그리고 내가 지적했듯이 a|>f b c 는 동일한 표기법을 더 많이 사용할 수 있는 자연스러운 확장자를 갖는 이점이 있습니다 f b c 는 "function f with 매개변수 b 및 c set), 따라서 i->f(i,b,c) 와 동일합니다. 이렇게 하면 고정뿐만 아니라 전달하려는 다른 상황에서도 작동할 수 있습니다. 매개변수가 있는 함수(특히 내장 함수)(표준은 함수의 객체를 먼저 갖는 것임).

|> 는 또한 어느 것이 함수인지 분명히 합니다. 예를 들어 (tissue wash fire dirty metal) 가 있었다면 wash 를 함수로 한 눈에 인식하기가 상당히 어려울 것입니다. 반면 tissue|>wash fire dirty metal 는 " wash 는 함수입니다"라는 큰 표시가 있습니다.

최근의 반대 의견 중 일부는 "하지만 이 기능을 남용할 수 있습니다!"라고 말하는 것처럼 들립니다. 내 대답은 다음과 같습니다. 물론 할 수 있습니다. 원한다면 이미 매크로를 사용하여 완전히 읽을 수 없는 코드를 작성할 수 있습니다. 파서의 역할은 합법적인 사용을 가능하게 하는 것입니다. 남용을 막기 위해 우리는 관례/관용구를 가지고 있으며 경우에 따라 삭제합니다. 구체적으로:

나는 마지막 두 가지 경우를 이해하지 못했습니다.

이것들은 어떤 식으로든 따라야 할 예가 아닙니다. 그것들은 우선순위 규칙의 자연스러운 결과를 보여줄 뿐입니다. (a^2 ಠ_ಠ b^2) => ಠ_ಠ(a^2,b^2) 는 충분히 명확하지만 마지막 두 예제는 모두 구문을 남용하는 것으로 간주됩니다.

f(a,b,c)를 (afbfc)로 쓰면 안 됩니다.

(a f b c d) 에 대한 제 제안은 솔직히 말해서 나중에 생각했습니다. 나는 그것이 의미가 있다고 생각하고 그것이 유용한 예를 생각해 낼 수 있지만 논쟁의 여지가 있다면 이 문제에 대해 이 제안을 중단하고 싶지 않습니다.

[예를 들어:

• f는 b, c, d를 사용하여 아마도 복잡하고 아마도 더 간단한 객체 a의 "객체 메소드"입니다.
• f는 push! 와 같은 "자연스럽게 브로드캐스트되는" 방법입니다.

(a f b f c) 가 f + 와 같다면 의미가 있지만 대부분의 연산자는 실제로 + 와 같지 않으므로 우리 모델이 되어서는 안됩니다.

더 복잡한 표현을 사용하면 읽기 어려울 것입니다.

다시 말하지만, 내 대답은 "그래서 남용하지 마십시오"입니다.

f 중위를 사용하여 $ a / (b + f(c,d^e)) 와 같은 복잡한 표현식을 작성하는 방법을 원한다고 가정해 보겠습니다. @toivoh 의 제안에서는 a / (b + (c f d^e)) 입니다. Haskell과 같은 사용법에서는 |> 우선 순위가 a / (b + c |> f d^e) 라는 특정 예제를 수정하기 위해 변경되면 a / (b + (c |> f d^e)) 또는 "최상"입니다. @toivoh 's가 여기만큼 쉽게 좋은 것 같아요.

(tissue wash fire dirty metal)

이에 대한 해결책은 중위 연산자에 대한 강력한 명명 규칙이라고 생각합니다. 예를 들어, 중위 연산자가 유니코드의 한 문자여야 하거나 전치사 또는 밑줄로 끝나야 하는 규칙이 있는 경우 위의 내용은 (tissue wash_ fire dirty metal) 와 같을 것입니다. .

...

요소별

이것은 유효한 우려입니다. (a .f b) 는 ((a.f) b) 로 읽을 수 있으므로 나쁜 생각입니다. 내 첫 번째 제안은 (a ..f b) 이지만 별로 기쁘지 않습니다.

circle 10 |> move 0 0 |> animate "scale" "ease"

나는 jquery를 사용했기 때문에 그런 함수 체이닝의 이점을 확실히 보았습니다. 하지만 중위 연산자와 같은 문제는 아니라고 생각합니다. (a f b) 제안을 사용하여 위의 내용을 다음과 같이 작성할 수 있습니다.

circle 10 |> (move <| 0 0) |> (animate <| "scale" "ease")

... Haskell 버전만큼 간결하지는 않지만 여전히 읽을 수 있습니다.

() 내부의 세 가지 항목으로 제한될 수 있습니다.
(a f (b,c))
.(a f (b,c)) 연산자 .( 사용

마지막으로, 일반적인 요점에 대한 답변:

전반적으로 나는 개인적으로 Julia가 현재 허용되는 것 이상으로 사용자 지정 중위 연산자를 지원해야 한다고 확신하지 않습니다.

분명히 우리 모두는 우리의 의견을 가질 권리가 있습니다. (엄지손가락이 댓글의 해당 부분을 참조했는지 여부는 확실하지 않지만, 그렇다면 3배가 됩니다.)

그러나 내 반론은 다음과 같습니다.

• Julia는 이미 수십 개의 중위 연산자를 가지고 있으며 그 중 다수는 매우 틈새 시장입니다. 더 많이 제안되는 것은 불가피합니다. 누군가가 "어떻게 ⅋ 가 있고 § 는 없을 수 있습니까?"라고 말하면 "다음 버전이 널리 채택될 때까지 기다리기"보다는 "직접 해보세요"라고 대답하고 싶습니다.
• (a § b) 와 같은 것은 매우 읽기 쉽고 구문은 한두 가지 예제에서 배울 수 있을 만큼 충분히 가볍습니다.
• 내가 이 문제를 제기한 첫 번째 사람이 아니며 마지막 사람도 아닙니다. 언어 디자이너는 크리핑(오류) 기능에 대해 매우 회의적이어야 한다는 것을 이해합니다. 한 번 못생긴 기능을 추가하면 기본적으로 나중에 고칠 수 없기 때문입니다. 하지만 위에서 말했듯이 (a f b) 는 후회하지 않을만큼 깨끗하다고 ​​생각합니다.

(a f b) 의 선명도가 확실하지 않습니다.

가능한 사용 사례는 다음과 같습니다.
select((((:emp_id, :last_name) from employee_tbl) where (:city, == ,'indianapolis')) orderby :emp_id));

이것은 확실히 중위 함수의 실행 가능한 사용입니다.
select 함수는 ID 함수이거나 빌드된 쿼리를 데이터베이스로 보냅니다.

이것은 명확한 코드입니까?
난 그냥 몰라.

.(a f b)

네, 이해가 됩니다. 하지만 가독성이 좋지 않습니다.

(a @. f b) 이 더 읽기 쉬운가요? @. 매크로를 활성화하는 것은 간단한 한 줄짜리이기 때문입니다.

[[[생각해보면, 괄호 없이 중위 매크로를 허용하면 @Glen-O가 괄호를 사용하여 원하는 작업을 수행할 수 있습니다. circle(10) @> move 0 0 @> animate "scale" "ease" => @> (@> circle(10) move 0 0) animate "scale" "ease" =macro> animate(move(circle(10),0,0),"scale","ease") . 나는 그 솔루션이 (a f b) 보다 못하다고 생각하지만 적어도 내 눈에는 이 전반적인 버그를 해결할 것입니다.]]]

...

select((((:emp_id, :last_name) from employee_tbl) where (:city, = ,'indianapolis')) orderby :emp_id);

조건식이 이상하게 인용될 필요가 없도록 "where"에 매크로를 사용하는 것이 좋습니다. 그래서:

select((((:emp_id, :last_name) from employee_tbl) <strong i="22">@where</strong> city == 'indianapolis') orderby :emp_id);

괄호는 약간 성가시지만 다른 한편으로는 파서가 없이 이러한 종류의 표현을 처리할 합리적인 방법이 없다고 생각합니다.

select((((:emp_id, :last_name) from employee_tbl) <strong i="6">@where</strong> city == 'indianapolis') orderby :emp_id);

괄호는 약간 성가시지만 다른 한편으로는 파서가 없이 이러한 종류의 표현을 처리할 합리적인 방법이 없다고 생각합니다.

다시 생각해보면 그 표현의 우선 순위는 오른쪽에서 왼쪽입니다. 따라서 중위 매크로를 사용하면 다음과 같이 될 수 있습니다.

select((:emp_id, :last_name) <strong i="11">@from</strong> employee_tbl <strong i="12">@where</strong> city == 'NYC' <strong i="13">@orderby</strong> :emp_id)

또는:

<strong i="17">@select</strong> (:emp_id, :last_name) <strong i="18">@from</strong> employee_tbl <strong i="19">@where</strong> city == 'NYC' <strong i="20">@orderby</strong> :emp_id

그래서 나는 여전히 (a f b) 를 좋아하지만 중위 매크로도 좋은 대답이라는 것을 알게 되었습니다.

다음은 예제를 통한 전체 제안과 장점 및 단점입니다.

주요 용도:

• a <strong i="28">@m</strong> b => <strong i="30">@m</strong> a b
• a <strong i="33">@m</strong> b c => <strong i="35">@m</strong> a b c
• a <strong i="38">@m</strong> b <strong i="39">@m2</strong> c => <strong i="41">@m2</strong> (<strong i="42">@m</strong> a b) c
• <strong i="45">@defineinfix</strong> f; a <strong i="46">@f</strong> b => macro f(a,b...) :(f($a,$b...)) end; <strong i="48">@f</strong> a b => f(a,b)

코너 케이스: (좋은 코드가 아니라 단지 파서가 어떻게 작동하는지 보여주기 위함)

• t1=a <strong i="54">@m</strong> t2=b t3=c => <strong i="56">@m</strong> t1=a t2=b t3=c (좋은 프로그래밍 스타일은 아니지만)
• t1 + a <strong i="59">@m</strong> t2 + b => <strong i="61">@m</strong> t1+a t2+b (좋은 프로그래밍 스타일은 아니지만)
• a b <strong i="64">@m</strong> c => 구문 오류(??)
• a <strong i="67">@m</strong> b [c,d] => 하지 마세요. 하지만 <strong i="70">@m</strong> a b[c,d] (ETA: 아니요, 패치 를 사용하면 <strong i="72">@m</strong> a b ([c,d]) 로 나오므로 더 좋을 것입니다.)
• a <strong i="75">@m</strong> b ([c,d]) => <strong i="77">@m</strong> a b ([c,d])
• [a <strong i="80">@m</strong> b] => 나쁜 스타일, 명확하게 하기 위해 괄호 를 사용하지만 [a (<strong i="83">@m</strong> b)] (??)
• a @> f b => @> a f b => f(a,b)
• <strong i="90">@outermacro</strong> a b <strong i="91">@m</strong> c d => <strong i="93">@outermacro</strong> a (<strong i="94">@m</strong> b c d)

장점:

• 중위 매크로를 정의하고 중위 함수를 무료로 가져옵니다(매크로 평가의 일회성 오버헤드 포함. 파서 매직만큼 오버헤드가 낮지는 않지만 모든 평가에서 추가 함수 호출을 사용하는 것보다 훨씬 낫습니다)
• 위의 SQL과 같은 예에서 볼 수 있듯이 강력한 DSL로 이어질 수 있습니다.
• 한 줄짜리 매크로이기 때문에 별도의 |> 연산자가 필요하지 않습니다. <| 및 @Glen-O의 나머지 제안도 마찬가지입니다.
• 명시적이므로 (a f b) 와 달리 우발적으로 사용될 위험이 매우 낮습니다.
• 표시된 대로 @defineinfix 매크로는 매크로가 아닌 기능에 대한 약칭 사용을 허용할 수 있습니다.

(사소한) 단점:

• 우선 순위 및 그룹화는 대부분의 경우 RtoL에서 잘 작동하는 것처럼 보이지만 괄호가 필요한 예외가 있습니다.
• a @> f b 또는 a <strong i="112">@f</strong> b 도 (a f b) 만큼 가독성이 떨어진다고 생각합니다.

이 스레드가 얼마나 활성화되었는가를 감안할 때 이 주제에 대한 나의 원래 우려를 사람들에게 상기시키겠습니다. 구문에 관한 문제는 종종 엄청난 양의 활동을 생성하지만 그 활동의 양은 일반적으로 장기적 가치에 비례하지 않습니다. 논의 중인 변경 사항입니다. 대부분 구문에 대한 스레드가 취향에 대한 순수한 논쟁에 가까워지기 때문입니다.

활동량이 일반적으로 비례하지 않습니다.

죄송합니다. 나는 아마도 앞뒤로 들어가는 것에 가장 죄가 있습니다.

다른 한편으로, 나는 이 스레드가 "사용 가능한" 진전을 분명히 만들었다고 생각합니다. 최신 제안 (a f b) 또는 [ a @> f b , a <strong i="10">@f</strong> b 를 바로 가기로 정의할 수 있음] a %f% b 또는 a |> f <| b .

그래도 나는 더 이상의 앞뒤가 없는 댓글이 더 이상 진전을 이루지 못할 것이라고 생각하며, 사람들이 제안할 진정으로 새로운 것이 없는 한 지금부터 추천 또는 추천을 사용하도록 권장합니다. 즉, 기존 제안에 대한 직교 변경이 아님). "투표 가능한 제안"에 "만세" 이모티콘(폭발 원뿔형)을 추가했습니다. 중위 위치에 임의의 함수에 대한 특수 구문이 없어야 한다고 생각한다면 버그 전체에 대해 반대 투표를 하십시오.

...

ETA: 이 토론은 이제 decision 태그를 얻을 만큼 충분히 성숙했다고 생각합니다.

참고로 (다른 누군가가 지적해주기를 기대했습니다).
SQL과 같은 구문을 포함하려면 작업에 적합한 도구가 비표준 문자열 리터럴이라고 생각합니다.
모든 매크로와 마찬가지로 호출 시 범위의 모든 변수에 액세스할 수 있습니다.
우선 순위를 선택하여 고유한 DSL을 지정할 수 있으며 컴파일 시간에 실행됩니다.

select((((:emp_id, :last_name) from employee_tbl) where (:city, == ,"indianapolis")) orderby :emp_id));

더 잘 쓰여진다

sql"SELECT emp_id, last_name FROM employee_tbl WHERE city == 'indianapolis' ORDER BY emp_id"

비표준 문자열 리터럴 은 매우 강력한 구문입니다.
DSL을 포함하는 데 사용되는 좋은 예를 찾을 수 없습니다.
하지만 그들은 할 수 있습니다.

그리고 이 경우 결과는 정의할 수 있는 중위 연산보다 훨씬 깨끗하다고 ​​생각합니다.
자체 마이크로파서/토큰나이저를 작성해야 하는 오버헤드가 있지만.

결정 태그가 필요하지 않다고 생각합니다.
이것은 PR로 구현되지 않으며 사용 가능한 프로토타입도 없습니다.
사람들이 그것을 테스트 할 수 있습니다.
8개의 사용 가능한 프로토타입이 있는 https://github.com/JuliaLang/julia/issues/5571#issuecomment -205754539와 대조

이 글을 읽을 때마다 느낌이 오르락 내리락 합니다. 실제로 해보지 않으면 모를 것 같아요. 그리고 지금은 그것을 무엇에 사용할지조차 모르겠습니다. (F#에서 사용한 |> 및 <| 에 대한 일부 정의와 달리)

SQL과 유사한 구문, 작업에 적합한 도구는 비표준 문자열 리터럴입니다.

SQL이 NSL로 가장 잘 수행되는지 여부에 관계없이 인라인 매크로가 매우 유용할 만큼 충분히 복잡하지만 자체 마이크로파서/토큰나이저를 작성할 가치가 있을 정도로 복잡하지 않은 DSL 수준이 있다고 생각합니다.

지금은 내가 그것을 무엇에 사용할지조차 모릅니다. (F#에서 사용한 |> 및 <|에 대한 일부 정의와 달리)

인라인 매크로 제안을 통해 사람들은 무엇보다도 자신의 |> 또는 <| 같은 매크로를 실행할 수 있으므로 F#에서 수행한 모든 작업에 사용할 수 있습니다.

(나는 앞뒤로 자전거 이동 논쟁에 들어가고 싶지 않지만 아래 때문에 어쨌든 응답하고 있었고 인라인 매크로 제안은 상대적으로 매끄러운 하나의 돌로 여러 새를 죽인다고 생각합니다.)

결정 태그가 필요하지 않다고 생각합니다.

내가 파서 패치를 만드는 것이 적절한지 이전에 물었지만 아무도 대답하지 않았습니다. 지금까지 그것에 대한 유일한 단어는 다음과 같습니다.

Julia 1.0 이전에는 "구문 혁신" 방식에 큰 지장이 없을 것이라고 생각합니다.

지금 패치를 만드는 것에 반대하는 것처럼 보일 수 있습니다. 주변에 앉아서 약간 썩을 수 있기 때문입니다. 그러나 지금 당신은 우리가 "PR [또는] 사용 가능한 프로토타입으로 구현"하지 않는 한 (지금 결정하지 않기로 한 결정을 포함하여) 이것에 대한 결정을 내릴 가치가 없다고 말하고 있습니다.

그게 무슨 뜻이야? (PR이란 무엇입니까?) @ 토큰 대신 '@' 문자를 사용하는 매크로가 작업을 수행하여 <strong i="22">@testinline</strong> a '@'f b => @f(a, b) ? 아니면 julia-parser.scm에 패치를 제출해야 합니까? (실제로 그런 패치를 작성하기 시작했고 간단해야 할 것 같지만 내 Scheme은 매우 녹슬었습니다.) 테스트 케이스를 만들어야 합니까?

현재 이 버그에는 13명의 참가자가 있습니다. 하나 이상의 제안에 투표하거나 버그 자체에 반대 투표를 한 사람은 총 5명이며, 인라인 매크로 제안이 테이블에 올라간 후 그 중 한 명만 그렇게 했습니다. 아직 프로토타이핑을 할 때라는 확신이 들지 않습니다. 마지막 진지한 제안 이후에 투표한 사람의 수가 참가자의 절반이 되었을 때 일종의 대략적인 합의가 이루어지고 프로토타입을 만들고 테스트하고 결정하는 시간이 되었으면 합니다(또는, 경우에 따라 아이디어를 포기할 수 있음).

"PR [또는] 사용 가능한 프로토타입으로 구현".
가지고 놀 수 있는 것을 말합니다.
그래서 실제로 어떤 느낌인지 알 수 있습니다.

PR은 풀 리퀘스트(pull request)이므로 패치는 당신이 사용하던 용어입니다.

PR을 만든 경우 다운로드하여 테스트할 수 있습니다.
매크로로 구현했다면 더 간단하지만
또는 비표준 문자열 리터럴,
julia를 빌드하지 않고도 테스트할 수 있습니다.

내 부름이 아닌 것처럼, 하지만 내가 가지고 놀 수 있는 것 없이 내 자신의 의견을 내기에는 무모할 것 같습니다.

또한 자전거 보관소를 앞뒤로 이동하지 않으려면 +1합니다.

...또는 매크로와 비표준 문자열 리터럴이 있는 Infix.jl 패키지일 수 있습니다.

우리는 이 대화에서 "작업 코드 또는 GTFO" 지점에 확실히 도달했습니다.

자, 다음은 작동하는 코드입니다. https://github.com/jamesonquinn/JuliaParser.jl

ETA: 특정 커밋을 참조해야 하나요, 아니면 최신 마스터에 대한 위의 링크가 괜찮은가요?

...

( |> , <| , ~ 및 @defineinfix 에 해당하는 것과 같이 내가 원하는 편리한 매크로가 없습니다. 위의 예에서 ~ 또는 |> 연산자에 대한 이제 쓸모없는 특수 사례 논리를 _deprecate_ 제거 하지 않습니다. 작동하도록 파서가 변경되었을 뿐입니다. 기본 기능을 테스트했지만 모든 경우는 아닙니다.

...

~ 를 사용한 현재의 추악한 해킹은 이런 종류의 명확한 사용 사례가 있음을 보여줍니다. 이 패치를 사용하면 매크로 동작이 필요할 때 @~ 라고 말합니다. 특별한 케이스 없이 훨씬 깨끗합니다. 아니면 ~ 이 완전히 독특하고 누구도 다시는 그렇게 하고 싶어하지 않을 것이라고 진지하게 믿는 사람이 있습니까?

패치(네이티브 부트스트랩 파서를 대상으로 하기 때문에 아직 PR이 아니지만 현재로서는 PR 측면에서 우선 순위가 되어야 함)가 여기에 있는 문제 이름보다 일반적으로 더 유용합니다. 문제 이름은 "사용자 지정 중위 연산자"입니다. 패치는 중위 매크로를 제공하며 중위 연산자는 그 부작용으로만 제공됩니다.

패치는 현재로서는 브레이킹 체인지가 아니지만 이것이 계획이 된다면 다음 단계는 현재 존재하는 ~ 및 |> 를 사용하지 않는 것이 될 것으로 예상합니다. 변경 사항을 깨고 있습니다.

...

몇 가지 간단한 테스트가 추가되었습니다.

11608은 우리 중 많은 사람들이 중위 매크로를 원하지 않으며 ~ 구문 분석의 현재 사례 중 하나가 실수라는 매우 분명한 합의로 마감되었습니다(R 호환성을 위해 초기에 만들어졌으며 특별히 좋은 이유는 없습니다). 우리는 그것을 더 이상 사용하지 않고 결국 제거할 예정이지만 아직 수행하지 않았습니다(JuliaStats 패키지의 수식 인터페이스에 대한 API 수정 작업과 함께).

매크로는 이제 기술적으로 일반적이지만 입력 인수는 항상 Expr , Symbol 또는 리터럴입니다. 따라서 함수(중위 또는 기타)와 같은 방식으로 패키지에 정의된 새로운 유형으로 실제로 확장할 수 없습니다. 중위 매크로의 가능한 사용 사례는 접두사 주석 매크로 DSL 또는 문자열 리터럴에서 더 잘 제공됩니다.

(일찍 게시해서 죄송합니다. 지금 수정했습니다.)

#11608에서 몇 가지 부정적인 주장을 봅니다.

===

다음은 무엇으로 변할까요?
...
y = 0.0 @in@ x == 1.0 ? 1 @in@ 2 : 3 @in@ 4

이것은 스레드에서 처리되었습니다.

그런 경우에는 항상 괄호를 사용합니다 ...

그리고

같은 판례 ... 매크로 없이 적용: 0.0 in 1 == 1.0 ? 2 in 2 : 3 in 4

===

사람들이 구현, 유지 관리, 테스트, 사용 방법 등을 배워야 하는 Julia에 더 많은 기능.

여기에서 (부분적으로) 답변(및 두 번째)되었습니다.

"파서 개발자의 두통"은 가능한 가장 낮은 우려입니다.

===

단일 사용자 코드 기반에서 명확하게 함께 사용할 수 있는 동일한 매크로 연산자에 대한 정의를 2개의 패키지가 동시에 가질 수 있는 방법은 없나요?

이것은 흥미로운 점입니다. 분명히 매크로가 함수를 호출하면 함수의 모든 디스패치 권한이 있습니다. 그러나 ~ 와 같이 실제 매크로인 경우에는 더 복잡합니다. 예, 함수로 호출을 시도하고 매크로로 사용하기 위해 오류를 포착하는 것과 같은 해킹된 해결 방법을 상상할 수 있습니다.

그러나 이것은 모든 매크로에 대한 문제만큼이나 중요합니다. 두 패키지가 모두 매크로를 내보내는 경우 "사용"으로 둘 다 가질 수 없습니다.

이것이 중위 매크로의 문제일 가능성이 더 큽니까? 글쎄, 그것은 사람들이 결국 그것을 사용하는 것에 달려 있습니다.

• 사용자 정의 중위 함수를 갖는 방법입니다. 이 경우 다른 기능보다 나쁘지 않습니다. 디스패치가 잘 작동합니다.
• 다른 프로그래밍 스타일을 사용하는 방법으로 @Glen-O가 위에서 논의한 |> 및 <| $와 같은 연산자를 사용합니다. 이 경우 충돌 가능성이 거의 없이 매크로가 무엇을 의미하는지에 대한 공통 규칙이 빠르게 발전할 것이라고 생각합니다.
• 위의 SQL 예제와 같은 특수 목적 DSL을 만드는 방법으로. 나는 이것들이 특정 상황에서 사용될 것이라고 생각하며 충돌 가능성은 그리 나쁘지 않습니다.
• R의 ~ 와 같은 경우. 처음에는 이것이 가장 문제가 있어 보입니다. R에서 ~ 는 여러 가지 용도로 사용됩니다. 그러나 거기에서도 다음과 같이 관리할 수 있다고 생각합니다.

macro ~(a,b) :(~(:$a, quote($b))) end

그러면 ~ 함수는 LHS의 유형을 기반으로 디스패치할 수 있지만 RHS는 항상 Expr입니다. 이런 종류의 것은 R(회귀 및 그래프 작성)에서 사용하는 주요 용도가 공존할 수 있도록 합니다. 즉, 다른 패키지에서 왔음에도 불구하고 올바르게 발송합니다.

(참고: 위의 내용은 수정되었습니다. 처음에는 a ~ b + c 와 같은 R 표현식이 R의 지연 평가를 통해 b 와 c 의 바인딩을 사용했다고 생각했지만 그렇지 않습니다. t; b 및 c 는 명시적으로 전달된 데이터 프레임의 열 이름이지, 암시적으로 전달되는 로컬 범위의 변수 이름이 아닙니다.)

===

여기서 앞으로 나아갈 수 있는 유일한 방법은 실제 구현을 개발하는 것입니다.

내가 한 일.

===

매크로는 이제 기술적으로 일반적이지만 입력 인수는 항상 Expr, Symbol 또는 리터럴입니다. 따라서 함수(중위 또는 기타)와 같은 방식으로 패키지에 정의된 새로운 유형으로 실제로 확장할 수 없습니다.

이것은 위의 요점과 관련이 있습니다. 중위 매크로가 특정 함수를 호출하는 한, 그 함수는 여전히 일반적인 방식으로 디스패치를 ​​통해 확장할 수 있습니다. 특정 함수를 호출하지 않는 한 확장하거나 재정의해서는 안 되는 구조적/구문적(예: |> 이 현재 수행하는 작업)을 수행하고 있습니다. 함수를 호출하더라도 매크로라는 사실은 여전히 ​​유용할 수 있습니다. 예를 들어, 일부 인수를 인용하거나 콜백으로 처리하거나 직접 함수 호출이 할 수 없는 방식으로 변수의 이름 및 바인딩과 동시에 상호 작용할 수도 있습니다.

===

중위 매크로의 가능한 사용 사례는 접두사 주석 매크로 DSL 또는 문자열 리터럴에서 더 잘 제공됩니다.

참조된 스레드에서 지적한 바와 같이:

[Infix는] 우리 언어가 그런 식으로 작동하기 때문에 구문 분석하기가 더 쉽습니다(영어 및 대부분의 서양 사용자의 경우). (일반적으로 운영자도 마찬가지입니다.)

예를 들어, 더 읽기 쉽고 쓰기 쉽습니다.

select((:emp_id, :last_name) <strong i="8">@from</strong> employee_tbl <strong i="9">@where</strong> city == 'NYC' <strong i="10">@orderby</strong> :emp_id)

또는

send(orderby((<strong i="14">@where</strong> selectfrom((:emp_id, :last_name), employee_tbl) city == 'NYC'), :emp_id))

?

===

드디어:

11608은 꽤 명확한 합의로 마감되었습니다.

"누가 그 일을 할 것인가"가 결정적인 투표를 하는 저에게 꽤 고르게 분할된 것 같습니다. 이제 적어도 부분적으로는 말이 안 됩니다. 나는 JuliaParser에서 작업을 수행했으며 사람들이 이 아이디어를 좋아한다면 Scheme에서 수행할 의향이 있습니다.

해킹된 juliaparser에 대한 긍정적인 반응이 없는 한 이것은 이 스레드의 마지막 게시물입니다. 내 의지를 강요하는 것은 내 의도가 아닙니다. 내 관점을 제시하기 위해.

중위 매크로( a <strong i="6">@m</strong> b => <strong i="8">@m</strong> a b )에 찬성합니다. 그렇다고 해서 내가 반대하는 주장을 모른다는 것은 아닙니다. 다음은 내가 반대하는 가장 좋은 주장을 요약하는 방법입니다.

언어 기능은 -100에서 시작합니다. 그것을 극복할 수 있는 중위 매크로는 무엇을 제공합니까? 본질적으로 접두사 매크로로 수행할 수 없는 중위 매크로로 수행할 수 있는 것은 없습니다.

내 대답은: Julia는 무엇보다도 STEM 프로그래머를 위한 언어입니다. 수학자, 엔지니어, 통계학자, 물리학자, 생물학자, 기계 학습 전문가, 화학자, 계량경제학자... 그리고 대부분의 사람들이 깨닫고 있는 한 가지는 좋은 표기법의 유용성입니다. 통계에 익숙한 예를 들면 다음과 같습니다. 독립 확률 변수를 추가하는 것은 PDF를 컨볼루션하거나 CDF의 파생물을 컨볼루션하는 것과 동일하지만 전자를 사용하여 무언가를 표현하는 것은 종종 후자보다 훨씬 더 간결하고 이해하기 쉽습니다. .

중위 대 접두사 대 후위는 어느 정도 취향의 문제입니다. 그러나 많은 경우에 중위어를 선호하는 객관적인 이유도 있습니다. 접두어와 접미사는 Forth 프로그래머가 독일 정치인처럼 들리거나 Lisp 프로그래머가 촘스키 풍자 만화처럼 들리게 만드는 것과 같은 연속 연산자의 소화 불가능한 침전물로 이어지는 반면, infix는 연산자를 종종 인지적으로 가장 중요한 위치에 넣습니다. 가능한 모든 피연산자에 가까운 자연적인 장소. 아무도 Forth에서 수학 논문을 쓰지 않는 데는 이유가 있으며 독일 수학자들도 방정식을 작성할 때 중위 연산자를 사용하는 이유가 있습니다.

예, 중위 매크로를 사용하여 난독화된 코드를 작성할 수 있습니다. 그러나 기존 접두사 매크로도 남용되기 쉽습니다. 남용하지 않으면 중위 매크로가 훨씬 더 명확한 코드로 이어질 수 있습니다.

• (a+b <strong i="18">@choose</strong> b) 이 binomial(a+b,b) ;
• score ~ age + treatment 이 linearDependency(:score, :(age + treatment)) ;
• domSelect("#logo") @| css "color" "red" @| fadeIn "slow" <strong i="25">@thenApply</strong> addClass "dummy" 는 addOneTimeEventListener(fadeIn(css(domSelect("#logo"),"color","red"),"slow"),"done",(obj,evt)->addClass(obj,"dummy")) 중에서 지옥을 능가합니다.

나는 이것들이 단지 장난감의 예라는 것을 알고 있지만 원칙은 유효하다고 생각합니다.

비표준 문자열 리터럴로 위의 작업을 수행할 수 있습니까? 두 번째와 세 번째 예는 NSL로 작동합니다. 그러나 NSL의 문제는 너무 많은 자유를 준다는 것입니다. 특정 문법에 익숙하지 않은 한 NSL의 토큰이 무엇인지, 작동 순서는 말할 것도 없고요. 중위 매크로를 사용하면 위의 모든 예를 수행할 수 있는 충분한 자유가 있지만 "좋은" 코드를 읽을 때 토큰이 무엇이며 암시된 괄호가 어디로 가는지 명확하지 않습니다.

알려지지 않은 미지수에서 알려진 미지수로 이동하려면 특정 항목이 필요합니다. 불행히도 이를 수행하는 메커니즘이 없습니다. 당신의 주장에는 존재하지 않는 구조가 필요합니다.

이제 <| 이 오른쪽 결합(#24153)이므로 초기 a |>op<| b 제안이 작동합니까?

나는 https://github.com/JuliaLang/julia/pull/24404#issuecomment -341570934에서 Steven이 언급한 해킹을 위한 패키지를 만들었습니다.

• https://github.com/Ismael-VC/InfixFunctions.jl

이것이 영향을 미치는 잠재적 중위 연산자의 수는 아니지만 <~ 를 사용하고 싶습니다. 파서는 협조하지 않을 것입니다 -- 내가 물건을 조심스럽게 띄워도 a <~ b 가 a < (~b) $ 를 의미하기를 원합니다.

<- 에도 비슷한 문제가 있습니다.

이것이 이미 이 문제나 다른 문제에 의해 다루어졌다면 죄송하지만 찾을 수 없습니다.

잠재적으로 a < ~b 에 공백이 필요할 수 있습니다. 우리는 전에 그런 규칙을 추가했습니다. 그런 다음 중위 연산자로 <- 및 <~ 를 추가할 수 있습니다.

감사 합니다 @JeffBezanson , 그것은 좋을 것입니다! 이것은 특별한 경우입니까, 아니면 더 일반적인 규칙입니까? 더 많은 중위 연산자를 허용하고, 명확하고 예측 가능한 코드를 제공하고, 기존 코드를 가능한 한 적게 중단하기 위해 규칙이 어떻게 되어야 하는지에 대한 몇 가지 세부 사항이 있다고 확신합니다. 어쨌든 도움과 빠른 응답에 감사드립니다. 새해 복 많이 받으세요!

a <~ b 가 a < ~b a =+ 1 를 오류(또는 최소한 경고)로 보고 싶습니다.

나는 이것이 꽤 오래된 토론이라는 것을 알고 있고 질문한 질문은 꽤 오래전에 제기되었지만 대답할 가치가 있다고 생각했습니다.

이제 <| 이 오른쪽 결합(#24153)이므로 초기 a |>op<| b 제안이 작동합니까?

아니요, 불행히도 |> 가 여전히 우선합니다. 업데이트가 완료되면 <|(a,b)=a(b) 를 정의하면 a<|b<|c 를 성공적으로 수행하여 a(b(c)) ...를 얻을 수 있지만 이것은 다른 개념입니다.

2년 동안 동결, 2, 5일 전 댓글과 커밋 !

사용자 정의 가능한 이항 연산자 f45b6be 문서 참조