The Ashtadhyayi Framework

In Software Programming, namespace is a very important concept. It is a context for identifying something uniquely. I strongly believe if a proper namespace or naming convention is not conceived, the ideas conveyed within the namespace will also be poor. Some examples are: domain names, namespaces in xml/xsd, package names in java which are mandatorily related to a folder hierarchy. In .Net also there are namespaces, though its not correlated to folder hierarchy, which I believe allows for ample confusion. The more the conventions, the lesser the code complexity.


Over the years I have reviewed how programmers have used package naming conventions in the Java world. In general there are two flavors of naming conventions: type-based and feature-based. Some used both conventions at the same time, I'm ignoring them as mutants.


Some examples of type-based conventions are com.acme.data, com.acme.controllers, com.acme.service, com.acme.exception. Here all the classes are grouped under "types" of the classes. While its easy to create and maintain such a structure, its really hard for a new-comer (or even for a revisit) to understand the functionality, unless all the classes are fully scanned and understood.


Imagine a "Purchase Order" functionality, which has the following classes:


com.acme.data.OrderInfo, com.acme.data.PaymentInfo;
com.acme.controllers.OrderForm, com.acme.controllers.PaymentForm;
com.acme.service.OrderService, com.acme.service.PaymentService;
com.acme.exception.OrderException, com.acme.exception.CreditCardException, com.acme.exception.StockUnavailableException


To understand the Purchase Order functionality, one should scan the whole hierarchy and associate the objects mentally. In a complex project, this would take several days to understand the code when there are several controllers, services etc especially if the classes themselves are named poorly or ambiguously.


The feature-based approach will define namespaces like: com.acme.order, come.acme.payment. So the classes will be


com.acme.order.OrderInfo, com.acme.order.OrderForm, com.acme.order.OrderException, com.acme.order.StockUnavailableException;
com.acme.payment.PaymentInfo, com.acme.payment.PaymentForm, com.acme.payment.CreditCardException.


Such grouping immediately draws focus on understanding the functionality. It is also easy to reverse-engineer the code into subject areas. One is not better than other as both techniques have merits. Every programmer would have written some kind of framework code. In a typical non-business framework code type-named conventions make more sense. For eg, the Spring-framework is arranged based on type-based packages. If I need to extend from a controller, it makes most sense for me to search for a "controller" package. In an application, feature-based package makes a lot of sense.


Now, what does pANini have to do with all this? Its illustrative to infer that there exists a very similar structure parallel in the sanskrita grammar literature. pANini's ashtadhyAyI is known for its outstanding brevity. However one cannot understand its application without pretty much scanning the whole work. Take for example the formation of word "rAma:"


arthavat adhAtu apratyaya: prAtipadikam (1.2.45)
svaujasamautchhastaabhyaamngebhyaambhyasngasibhyaambhisngasosaamngyossup (4.1.2)
upadeshe ajanunaasika it (1.3.2)
tasya lopa: (1.3.9)
sa sajusho ru: (8.2.66)
kharaavasaanayo: visarjanIya: (8.3.15)


Just to form the word rAma: ("application") one has to understand 1, 4, 8 chapters, pAda-s and several sutra-s and anuvritti-s within. Why? Because pANini has grouped his sutras based on "types". Package is called "adhikAra" in sanskrita. Each adhikAra is a namespace: pratyaya, samasa, samhitaayam, paribhasha etc. The order of these sutras are extremely important. Just like the folder hierarchy: com.acme.order is not the same as com.order.acme. Changing of the order sutras will invalidate the structure and the meaning too. There are no examples within Ashtadhyayi, just like you wont find an example within a framework itself.


The sanskrita vyAkarana literature that followed (a big list including Katyayana's vartika, Patanjali's Mahabhashya, Kasika vritti, Siddhanta Kaumudi, Laghu Siddhanta Kaumudi, Paribhasha indusekhara and so on) attempted to re-arrange sutras according to functionality  or "prakriya". They also supplied numerous examples ("test cases") and counter-examples ("negative test cases"). There are fantastic precise examples and counter-examples in Siddhanta Kaumudi by bhattoji dIkshita.


As a good programmer, lets end with good comments. If pANini had to write a javadoc header for his grammar, this is pretty much how it would have looked:


/**
* The Ashtadhyayi Framework
* vyAkaraNa.sUtrapATha.ashtAdhyAyI.framework
* @author pANini
* @since 1500 BC
* @version १.०.०
* @see SAkalya, SAkatAyana, SphotAyana, yAska etc. frameworks
* @see Siva-sutra, dhAtupATha, gaNapATha, uNAdi, Chandas
*
* This framework provides a complete set of base sutras, definitions, interpretations, sandhis, rules and exceptions for generating an infinite number of sentences in natural language using a finite set of rules.
*
*

* WARNING: Do not modify the order of the sutra-s without understanding the complete framework.
*

*
* Code Metrics:
* Number of lines of code: 3986
* PMD index: 0
* Cyclomatic complexity: 1000
*
*/