Template overload for `.調整`

[graphemecluster]

[graphemecluster]

Badly written 😕

[graphemecluster]

@syimyuzya (Well, first of all, do you think we ever need this? I guess you and Ayaka may find this feature redundant?)

[syimyuzya]

More on the expression syntax for .屬於:

When I rewrote .屬於, I intentionally made it only accept whole predicates to avoid too much complexity and difficult design choices in its syntax. Examples be like:

1. Should we accept 重紐${'A'}類? Why or why not? If so, should we also accept ${'重紐A'}類, or 重${'紐A'}類? (:herb:
2. Should we accept ${() => cond ? '見' : ''}影母? How about 影${() => cond ? '見' : ''}母?
3. Should we accept 清${() => cond ? '母' : '韻'}?
4. How should we parse ${() => true}影母? Is it a valid expression (true && 影母), or is it invalid?
5. Should we accept ${() => '去' : '仄'}聲? (note that 仄聲 is not a basic 音韻屬性) If so, should we also accept 陽${() => cond ? '' : '聲'}韻? (:herb:

:joy::joy:

[syimyuzya]

@syimyuzya (Well, first of all, do you think we ever need this? I guess you and Ayaka may find this feature redundant?)

I think it's not redundant at least (except for the template part, maybe that's overkill :see_no_evil:). Not sure how much it's need either, though.

.調整 is currently the only method where users have to write like { 聲: '去' } but not the more natural '去聲' (other methods have, for example, from描述 instead of the constructor, 屬於 instead of === or [...].includes), this PR just fills the gap.

[syimyuzya]

except for the template part, maybe that's overkill

The expression syntax for .調整 is quite restricted and much simpler than .屬於 (in particular, no logical operators, parentheses or sub-expressions), so IMO the ordinary string template (.調整(`${'見'}母`)) should suffice already, and there is not much to benefit from special handling of template arguments.

[graphemecluster]

IMO:

1. Should we accept 重紐${'A'}類? Why or why not? If so, should we also accept ${'重紐A'}類, or 重${'紐A'}類? (🌿

Accept 重紐${'A'}類 but not ${'重紐A'}類 or 重${'紐A'}類.

2. Should we accept ${() => cond ? '見' : ''}影母? How about 影${() => cond ? '見' : ''}母?

I would probably only accept ${() => cond ? '見影' : '影'}母 if you didn't mention them, but it seems to be reasonable to accept them.

3. Should we accept 清${() => cond ? '母' : '韻'}?

Yes for me. At least, the current implementation of .調整 accepts 清${cond ? '母' : '韻'}.

4. How should we parse ${() => true}影母? Is it a valid expression (true && 影母), or is it invalid?

Should be OK to keep it valid.

5. Should we accept ${() => '去' : '仄'}聲? (note that 仄聲 is not a basic 音韻屬性) If so, should we also accept 陽${() => cond ? '' : '聲'}韻? (🌿

I am neutral to ${() => cond ? '去' : '仄'}聲 (in fact it seems that I made it invalid for simplicity in the past 😂😂), but 陽${() => cond ? '' : '聲'}韻 should definitely be rejected.

[graphemecluster]

And please complete the documentation for me, I am too lazy, please forgive me, @syimyuzya

[syimyuzya]

3. Should we accept ${() => cond ? '見' : ''}影母? How about 影${() => cond ? '見' : ''}母?

I would probably only accept ${() => cond ? '見影' : '影'}母 if you didn't mention them, but it seems to be reasonable to accept them.

7. How should we parse ${() => true}影母? Is it a valid expression (true && 影母), or is it invalid?

Should be OK to keep it valid.

Note the syntactic ambiguity here: How should we then handle 來母 或 ${() => cond ? '見' : true }影組? 😂

Be aware that:

1. The type of a lazy template argument cannot be predicted until it gets evaluated;
2. We can't just let lazy arguments affect the (already parsed) syntax tree, even in this simple case; otherwise it would bring more surprises.

[syimyuzya]

主開發分支的 92ab876 已經加入了支援普通字串的 .調整。

不過這個 PR 可以保持 open，用來繼續討論 tagged literal 版本的設計細節w