얼마 전 코딩도장에서 N-Queen 문제를 손대본 적이 있다. 유명하고 어려운 문제라서 많은 사람들이 도전했고, 그만큼 효율적인 코드도 많이 알려져 있다. ... 코딩도장에서는 나이브하게 Coffeescript로 만들어 보고, 집에 와서는 요즘 연습 중인 D로 다시 만들어 보았다.
속도를 위한 최적화는 별로 없고, 그냥 무난하면서 Out-of-memory를 띄우지 않을 정도의 코드만 만들고 끝내야지 ~ 했는데, 테스트가 계속 실패한다. 각 Row에서 퀸의 위치를 Bit flag로 나타내는 식으로 보드를 저장하고 있었고, 실패하는 코드는 "현재 Queen의 위치 리스트" + "이번 Row에 놓고 싶은 Queen의 위치" 를 받아서 유효한지를 돌려주는 함수 부분이다.
테스트는 그냥 가볍게 이번에 놓고 싶은 Queen의 위치 - Row, Col - 에서 위로 한칸씩 올라가며 3개씩 확인하는 방식으로 했다.
cur.reverse 가 뒤집힌 녀석을 리턴하는건지, 스스로를 뒤집는건지 잘 모르겠지만 cur 에 변화가 있다면 저기 달아놓은 in qualifier 가 못한다고 말해주겠지 - 라고 생각했다. in 은 const 를 강제하니까. 그리고 이녀석은 컴파일이 된다. 헤헤 안심 ~하고 다음으로 넘어가보자 했는데 ... 계속 테스트가 실패하네?
알아보니 reverse는, 1. 스스로를 뒤집고, 2. 그 뒤집은걸 리턴, 도 하는 녀석이다. 배열의 property 를 참조하면 배열 자체가 뒤집혀 버리는 상황. -_-; 뭐 이래? 거기까지면 괜찮은데 왜 컴파일이 된거야?. 어이가 없어서 위의 in 을 immutable 로 고치고 테스트 했는데, 역시 컴파일이 되고 실행도 된다. 아놔... ;; 결국 side-effect가 있는 property는 immutable, const 를 그냥 씹어 드신다는 뜻.
이 코드가 컴파일+실행된다는 사실을 발견. ... 실행하면 [1, 2, 3] [3, 2, 1] 을 차례로 찍는다. 뭐라굽쇼? property 에 대해서는 수정 불가 조건을 검사하지 않는 것 같은데, 그 property가 side-effect 만땅 ... 이라는 암울한 상황이다. IRC에 가서 물어봤더니 돌아오는 대답은,
Looks like a bug
Those properties like reverse, sort will be deprecated.
였다. 으으, 아직 D 두번째 스펙이 불안정하다고는 하지만 이건 좀 지나친 거 아닌가 싶기도 하고.
C/C++ 에서는 대입문 - 이 사실 문(statement)이 아니라 식(expression)이다. 따라서 다음 코드가 동작한다.
#include <stdio.h>
int main() { int x = 10; printf("%d\n", x = 20);
return 0; }
실행하면 20 이란는 숫자가 콘솔에 찍힌다. 파이썬에서는 대입문이 맞다. 따라서
print x=10
이런 파이썬 코드는 유효하지 않다. 별 생각 없이 쓰고 있었는데, 파이썬에 대해 아무것도 모르고 있었구나 -_-; ... 뿐 아니라 프로그래밍 언어 자체에 대해 기초가 부족했다. 아 뼈아퍼라...
사실, 문과 식을 구분해서 쓰는 사람이 그다지 많지는 않다(고 느낀다). 나도 가끔 필요할 때만 확인해보곤 하는데 ... 자, 정확히 statement, expression 이 무엇인지 설명한다면? 이라고 하니까 바로 답이 튀어나오지 않는다. 그래서 위키에서 긁어왔다.
In computer programming a statement can be thought of as the smallest standalone element of an imperativeprogramming language. A program is formed by a sequence of one or more statements. A statement will have internal components (eg, expressions). - From wikipedia
An expression in a programming language is a combination of values, variables, operators, and functions that are interpreted (evaluated) according to the particular rules of precedence and of association for a particular programming language, which computes and then produces (returns, in a stateful environment) another value. The expression is said to evaluate to that value. As in mathematics, the expression is (or can be said to have) its evaluated value; the expression is a representation of that value. - From wikipedia
그냥 개인적인 생각이지만, 해보면 쉽다 쉽다 - 하는 함수형 언어를 사람들이 처음 접할때 많이 좌절하곤 하는데 그 이유가 이게 아닐까 한다. Imperative language에 익숙한 상황에서는 statement 의 나열로 문제를 해결하려고 하기 쉬운데, Functional language에서는 그게 쉽지 않다 - 기 보다는 제한적이거나 불가한 경우도 있다. 함수형 언어를 써보면 새로운 접근 방식을 익히게 된다고 하는데, 그 새로운 접근이 뭐냐? 라고 물으면 좀 난감했는데, 일단 이렇게 정리해볼 수 있으려나?
Expression oriented problem solving
Expression은 side-effect가 있을 수도 있고, 없을 수도 있다 - 고 한다. 이에 반해 Statement는 Side-effect를 만들어내기 위한 것이라고도 하는데 (statements do not return results and are executed solely for their side effects, - From wikipedia), side-effect를 지향/지양 하는 정도에 따라서도 접근이 달라질 수 있는 것 같다.
역시 기본부터 차근차근 다져야 하는데, 이런것도 확실히 정리 안해두고 코드를 만지고 있었다니 부끄럽다. :'( 일단 낙서 종료.
side-effect, referential transparency 등에 대해서도 살짝 정리해둬야겠다.