nk2028 / qieyun-js

A JavaScript library for the Qieyun phonological system

qieyun

A JavaScript library for the Qieyun phonological system

Usage

Browser:

<script src="https://cdn.jsdelivr.net/npm/[email protected]"></script>

Node.js:

$ npm install qieyun

> import * as Qieyun from 'qieyun';

Documentation

See here.

qieyun-js's Issues

Progress v0.15

測試版 Qieyun.js v0.15 推導器現已上線！

👉 https://syimyuzya.github.io/qieyun-autoderiver/ 👈

目前已更新可供試用的推導方案：切韻拼音、unt 擬音、王力擬音、推導普通話、不通話(🌿)、白一平轉寫、有女羅馬字

舊版方案不兼容，需更新後才可使用，更動詳見：https://github.com/nk2028/qieyun-js/releases/tag/v0.15.0-beta.1

關於本版

v0.15 的開發計劃，始於今年切韻新韻圖再次更新的更加規整的音韻地位表示法。

其實之前 v0.14 的開發也是相同的原因，但由於當時未能更新推導器，就始終未能完成測試與發佈。這次 v0.15 開發，終於實現了推導器更新，即將開始 beta 測試。之前的 v0.14 則將直接跳過。

Beta 階段

• 發佈 beta 版，可用 npm i qieyun@beta 安裝試用
• 上線測試用推導器（包含若干已更新的推導方案；舊版方案不再兼容，需更新後方可使用）
• 公開遷移指南
• 試更新一些其他推導方案（具體更新哪些尚待確定）
• 舊版推導器改在 /qieyun-autoderiver-legacy 上線（可用於運行舊版推導方案，此外其應該不會有大的更新）

其他一些相關套件（如輸入法、切拼轉音韻地位等工具），將在 v0.15 發佈後更新

文檔頁面連結中的漢字全被 TypeDoc 換成底線

推導方案　　 → /modules/____.html
表達式　　　 → /modules/___.html
資料　　　　 → /modules/__.html
適配分析體系 → /modules/______.html
音韻地位　　 → /classes/____.html
音韻地位.屬於→ /classes/____.html#__-6

`.判斷` suppresses more exceptions than necessary

qieyun-js/src/lib/音韻地位.ts

Lines 653 to 657 in 59de776

	try {
	return loop(結果);
	} catch {
	continue;
	}

qieyun-js/src/lib/音韻地位.ts

Lines 663 to 667 in 59de776

	try {
	return loop(規則);
	} catch {
	return null;
	}

I guess the intention is to determine if there isn't any condition that matches in the sublist, but it also catches and silently drops other exceptions.

關於要不要把 `音韻地位` 的對象方法都在構造時就 bind

之前在 #29 裡提過一下，雖然沒採用，但放在這裡待討論。

#29 原本在 音韻地位.constructor 中加上了這樣的代碼（當時未考慮 constructor）：

Object.getOwnPropertyNames(Object.getPrototypeOf(this)).forEach(function (this: Record<string, CallableFunction>, key) {
  typeof this[key] === 'function' && (this[key] = this[key].bind(this));
}, this);

其作用是將 音韻地位 的 屬於、判斷 等方法在構造時立即 bind。

這樣會使這些方法的用法與 Python 相仿，但符不符合 JS 中對「對象方法」的期望行為呢？

（而且印象中除了 Python 外，別的語言（無論動態靜態）幾乎都沒有這種「隱式 bind」的用法（討論見此）

屬於('影組')?

文檔中有「影組」但代碼中實際並沒有的樣子。。

（沒直接 PR 是因為不太清楚這個「影組」是該加入還是該刪去）

qieyun-js/build/brogue2.js

Lines 1 to 9 in 72d0646

	var __組到母=
	{"幫":["幫","滂","並","明"]
	,"端":["端","透","定","泥"]
	,"知":["知","徹","澄","孃"]
	,"精":["精","清","從","心","邪"]
	,"莊":["莊","初","崇","生","俟"]
	,"章":["章","昌","船","書","常"]
	,"見":["見","溪","羣","疑"]
	}

PS Haskell 式逗號位置好耶～

配合 qieyun-autoderiver 0.2

@graphemecluster 已經公開了推導器 0.2 版的 PR 及相關功能的 issue，對推導方案做了新的擴展：可以動態依用戶所調整的選項值，來決定顯示或不顯示某些選項。

這個目前超出 Qieyun.推導方案.建立 的處理能力，而該 API 本來就是為了給推導器與 qieyun-examples 兩方共同使用的，因此 Qieyun.js 也需要配合它改動一下。

但實際改動之前，有些要點要先考慮一下。

推導器目前的行為

先看一下新版推導器下，推導方案的增強之處。參照原 issue 所給的演示代碼，實測並讀了下相關代碼之後，總結如下：

• 推導方案返回的選項列表中的項，可以寫成 [選項名, 預設值（及可選值列表）, 條件]，增加一個第三項（boolean 型）作為該選項的出現條件。
• 每當用戶修改選項，推導方案便會以 方案(null, null, 當前選項) 為參數重新調用一次，並顯示新的選項列表。
  • 最初一次則會以 方案(null, null, <一個特殊構造的「空」對象>) 形式調用，以獲取預設值。
• 因不符合出現條件而被隱藏的選項，推導時不會包含在 選項 參數裡（就好像它完全不存在一樣）

我當時看到示例代碼時提出了反正都要重新調用一次推導方案，與其僅僅調整一個「可見性」，不如直接依用戶選項構造個新的選項列表返回，且這樣功能還更強，並給了代碼例。（甚至之後還想到能利用它做到更有趣的效果2333

也說是說，「選項出現條件」這個增加的部分，其實完全被另一個（無論有意還是無意引入的）更強大的功能給架空了😂

另外，除了推導器外，也會有在 Node 下用 qieyun-examples 調用推導方案的情況，它的 API 也需要考慮一下。比如這樣一例：在 qieyun-examples 下，如果我調用了 方案(地位, 字頭, { ...部分選項 }) 只給了一部分選項，按 Qieyun.js 0.13 的做法，其餘未指定的選項應當填入預設值，但由於方案可以依條件任意返回選項列表，一些選項「預設值」也可能變成動態的。所以傳入選項進行推導時，要調用兩次方案代碼，第一次獲取未指定選項的預設值，第二次實際推導。

那麼 Qieyun.推導方案 API 該怎麼辦

根據以上的分析，需要在以下方案中做一下選擇：

1. 僅保留「出現條件」這一功能，同時不要讓推導方案能「任意」返回選項列表，而是讓它只返回一次列表，裡面的「出現條件」全都改成用 lambda（即不用普通 boolean 而是用 (當前選項: Record<string, unknown>) => boolean 作為出現條件）

• 優點是簡單明瞭
• 缺點是用 tuple 將來不便擴展（即使擴展了也達不到方案②的程度），且 tuple 本身意義也不那麼明朗

2. 保留任意返回列表的功能，就不需要「出現條件」這個東西了。

• 優點是功能強大
• 雖然可能有意想不到的用法

個人看法是方案②比較好些。

Progress v0.14

目前在 dev-0.14 分支 進行中～

• 移除 推導方案 API

  • 其工作交由 nk2028/tshet-uinh-deriver-tools 處理

• 音韻地位 體系調整

  • 標準體系調整（韻目用字、開合/重紐標法等）
  • 音韻地位「導入/驗證」功能（代替原本的 適配分析體系.v2ext 與 音韻地位.驗證）
  • 音韻地位.正則地位 功能（作用是過濾掉非正則地位，代替原 適配分析體系.v2）
  • （2022-09-15 增）彙整 正則地位 中發現的設計問題，重新設計「分析體系相混」的解決方案
  • 移除「導入」「正則地位」的轉換功能，整合為「驗證」
  • 移除 適配分析體系（v0.14 起將僅支持別家體系地位轉換至 nk2028 音韻地位，不再內置支持反向轉換，也不再內置提供推導方案「兼容模式」 Edit: 不再支持「轉換」相關操作）
  • 調整音韻屬性相關常量（如重紐韻範圍等）、常用表達式等
  • （推遲至 v0.15 未定）提供用於 任意音韻地位 的 基礎驗證、屬於、判斷

• （推遲至 v0.15）資料 增強

Beta 測試：

• 上線測試用推導器
• 更新 qieyun-examples（相當一部分方案會下線⊙ω⊙）

Packaging

v0.13 Progress (est'd release 2022-04-24)

代碼在 dev-0.13 分支（目前尚未成形，還需要不少更動） Edit: 代碼已經基本穩定，正在試更新幾套推導方案測試效果 Edit: 將在準備工作完成後發佈

（預計發佈：2022-04-23 24）

• 放寬 音韻地位 限制
  • 編碼空間擴張（目前做到 呼 和 重紐 可在任意場合非 null（當然過於離譜的地位即使創建了也可能在下述「適配分析體系」過程中被拒掉（
  • 提供基於新版資料音韻地位體系（下稱 v2 體系）的、標準化的、能無歧義表達新資料、原資料（下稱 v1 體系）、（poem）字音表、韻典 四種 三種音韻地位分析體系的「中介體系」（稱為 v2ext 體系）
  • 實現上述體系與 v2ext 中介體系間的轉換（稱為 適配分析體系，暫時不打算支持用戶任意調節各種選項，以免貿然搞出另一個 DSL 和 Lisp 解釋器來x）
• 預設資料升級，與（計劃中的新版）韻鑒將統一使用 v2 音韻地位體系
  • 資料相關 API 亦從 音韻地位 屬性分離為獨立模塊
• 更新 README 示意圖
• 為 qieyun-examples、qieyun-autoderiver 兩者提供統一的推導方案 wrapper（以便於調用，以及區分新舊體系下的
  代碼）

發佈前準備：

• 公開 API 更動說明與遷移指南
• 更新至少四套推導方案
  • 切韻拼音（試驗及更新 RIME 輸入法用）
  • 嚴拼（重生成 RIME 詞典用）
  • 有女羅馬字（試驗用）
  • 白一平轉寫（日後維護 RIME 詞典可能有用）
• 測試使用
  • 生成 RIME 詞典（tupa, kyonh 兩種），並與舊版對照
  • 聲音唱和圖新版方案（第一個按 0.13 大幅重構的方案）
  • 讀入五家資料（v2、poem字音表、韻典、有女全字表、古韻字表）音韻地位，驗證與 v2ext 地位間雙向轉換，並比較各家審音差異

Beta 修正（beta.1--5 略）：

• beta.6
  • ytenx 體系清韻鈍音需標「A類」

Edit: 新版發佈後，原 v1 音韻地位體系會成為非公開的，並在 qieyun-examples 升級完成後停止支持並移除。

其他相關工作（僅列出，不在此追蹤進度）：

• 推導方案適應 0.13（切韻拼音、嚴拼、有女三套優先，其他方案允許 gradual adoption，舊代碼仍可工作於舊體系）
• 推導器升級使用 0.13
• 利用新的 v2ext 中介體系重新生成 RIME 上游詞典
• 切韻拼音反推更新
• 資料支持更多其他體系存在的對立（預設不啟用，需主動 opt-in）

TypeScript gets confused with entry.ts

(Present in 0.13.1 & 0.13.2, temporarily reverted in 0.13.3)

0.13.1 和 0.13.2 雖然加入了 default export，但它的 index.d.ts 在 submodule 方面似乎出了很大問題。

於是導致在 TypeScript 項目中：

• 無法 import { 資料 } from 'qieyun'（似乎所有 submodule 都無法引入）
• 寫 import { query音韻地位 } from 'qieyun' 不會報錯（本來應該是 Qieyun.資料 中的）

0.13.3 暫時把入口從 entry.ts 改回了 index.ts。