uft-8 이나 uft-16(리틀) 을 생각중입니다. 혹은 직접 설계해볼생각입니다.(os 코딩 경험이 있어서 필수적인 지식은 압니다;)
나루의 정책은 인코딩을 굳이 고정할 필요가 없도록 만든 것입니다. 예를 들어서,
use encoding "utf-8"
-- 여기서 utf-8로 된 코드를 쓰고
use encoding "ebcdic"
-- 여기서 ebcdic로 된 코드를 쓰고
...하는 것도 가능합니다. (다만 얼마나 소용이 있는지는 모르겠습니다. use encoding directive는 기본적으로 코드 안에서 하나만 나타날 가능성을 염두에 뒀기 때문에...) 이런 정책을 취하는 언어가 실제로 여럿 있는데, 예를 들어서 vim script에서는 스크립트 인코딩을 scripte 명령으로 지정합니다.
인코딩과는 별개로 내부적으로 다루는 문자열 등은 (인코딩은 뭘 쓰더라도) 유니코드로 하는 것이 범용성 면에서 나아 보입니다.
이 글에서 중요한 건 UFT로군요. 이것은 Unidentified Flying Thread를 의미합니다. (농담인 거 아시죠?) 일단 저는 소스 코드 인코딩은 최대한 많이 지원하고, 내부의 문자열은 예를 들어 u8, u, U 등(C++ TR1)을 통해 지정할 수 있게 해야 한다고 생각합니다. 만약 UTF-8이 기본값이라면(한글 프로그래밍 언어가 아닌 이상, 대부분의 문자가 1바이트씩이 되므로 일단 코드 크기상은 유리함) u를 통해 UTF-16을, U를 통해 UTF-32를 지원할 수 있겠고 다중 바이트 문자집합(MBCSs)은 표준 라이브러리를 통해서 지원할 수 있...을 거라고 생각합니다. 이름이 정해지지 않은 제 프로그래밍 언어의 경우 UTF-16이 기본이기 때문에 u가 UTF-8을 의미합니다.
굳이 유니코드 자료형을 여럿 만들어야 하나요? C++ TR1이야 하위 호환성을 유지해야 하기 때문에 그런 접근을 취했지만, 고수준 언어에서 여러 개의 유니코드 자료형이 필요하다고 생각하지는 않습니다. 하나의 유니코드 자료형과 (필요하다면) 바이트 배열을 위한 자료형 하나로 충분하다고 생각합니다.
앞에서 "고수준 언어"라고 했는데 그 기준은 시스템에 직접 접근하는 일이 적은 언어를 뜻한다고 보면 됩니다. D 같은 경우 외부 함수 인터페이스(FFI) 등을 위해 세 종류의 문자형이 있죠.
"열정"은 C++에 내장하는 걸 목표로 하기 때문에 세 가지를 지원합니다. 그나저나 UTF-8을 기본으로 했을 때 바이트 배열로 형을 변환해서 UTF-8 인코딩된 상태의 바이트에 접근할 수 있고, 문자열 상태에서는 코드 포인트로 접근할 수 있다면(예: str[0]=='가'이고 str.toByteArray()[0]==0xEC인 경우) 필요 없겠지요.
나루의 정책은 인코딩을 굳이 고정할 필요가 없도록 만든 것입니다. 예를 들어서,
...하는 것도 가능합니다. (다만 얼마나 소용이 있는지는 모르겠습니다. use encoding directive는 기본적으로 코드 안에서 하나만 나타날 가능성을 염두에 뒀기 때문에...) 이런 정책을 취하는 언어가 실제로 여럿 있는데, 예를 들어서 vim script에서는 스크립트 인코딩을 scripte 명령으로 지정합니다.
인코딩과는 별개로 내부적으로 다루는 문자열 등은 (인코딩은 뭘 쓰더라도) 유니코드로 하는 것이 범용성 면에서 나아 보입니다.
그렇군요... 일단 seoula 2의 기본 인코딩은 uft-8 로 하고 별도의 설정으로 인코딩 변경이 가능하도록 생각중입니다. (최대한 아스키쪽은 피해보려 하고 있습니다 :)
이 글에서 중요한 건 UFT로군요. 이것은 Unidentified Flying Thread를 의미합니다. (농담인 거 아시죠?) 일단 저는 소스 코드 인코딩은 최대한 많이 지원하고, 내부의 문자열은 예를 들어 u8, u, U 등(C++ TR1)을 통해 지정할 수 있게 해야 한다고 생각합니다. 만약 UTF-8이 기본값이라면(한글 프로그래밍 언어가 아닌 이상, 대부분의 문자가 1바이트씩이 되므로 일단 코드 크기상은 유리함) u를 통해 UTF-16을, U를 통해 UTF-32를 지원할 수 있겠고 다중 바이트 문자집합(MBCSs)은 표준 라이브러리를 통해서 지원할 수 있...을 거라고 생각합니다. 이름이 정해지지 않은 제 프로그래밍 언어의 경우 UTF-16이 기본이기 때문에 u가 UTF-8을 의미합니다.
굳이 유니코드 자료형을 여럿 만들어야 하나요? C++ TR1이야 하위 호환성을 유지해야 하기 때문에 그런 접근을 취했지만, 고수준 언어에서 여러 개의 유니코드 자료형이 필요하다고 생각하지는 않습니다. 하나의 유니코드 자료형과 (필요하다면) 바이트 배열을 위한 자료형 하나로 충분하다고 생각합니다.
앞에서 "고수준 언어"라고 했는데 그 기준은 시스템에 직접 접근하는 일이 적은 언어를 뜻한다고 보면 됩니다. D 같은 경우 외부 함수 인터페이스(FFI) 등을 위해 세 종류의 문자형이 있죠.
"열정"은 C++에 내장하는 걸 목표로 하기 때문에 세 가지를 지원합니다. 그나저나 UTF-8을 기본으로 했을 때 바이트 배열로 형을 변환해서 UTF-8 인코딩된 상태의 바이트에 접근할 수 있고, 문자열 상태에서는 코드 포인트로 접근할 수 있다면(예: str[0]=='가'이고 str.toByteArray()[0]==0xEC인 경우) 필요 없겠지요.
저는 그냥 라이브러리써서 라이브러리가 지원하는 만큼만 지원하게 합니다. 파일 인코딩이야 실행 option이나 conf에서 정하도록 하구요.
혹시 ICU(International Component for Unicode)를 쓰실 생각이신가요?
네 ICU써서 lexer는 손으로 만들었습니다.