목표

나루를 만들고자 하는 크고 작은 목표들을 모은다. 어떤 목표는 상호 모순될 수도 있다. 그래도 최대한 많이 충족하고 싶다.

목록

EMBED - 구현체가 다른 프로그램에 라이브러리로 들어갈 수 있어야 한다

주제넘은 짓(예: 시그널 핸들링)을 호스트 프로그램의 허락 없이 해서는 안된다. 최상위 캡슐과 호스트 프로그램이 이러한 주제넘은 짓을 하고자 하는 요구를 주고 받을 방법이 존재해야 한다.

EXTENSIBLE - 문법의 확장을 어느 정도 지원해야 한다

문법의 완벽한 확장이 필요하진 않은데, 구현이 어려울 뿐만 아니라 나루 "언어"를 파편화시킬 위험성이 있다(래킷처럼 이걸 의도하고 언어 만드는 플랫폼으로 포지셔닝한 경우가 아닌 이상). 사용자들이 나루 구현체를 뜯어서 호환성이 깨지기 시작하는 상황이 발생하지 않을 정도의 확장만 있으면 된다. 코어 파서의 파라미터를 변경할 수 있되, 코어 파서 자체는 변경이 불가능해야 할 것이다.

FREEZE - 소스 코드와 그 의존성, 그리고 그걸 실행할 구현체를 모두 한데 모아 하나의 고정된(frozen) 배포본으로 만들 수 있어야 한다

단순히 가능하다는 것 뿐만이 아니라 이 과정이 기본으로 자연스럽게 제공되어야 한다. AutoHotKey와 같은 것을 생각하면 좋을 것이다.

GRADUAL - 점진적 타이핑을 지원해야 한다

타입을 지정하고 싶을 때 지정할 수 있어야 하고, 그렇지 않을 경우 타입 추론이 동작하거나 실행시간으로 타입 오류가 옮겨 가야 한다. 타입이 지정되어 있지 않을 때 어느 쪽을 우선시할 지는 코드의 지역적인 특성으로 바깥에 영향을 주어서는 안된다.

INSPECT - 실행시간에 내부 상태를 들여다 볼 수 있어야 한다

실시간 디버깅이 가능해야 하며, 코드 커버리지와 같은 instrumention을 지원해야 한다. 이는 임베딩된 구현체에서도 마찬가지로 적용된다(사실 이런 구현체일수록 더더욱 내부 상태를 보고자 하는 요구가 많다).

REPROD - 재현이 가능해야 한다

외부 환경(대표적으로 난수)을 통제할 수 있어야 하며, 통제를 한다는 전제 하에 결과가 항상 동일해야 한다. 이는 소프트웨어 테스팅에 큰 영향을 미친다.

SANDBOX - 실행 환경이 완전히 격리되어 있어야 한다

한 프로세스에서 샌드박싱된 나루 구현체가 여럿 존재할 수 있어야 한다. 캡슐에서 별도로 열어 주지 않는 한 안전하지 않은 동작이 불가능해야 하며, 캡슐 사이의 통신은 명시적이어야 한다.

SMALL - 구현체가 충분히 작아야 한다

여기서 작다는 것은 다음을 의미한다.

• 구현체의 컴파일된 바이너리가 작다.
• 구현체의 논리적인 크기가 크지 않다.
• 지나친 메모리를 소모하지 않는다.

그러나 너무 작은 것을 추구하려 다른 목표를 버려서는 안된다. 따라서 이 목적은 타협의 여지가 있다. 현재 생각으로는,

• 바이너리는 1MB 아래를 목표로 하나 강제는 아니다.
• 소스 코드는 Lua 5.3(순수 소스 코드 1만 5천줄)의 3배 정도는 허용할 수 있다.

TEST - 코드에 테스트를 끼워 넣을 수 있어야 한다

코드와 테스트가 한데 어울러 있어야 하며(테스트가 커진다면 아니어도 괜찮다), 가장 작은 부분부터 가장 큰 부분까지 매끈하게 테스트가 가능해야 한다. 테스트가 실패했을 때 그 실패의 원인을 추적할 수 있어야 한다(#INSPECT).

VERSIONED - 의존성은 버저닝되어야 한다

이는 나루 코드든 네이티브든 동일하게 적용되며, #REPROD의 중요한 요건이 된다.

? 네이티브 의존성을 안정적으로 버저닝할 수 있는가? 그러한 도구를 나루 구현체가 스스로 제공할 수 있는가?