[prakriya] Handling rule conflicts

[vvasuki]

​We currently have reasonable support for karmani prayoga, and I'll also add support for sanAdi pratyayas by the end of the year. We have experimental support for various krdantas and basic support for subantas.

Currently, how are rule conflicts handled in prakriyA simulation? The regular interpretation of विप्रतिषेधे परं कार्यम्, augmented by a web of paribhAShA-s?

Would it be simple to implement an option to resolve such rule conflicts by means of the simpler framework described in Rishi rajpopat's thesis which recently entered the news and fascinated / surprised many? This will be enormously valuable in validating the claims made therein, and will likely lead to advances in our understanding of what pANini intended + drawbacks therein.

[akprasad]

Sadly it would not be simple -- details below. My current focus is on making vidyut-prakriya fast and correct, and I think exploring this problem is a better fit for a fork of this repo.

~

Right now, I use a similar approach to SanskritVerb: I hand-code a specific rule ordering. I haven't followed any specific philosophy except "produce the correct padas with a reasonable-looking prakriya." But since this project is heavily inspired by SanskirtVerb (which, I believe, draws on the work of Smt. Pushpa Dikshit), in practice I am using a पौष्पी प्रक्रिया.

Regarding rule selection, my thinking was: as long as the major sections of the Ashtadhyayi are unimplemented, modeling the resolution of rule conflicts is extra complexity and a new source of bugs and degraded performance. For my current needs, I want to focus first on generating the correct forms quickly with reasonable prakriyas.

However, I agree that modeling rule conflicts is tremendously useful for the reasons you mention.

Due to the substantial nature of these changes, I think a fork is best; but, such a fork could lean on this library's rich APIs and exhaustive test suite. So perhaps something like this would be workable:

1. Refactor each rule so that it's in its own function. Then, create a new function that receives the name of a rule and runs the associated function on the current prakriya. This lets us have dynamic control flow.
2. Find a way to examine the "meta" aspects of each rule: which properties they select on, which samjnas they use, which changes they cause, etc. The only academic work I'm familiar with in this vein is here, but I don't know if it's public. Otherwise, some work might be required to create an inspectable representation of each rule. (One hacky approach might be to walk the AST we create in (1).)
3. Implement a function that accepts a prakriya and returns the rule that should be run. This is the core logic we would test.
4. Validate the implementation of (3) against our test suite.

This procedure is quite promising because each step can lean on our test suite, so the developer can always know that the overall system is in a reasonable state. While it would still involve quite a bit of effort, it's far less effort than writing a system from scratch.

[vvasuki]

Indeed, I had anticipated that you wouldn't have implemented true rule-conflict resolution (not only because it is hard to do, but because the traditional "algorithm" is quite arbitrary -  iṣṭa-vāci para-śabdaḥ, vipratiṣedhe paraṁ yad iṣṭaṁ tad bhavati (Mahābhāṣyam on 1.1.3) ). Rather, I meant something simpler -

It sounds as if one of the (implicit) inputs to the prakriya generator is a list of rule-conflict resolutions (partially ordered list?). Could this input be made explicit? If it could, then trying out a new rule-conflict resolution algorithm would be as simple as inputting an alternate list of rule-conflict resolutions.

[akprasad]

Ah, I see -- If I follow you correctly, I think doing as you suggest would require implementing (1) in what I mention above, i.e. moving each rule to its own function then creating a deterministic/explicit list of rules to call.

I wonder how such an approach could model control flow. For example, in the इडागमप्रकरण only one इट् rule should be selected, but a naive approach could potentially run multiple rules in error.

Another possible approach would be to extract the current ordering by looking at the ~million or so prakriyas we generate and building a directed graph of rules. This would be an output of the program as opposed to an input to it. Then new proposal for conflict resolution could produce a new ordering that we could check against this directed graph. Based on the differences, we could reorder rules manually by copy-pasting code blocks then re-run the program.