+1
정말 이런 일이 일어나는 것을 보고 싶습니다.
인덱싱에 사용되는 end 와 같이 더 읽기 쉽습니다.

+1
2013년 12월 27일 오후 1시 6분에 "GaborOszlanyi" [email protected]에 다음과 같이 썼습니다.

+1
정말 이런 일이 일어나는 것을 보고 싶습니다.
인덱싱에 사용되는 끝과 같이 더 읽기 쉽습니다.

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

이 제안도 마음에 듭니다.

나는 이것이 받고 있는 지지의 폭발적 증가에 약간 놀랐다. 나는 항상 철자된 연산자가 제어 흐름에 대해 훨씬 더 직관적이라고 느꼈지만 그 느낌이 널리 퍼져 있다는 것을 깨닫지 못했습니다.

당신이 이 제안을 할 때 나는 팬이 아니었지만, 조금 더 생각한 후에 그것이 나에게도 많은 의미가 있다고 말해야 합니다. 이들은 텍스트가 아닌 기호를 사용하는 다른 모든 것과 달리 실제로 제어 흐름 연산자입니다. 이것은 & 및 | 와의 혼동을 줄일 수 있습니다.

and 및 or (Perl, Ruby, Lua -- 내가 확인한 언어)를 제공하는 언어도 not (Lua는 ! ). 내 첫 번째 반응은 ! 중복되므로 마음에 들지 않는다는 것입니다. 하지만 아마도 이러한 언어들이 그렇게 하기로 선택한 강력한 이유가 있을 것입니다.

나는 개인적으로 not 를 많이 좋아하지만 not 전환하는 것이 and 및 or 를 사용하여 제공하는 모호성 감소와 같은 것을 제공한다고 생각하지 않습니다.

not 는 단락/제어 흐름 작업도 아니며 연관성과 관련하여 읽는 방법에 대해 항상 고심하고 있습니다. 내가 파이썬에서 유일하게 좋아하는 곳은 if not ... 이지만 그것은 제어 흐름 작업으로 읽었기 때문입니다.

+1

XOR을 단락으로 추가할 수도 있습니까?
그리고 반전 버전(XNOR,NAND,NOR)의 단락 버전?

XOR은 결코 단락될 수 없습니다. 다른 것들은 ! 와 and 및 or 연산자로 간단하게 작성할 수 있습니다.

+1
Ruby에서는 && 대 'and'(http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/)에 대한 지속적인 혼란이 있음을 지적하겠습니다. Ruby가 두 세트의 연산자를 모두 사용하고 혼동할 가치가 있는지 또는 'and'를 위해 &&를 완전히 제거해야 하는지 여부를 결정하는 데 사용하는 합리성을 염두에 두면 좋을 것입니다.

and 및 or 가 Perl 및 Ruby에서와 같이 매우 낮은 우선 순위를 가지므로 다음과 같은 것을 작성할 수 있습니다.

k <= n and k *= 2

때로는 부울 결과를 무언가에 할당하고 싶을 때가 있습니다.

cond = f() && g()

그것과 충돌하는 것 같습니다.

이것이 바로 Ruby와 Perl이 서로 다른 우선순위를 가진 두 연산자 세트를 가지고 있는 이유입니다. 옹호하는 것이 아니라 그냥 말하는 것입니다. 나는 그 사용법이 실제로 얼마나 일반적인지 잘 모르겠지만, 우리 코드를 grepping하면 많은 k <= n && (k *= 2) 종류가 드러납니다.

첫째, 나는 또한 and 및 or 입니다.
현재 Julia에서 가장 낮은 4개의 우선 순위 그룹은 다음과 같습니다.

1. += 등, := , => 및 ~ 포함한 할당
2. 삼항 연산자 ?
3. ||
4. &&

나는 이것이 좋은 의미가 있다고 생각합니다 ( ~ 에 대해 확실하지 않지만 요점에서 벗어남). 논리 and 및 or 는 할당의 오른쪽 및 ? 조건으로 유용합니다. and 또는 or 대한 인수로 대입 또는 삼항 연산자를 사용하려는 경우 비정상적인 작업을 수행하고 있고 괄호가 순서대로 정렬되어 있다는 것을 알고 있다고 생각합니다.

Btw, 많은 사람들이 논리 연산에 and 및 or 를 사용하는 언어가 논리적 부정에 not 를 사용할 것이라고 예상할 것이라고 생각합니다. 하지만 ! 를 유지해야 하는 타당한 이유가 있다면 괜찮을 것입니다. ( ! 는 적어도 #4892가 구현된 경우 병합되는 논리적 부정이 아닙니다.)

나는 약 조금 슬픈 것 not 대신 ! ,하지만 난 여기에 무엇이든 갈 수 있습니다.

not 가 전혀 유사하다고 생각하지 않습니다. and 및 or 는 함수가 아닌 제어 흐름 연산자인 반면 ! 는 함수일 뿐입니다.

나는 스테판에 동의합니다. not 실제로 얻을 수 있는 유일한 것은 많은 괄호를 사용할 필요가 없다는 것입니다. 그건 별개의 문제라고 생각합니다.

나는 단지 새로운 사용자의 초기 기대에 대해 이야기하고 있었습니다. 하지만 나는 생각해
유지할 수 있는 건전한 이유가 있는 것 같습니다!

저는 반대하고 싶습니다. 내가 규칙적으로 사용했던 모든 언어를 포함하여 꽤 많은 언어에서 && 및 ||를 사용하며 항상 단락입니다. 및 / 또는 단락 여부에 관계없이 직관적 인 기대가 없습니다. 나는 또한 &&와 || 변수 이름 및 숫자와 시각적으로 명확하게 구분됩니다.

http://en.wikipedia.org/wiki/Short-circuit_evaluation 의 표는 이 논의와 관련이 있을 수 있습니다.

Python 세계에서 온 사람으로서 @GunnarFarneback과 동의한다는 사실에 놀랐습니다. 최근에 나는 영어 조건부( and , or , not )가 종종 내가 순진하게 작동할 것으로 예상하는 잘못된 코드를 작성하게 한다는 것을 발견했습니다. 영어) 그런 다음 내 오류를 깨닫기 전에 영어에서 논리적 문장으로 정신적으로 변환하는 동안 몇 초 동안 머리를 긁적입니다. 그렇다고 내가 특별히 어느 방향으로 편향된 것은 아닙니다. 그냥 내 2¢를 넣어.

나도 and 및 or

+1

+1
두 연산자를 모두 가지고
and 및 or 우선 순위가 낮음)
cond = f() && g() 는 cond = (f() && g()) 로 작성해야 한다고 주장합니다.
나는 또한 내가 본 모든 컨텍스트에서 강력한 우선 순위를 갖는 if !(something and something) 가 어떤 깊은 곳에서 싫어하는 not 사용을 지원합니다 ! , 비합리적이고 불변의 수준. 저도 가끔 ! 힘든 것 같아요. 나는 또한 그가 ! 기원에 대해 알지 못하지만 그것이 정수에 대한 계승 연산자로서 더 정당한 위치를 가지고 있다고 생각합니다. 따라서 matlab의 ~ 구문을 선호합니다.

@johnmyleswhite 이 문제가 종료되었습니까? 이 배를 타고 항해한 것 같아요.

:(

찡그린 얼굴의 단락

나는 우리가 여전히 이것을 고려해야 한다고 생각합니다. 많은 사람들이 && 및 || 우리가 사용하는 방식으로 사용하는 것을 싫어하고 and 및 or 선호합니다. && 및 || 다소 어색하게 만드는 우선 순위 문제도 있습니다. && 및 || 는 두 피연산자가 모두 부울이어야 하고 and 및 or 는 && 및 || 를 수행하는 미래로 이동할 수 있습니다. x == nothing and x = 0 등을 쓸 수 있도록 우선 순위가 낮습니다. 그 중 하나 또는 x = 0 if x == nothing 와 같은 다른 한 줄 조건부 구문을 도입하십시오.

마지막 구문 x = 0 if x == nothing 에는 https://groups.google.com/forum/#!topic/julia -dev/cnmLcNg8h0Q의 제안이 수행하는 IMO 문제 중 일부가 있습니다.
다음 두 가지 옵션이 너무 끔찍해서 Julia가 사후 조건을 필요로 합니까?

    if x == nothing ; x = 0 ; end

또는

   x == nothing && (x = 0)

즉, Julia에서 repeat ; expr(s) ; until cond 구조를 보는 것이 마음에 들지 않는 것처럼(그러나 그것 없이도 살 수 있음) and 및 or 있는 데 아무런 문제가 없다고 생각합니다
C && 및 || 에서 빌린 것보다 julia 구문에 더 잘 맞는 것 같습니다.

나는 우리가 여전히 이것을 고려해야 한다고 생각합니다.

+1

|| 보다 우선 순위가 낮은 할당에 놀랐습니다. 그래서 이전 토론을 검색하여 이 문제를 찾았습니다. 큰 문제는 아니지만 그 괄호는 나에게 적합하지 않게 보입니다. 어떤 할당 위치가 유효하지 않은지 알아내는 데 시간이 걸렸습니다(몇 초, REPL 테스트). - 오류 메시지는 함수 정의의 끝을 지난 줄을 나타냅니다.

isempty(o) || (m.over[s][NULL] = o)

대조적으로, cond = (f() && g()) 의 괄호는 나에게 괜찮아 보입니다. 나는 어쨌든 그들을 사용할 것이라고 생각합니다.

그 가치를 위해 and 및 or 도 선호합니다.

나도 +1.

응답은 and 등에 찬성하여 거의 만장일치로 긍정적입니다. 저는 반대 2개, 무관심 1개, 불특정 2개, 기타 모든 사람(15명 이상)에 대해 찬성합니다.

(읽기가 더 어렵다)에 대한 한 가지 주장은 틀렸다고 생각합니다. foo and bar 는 3단어와 SYMBOL단어로 인해 foo && bar 보다 읽기 어렵다는 주장입니다. 그러나 모든 사람이 구문 강조 표시를 사용하고 있으며 이 경우에는 반대 현상이 발생합니다. and 는 키워드로 색상이 지정되므로 a<1 and b>3 는 실제로 왼쪽 및 오른쪽 하위 표현식을 시각적으로 분할하기 위해 색상을 지정하는 반면 a<1 && b>3 세 연산자는 모두 같은 색상이 됩니다. 큐 잠재 연산자 우선 순위 머리 긁기.

아직 제시되지 않은 _for_ 인수는 부울 연산자가 단어가 되는 우아한 일관성이 있다는 것입니다. 연산 결과가 true 또는 false , 즉 단어이기도 하기 때문입니다. 따라서 초보자가 & vs and 를 비트 단위 대 논리 단위로 암기하는 것은 매우 쉽습니다. & 대 && 를 암기하는 것은 임의의 할당처럼 보이기 때문에 훨씬 더 어렵습니다. & and 는 영어로 & 잘못 사용합니다. 이로 인해 우선순위 버그(?)가 발생할 수 있습니다.

또 다른 가능한 주장은 뇌가 {BUNCH OF SYMBOLS} 단어 {BUNCH OF SYMBOLS}를 자연스럽게 구문 분석한다는 것입니다.

왜 그냥 전환하지? 지금은 항상 그것을 하기 가장 좋은 시간이며, 지금보다 쉬울 수는 없습니다. 현재 &&를 사용하는 코드를 수정하는 것은 그리 어렵지 않습니다.

and or not xor 아마도 nand 가 완전성을 위해? 나는 ! 을 유지하는 아이디어에 신경 쓰지 않습니다. 프로그래머가 언제 어느 것을 사용할지 선택하게 하십시오. 아무 문제가 없습니다! ! 이미 foo! 스타일 함수에서 사용되므로 "기호 재사용 최소화" 인수가 있습니다.

@StefanKarpinski 2013년부터 찬성 의견이 일치한 것 같습니다. 이를 구현하려고 시도할 수 있지만, 이 문제가 아직 닫히지 않았기 때문에 이것이 전혀 고려되지 않을지 걱정됩니다. 논의? 기호 대신 이 단어를 사용하면 true , false , end 등과 마찬가지로 중위 연산자인 isa 와도 잘 어울립니다. 이 방법으로 더 일관되고 읽기 쉽습니다.

+1

Python에서 Julia로 이동하는 중입니다. Julia가 기호 오버플로에 빠질 위험이 있는 것 같습니다. 사람이 읽을 수 있는 코드를 위해 and 및 or 강력히 지원합니다.

not 키워드를 지원하면 코드 가독성도 향상될 수 있습니다.

0.7/1.0에서 각각 and 및 or (및 아마도 not )의 사용을 중단/금지해야 하며, 나중에 이를 추가하기로 결정한 경우 정말로 그들을 좋아합니까?

나는 그것으로 실망할 것입니다. @JeffBezanson 은 반대하지만 지금 허용하지 않으면 나중에 언제든지 마음을 바꿔서 허용할 수 있지만 다른 방향으로 갈 수는 없습니다. 간단한 "를 사용하여 제공 할 수 있도록 그것은 또한 도움이 될 수 && 대신 and "파이썬 스타일의 연산자를 시도 사용자에게 오류 메시지가.

정말 좋을 것 같아요!

잊지 않기 위해 이정표를 다시 열고 추가합니다.

이정표의 의도를 이해하지 못합니다. and 및 or 를 추가할 예정입니까? 우리는 그것을 재고하고 있습니까? 이것의 다른 용도를 찾고 계십니까? 또는 경고와 같은 비추천을 추가할 예정이므로 Python에서 오는 사람들은 and 대신 && 를 사용하는 것을 알 수 있습니까?

나는 그들이 별칭이었던 https://github.com/JuliaLang/julia/pull/19788 을 가지고 있었지만 그것을 대체하기 위해 변경할 수 있습니다.

이정표는 다음을 의미해야 합니다. 결정에 도달합니다. 또는 제 시간에 결정에 도달할 수 없는 경우 나중에 다른 사람의 코드를 깨뜨릴 위험 없이 결정을 연기할 수 있도록 and 및 or 을 중단합니다.

몇 주 안에 코드를 동결하려는 열망이 주어진다면 이 웜 캔을 지금 다시 여는 것이 늦을 수 있다는 점을 이해하지만(미래를 위해 문을 열어두도록 감가상각을 추가하는 아이디어에 감사드립니다), 한 가지 생각은 다음과 같습니다.

이것이 논의를 위해 처음 나왔을 때(2013) Julia 커뮤니티는 주로 개발자였습니다. && 및 || 사용에 익숙했던 강력한 CS 배경을 가진 사람들이었습니다. and 및 or 가장 좋아하는 사람들은 ASCII 샐러드에 익숙하지 않고 아직 이전 언어로 완전히 익숙해지지 않은 응용 사용자일 것이라고 _의심__ && 및 || . 우리가 현재 Julia 사용자를 대상으로 설문조사를 했다면 사람들이 이에 대해 어떻게 느꼈는지 보는 것이 흥미로울 것입니다.

제안된 것은 and , or 및 not 구문을 예약하는 것입니다. 그렇게 하면 1.x 타임라인의 어느 지점에서나 이들을 연산자로 추가할 수 있습니다. 현재로서는 더 이상의 논의가 필요하지 않습니다.

** 와 같이 이것을 영구적인 구문 오류로 구문 분석하는 것이 좋습니다. 그러나 나는 매우 그들에게 다른 의미의 종류를 제공에 대해, 여전히 매우입니다.

나는 또한 우리가 이미 결정에 도달한 오래된 문제, 특히 1.0에 매우 가까운 오래된 문제를 파헤치고 있다는 사실도 유감스럽게 생각합니다.

분명히 하자면, 이것은 누군가가 하면 완료됩니다.

설명 감사합니다! :NS

그것들을 구문 분석하고 다른 사용을 금지하는 것을 귀찮게하고 그럼에도 불구하고 구문 오류로 만드는 것은 나에게 매우 어리석은 일입니다. 대부분의 사람들은 and 및 or 가 예약어(예: <strong i="7">@stackeval</strong> 1 0 and 1 or 와 같은 컨텍스트에서는 사용할 수 없음)이지만 아무 것도 유용하지 않은 상황을 원하지 않을 것이라고 생각합니다. 나는 그것들이 전혀 구문 분석되지 않거나 별칭으로 구문 분석될 것을 제안합니다(C와 Ruby가 그렇게 하는 것처럼 드문 일이 아닙니다).

이미 별칭으로 구문 분석하지 않기로 결정했기 때문에 PR이 종료되었습니다. 따라서 전혀 구문 분석하지 않은 것에 대해 +1입니다.

메스꺼움을 겪었던 이 토론을 다시 할 위험을 무릅쓰고 C와 Ruby에 대해 C에서 and 및 or 를 사용하는 것은 내 경험상 매우 드문 일이며 일반적인 Ruby 스타일 가이드에는 && 및 || 대신 and 및 or 합니다.

IMHO: 원래 토론이 다소 분열된 것 같으며 이 보호 기능을 추가하면 커뮤니티가 원하는 미래에 다시 방문할 수 있는 공간이 남습니다.

이게 왜 다시 열렸는지 모르겠네요.

이와 같은 구문 기능이 있는 Julia 방언은 JuliaParser.jl을 사용하여 쉽게 수행할 수 있습니다. 내부 및 메타 프로그래밍 API가 안정화되면 기다릴 수 없습니다! :웃다:

일어난 일을 따르지 않고 이 문제에 온 사람들을 위해: and 및 or 를 사용하는 아이디어가 상당한 지지를 모았지만 *), 문제에 접근한 첫 번째 PR - #19788 - 주로 and 및 or 가 && 및 || 직접 대체해야 하는지 아니면 약간 다른 의미를 가져야 하는지에 대한 결정적이지 않은 토론으로 이어졌습니다. 우선 순위를 지정했지만 별칭을 만드는 것은 원치 않는 것으로 간주되었습니다. PR #24965는 1.x 주기 동안 키워드에 의미를 부여하기 위해 키워드( not 와 함께)를 예약했을 것입니다. 그러나 분류 호출 중 논의 결과 비승인이 되었기 때문에 이를 재검토할 수 있는 가장 빠른 시점은 2.0입니다. (그리고 아마도 변화가 일어나려면 정말 설득력 있는 사례를 만들어야 할 것입니다.)

*) 제안된 변경 사항이 더 영향력 있는/"핵심" 개발자에게 덜 인기 있는 것처럼 보이므로 👍의 수만 보면 오해의 소지가 있을 수 있습니다.

나는 내가 지나치게 단순화하지 않고 일을 적절하게 올바르게 하기를 바랍니다. 내가하지 않았다면 사과드립니다.

따라서 이것이 재고될 수 있는 가장 빠른 시점은 2.0입니다. (그리고 아마도 변화가 일어나려면 정말 설득력 있는 사례를 만들어야 할 것입니다.)

우리가 지금 여러 번 하지 않기로 결정했다면 왜 그런 일이 일어날지 모르겠습니다. 모든 주요 릴리스에 대해 이 문제를 다시 파헤치는 일을 피할 수 있기를 바랍니다.

Julia가 Python과 경쟁할 수 있을 만큼 오래 머물면 이것이 점점 더 많이 나올 것이라고 장담할 수 있습니다. 많은 Python 사용자는 C 구문으로 돌아가기를 원하지 않습니다. 이것은 Python이 인기 있는 많은 이유 중 하나입니다. 배우기 쉽고, 사용에 중독되어, 예전 방식으로 돌아가고 싶지 않을 것입니다.

새로운 언어 디자이너는 종종 사용자 친화적인 구문을 원한다고 주장하지만, 채택을 유도할 수 있는 간단한 조정을 간과하면서 사용자의 극소수 하위 집합만 원하거나 사용할 멋진 기능에서 길을 잃는 경향이 있습니다.

적절한 사례: 기괴한 유니코드 연산자는 지원 되지만 자연어 and 및 or 는 지원 되지 않습니다.

R은 또한 && 및 || 및 1-인덱싱을 사용합니다. 그것은 단지 더 오래된 (또는 C와 같은 저급 언어)가 아닙니다. 나는 어떤 것을 사용해야 하는지에 대해 무관심하지만 더 어렵지는 않습니다. 저는 R과 Python 모두에게 초보자를 완료하도록 가르쳤고(프로그래밍 차이 없음) 이것이 그들이 고군분투했던 것이 아닙니다. 일반적으로 기본 개념이 코드를 작성하는 데 사용되는 기호나 단어보다 더 중요하고 학습하는 데 더 많은 시간이 걸렸습니다. R, Python, C 등의 사용자에게 "사용자 친화적인" 및 "직관적인" 구문은 단순히 이미 익숙하기 때문에 다를 것입니다. 다른 언어로 프로그래밍한 경험이 있는 사람들은 새로운 언어에서 다른 규칙을 다룰 수 있는 경험과 전문성이 있다고 생각하기 때문에 여기에서 더 관심을 가져야 하는 절대 초보자의 경우는 아닙니다.

여기에서 제기된 유일한 이유는 Python이 and 및 or 하고 그런 사람들이 있기 때문입니다. 바꿀 가치가 있습니까? Julia는 Python이 아니므로 시도해서는 안 됩니다. 우리는 이미 파이썬을 가지고 있습니다. 새로운 언어로 전환하려는 동기를 부여하려면 언어가 달라야 합니다. Julia의 새로운 사용자는 Python 프로그래머가 아닐 수도 있고 다른 언어에 대한 경험이 있을 수도 있습니다(또는 충분히 대중화되면 전혀 경험이 없을 수도 있습니다).

나는 이것이 아마도 죽은 문제라는 것을 알고 있지만 @TomKellyGenetics 에 대한 응답으로 IMHO는 R이 "오래된" 것으로 간주되며 특히 사용자 친화적이지 않다고 주장할 것이라고 제안합니다... 그리고 초보자의 경우 && 동의합니다 and , or )가 Python인지 여부에 관계없이 더 친숙하고 읽기 쉽다고 생각합니다. 사용자 여부.

R은 &&와 ||도 사용합니다. 및 1-인덱싱. C와 같은 오래된(또는 낮은 수준의) 언어가 아닙니다.

나는 C와 같은 언어, 즉 '다른 모든 언어가 사용하는 구문이다'라는 자체 충족적인 주장과 함께 C에서 구문을 많이 차용하는 언어를 언급하고 있었습니다. R 구문은 여기저기서 다르지만 C와 비슷합니다. Julia는 C보다 Fortran과 비슷하지만 약간의 중복이 있습니다.

나는 R과 Python을 모두 초보자를 완료하도록 가르쳤고(프로그래밍 차이 없음) 이것이 그들이 고군분투했던 것이 아닙니다.

프로그래밍을 처음 접하는 IME 학생은 다른 모든 것 외에도 구문 문제로 어려움을 겪습니다. 프로그래밍은 낯설고 자연어보다 추상적인 기호를 선택하면 프로그래밍이 훨씬 더 낯설고 잊기 쉽습니다. C와 같은 언어의 초보자가 "'or'를 다시 쓰는 방법은 무엇입니까?"와 같은 질문을 자주 듣습니다.
그러나 프로그래밍에서 자연어는 초보자에게만 해당되는 문제가 아닙니다. 심지어 숙련 된 프로그래머는 놓칠 가능성이됩니다 ! 이상 not 가 속도를 읽고 입력 쉽게, 많은 찾기 or 및 and 이상 || 및 && .

Julia는 Python이 아니므로 시도해서는 안 됩니다. 우리는 이미 파이썬을 가지고 있습니다. 새로운 언어로 전환하려는 동기를 부여하려면 언어가 달라야 합니다.

Julia는 C나 Fortran도 아닙니다. 대부분의 대중적인 언어는 C와 유사하므로 눈에 띄는 것은 일반적으로 C와 다른 작업을 수행하는 것을 의미합니다. 저는 실제로 Fortran, C 및 그 후손을 좋아하고 항상 사용하지만 일부 위치에서는 부족하여 우리가 할 수 있다고 생각합니다. 더 잘해. 보다 자연스러운 언어를 사용하는 것도 한 가지 방법입니다. Fortran 77 이상에서는 .not. , .and. 및 .or. 를 사용하여 좋은 효과를 얻을 수 있습니다. 이런 의미에서 저는 Julia가 더 포트란과 비슷하고 C와 비슷하지 않기를 원합니다!

이 문제는 해결되었습니다. and 및 or 는 식별자로 허용되며 제어 흐름에 && 및 || 를 계속 사용합니다. 이것이 왜 아직도 논의되고 있는지 잘 모르겠습니다.

피상적인 구문 문제의 중요성을 과대평가하는 경향이 있습니다. 왜냐하면 그것들은 눈에 잘 띄고 논의하기 쉬우며 그 의미가 일반적으로 분명하기 때문입니다. 다른 영역에서는 코드 블록이 중괄호로 묶이지 않는 한 언어를 사용할 수 없는 것으로 간주됩니다. 이 경우 julia와 python은 모두 창백하지 않습니다.

a and b 이 실제로 a && b 보다 더 읽기 쉬운지 여부는 논쟁의 여지가 있다고 생각합니다. && 가 더 눈에 띕니다. || 와 && 가 같은 길이라는 사실도 더 나은 형식으로 이어질 수 있습니다. 같은 이유 연산자 기호 중 하나 a = b 및 a + b 잘 작업은 같은 것을 통해 시각적 구조를 추가한다는 것입니다 set a to b . a[i] 또는 element i of a ?

예전 방식으로 돌아가고 싶지 않을 것입니다.

나에게 예전 방식은 수동 메모리 관리와 && 철자가 아닌 다형성에 대한 약한 지원입니다.

Julia에는 for a in [1, 2, 3] 와 같은 몇 가지 자연어 표현식이 있습니다. 이것은 Julia도 지원하는 for a = [1, 2, 3] 보다 읽기 좋고 직관적입니다. 모든 기호 연산자에 대해 자연어 대안을 제공할 것을 제안하지는 않습니다. Julia를 더 직관적이고 읽기 쉽게 만드는 몇 가지만 제공합니다.

FWIW, 나는 채택을 용이하게하고 사용자에게 스타일 선택을 제공하기 위해 두 연산자 세트를 모두 채택하는 데 투표했습니다. 사람들이 둘 다 사용하는 C++ 프로젝트에서는 결코 귀찮게 한 적이 없습니다. 나는 그것에 해를 끼치 지 않고 이익 만 봅니다.

전반적으로 나는 Julia의 구문이 진행한 방향을 좋아합니다. 자연어와 기호 사이의 훌륭한 균형을 통해 숫자 언어가 범용 프로그래밍에서 뛰어날 수 있음을 증명합니다. 그것이 어떻게 성장하고 발전하는지 기다릴 수 없습니다. 자연어 연산자를 추가하는 것이 기술적으로 이전 버전과 호환된다고 말하는 방법입니다. :이를 드러내고 웃다:

나중에 사용할 수 있도록 or , and 및 not 를 예약하고 해당 기호를 사용하라는 경고/제안을 발행하겠습니다. Julia 0.7, 1.0 또는 둘 다에서 이 작업을 수행해야 합니까?

24965?

아, 놓쳤군요, 감사합니다! 키워드를 예약하지 않아도 앞으로 이러한 키워드를 지원하는 것을 막을 수는 없을 것 같습니다.

죄송합니다. 모든 토론을 읽었지만 여전히 이해하지 못했습니다. 이제 Julia에서 and , or 를 사용할 수 있습니까?

당신은 할 수 없습니다