기록/2019-06-16

• 토큰화 아키텍처
  • (disjukr) 코드 문자를 분류할 때 span을 붙이고 싶은데(지금은 토큰에 붙음), 이렇게 하려니 토큰에 코드 문자가 다 들어가서 비효율적이 되는 것 같다
  • (lifthrasiir) 나루에서 한 토큰이 여러 파일에 걸치거나 한 파일의 불연속적인 부분에서 유래하는 경우는 절대로 없을 것이다. 그냥 시작점과 끝점을 기록하는 걸 추천
    • (lifthrasiir) Rust나 카일루아의 예를 들면 파일 맵이라고 하여, 사이드 테이블로 현재 열려 있는 파일의 핸들(작은 정수)을 실제 파일 내용으로 매핑함. span 정보에는 파일 핸들 + 시작/종료 오프셋이 기록됨
    • (disjukr) 파일 맵은 그럼 gc되지 않는가?
    • (lifthrasiir) IDE & language server 같은 경우에는 gc를 해야 하는데, 충분히 가능하다. 버저닝 컨셉을 도입해서 유사하게 구현한 사례를 VS 확장 API에서 봤음
    • (disjukr) 줄 번호 번역은 어떻게 하는가?
    • (lifthrasiir) 카일루아의 경우에는 파일 맵에 오프셋-줄번호 매핑이 있어서 이진 검색을 했다
    • (lifthrasiir) language server 같이 기반 모델이 줄 단위일 경우에는 오프셋이 (행, 열) 순서쌍이어야 할 수는 있다. 그러나 그 행/열 정보는 블랙박스 취급해도 된다
    • (lifthrasiir) 첨언하자면 language server protocol의 경우 열 오프셋이 UTF-16 unit 기준이라 에모지 따위 넣으면 터질 수 있음;;;;
    • (disjukr) 오 쉣
  • (lifthrasiir) 그런데 애초에 왜 코드 문자에 span을 붙이고 있는가? 근본적으로 말하자면 코드 문자와 토큰화 과정을 분리할 이유가 거의 없음
    • (disjukr) 코드 문자 중에 \r\n이 있는데, 그 중간에 다른 문자가 들어 오면 오류를 내 줘야 할 것 같다
    • (lifthrasiir) 아니다. \r도 \n도 모두 올바른 vertical space이기 때문에 그냥 \r어쩌구\n은 새 라인을 만들면 된다
    • (disjukr) 서로게이트는 어떤가?
    • (lifthrasiir) 입력이 유니코드 문자열은 아니지 않는가?
    • (disjukr) 자바스크립트 문자열이 입력이라서...
    • (lifthrasiir) 아 그런 경우라면 암묵적으로 바이트열을 유니코드 문자열로 바꾸는 디코딩 스텝이 있는 셈인데 이건 나루 표준에서 커버하는 건 아니므로 맘대로 해도 된다. 첨언하자면 U+FFFD는 올바른 코드 문자가 아님(물론 문자열이나 주석에는 들어가겠지만)

• #1: 부동소숫점 및 실수
  • (lifthrasiir) "실수"는 표준에 나오면 안된다. 컴퓨터가 다루는 것은 유리수나 실수의 근사값 뿐이고, 정확한 실수 연산(exact real number arithmetic)은 극히 어렵다
  • (lifthrasiir) 두 가지 대안을 생각하고 있다
    1. 소수(decimal) 또는 유리수(rational)
       • (lifthrasiir) 내가 생각하기에는 유리수가 더 나음
         • 현존하는 임의 정밀도 소수 구현들(mpfr, 파이썬 decimal 따위)을 보면 뭔 짓을 하더라도 암묵적으로 또는 명시적으로 정밀도가 맥락으로 들어간다
         • 소수는 주요 연산에 대해서 닫혀 있는게 아니기 때문에(예: 나눗셈) 맥락이 무조건 필요함
         • 유리수는 모든 사칙연산에 대해서 닫혀 있으므로 이 부분이 훨씬 수월하다
       • (lifthrasiir) 거의 모든 값에 대해 무리수를 반환할 수 밖에 없는 sin 같은 함수는 정밀도를 명시적으로 받게 하면 된다
       • (aury) IEEE 754-2008 소수 연산을 사용할 수 있지 않은가?
         • (lifthrasiir) 그것은 binary32처럼 고정 정밀도 부동 소숫점을 구현하는 것이기 때문에 부동 소숫점의 문제를 해결하지 못함. 하드웨어 지원이 있는지도 미지수
    2. 구간 연산(IA; interval arithmetic)
       • (lifthrasiir) IEEE 1788 같은 것을 참고하면 됨. 가장 유망한 표현법은 중간값과 +/- 값을 넣는 것
       • (lifthrasiir) http://verifiedby.me/adiary/ 같은 시도를 알고 있다
  • (disjukr) f32/f64는 naru core에 있으면 안될 것 같다
    • (lifthrasiir) 확실하진 않은데 그럴 수 있을 듯, 그렇게 된다면 naru arch로
    • (disjukr) "크기 고정" 소수 같은 표현을 쓸 수 있지 않을까?
      • (lifthrasiir) 부동 소숫점은 엄밀히 말해서 실수의 올바른 근사값은 아니며, 실수 다루듯이 부동 소숫점을 다룰 수 없다
      • (aury) 개별 부동 소숫점 "값"은 근사값으로 간주할 수 있다
      • (lifthrasiir) 어쨌든 부동 소숫점에 한정된 도메인 지식이 필요한 것은 분명하므로, 실 구현에 부합하는 이름을 쓰는 게 낫다고 여겨짐("float", "decimal", "rational" 등)

• JSON 지원
  • (disjukr) JSON 파싱을 할 때, 이걸 다시 JSON으로 직렬화하면 같은 문자열이 나온다(round-trip)는 걸 보장할 수 있는가? 부동 소숫점이 아닌 다른 걸 쓰게 되면 문제가 될 것 같음
    • (lifthrasiir) 그게 JSON 표준에 있는가?
    • (disjukr) 그렇다고 생각함
    • (lifthrasiir) ES2017(ES8)에 따르면 유효자릿수의 첫 20자리만 정확하다는 게 보장되는 것 같다
    • (lifthrasiir) 현실적으로는 V8/SpiderMonkey 같은 주요 구현에서 double-conversion을 쓰고 있기 때문에 모든 유효자릿수가 정확하다고 볼 수 있음
    • (lifthrasiir) 내 생각에 스키마 없는 모드에서는 소수/유리수를 쓰고, 스키마 있는 모드에서는 사용자가 선택할 수 있게 하면 될 것 같음
    • (aury) 기존 구현을 살펴 보고 round-trip이 실현 가능하다고 확인하기 전까지는 고려하는 걸 늦춰도 된다고 봄
    • (lifthrasiir) 사실 오브젝트 순서부터 좀...
  • (lifthrasiir) JSON 지원은 적어도 "표준" 패키지에는 들어 있어야 한다
    • 말하자면, 내장 패키지(Go의 fmt 같은 것)는 "표준" 패키지(Go의 golang.org/x 같은 것, 편의상 이리 부르고 있음)의 부분집합이고, 거버넌스와 호환성 제약이 "표준" 패키지보다 빡세다
    • (disjukr) 내장 패키지가 루아에 더 가까운가(큰 쪽) 자바스크립트에 더 가까운가(작은 쪽)?
      • (lifthrasiir) 자바스크립트가 작은 내장 패키지를 가지고 있다고 보긴 어려운데;;; (정규식과 유니코드가 주 원인) 대략 중간 어딘가를 생각하고 있음
      • (lifthrasiir) 하지만 권한 모델에서 별도 권한을 요구하는 건 아마 내장으로 가야 하지 않을까
      • (disjukr) 그렇게 되면 파일 I/O부터 시작해서 자바스크립트보다 훨씬 많은 기능이 내장으로 가야 할 것
      • (disjukr) FFI는 어떻게 할 것인가?
      • (lifthrasiir) 퍼미션 중에서 가장 넓고 안전하지 않은 퍼미션으로 들어가야 하지 않을까
      • (aury/disjukr) 표준 패키지가 스스로 새로운 종류의 퍼미션을 만들 수 있어야 한다고 생각