표준 패키지

표준 패키지는 런타임이 기본적으로 제공할 수 있는 패키지이다.

기본 패키지와 달리 표준 패키지는 런타임에 따라 일부만 선택적으로 제공되거나, 퍼미션이 있어야 불러다 쓸 수 있도록 제약이 주어질 수 있다.

목록

이름	설명
naru arch	i32, u64 등의 저수준 고정 크기 정수 자료형과 f64 등의 부동소수점 실수 자료형을 제공
naru json	JSON 포맷을 파싱하거나 직렬화할 수 있는 함수를 제공
naru regex	정규 표현식 패키지
naru unicode	유니코드 문자 데이타베이스

논의

표준 패키지가 될 만한 후보군

• HTTP 클라이언트
• OS 쓰레드
• 표준 입출력
• 파일 입출력 및 파일시스템 접근
• TCP 및 UDP 소켓
• 나루 타입 연산
  • 타이핑 및 정적 평가 단계에서만 타입을 직접 다루기 위한 퍼미션을 부여한다던가 하는 식의 활용이 가능할 수 있음
• 32비트 및 64비트 정수
  • 런타임이 실행될 아키텍쳐의 한계 등으로 사용이 제한되는 상황이 있을 수 있음
• 로그
  • 어쩌면 기본 패키지까지 올리는 게 좋을 수도
• 뮤텍스 등의 동기화 도구

표준 패키지로 부적절한 수 있는 것들

• 그래픽스
  • 루아처럼 임베드되어 쓰이는 게 주된 쓰임새가 된다고 가정하면, 호스트와 별개로 동작하는 그래픽스 시스템은 넌센스가 될 가능성이 매우 큽니다. --Kroisse (토론) 2019년 7월 26일 (금) 00:35 (KST)
• GUI 툴킷
  • 위와 비슷한 이유이고, 덧붙여 GUI 툴킷은 표준에서 감당하기에는 너무 큰 패키지가 되기 쉽다고 봅니다. --Kroisse (토론) 2019년 7월 26일 (금) 00:35 (KST)
• 커맨드라인 파서
• JSON 이외의 다른 직렬화 포맷 지원
  • 너무 많음
• 컬렉션이나 연관 배열(해시맵 같은)의 범위를 넘어가는 고수준 자료구조
  • 이것도 마찬가지로 어디까지 지원할지가 문제
  • 자료구조는 기본 패키지에 들어가거나 아예 표준의 범위에서 빠지거나 해야 한다고 생각합니다. 공통 인터페이스를 제공하는 것이 언어에 내장된 자료구조의 핵심적인 역할인데, 표준 패키지에 들어간다는 것은 이 자료구조가 제공되지 않는 실행 환경이 있을 수 있다는 의미가 되고, 그러면 사용자가 표준 패키지를 쓰는 걸 기피하게 만들어서 오히려 역효과를 일으킬 거라고 봅니다. --Kroisse (토론) 2019년 7월 26일 (금) 00:35 (KST)
    • 누락된 표준 패키지를 사용자 패키지로 채워넣는 기능이 언어 스펙에 있으면 기피할 이유가 줄어들지 않을까요? 표준 패키지 구현이 모든 언어 구현체에 꼭 들어가지는 않더라도 표준에서 권장하는 인터페이스가 있다는 점이 중요할 것 같습니다. --JongChan Choi (토론) 2019년 7월 26일 (금) 01:43 (KST)
    • 그 경우에 중요한 건 말씀하신 것처럼 자료구조의 구체적인 구현이 아니라 인터페이스가 될 것이고, 그건 기본 패키지에 들어가는 편이 바람직하겠지요. --Kroisse (토론) 2019년 7월 26일 (금) 01:48 (KST)
    • 표준 구현(갈아끼워질 수 있음)을 이용하는 것을 원하는 경우가 있지 않을까요? 인터페이스만 공유할 경우 같은 프로그램에서 돌아가는 런타임 구현체가 불필요하게 많아질 수 있으니까요 --JongChan Choi (토론) 2019년 7월 26일 (금) 02:40 (KST)