Fix han+kvip declension, refactor angasya, and related fixes

[yajnadevam]

Summary

• Full vftrahan (han+kvip) masculine declension — all 24 forms + sambodhana
• Refactor run_before_dvitva into 18 named helper functions (~1000 lines → ~60 line orchestrator)
• Fix ṇatva (8.4.2) across upapada boundary using FlagUpapadaSup
• Implement bhāṣya exception: block ṇatva when G comes from ha-ādeśa (7.3.54)
• Fix Bha saṃjñā assignment for n-ending dhatus with empty kvip
• Fix nyapu_pratipadika to include dhatus with Bha tag
• Apply 7.3.54 (ho hanteḥ) in subanta path after bhasya
• Fix 6.4.98 to not apply for sup pratyayas
• Fix 8.2.7 na-lopa for dhatus followed by empty krt pratyayas
• Handle vocative mat→man and hat→han
• Add enclitic outputs for asmad/yuṣmad
• WASM: nyap pratipadika and taddhitanta support

vftrahan declension table

vibhakti	ekavacana	dvivacana	bahuvacana
prathamā	vftrahA	vftrahaRO	vftrahaRaH
dvitīyā	vftrahaRam	vftrahaRO	vftraGnaH
tṛtīyā	vftraGnA	vftrahaByAm	vftrahaBiH
caturthī	vftraGne	vftrahaByAm	vftrahaByaH
pañcamī	vftraGnaH	vftrahaByAm	vftrahaByaH
ṣaṣṭhī	vftraGnaH	vftraGnoH	vftraGnAm
saptamī	vftrahaRi, vftraGni	vftraGnoH	vftrahasu
sambodhana	vftrahan	vftrahaRO	vftrahaRaH

Test plan

• cargo test --workspace — all pass (3139 passed, 0 failed)
• Full vftrahan declension verified against traditional grammar

Fixes #224

[akprasad]

thanks for the PR, will take a look this weekend

[tbdasap]

@yajnadevam : Are you able to run cargo test successfully on your local development ?

[yajnadevam]

@yajnadevam : Are you able to run cargo test successfully on your local development ?

Yes. I am able to run the test. Updated the PR. Kept the han exception in the 6.4.15 block.

[tbdasap]

W.r.t Handle mat -> man vocative

The test case uses mA (adAdi) + yaNluk + Satf and expects mAman.
Is there a shastric reference for this ? Curious about the motivation.
It seems to violate the intent of नाभ्यस्ताच्छतुः

[yajnadevam]

W.r.t Handle mat -> man vocative

The test case uses mA (adAdi) + yaNluk + Satf and expects mAman. Is there a shastric reference for this ? Curious about the motivation. It seems to violate the intent of नाभ्यस्ताच्छतुः

I essentially followed Ashtadhyayi.com:
https://ashtadhyayi.com/dhatu/02.0057?tab=yangluk_krut&scroll=dhatuform-1020057-yangluk_krut-शतृ&scrollcolor=cyan&scrolloffset=400

Im not certain of the nuances of 7.1.78. ashtadhyayi.com seems to prohibit नुम् for reduplicated main stems but not intensives. see √हु. It is possibly because the आतिदेशिकधातुः = जोहूय is no longer just a reduplicated stem. It is a different root already: 3.1.32 सनाद्यन्ता धातवः

1.1.62 प्रत्ययलोपे प्रत्ययलक्षणम् (“even when an affix is elided, operations conditioned by it still take effect”).
So the system can treat the śatṛ as coming after yaṅ (though lopped) rather than “directly after abhyasta.”

[tbdasap]

1.1.62 प्रत्ययलोपे प्रत्ययलक्षणम् (“even when an affix is elided, operations conditioned by it still take effect”).

Good observation. IMO the primary effect is dhatu abhyasa for yaN even if luk.

Reference: See 14th pdf page (page with number 12) example from this PDF from 1929.

It declines बोभुवत् which is भु+यङ्लुक् like मरुत्

I essentially followed Ashtadhyayi.com:
https://ashtadhyayi.com/dhatu/02.0057?tab=yangluk_krut&scroll=dhatuform-1020057-yangluk_krut-शतृ&scrollcolor=cyan&scrolloffset=400
Im not certain of the nuances of 7.1.78. ashtadhyayi.com seems to prohibit नुम् for reduplicated main stems but not intensives. see √हु. It is possibly because the आतिदेशिकधातुः = जोहूय is no longer just a reduplicated stem. It is a different root already: 3.1.32 सनाद्यन्ता धातवः

@neeleshb : Please help clarify the above. बोभुवत् मामत् perhaps should decline like दधत् due to नाभ्यस्ताच्छतुः

[neeleshb]

नाभ्यस्ताच्छतुः is indeed applicable and बोभुवत् is the correct प्रथमा-एकवचनम्, the forms would be like ददत्. I will fix the website soon.

[yajnadevam]

Thanks for the clarification @neeleshb and thanks for catching this @tbdasap

I have updated the code to incorporate 7.1.78 num blocking for reduplicated stems for sarvanāmasthāna.

@tbdasap here is pointing to the vocative, which should still be num agama

Can you clarify if vocative also should be blocked even though its not sarvanāmasthāna ? You have it for Voc. dadat https://ashtadhyayi.com/dhatu/03.0010?tab=krut&scroll=dhatuform-1030010-krut-शतृ&scrollcolor=cyan&scrolloffset=400

W.r.t Handle mat -> man vocative

The test case uses mA (adAdi) + yaNluk + Satf and expects mAman. Is there a shastric reference for this ? Curious about the motivation. It seems to violate the intent of नाभ्यस्ताच्छतुः

[yajnadevam]

Updated here #226

Now, both nom and voc check for yaN or yaNluk and block num-agama

[tbdasap]

Updated here #226

[test]
fn satf_yanluk_mat_voc() {
    let ma = d("mA\\", Adadi).with_sanadi(&[Sanadi::yaNluk]);
    let mamat = krdanta(&[], &ma, Krt::Satf);
    assert_has_sup_ss(&mamat, Pum, &["mAmat"]);
}

#[test]
fn satf_yanluk_hat_voc() {
    let mah = d("ma\\ha~", Bhvadi).with_sanadi(&[Sanadi::yaNluk]);
    let mamahat = krdanta(&[], &mah, Krt::Satf);
    assert_has_sup_ss(&mamahat, Pum, &["mAmahat"]);
}

1. The above tests seem to succeed on the main branch (without the proposed code changes for these tests) in my dev-env. @yajnadevam : Are these failing in your dev-env. main-branch ?
2. Existing convention for test-case organization: The kashika_\<section\>.rs test cases must be the actual examples given in the Kashika vritti; similarly with kaumudi_*. For now, please put additional unit_tests in integration/regressions.rs.

[yajnadevam]

Is there a particular kashika reference that you use for enumerating tests

[tbdasap]

Is there a particular kashika reference that you use for enumerating tests

@akprasad gave me the above guidance with regard to test organization. Will defer to him.

[tbdasap]

The unit-tests for han + kvip exist at tests/integration/kashika_3_2.rs (although ignored due to failure).
Removing #ignore may be sufficient for han testing (of kashika examples at 3.2.87)

[akprasad]

have not forgotten to review this, just swamped by other obligations. thanks for sending it in

[tbdasap]

The han kvip fix is going to require more non-trivial changes for it to generate
usable forms like virahan

#[test]
fn han_kvip_test() {
    let vftrahan = upapada_krdanta("vftra", &[], &d("ha\\na~", Adadi), Krt::kvip);
    assert_has_sup_1s(&vftrahan, Pum, &["vftrahA"]);
    assert_has_sup_2p(&vftrahan, Pum, &["vftraGnaH"]);
    assert_has_sup_7s(&vftrahan, Pum, &["vftrahani"]);
}

[yajnadevam]

run_before_dvitva is a 1000 line function ... I will refactor it and add your test and ensure it passes

[yajnadevam]

Added all forms for vftrahan in test, all pass

pronoun-enclitics branch has all changes. PR updated.

fn han_kvip_test() {
let vftrahan = upapada_krdanta("vftra", &[], &d("ha\na~", Adadi), Krt::kvip);
// prathamA
assert_has_sup_1s(&vftrahan, Pum, &["vftrahA"]);
assert_has_sup_1d(&vftrahan, Pum, &["vftrahaRO"]);
assert_has_sup_1p(&vftrahan, Pum, &["vftrahaRaH"]);
// dvitIyA
assert_has_sup_2s(&vftrahan, Pum, &["vftrahaRam"]);
assert_has_sup_2d(&vftrahan, Pum, &["vftrahaRO"]);
assert_has_sup_2p(&vftrahan, Pum, &["vftraGnaH"]);
// tftIyA
assert_has_sup_3s(&vftrahan, Pum, &["vftraGnA"]);
assert_has_sup_3d(&vftrahan, Pum, &["vftrahaByAm"]);
assert_has_sup_3p(&vftrahan, Pum, &["vftrahaBiH"]);
// caturTI
assert_has_sup_4s(&vftrahan, Pum, &["vftraGne"]);
assert_has_sup_4d(&vftrahan, Pum, &["vftrahaByAm"]);
assert_has_sup_4p(&vftrahan, Pum, &["vftrahaByaH"]);
// paYcamI
assert_has_sup_5s(&vftrahan, Pum, &["vftraGnaH"]);
assert_has_sup_5d(&vftrahan, Pum, &["vftrahaByAm"]);
assert_has_sup_5p(&vftrahan, Pum, &["vftrahaByaH"]);
// zazWI
assert_has_sup_6s(&vftrahan, Pum, &["vftraGnaH"]);
assert_has_sup_6d(&vftrahan, Pum, &["vftraGnoH"]);
assert_has_sup_6p(&vftrahan, Pum, &["vftraGnAm"]);
// saptamI
assert_has_sup_7s(&vftrahan, Pum, &["vftraGni", "vftrahaRi"]);
assert_has_sup_7d(&vftrahan, Pum, &["vftraGnoH"]);
assert_has_sup_7p(&vftrahan, Pum, &["vftrahasu"]);
// samboDana
assert_has_sup_ss(&vftrahan, Pum, &["vftrahan"]);
assert_has_sup_sd(&vftrahan, Pum, &["vftrahaRO"]);
assert_has_sup_sp(&vftrahan, Pum, &["vftrahaRaH"]);
}

[tbdasap]

@yajnadevam : Please close if this is no longer necessary.

[yajnadevam]

Closed as the changes are in #226