SOML, YAML의 'country: no'가 false 되는 문제를 없앤 설정 포맷
SOML – A Config Format for Humans
Sindre Sorhus가 만든 SOML은 JSON의 엄격함과 YAML의 편안함을 합친 설정 포맷이다. 값의 타입을 내용이 아니라 문법으로 결정해 '123'은 문자열, 123은 정수로 명확히 구분된다. 날짜·시각·기간이 실제 값 타입이고, 경로와 정규식에 이스케이프가 필요 없으며, 주석을 어디에나 쓸 수 있다. 중복 키, 범위를 벗어난 숫자, 고아 서로게이트는 오류로 처리한다. 표준 형식과 약 1000개의 적합성 테스트로 모든 구현이 같은 결과를 내도록 했다. 현재 초안 명세다.
SOML은 YAML에서 내가 좋아하는 것들, 즉 주석, 파일을 감싸지 않는 중괄호, 줄 끝에 붙지 않는 쉼표, 따옴표 없는 키를 유지한다. 문제가 되는 것은 제거한다. YAML에서는 값의 내용이 타입을 결정하지만, SOML에서는 문법이 결정하므로 'no'는 문자열, 3.10은 부동소수, 2는 정수다.
HN 토론
63- layer8
> 보이는 것이 곧 얻는 것이다: […] '10.20'과 10.20은 각각 문자열과 부동소수점이며, 쓰인 그대로다.
이건 명세가 불충분해 보이고 또 틀린 것 같다. 단정밀도 바이너리 IEEE 754 부동소수점 수라고 가정하면, 10.20은 실제로 10.19999980926513671875이다. 배정밀도라면 10.199999999999999289457264239899814128875732421875가 될 것이다. 그러니 보이는 것이 곧 얻는 것이 아니고, 정확히 무엇을 얻게 되는지도 불분명하다.
> 값의 타입은 내용이 아니라 문법에서 온다 […] allowed-origins: [
]
이건 URL처럼 보이지만 문자열이다. 만약 다음과 같다면 어떨까:
> allowed-origins: [
'httpș://example.com'
'ħttps://example.org'
]
여전히 문자열이라 SOML 파서에게는 문제없지만, 값의 애플리케이션 수준 타입 측면에서는 아마 유효한 설정이 아닐 것이다. 애플리케이션 스키마가 설정 언어보다 타입에 대해 더 구체적인 생각을 갖는 순간, 타입을 알려주는 문법은 제한적인 유용성만 갖는다.
- lightandlight
아이러니하게도 이 프로젝트는 LLM이 생성한 것 같다.
당신의 프로젝트가 왜 중요한지에 대한 Claude의 해석을 읽고 싶지 않다. 당신이 직접 말해주길 원한다.
- ActionHank
솔직히 말하면, 뭔가를 더 "인간적"으로 만드는 해결책이 나올 때마다 그들은 그저 구조/문법을 없애버린 것이다.
아마도 사람들이 그것을 배울 필요가 없도록 하려는 것이고, 그래서 길거리의 누구나 파일을 편집할 수 있게 하려는 것 같은데, 그런 가드레일 없이는 보통 예상치 못한 방식으로 아주 심하게 깨질 것이다.
결국 우리는 더 많은 암묵적 규칙을 가진 새로운 "인간적"인 무언가를 다시 발명하게 되고, 이 사이클은 계속된다.
- mofle
안녕하세요 여러분. 이걸 작업하는 사람(인간)입니다. 아직 초기 단계입니다. 수년 동안 원해왔던 것이지만 지금까지 투자할 시간이 없었습니다.
이미 제 웹사이트의 frontmatter를 구동하고 있습니다: https://github.com/sindresorhus/sindresorhus.github.com/blob...
- james_marks
제목만 보고는 인간을 설정하기 위한 명세인 줄 알았다. 그게 무슨 뜻인지 잘 모르겠고, 여전히 모른다는 게 아쉽다.