Open Source Adventures: 에피소드 75: Crystal Char 유형 문제

Z3 Crystal에서 퍼즐 게임 해결사를 작성하는 동안 무엇보다 가장 많이 부딪힌 문제는 Char 유형의 존재였습니다.

대부분의 현대 언어에는 문자 유형이 없습니다. "foo"[0]는 대부분의 언어에서 a "f" - a String로, 한 문자 길이입니다.

별도Char가 있으면 API가 엄청나게 복잡해집니다. 성능에 유용한 이유를 알 수 있지만 복잡성 비용은 현실입니다.

일반적으로 문자 유형이 문제가 되는 이유

주된 이유는 유니코드 세계에서 문자에 대해 직관적으로 작동할 수 있는 많은 작업이 실제로는 작동하지 않기 때문입니다. 그러나 그들은 문자열에서 잘 작동합니다.

많은 작업 중 그러한 작업 중 하나만 대문자입니다. 다음은 크리스탈입니다.

puts "ß".upcase # outputs correctly uppercased SS
puts 'ß'.upcase # outputs lowercase ß

아야!

길이가 1인 문자열을 대문자로 바꾸면 1보다 긴 문자열이 되는 상황이 많이 있습니다.

따라서 별도의 문자 유형이 있는 언어는 선택할 수 있습니다. 문자에 대한 이러한 작업을 지원하지 않거나(큰 고통이 될 수 있음) 제대로 구현되지 않은 경우(Crystal처럼)입니다.

크리스탈 특정 문제

Crystal에서는 c == "." 또는 c =~ /[0-9]/ 와 같은 많은 코드를 작성했습니다.

여기서 문제는 그들이 단순히 false 또는 nil 를 반환하고 어떤 유형 문제도 불평하지 않는다는 것입니다. 그래서 저는 완벽하게 괜찮아 보이는 코드를 가지고 있고 Ruby와 대부분의 다른 언어에서 완벽하게 잘 실행될 것이고 어떤 식으로든 유형 검사기가 불평하지 않지만 정적으로 잘못되었습니다.

다음은 몇 가지 질문입니다.

크리스탈이 애초에 노출Char했어야 했나? 내가 언어를 설계하고 있었다면 그러한 유형을 추가하지 않았거나 일반 API에 노출되지 않은 내부 유형이 있었을 것입니다.
"a" == 'a' ? 물론 서로 다른 유형이지만 420 == 420.0는 서로 다른 유형이더라도 참이므로 본질적으로 불가능한 것은 아닙니다. 여기에 어떤 의미가 있는지 잘 모르겠습니다.

길이 1Char =~ Regexp인 것처럼 String 일치해야 합니까? 나는 아마도 이것에 대해 예라고 말하고 싶습니다. 적어도 큰 단점은 보이지 않고 매우 분명한 의미가 있으며 달리 표현하기 어렵습니다.

일치하지 않는 유형이 있는 == 또는 =~가 유형 검사를 통과해야 합니까? 노조 유형으로 인해 분명히 그렇습니다. x가 String | Nil이면 x == nil는 "foo" == nil가 유효한 코드여야 함을 의미합니다. 그리고 =~에 대한 동일한 인수입니다.

일치할 수 없는 유형의 == 또는 =~가 경고를 생성해야 합니까? 이제 흥미로운 질문이 있습니다. a == b 및 a =~ b 의 유형으로 인해 false 또는 nil 가 a/b 임을 정적으로 알면 의도한 코드가 아니라 프로그래머 오류일 가능성이 높습니다. 그리고 그것은 매우 복잡한 분석처럼 보이지 않습니다. 그렇다면 Crystal은 이러한 경우에 경고해야 합니까? 모든 경고와 마찬가지로 과도하게 공격적인 린터는 큰 고통이기 때문에 이는 주로 거짓 긍정 비율의 문제입니다.

다음에 온다

좋아요, 지금은 Crystal로 충분합니다. 다음 에피소드에서는 약속대로 다른 기술을 시도하겠습니다.