프로그래밍 언어 개발에 관심 있는 사람들의 모임입니다.
|
2008-03-15 13:33:21
|
기존에도 창조나 아희같은 한글 및 한국어 기반의 프로그래밍 언어가 있는데 (더 있으면 알려주시고), 한글(또는 한국어)로 된 프로그래밍 언어를 만들고 싶다는 생각을 가끔 합니다. 루비나 C 코드가 완전한 영어가 아니듯이 한국어 문법에 완전히 얽매일 필요는 없을 듯 합니다. 기호가 필요한 곳에는 기호를 쓰고, 조사 정도는 빼도 되겠죠. 새로운 언어를 만드는 대신 기존 언어에서 일부만 바꿔치기 하는 방법도 있을 듯 합니다. 이런 식으로요.
하지만 별로 안 예뻐보인다는 문제가 있긴 합니다. -_-;; 여러분은 어떤 아이디어가 있으신지요? 디토 님이 2008-03-15 13:33:43에 고쳤습니다. |
트랙백 주소: http://langdev.net/post/trackback/4
기존 언어로 하는거라면 Java로 한번 시도해보시죠. utf-8 identifier를 지원하니까 별로 어렵지 않을 것 같네요. 하루 잡고 장난쳐봐도 될 듯.
루비도 클래스 이름같은 케이스(첫글자 대문자)를 제외하면 가능해요.
스킴도 그냥 되네요. (DrScheme v372)
새로운 언어에 대한 아이디어는 없으신지~
Io도 역시 가능합니다.
짧은 스크립트에 사용되는 변수/메소드명에 한글/한국어를 사용하는 것은 유지보수에 도움이 되겠지만, 언어 자체를 한글/한국어로 간다면해당 언어의 유저층을 제한하는데서 오는 불이익이 훨씬 많지 않을까요?
꼭 실용적이어야만 언어가 될 수 있는 것은 아니지 않습니까? 재미로 하는 거죠. =)
하악… 문법적인 구조(syntax construct)보다 어휘들을 통해서 대부분의 construct들을 해결하는 언어들(대표적으로 리습이겠죠. 몇몇 special을 제외하고는 거의 함수. forth들도 그렇겠고. 둘 다 문법이랄게 없죠. Io도 그렇다고는 하지만…)에서는 별다른 문제없이 그렇게 한국어로 어휘를 정의하고, 또한 그 어휘들 자체가 문법이랄까 표현의 거의 전부이기 때문에 그외에 언어들보다 한국어 언어를 만들기에 적합하지 않을까 싶어욜.
…또는
…어느쪽이 더 어울릴까요?
이런 식의 한글 언어는 어떨까요?
여기서
은/는,이,이면,아니면,에,이다,을등은 예약어 정도가 되고팩토리얼이나갑,출력해등은 식별자가 되겠지요. 근데 이렇게 하려면 … 형태소 분석기가 있어야 할라나요? ^^;갑자기 든 생각이지만, 프로그래밍 언어가 자연어에 가까워질 수록, 자연어에서 발생하는 모호성 문제도 함께 안게 될 것 같습니다.
위 글은
가의 나가 가르키는 대상과다를 가르키는 걸까요, 아니면가의 나와가의 다를 가르키는 걸까요?뭐, 이런 간단한 모호성 문제는 이미 프로그래밍 언어에도 있긴 하지만요. (당장 생각나는 것이 이런 것밖에 없어서 예제가 좀;)
우리말이 후순위(postfix) 연산과 유사하잖아요. 물론 100% 동일한 건 아니지만. 거기서 실마리를 찾을 수 있지 않을까 싶어서 뭐라고 블라블라 썼는데 정리가 안되네요. (표현이 안되는 게 아니라 정리 자체가;;)
가의 나와 다보다는나의 차의 열쇠로 생각을 해볼께요. 이 코드 역시 두가지로 해석될 수 있죠.각 경우를 후순위로 표현하면
… 역시 말이 안되네요. 뉴_뉴
”~의”라는 것은 많은 뜻을 가지고 있습니다. 우리말을 쓸 때 “~의”를 자주 쓰는 것은 좋은 습관이 아닙니다. 위의 예제에서 “나의”는 “내가 가진”이라고 쓰는 것이 알맞고, “차의 열쇠”는 “차 열쇠”라고 “쓰는 것이 올바릅니다. 우리말이 모호한 것이 아니라 모호하게 쓰는 사람들이 문제지요.
이런 코드를 우리말로 옮기다 보니 그런 문제가 발생했네요. ‘~의’ 표현이 일본식 표현이라 자제해야지 하면서도 실제로는 잘 안되네요. ^^;
좋은 지적 고맙습니다~
이건 어때요? 대충 설명해보면
차례곱,빼기,더하기등은 ‘거르개’라서 어떤 값을 지나가게 하면 또다른 값이 나오게 됩니다. (그러니까 결국 함수죠. 객체지향적으로 말하면 메시지이기도 합니다.) 어색한 점은 지적해주세요. (차례곱은 팩토리얼 대신 북조선에서 주로 쓰이는 말이라고 하네요.)더하기가 아니라 곱하기겠죠? 그리고 너무 OO냄새가 나요. 우리말처럼 동사가 맨마지막에 올 수는 없을까요? ^^
뭔가 함수형 언어의 느낌이 드는 코드로군요 :)
아니 이런 실수를 =3=33 더하기가 아니라 곱하기 맞습니다 맞고요;
동사가 뒤로 오려면… 음;
값”에” 적용하는 거니,
,대신에를 써도 괜찮을 것 같습니다.그런데 좀 어색하니까
해를 호출 연산자로 본다면(Python 등의()같은),하고를 함수 합성 연산자로 해서(Haskell의.같은)이상한가요.
코드 모양은 상당히 괜찮네요~ 근데 우선 순위 문제는 없을까요?
좀 더 실용적(?)인 코드를 짜 봤습니다 :P
뱀다리) 디토님,
내 차 열쇠는 어디로? ^^;흠… “내 차 열쇠”가 맞군요. 역시 서로 머리를 맞대고 생각하니 정답에 가까워지는군요. 우리말 문법도 이런 식으로 하면 좋은 생각이 떠오를 것 같습니다. 그런데 일부러 맞춤법 틀리신건가요? 영 적응이 안되서…
끗은 개그입니다만;;;
근데 semmal님의 닉은 셈틀할 때 셈에데 언어라는 뜻에서 말을 합쳐서 만드신 건가요? 그렇다면 닉 정말 끝내주네요. ^-^)/
맞습니다. 셈하는 언어, 즉 프로그래밍 언어라는 뜻으로 만든겁니다. 제가 만들고 싶은 언어의 이름이기도 하구요.
저는 예전부터 유추하고 있었지롱요
~롱 다음에 이모티콘(:P)이 없으므로 무효;입니다용~ :P
영어는 8품사 : 명사,대명사,동사,형용사,부사,전치사,접속사,감탄사 우리말은 9품사 : 명사,대명사,수사,동사,형용사,관형사,부사,조사,감탄사
영어의 문장성분 : 주어,동사,목적어,보어 우리말의 문장성분 : 주어,서술어,목적어,부사어,관형어,독립어,보어
보통 언어에서 주어는 오브젝트의 이름, 동사는 메소드(함수), 목적어와 보어는 인자로 쓰입니다.
만약 우리말다운 언어라면 어떤 식으로 구성되는 것이 맞을까요? 역시나 고등학교 다닐 때 국/영/수 공부를 게을리한게 한이 되는군요. 그렇게 중요하다 중요하다 어른들이 노래를 불렀는데 말이죠.
우리말은 기본적으로 주어+서술어 관계이지만, 주어를 생략하는 경우도 흔합니다. 그렇게 생각하고 보니 주어를 생략한다는 건 상당히 특이해보입니다. 마치 보통 언어에서 전역변수를 쓰거나 오브젝트에 있는 멤버변수를 쓰는 느낌이랄까요?
영어는 어떤 주제에 대해서 완전한 문장을 만듭니다. 그래서 이렇게 완전하게 정의되지 않으면 사람끼리 “통신”을 할 수 없습니다. 하지만 우리말은 마치 공유된 데이터를 가지고 서로 “통신”을 하는 듯합니다. 이 공유된 데이터는 왠지 통신에서 필요한 데이터베이스뿐만 아니라 프로토콜까지 정의되어있는 것 같은 느낌이 드네요. 지식이 일천해서 그냥 느낌으로 말하는 것일 뿐이지만요…
그리고 형용사도 특이합니다. 영어에서 형용사가 명사등을 꾸미는 말이라면 우리말에서는 영어의 동사처럼 쓰입니다. 이 말은 우리말에 가까운 언어를 통해서 어떤 문제를 해결하고자 할 때 프로그램의 설계가 달라질 수도 있다는 느낌이 드는군요.
맞습니다. 영어와 함께 스웨덴어, 독일어, 또 일본어 등을 함께 공부해보니 한국어와 일본어의 문장 구조가 상당히 특이한 편이죠.
특히 형용사가 동사의 형태를 띤다는 점이나 주어의 생략이 굉장히 빈번하다는 게 그 특징이 되겠습니다.
한국어로 언어를 만든다면 형용사 또한 메소드의 형태가 되고 인자로 ‘정도’를 받는다든가.. 하는 식이 될지도 모르겠군요;; (써놓고 보니 어째 자바의 get/set이..-_-)
개인적인 생각이지만, 형용사는 어떤 오브젝트를 설명하거나 설정하기 위한 용도로 사용될 것 같습니다. 동사는 오브젝트를 변화시키는 목적이 될테지요.
그렇다면 형용사로만 만들어진 프로그램은 그 동작이 상당히 정적인 특징을 지니게 될 것 같구요. 동사로만 만들어진 프로그램은 상당히 다이나믹해질 것 같군요.
역시 지식 부족에다 정리도 안되서 제대로 설명도 못하겠네요. 나중에 더 정리해보고 다시 댓글을 다는게 좋을 것 같네요.
셈말 님의 댓글을 보고 든 몇가지 단상.
move(), “천천히 움직여” →slowly(move)()그렇다면 역시 Factor나 Forth 같은 스택/단어 언어가 적당한 것일까요?
어순이 일치해서 다른 언어들보다 어쩌면 ‘국어’에 가까운 stack-based언어들의 특징을 살려서 워드들이 한글화된 forth가 예전에 있었어요. (사실 forth에서 word은 function와 유사한 단위이고 문자열 “…” 같은 파싱단위도 word로 선언하는 forth계열에서는 거의 전부.)
좀 심술인 생각인거 같은데요, 한국어의 상대적으로 복합적이고 다양한(영어의 불규칙변화도 그렇지 않냐고 한다면 할말이 없지만) 조사, 어미등 사용과 같은 거의 완전한 구어/문어의 표현보다는 축약적인 표현으로 의미전달체계를 형성하거나(분명 진짜 영어와 code은 서로 다르지만 영어를 기반으로 설계된 언어들의 코드는 그 자체로 의미전달수단이잖아요) 그와 함께 한국어나 한글의 특성을 잘 살린 언어가 의의가 있지 않을까요. (아희’가 그런 언어겠죠.)
저는 부정적입니다. 스택 구조를 가지는 언어는 추상 수준이 지나칠만큼 너무 낮다고 생각합니다.
개인적인 생각일지 몰라도 한글은 거의 최고의 추상수준을 가진 자연어라고 봅니다. 우리말을 기본으로하는 프로그래밍 언어라면 최소한 그에 어울리는 추상수준은 가져야 한다고 봅니다.
뭐… 그정도까지는 아니더라도 꿈은 크게 가져야하지 않을까요?
스택 구조의 언어가 추상 수준과 관련이 있나요? “스택 기반 언어”라는 말에 약간 오해가 있는 듯합니다.
stack-based란 말 이외에 [concatenative programming language][http://en.wikipedia.org/wiki/Concatenative_programming_language]이란 말도 이를 지칭하는데요 사실 어떻게 보면 매 연산에 대해서 현재 스택에 대해서 신경쓰지 않으면 코딩이 불가능하지요. ^^
명시적인 인자나 그런걸 전달하거나 하는 방법이 아니라 중립적 위치의 자료전달장소를 두고 이를 공유하여 결합하므로 그렇게 생각하기 쉽다고 생각합니다.
‘한글’은 그렇다는데 동감하고, ‘한국어’도 아름답고 우아한 ‘자연어’라는점에 감히 토달지는 못하겠습니다.(잘모르니까요.) 하지만 복잡함, 혹은 자연상태의 혼란상태가 꼭 큰 꿈이라고 하기는 힘들지 않을까 조심스럽게 생각해봅니다.(물론 목표는 자연어스럽게 코딩하는것이 좋겠지만요 :-))
자연 상태의 혼란을 논리적인 프로그래밍 언어로 잘 표현해 낸다면 큰 꿈이라 할 수 있겠죠~ :)
프로그래밍을 할 때 내부적인 구조를 알아야한다면, 또는 신경 써야한다면 추상 수준이 낮은것이 아닐까요?
스택 기반 프로그래밍 언어에서의 스택은 그 스택(그러니까, 함수 호출의 스택)이 아니라고 알고 있어요;
위키피디아에 있는 Forth 예제를 하나 보면요.
: FLOOR5 ( n -- n' ) DUP 6 < IF DROP 5 ELSE 1 - THEN ;와 C언어의int floor5(int v) { return v < 6 ? 5 : v - 1; }를 비교하고 있습니다. 두 가지 언어를 비교해봤을 때 “스택 자료구조”를 반드시 알아야 하는지 몰라도 되는지는 큰 차이가 있습니다. C는 infix, Forth는 postfix이므로 표현은 동일하다고 말할 수도 있겠지만, 괄호를 통해서 계산범위와 예상되는 값을 쉽게 추적할 수 있는 lisp과는 달리 스택기반 언어에서는 괄호가 보이지 않습니다. 때문에 스택을 머리속에 그리고 값이 변화되는 것을 추적해야합니다. 그리고 stack은 후입선출되는 모든 형태의 개념/자료 구조를 통칭하는 뜻 아닌가요? 왜 제 말을 함수 호출로 오해하셨는지 모르겠네요.리습에 대해서 괄호가 리습을 죽인다고 말하는 사람이 있고, 반대로 괄호야 말로 리습의 진정한 파워를 위한 것이라고 말하는 사람들이 상존하듯이, 스택기반의 언어들에 대해서도 그렇게 생각하는 분들도 계시고, 실제로 그러한 것들에 대해서 공부해보거나 사용해보면 그런 결합이 다른 언어들에서의 그런것들과는 다른 매력을 갖는다는걸 깨닫게 되더라구요.
지엽적인 일례로 흔히 partial application, currying등에 대해서 언어의 예외적인 구문으로 구현하거나 생각해야하는 경우가 많은데(혹은 아예 별도로 HOF로 구성하거나요) 이러한 언어들에서는 그런 자유로운 함수에 대한 연산이 더 편리하죠.
Forth 같은 스택기반언어는 함수를 뒤로 빼서 우리말과 유사한 것이지 그게 우리말의 특성을 살려서 그렇다고 보기는 힘들지 않을까요? 디토님의 얼에 관한 새 글에도 언급했듯 문장 순서가 바뀌더라도 해석을 동일하게 되어야 하는데 스택언어에서도 그렇게 처리되는지 모르겠네요.
위의 semmal님 말처럼 스택에 어떻게 쌓일지를 고민하기 보다는 작성한 문장이 정확한지를 고민하는 게 맞을 것 같네요~
논의가 점점 세밀해지고 있네요. 대부분 자연어로서의 우리말과 유사한 형태의 언어를 가정하고 말씀을 하시는데, 맞죠? 좀 더 논의의 조건을 정하면 더 흥미로운 이야기가 나올 것 같네요.
그나저나 수학을 열심히 할 걸이란 생각은 많이 들었지만 국어를 열심히 할 걸이란 생각이 드는 건 처음이네요. ^^
http://wiki.kldp.org/wiki.php/KTS?action=download&value=tag-set.pdf
한국어 품사 태깅에 관한 문서입니다. 혹시 형태소 분석을 쓰는 언어를 만들거나, 그렇지 않더라도 꽤 유용한 자료일 것 같아서 링크합니다.
그런데 예뻐보인다의 기준이 뭐죠? 단지 익숙함을 말하는 것이 아닌지… 개인적인 취향의 기준을 이야기해주셔도 좋습니다.
이제가지 programming 언어용 예약어들은 영어로 쓰여지는 것이 당연하다고 생각되어졌습니다만, 또 저도 영어로 된 source의 해석이 현재로서는 편합니다만.
만일 국어로 된 programming 언어가 있고, 그것이 익숙했다면 다시 영어로 된 source를 보면 머리가 어지러울 것 같습니다.
글꼴에 대해서도 그동안 코딩용 글꼴하면 다 영어를 중심으로 이야기되었습니다만(밑의 link가 대표적) 국어로 된 source에 적합한 글꼴이 등장하는 상상도 흥미로울 것 같네요.
http://wiki.kldp.org/wiki.php/CodingFont
역시 예쁘다라는 건 개인적인 취향이죠. 저 같은 경우는 의도를 명확히 표현할 수 있을 만큼 간단한 코드를 적을 수 있을 때 예쁘다고 하죠. Haskell의 qsort같은 걸 보면 예쁘다는 생각이 듭니다.
다른 글타래에서도 잠깐 언급했지만, 모든 코드를 우리말로 대체하겠다는 것은 욕심이라 생각합니다. 수학에서 기본적인 수식도 우리말로 나타내지 못하는 것이 사실이고, 그 수식이 특정 나라말을 의미하는 것도 아니기 때문입니다. 수식은 그 자체로 abstraction이 아주 잘되어있는 도구입니다.
그렇지만, OO가 가진 특이한 체계처럼 우리말을 쓰는 언어 또한 우리말에 맞는 특이한 체계를 가질 수 있지 않을까요? Functional이 수식에, OO가 외국어의 어순에 맞게 만들어졌듯이, 우리말을 쓰는 언어라면 우리말의 어순이나 특성에 맞출 수 있을거라 생각합니다.
그리고 Functional이나 OO라면 기본적인 예약어는 없는 것이나 마찬가지지요. 굳이 따지자면
=, (, ), .정도만 정의되어 있으면 끝이 아닐까 생각하는데요.예전에도 말했지만, Functional패러다임을 따르는 언어나 Logic패러다임을 따르는 언어, 또는 특정 구조를 따르는 언어는 그 자체로 체계를 지니고 있습니다. 때문에 아마 한글화를 한다고 하더라도 함수이름 변수이름 정도를 한글화 하는 것이 한계라고 생각합니다. 문제는 변수”x”가 변수”가”보다 더 쓰기 쉽고 보기도 깔끔해보인다는 겁니다. 쓰기 쉽게 하려고 변수”ㄱ”을 쓰는 것은 너무하다는 생각이 들구요.
하지만 OO는 다릅니다. OO의 문법은 실제로 영어의 문법과 매우 유사하다고 생각합니다. “주어.동사(목적어,보어)”로 구성된다고 볼 수 있으니까요. 또한 OO가 대부분 따르는 imperative 패러다임의 특성상 서술하는 문장이나 변수이름이 더 가치가 있다고 봅니다. 주석을 적을때 한글로 적기 더 편하듯이 말입니다. 물론 주석과 코드를 통합하려는 시도는 어리석다고 느끼기는 합니다. 어쨌든 다시 주제로 돌아가서 OO는 영어식의 서술문장과 함수형식의 짬뽕으로 생각됩니다. 물론 함수라는 형식도 서양식의 문법에 영향을 받았겠지만 말이죠. 하지만 OO에서의 함수처럼 보이는 문법 형식은 실제로 큰 의미가 없는 것이기 때문에, OO패러다임 자체를 우리말처럼 만든다고했을 때에도 큰 문제는 없다고 생각합니다.
영어는 대부분 어떤 단락에 대한 꾸밈을 뒤에서 합니다. “나는 준다”라는 문장에 “나는 준다 너에게”가 되고, 다시 “나는 준다 너에게 빵을” 이런 형식으로 완성이 된다고 볼 수 있습니다. 이것을 “나는 너에게 빵을 준다” 또는 “나는 빵을 너에게 준다”라고 바꾸는 작업이 바로 우리말을 쓰는 언어가 만들어지는 기본이겠지요. 그런데 재밌게도 영어는 “너에게”가 아닌 “너(you)”를 쓰며, “빵을”이 아닌 “빵(a bread)”을 쓴다는 겁니다. “~에게”인지 “~을”인지는 문장의 구성과 차례을 보고 파악하는 것이지, 우리말 처럼 “~에게”나 “~을/를”과 같은 조사를 통해서 구별하지 않습니다. 우리말은 문법적으로 따지자면 단어가 나열되는 차례에서 자유롭다고 볼 수 있습니다. 위에서 언급한 “나는 너에게 빵을 준다” “나는 빵을 너에게 준다” 둘 다 맞는 표현이라는 겁니다. “i give you a bread”와 “i give a bread you”를 비교해보면 그 차이가 명확하다고 생각합니다. 그래서 판단을 내리건데 우리말에서 중요한 것은 조사의 존재입니다. 어순도 중요한 부분이기는 하지만 우리말 답게 만드는 가장 중요한 바탕은 조사의 사용일 것이라 예상합니다.
일단 너무 길어서 저장하고 아래에 적겠습니다. 글이 날아갈까봐 겁나네요.
일단 우리말답다고 느끼려면 f(x,y)같은 메소드(?)에서 x와 y의 이동과 생략이 자유로워야 한다는 생각이 듭니다. 즉, f(x,y)==f(y,x)여야 한다는 것이죠. 심볼(즉, 이름)과 위치에 의해서 해석하는 방식이 아니라 조사에 의해서 변수가 해석되고, 그 구성성분에 따라서 뒷 부분 처리에 영향을 주는 방식을 말합니다. “너에게 빵을 준다 = 바구니에서 꺼내서 던진다.”와 같은 메소드를 정의한다고 생각합시다. 물론 왼쪽에서 생략된 “나는”이나 오른쪽에서 생략된 “내가” “빵을” “너에게”도 머릿속으로는 고려를 해봅시다. 일단 “바구니”는 “내 바구니”입니다. “꺼내서”는 “빵을 꺼내서”이며, “던진다”는 “너에게 던진다”입니다.
이것을 영어식으로 원본을 구성해보면 “class i { give(who,what) = i.throw(who,i.pick(basket,what)); }”일 겁니다. 우리말처럼 생략된 형식이라면 “give(who,what) = throw«pick«basket”정도로 볼 수 있을까요? 단지 throw와 pick에 들어가야할 you(who에 해당하는)와 bread(what에 해당하는)와 같은 인자는 조사와 서술어에 의해서 자동으로 결정되게 됩니다. 보여드린 예제가 약간 헷갈릴 수도 있지만 만약 이것이 가능하다면 제 생각에는 우리말에 기반을 둔 언어가 만들어진다면 기존의 OO언어보다 훨씬 더 강력하고 간결한 언어가 만들어 질 수도 있다고 봅니다.
조사에 의한 뒤바꿈과 생략의 원칙은 이런 단순한 생각보다 훨씬 더 어렵고 복잡한 일임에 틀림없습니다만, 기본적인 규칙을 생각하자면 생각보다 간단할 것 같습니다. 각각의 조사는 “~격 조사”로 불리우며 문장성분을 정하는 역할을 합니다. 이런 문장성분은 수학의 그것과는 약간 다르지만 특정한 타입이나 클래스를 말한다고 볼 수도 있습니다. 조사가 어떤 단어에 대해서 문장성분을 정해주면 동사나 형용사와 같은 서술어는 해당하는 문장성분을 선별해서 받아들일 수 있는겁니다. 즉, 조사는 type casting이며, 뒤에서 사용하는 서술어는 명시되지 않은 변수를 차례에 관계없이 type checking또는 pattern matching만으로 받아들일 수 있게 됩니다. 같은 문장성분이 2개가 있다면 우리말에서도 정확하게 명시를 해주지 않으면 알 수 없으므로, 이런 경우에는 심볼로 정확히 명시해서 파악해야 할겁니다.
그런데 길게 적기는 했는데 설명이 제대로 전달이나 될런지 모르겠네요.
문제가 될 수 있는 점은 그 type checking을 하는 경계가 명확하느냐가 가장 중요한 것 같습니다. 명확한 set을 정의하지 못한다면 기계적으로 pattern matching을 수행하거나 type checking을 수행할 방법은 없을테니까요. 또한 각 서술어에 익숙치 않은 type system을 고려해서 타입을 정해줘야하는 것도 부담이 될 수 있습니다. 우리가 말을 하면서도 흔히 실수할 수 있는 것 처럼 잘못된 조사를 사용하였을 때나 우리말 스스로가 가지고 있는 문법의 부정확함이나 의미의 불명확함이 문제가 될 소지도 있습니다.
또다른 문제점을 생각해보자면 기존의 수학이 가지고 있는 type system과 어떤 식으로 동작해야하는지에 대한 의문이 있겠습니다. 서로 다른 두개의 타입 시스템이 존재해야하는 것인지 자연스럽게 녹아들어가야 하는 것인지 고민을 해봐야겠죠.
또한, 이런 인자의 이동과 생략이 실제 프로그래밍에 들어갔을때 어떤 소소한 장점과 엄청난 단점이 있는지는 확신할 수가 없습니다. 막연하게 생략과 이동이 더욱 큰 표현력을 줄 것이라 예상만 했기때문이지요.
이래나 저래나 문제는 많아보입니다만, 어때요? 조금 가능성이라는게 보이시는지요?
뛰어난 통찰이십니다. :)