추상 위키백과/업데이트/2023-09-20

추상 위키백과 업데이트

유형에 대한 렌더러 및 파서

위키함수는 현재 문자열과 부울이라는 두 가지 유형을 지원합니다. 위키함수를 유용하게 만들려면 숫자, 날짜, 지리좌표, 그리고 결국 위키데이터 어휘소 및 항목과 같은 더 많은 유형을 지원해야 합니다. 유형은 위키함수의 함수가 가질 수 있는 입력 및 출력의 종류를 정의합니다.

위키함수를 통해 우리는 다른 프로그래밍 언어가 수행한 작업을 단순히 반복하고 싶지 않습니다. 그러나 가능하다면 프로그래밍 언어 연구와 경험을 통해 배운 교훈을 부드럽게 업데이트하고 최대한 포괄적이 되도록 하세요.

위키함수의 첫 번째 배포를 위해 문자열과 불리언은 매우 신중하게 선택되었습니다: 문자열은 특정 문자 시퀀스일 뿐이고 사용자의 언어에 의존하지 않기 때문입니다. 불리언은 프로그래밍 논리 흐름의 핵심 기반이기 때문입니다. 또한 위키함수에서 완전히 번역될 수 있습니다. 참과 거짓이라는 두 값은 모두 우리가 지원하는 모든 언어로 이름을 가질 수 있는 위키함수 객체로 표시됩니다. 초기 배포 이후 12개 이상의 번역이 추가되었습니다! 더 추가할 수 있다면 좋을 것 같습니다.

소개하기에 흥미로울 수 있는 다음 유형의 한 예는 정수입니다. 이는 큰 질문을 제기합니다. 정수를 어떻게 표현해야 할까요?

대부분의 프로그래밍 언어에는 이에 대한 두 가지 대답이 있습니다. 하나는 이러한 숫자를 효율적으로 저장하고 처리하기 위해 일반적으로 내부적으로 특정 길이의 이진 문자열로 표현합니다. 그러나 사람이 읽을 수 있는 소스 코드에도 표현이 있으며 여기서는 일반적으로 일련의 아라비아 숫자로 표현됩니다. 예를 들어, 4657388. 일부 프로그래밍 언어는 숫자를 그룹화할 수 있을 만큼 충분히 훌륭합니다. 에이다에서는 4_657_388을 쓸 수 있고, 인도식 기수법을 선호한다면 46_57_388을 써서 이 숫자를 좀 더 읽기 쉽게 만들 수 있습니다.

그러나 같은 숫자를 가리키는 벵골 숫자를 사용하여 ৪৬,৫৭,৩৮৮를 쓸 수 있는 프로그래밍 언어는 거의 없습니다. 위키함수의 경우, 우리는 전체 시스템이 모든 인간 언어를 유창하고 일관되게 지원하도록 하기 위해 이를 바로잡고 싶습니다.

내부적으로는 다른 모든 객체와 마찬가지로 숫자를 ZObject로 표현합니다. 위의 숫자는 내부적으로 다음과 같이 표현됩니다(아직 실제 위키함수에 해당 유형이 없기 때문에 베타의 프로토타입 ZID를 사용함):

{
  "Z1K1": "Z10015",
  "Z10015K1": "4657388"
}

또는 영어 레이블을 사용하면 다음과 같습니다:

{
  "type": "positive integer",
  "value": "4657388"
}

이것이 내부 표현을 해결하더라도 가능하다면 이 객체를 시스템에 표시하지 않는 것이 좋습니다. 대신, 우리는 위키함수 커뮤니티가 각 유형에 '렌더러'와 '파서'를 첨부할 수 있도록 허용할 계획입니다. 렌더러는 주어진 유형의 객체(이 경우 양의 정수 유형의 객체)와 언어를 취하고 문자열을 반환하는 함수입니다. 파서는 그 반대입니다. 문자열과 언어를 사용하고 양의 정수 유형의 객체를 반환합니다.

이를 통해 위키함수 커뮤니티는 각 유형 및 언어에 대한 함수를 생성하여 해당 유형의 값이 해당 언어로 표시되는 방식을 결정할 수 있습니다. 벵골어 인터페이스에서 위의 숫자는 벵골어에 대한 가장 자연스러운 표현(৪৬,৫৭,৩৮৮일 수 있음)으로 표시될 수 있습니다.

숫자를 입력할 때 구문 분석 함수를 사용하여 사용자의 입력을 내부 표현으로 변환합니다. 그런 다음 얼마나 유연해지고 싶은지 결정하는 것은 커뮤니티에 달려 있습니다. 입력으로 ৪৬,৫৭,৩৮৮만 허용할지, 또는 ৪৬৫৭৩৮৮도 마찬가지로 좋을지, 아니면 4657388만 허용할지 여부는 커뮤니티에 달려 있습니다. 결정은 다음과 같습니다. 위키함수 커뮤니티에서 만들 수 있습니다.

위의 텍스트에서는 많은 가정을 했습니다. 예를 들어 베타의 ZID를 사용하여 "양의 정수" 유형을 호출하고 양의 정수의 내부 표현이 서식 없는 아라비아 숫자라고 가정합니다(16진수, 64진수 또는 2진수 대신 좋은 솔루션이 될 수 있음). 그리고 다른 가정. 이러한 모든 결정은 귀하에게 달려 있지만 여기서는 제안에 대해 구체적으로 설명하기 위해 가정을 사용했습니다.

우리는 이 제안을 몇 주, 몇 달에 걸쳐 점진적으로 구현할 계획입니다. 처음에는 (현재 베타에서 작동하는 것처럼) 내부 표현만 허용하고 그런 다음 렌더러와 마지막으로 파서를 추가하는 경우가 있을 것입니다.

우리는 이 계획에 대한 귀하의 의견을 듣고 싶습니다.