Haskell 커뮤니티의 일반적인 의견은를 Text대신 사용하는 것이 항상 더 낫다는 것 같지만 String, 유지 관리되는 대부분의 라이브러리의 API가 여전히 String지향적 이라는 사실 은 저를 혼란스럽게합니다. 다른 한편으로, 모두 실수로 간주 하고 모든 지향 함수의 인스턴스를 제공하는 주목할만한 프로젝트 가 있습니다.StringPreludeStringText .
그렇다면 사람들이 String역방향 및 표준 Prelude 호환성과 “스위치 만들기 관성”을 제외하고 계속 지향적 인 API를 작성해야하는 이유가 있습니까? 다른 단점이 있습니까?Text 비해 이 String있습니까?
특히 저는 라이브러리를 설계하고 오류 메시지를 표현하는 데 사용할 유형을 결정하려고하기 때문에 이에 관심이 있습니다.
답변
내 무조건 추측은 대부분의 라이브러리 작성자가 필요 이상으로 종속성을 추가하기를 원하지 않는다는 것입니다. 문자열은 말 그대로 모든 Haskell 배포판의 일부이기 때문에 (언어 표준의 일부입니다!), 문자열을 사용하고 사용자가 해킹에서 텍스트 배포판을 분류 할 필요가 없으면 채택하기가 훨씬 쉽습니다.
대부분의 커뮤니티에서 밤새 전환하도록 설득 할 수없는 경우는 함께 살아야하는 “디자인 실수”중 하나입니다. Applicative가 Monad의 수퍼 클래스가되는 데 얼마나 걸 렸는지 살펴보세요. 상대적으로 사소하지만 많은 변경이 필요했습니다. 그리고 모든 String 항목을 Text로 바꾸는 데 얼마나 걸릴지 상상해보세요.
좀 더 구체적인 질문에 답하려면 Text를 사용하여 눈에 띄는 성능 이점을 얻지 않는 한 String을 사용하겠습니다. 오류 메시지는 일반적으로 다소 작은 일회성이므로 String을 사용하는 것이 큰 문제는 아닙니다.
반면에 당신이 이상주의에 대한 실용주의를 피하는 일종의 이념적 순수 주의자라면 텍스트로 가십시오.
* 문자 목록으로서의 문자열은 기존의 다른 목록 연산 함수와 쉽게 추론하고 통합 할 수있는 깔끔한 속성이기 때문에 디자인 실수를 겁 따옴표에 넣었습니다.
답변
API가 대량의 문자 지향 데이터 및 / 또는 다양한 인코딩을 처리하는 것을 목표로하는 경우 API는 Text를 사용해야합니다 .
API가 주로 작은 일회성 문자열을 처리하는 데 사용되는 경우 내장 문자열 유형 을 사용하는 것이 좋습니다.
많은 양의 텍스트에 문자열 을 사용하면 API를 사용하는 애플리케이션이 훨씬 더 많은 메모리를 소비하게됩니다. 외부 인코딩과 함께 사용하면 API 작동 방식에 따라 사용이 심각하게 복잡해질 수 있습니다.
문자열은 상당히 비쌉니다 (최소 5N 단어, 여기서 N은 문자열의 문자 수). 단어는 프로세서 아키텍처와 동일한 수의 비트입니다 (예 : 32 비트 또는 64 비트) :
http://blog.johantibell.com/2011/06/memory-footprints-of-some-common-data.html
답변
소규모 프로젝트에서 [Char]를 사용하는 이유는 최소한 세 가지입니다.
-
[Char]다른 플랫폼에서 다르게 작동하거나 아예 사용할 수없는 외부 포인터, 원시 메모리, 원시 배열 등과 같은 신비한 직원에 의존하지 않습니다. -
[Char]하스켈의 링구아 프랑카입니다. 하스켈에서 유니 코드 데이터를 처리하는 ‘효율적인’세 가지 방법이 있습니다.utf8-bytestring,Data.Text.Text및Data.Vector.Unboxed.Vector Char, 각각 추가 패키지를 처리해야합니다. -
[Char]하나 를 사용하면[]많은 특정 기능을 포함하여 모나드의 모든 기능에 액세스 할 수 있습니다 (대체 문자열 패키지는이를 지원하려고하지만 여전히).
개인적으로 utf16 은 utf8 과 utf32 인코딩의 결점을 결합 하는 동시에 장점이 전혀 없기 때문에 utf16 기반 Data.Text의 haskell 커뮤니티에서 가장 의심스러운 설계 중 하나 라고 생각 합니다.
답변
Data.Text가 항상 Data.String보다 효율적인지 궁금합니다 ???
예를 들어 “cons”는 문자열의 경우 O (1)이고 텍스트의 경우 O (n)입니다. Append는 문자열의 경우 O (n)이고 엄격한 텍스트의 경우 O (n + m)입니다. 마찬가지로,
let foo = "foo" ++ bigchunk
bar = "bar" ++ bigchunk
엄격한 텍스트보다 문자열에 대해 공간 효율적입니다.
효율성과 관련이없는 다른 문제는 패턴 일치 (명시적인 코드) 및 게으름 (예측 가능한 문자열의 문자 당, 어떻게 든 게으른 텍스트에 따라 구현 됨)입니다.
텍스트는 정적 문자 시퀀스 및 내부 수정에 분명히 좋습니다. 다른 형태의 구조적 편집의 경우 Data.String에 이점이있을 수 있습니다.
답변
나는 String이 남아있는 하나의 기술적 이유가 없다고 생각합니다. 그리고 몇 가지를 볼 수 있습니다.
전반적으로 먼저 텍스트 / 문자열의 경우 최상의 솔루션이 하나 뿐이라고 주장합니다.
-
현악 연주는 나쁘다, 모두가 그것에 동의한다
-
텍스트는 사용하기 어렵지 않습니다. 문자열에서 일반적으로 사용되는 모든 함수는 텍스트에서 사용할 수 있으며 문자열 컨텍스트 (대체, 패딩, 인코딩)에서 더 유용합니다.
-
두 가지 솔루션을 사용하면 모든 기본 함수가 다형성이 아닌 경우 불필요한 복잡성이 발생합니다. 증명 : 자동 변환에 대한 질문 이 있습니다 . 그래서이 입니다 문제는.
따라서 하나의 솔루션은 두 가지보다 덜 복잡하며 String의 단점으로 인해 결국 사라질 것입니다. 빠를수록 좋다 !
답변
