평범한 한글의 방향성에 대하여

안녕하세요? 트위터로만 소통하다보니 뭔가 한계가 있어서 이번에는 용기를 내어서 새로운 논점을 열었습니다.

현재 평범한 한글에서는 객체에게 이름을 붙여줄 수 있는 방법이 없습니다. 나중에 객체를 사용하기 위해서는 함수에 인수로 넘기고 ㄱ ㅇㄱ, ㄴ ㅇㄱ 처럼 참조하는 방법이 유일합니다. 이 방법은 작은 프로그램에서는 괜찮지만 프로그램이 커진다면 복잡해져서 읽기가 어려울 듯합니다.

언어 명세를 보면 클래스 등 사용자 자료형과 기타 기능 추가도 생각하고 계신 듯한데요, 그렇다는 건 평범한 한글이 큰 프로그램 작성을 염두에 두셨다는 것인지요?

처음 평범한 한글을 접해을 때는 일상에서 접할 수 있는 작은 문제들을 한글로 써서 풀어내는 언어라고 생각했습니다. 하지만 언어를 공부하다보니 굉장히 독특한 구조를 가지고 있고, 이 구조대로라면 생각보다 큰 규모의 프로그램도 작성할 수 있다고 생각했습니다.

그러려면 객체에 이름을 붙인 다음 필요할 때 이름으로 객체를 꺼내 쓰는 기능이 꼭 필요합니다. 이 기능이 말씀하신 '사요자 클래스'와 관련이 되는 것일까요?

평범한 한글과 굉장히 비슷한 스택 지향 언어인 Forth 에서는 새로운 이름을 지을 수 있는 여러 가지 방법이 마련되어 있습니다.

4 4 *
: SQUARE DUP * ;
4 SQUARE

VARIABLE A
10 CONSTANT B
4 SQUARE A !
A @ B + A !

Haskell에서도 함수 뿐만 아니라 다양한 값에 이름을 붙일 수 있고 이들을 쌓아서 프로그램의 규모를 키울 수 있습니다.

@dragonteros 님이 생각하시는 평범한 한글의 방향성은 어떤 것인가요? 이를 알게 된다면 저도 기능을 건의하거나 논점을 새로 열 때 이것이 기준이 되리라 생각합니다. 아마도 #2 (파일/모듈 불러오기)논점과 맥락이 비슷한 것 같기도 합니다만 조금 더 범위를 키워서 논의해보고 싶습니다.

안녕하세요 찬홍 님, 좋은 하루 보내고 계신가요?

먼저 기본 함수를 추가할 때, 현재 구조로도 가능은 하지만 읽기 번거로운 정도라면 그냥 유지하는 쪽으로 하려고 합니다. 예를 들면 기본함수로 '작다'는 제공하고 있고, ~~'작거나 같다'는 추가할 예정이지만,~~ '크다'와 '크거나 같다'는 추가하지 않을 예정입니다. a가 b보다 큰지를 보려면 순서를 바꿔 b가 a보다 작은지를 보면 되기 때문입니다. 이름을 붙이는 방법을 제공하지 않는 것도 이와 같은 이유입니다. 다만 하위 함수를 만들 때마다 같은 객체를 다른 번호로 접근하게 되는 문제를 보완하기 위해 음수 인덱싱을 허용할 예정입니다.

코드를 읽기 어렵다는 것은 잘 알고 있지만 이것은 난해한 언어라는 특성 때문이라고 생각합니다. 해서 다른 언어에서 번역해오는 트랜스파일러를 작성할 계획이 있습니다.

p.s. '크거나 같다'를 '작다'를 부정해서 얻는 것으로 했었는데 깜빡했습니다. '작거나 같다' 역시 추가하지 않기로 하겠습니다.

안녕하세요 찬홍 님, 좋은 하루 보내고 계신가요?

감사합니다~ 정신 없는 하루였지만 테로스 님의 리플라이 읽으니 막 다시 힘이 솟아납니다 :)

먼저 기본 함수를 추가할 때, 현재 구조로도 가능은 하지만 읽기 번거로운 정도라면 그냥 유지하는 쪽으로 하려고 합니다. 예를 들면 기본함수로 '작다'는 제공하고 있고, '작거나 같다'는 추가할 예정이지만, '크다'와 '크거나 같다'는 추가하지 않을 예정입니다. a가 b보다 큰지를 보려면 순서를 바꿔 b가 a보다 작은지를 보면 되기 때문입니다.

동의합니다. 지금의 평범한 한글은 굉장히 정제되어 있고 깔끔하고 구조적으로 아릅답다고 생각합니다. 말씀하신 대로 기본 함수를 많이 만드는 것보다 언어 구조를 탄탄하게 하는 쪽으로 방향을 잡으셨다면 기능이 추가되더라도 너저분해지는 일 없이 깔끔한 '평범한 한글'이 되리라 믿습니다.

이름을 붙이는 방법을 제공하지 않는 것도 이와 같은 이유입니다. 다만 하위 함수를 만들 때마다 같은 객체를 다른 번호로 접근하게 되는 문제를 보완하기 위해 음수 인덱싱을 허용할 예정입니다.

명령형 언어 뿐만 아니라 함수형 언어에서도 객체에 이름을 붙이는 것이 익숙해지다보니 사실 아직까지도 함수에 전달되는 인수로만 객체를 식별해야 한다는 점에 굉장한 저항감이듭니다. 그래서 이름을 붙이게 되면 소스 코드의 가독성이 좋아질 거라고 생각했는데, 그런 취지로 글을 써가다 보니 평범한 한글에서 사용자가 원하는 이름을 마음대로 짓기도 어렵겠다고 생각했습니다.

(ㄱㅇㄱ ㄴㄱ ㅅㅎㄷ ㅎ) 에 역수구하기 같은 이름을 붙일 수 없다면, 괜히 이름 잘못 붙였다가 난해한 것이 아니라 쓸데없이 군더더기가 될 수도 있겠습니다.

말씀하신 것처럼 함수가 추가되더라도 같은 모양으로 다른 함수를 호출할 수 있게 된다면 소스 코드의 가독성이 높아질 것입니다. 이름 대신 인수의 인덱스를 활용하는 '평범한 한글'의 방식에 좀 더 익숙해지도록 노력하겠습니다. ~(안되면 복잡한 구현 부분을 다른 파일에 떼려넣고 "역수구하기"ㅂㄱ 처럼 불러서 쓰죠 뭐....)~

코드를 읽기 어렵다는 것은 잘 알고 있지만 이것은 난해한 언어라는 특성 때문이라고 생각합니다. 해서 다른 언어에서 번역해오는 트랜스파일러를 작성할 계획이 있습니다.

'읽기 어려움'의 원인이 구조적인 난해함이 아니라 '떨어지는 가독성'이 되지 않았으면 좋겠습니다. 아직까지는 제가 평범한 한글에 익숙해지기 전이기도 하겠지만, 익숙해진 뒤라면 좀 더 술술술 코드를 써내고 읽기에 편했으면 좋겠습니다~ ^^ 어렵지만 생각의 흐름이 막히지 않는, 그래서 '펑볌한 한글' 식으로 생각하면 고정 관념을 깰 수 있는, 그런 희열이 느껴지는 '어려움'이기를 바랍니다.

그리고 트랜스 파일러 개발 계획이 있으시다니 반가운 일입니다. 어떤 방식으로든지 평범한 한글의 난해함을 '재밌게' 즐길 수 있었으면 좋겠습니다~

힘이 솟으셨다니 다행입니다 ;)

우선, 다시 생각해보니 '작거나 같다'는 '크거나 같다'에서 좌우만 바꾸면 된다는 걸 깜박했습니다. 해서 별도로 추가하려던 계획은 취소했습니다.

다음으로, 문자열은 다음 두 가지 방법으로 만들 수 있도록 할 계획입니다. 아직은 평범한 한글이 취급하는 문자의 종류를 늘리지 않고 최대한 현재의 구조를 유지하려고 합니다.

유니코드 코드포인트를 나열하는 방법: 예를 들어 'A가'(코드포인트 \u41\uAC00)는 ㄴㄱㄴ ㄱㄱㄱㅅㄷㄴ ㅁㅈㅎㄷ로 생성
UTF-16으로 인코딩한 후 65536진법(?)을 써서 정수로 변환(=비트스트림): 예를 들어 'A가'는 0x41 0x1 + 0xAC00 0x10000 = 0xAC000041로 보아 ㄴㄱㄴㄱㄱㄱㄱㄱㅁㅂㄷ ㅁㅈㅎㄴ로 생성 (1의 자리부터 채우는 것은 코드와 실제 문자열의 순서를 맞추기 위함)

두 방법 모두 부호는 무시하고, 대신 2번의 경우 명시적으로 ㄱ을 덧붙여 끝에 널 문자가 올 때도 표현할 수 있도록 할 생각입니다. 이 방법을 조금 더 확장해서 훨씬 나중이 되겠지만 임의의 바이트열도 다룰 수 있도록 정비할 생각입니다.

답변 감사합니다~ 사실 주신 답변이 무슨 말인지 곱씹어보고 있었는데 이제 깨달음이 오는 군요. ^^ 문자열을 저런 방식으로 다루시겠다니, 정말 신박합니다. 지금의 구조를 해치지 않으면서 문자열 처리를 하는 건 굉장히 재밌는 어려움처럼 보입니다. 특히 65536 진법은 신박 그 자체네요. 다만 한 가지 걱정스러운 점은...

숫자를 다룰 때는 자체 내장 계산기로 진수 변환이 자유로웠지만, 특정 문자열의 유니코드 포인트를 구해서 평범한 한글 식으로 바꾸는 작업이 쉽지 않을 것 같습니다. 특정 문자열을 유니코드 포인트로 바꾸어주는 유틸리티 같은 걸 만들어야겠습니다.
65536 진법으로 표시할 수 있는 문자에 제한이 있지는 않을까요? 이건 구현의 문제인 듯한데, 내부적으로 정수 리터럴을 파싱하실 때 64비트 이상의 긴 문자열을 지원 가능하실지 걱정이 됩니다. '평범한 한글은 너무 좋아요'처럼 기 문자열은.... 언뜻 봐도 '2번' 방식으로 나타내기가 쉽지 않을 것 같은데요....

이쯤 되니 평범한 한글 식의 문자열 구현이 굉장히 궁금해집니다~ 조금씩 꾸준히 성장하는 평범한 한글을 응원합니다!

p.s.: '작다'와 '작거나 같다'로 모든 비교 연산을 수렴하도록 결정하신 것을 저의 튜토리얼에도 반영하겠습니다. ^^

dragonteros / unsuspected-hangeul

평범한 한글의 방향성에 대하여 #8