Pāṇinian Grammar:Part 7 - Introduction to Object Oriented Programming

In this section, I will take a little step further and introduce object oriented programming concepts. Again, this can be safely skipped for those to whom it is a day job. In this section, I am going to introduce a few more concepts that may sound sophisticated but are in essence simple to understand. They are the following - class, object and inheritance.

Class & Object

The standard types of data that computers are trained to manipulate are routine objects like integers or strings or arrays. When we deal with more complicated data types, one needs to come up with the notion of a class. A class is simply a blueprint for a combination of a novel data type and a set of instructions one is interested in. For example, I can define the class for driving a car named CAR_CONTROLS with the following attributes - fuel, speed that also has some operations associated with it - accelerating and driving. All these characterize a car control system (there are lots of others too but for now, let us stick to only these). For example,

class CAR_CONTROLS {

float fuel_level

float speed

float driving(float accelerator) {...}

float braking(float brake_position) {...}

}

Here, the class CAR_CONTROLS has two data associated with it - fuel_level and speed. And we have two operations - driving and braking that take as their inputs, accelerator and brake position and modify the speed accordingly in the {...} section. So, this is what the concept of a class is - a template for a combination of a data set and instructions.

Now, this class is a template for creating so many actual cars having some values for these numbers specified. A specific car may have a fuel_level of 0.5 in liters. An object is an instance of a class.

Inheritance

A very important concept in object oriented programming is the notion of inheritance. Consider two classes - the class HUMAN and the class STUDENT. We see that all students are humans and hence we would like the class STUDENT to inherit the data and instructions in the class HUMAN. This phenomenon is called inheritance. Of course the class STUDENT could contain more specific information like name of the school that is not present in the generic class HUMAN but we all agree that it should logically get the properties of the class HUMAN. This inheritance saves lots of programming time and space since one need not keep on mentioning the repeating set of features in all the inherited classes from a given parent class.

Consider the even more generic class ANIMAL. And now the class HUMAN which is an inherited class from ANIMAL. Now consider the instruction MOVEMENT. In the generic class ANIMAL, the instruction MOVEMENT would be something like: position four limbs vertically upright and touching the ground and then actuate to move. But we know that humans, while being an inherited class from ANIMAL do the movement differently - we walk erect with just two of our backlimbs (called legs) positioned vertically and touching the ground and we reserve our forelimbs (called hands) for novel tasks like tool making and grasping. So, consider the scenario:

class ANIMAL {

movement {..walk using four limbs..}

}

For other classes of animals like DOG, CAT, etc this function “movement” using four limbs can be inherited directly. But it cannot be done so for humans. So, for the class HUMAN, we must have

class HUMAN: ANIMAL {

movement {..walk using two back limbs..}

}

Now, let us say that I create an object from the class HUMAN and call the function “movement”. What should be implemented? It turns out that instructions in the inherited class overrides the instructions in the parent classes. This phenomenon is called function overriding in object oriented programming. Its formal definition is given below.

Function Overriding

Function overriding is a concept in object-oriented programming which allows a function within an inherited class to override a function in its base class. This is very important and saves lots of programming time - if you have a general instruction that is applicable by default but some special set of instruction to override it for special cases, then function overriding ensures that by simply rewriting the function for the special case, the special instruction is implemented for the special case and the general instruction is ignored.

Multiple inheritance

How about a class that inherits from two or more base classes? After all, biologically, a child inherits from two parents. This phenomenon is called multiple inheritance. For example, the class INDIAN_BOY needs to inherit both from the class INDIAN and the class BOY. But what if there are two instructions of the same name but doing different things in the two parent classes? If both the parent classes contain different implementations of a function named X, then when the subclass inherits it, from what parent class will it implement X? If the inherited class has another instruction for X, then it turns out that by overriding, it overrides both of the instructions of X in the parent classes. Otherwise, there should be an explicit redefinition of X in the inherited class that tells us from which parent class, the function X is inherited in the inherited class.

Programming Genius

You might ask again what the above things have to do with Saṃskṛta? Let us see now.

In Saṃskṛta, to form the present tense of most verbs, one adds an extra अ before the personal endings. I give some examples:

1. Root पठ् (to read) => पठ् + अ = पठ => पठ + ति => पठति (he/she/it reads)
2. Root पत् (to fall) => पत् + अ = पत => पत + ति => पतति (he/she/it falls)
3. Root लिख् (to write) => लिख् + अ = लिख => लिख + ति => लिखति (he/she/it writes)
4. Root रक्ष् (to guard) => रक्ष् + अ = रक्ष => रक्ष + ति => रक्षति (he/she/it guards)

This is the case with most of the verbs. About 80% of the verb roots get an extra अ vowel before the personal endings are attached in the present and some other related tenses. But there are some classes of verbs that refuse to adhere to this rule or do something weird. Some examples are:

1. Root हन् (to kill) => हन् + ति => हन्ति (he/she/it kills)
2. Root अस् (to be) => अस् + ति => अस्ति (he/she/it is)

So, we again have a general rule applicable to all verb roots but a special exception for only some small class of roots. Does this remind you of inheritance? Note that there are many other rules in action as well and the picture is more complicated - I am simplifying it and am taking only one aspect to demonstrate in a simple fashion.

Pāṇini as usual solves this by using inheritance. He defines a class of ROOTS in general and divides them into ten subclasses - CLASS_1 , CLASS_2, CLASS_3, …CLASS_10. He generally gives an instruction to add the extra vowel अ to all roots by giving it in the parent class ROOTS but redefines that instruction in certain irregular classes and overrides them in the irregular classes.

This is a general rule in Pāṇinian grammar:

Whenever there are two rules competing to be applied on the same object, with one rule for a generic case (applicability in a larger domain) and the other for a particular case (applicability in a smaller domain), the smaller domain is viewed as an inheritance of the larger domain since it it is a part of it and hence the rule for the smaller domain overrides the rule for the larger domain.

Authored by Rama Seshan Chandra Sekaran. Published by Brhat.