Currently, all class members (fields and/or methods) are public in KOOL.
Sometimes we want to keep members of a class private, in the sense that
subclasses do not have direct access to those members.  This exercise asks
you to add private members to untyped KOOL.  Syntactically, you should
allow a new keyword, "private", to optionally precede member
declarations.  For example, "private var x=10, y=10;" or "private
method f(x,y) {...}".

There is no full agreement among programming language designers on
what the precise semantics of private members should be, with or
without types around, or whether private members should be allowed at
all in an OO language.  For example, the overall attitude in the
Smalltalk community is that private members should not be used or even
allowed (indeed, Smalltalk does not have them), because they work
against the OO philosophy.  Consequently, we will here make it clear
what the desired semantics of private members is in untyped KOOL.

Our high-level semantics of private members is the usual one: they can
be directly accessed only by members of the same class.  In untyped
KOOL, we keep the above semantics as general as possible, in that we
impose no apriori restriction on how private members are declared or
accessed.  For example, we allow a non-private method to be overridden
by a private method, and viceversa.  The only check we perform is a 
dynamic one, namely that a private member (field or method) can only
be accessed from code in the same class (but possibly in a different
object instance).  We let the program execute normally, including
dynamic method dispatch, and only check at access time whether the
accessed member is private and, if it is, then whether it was accessed
from the same class.

Note that our semantics above is controversial.  Specifically, the fact
that we allow to override private methods and do not treat private
method invocations differently, can lead to strange situations.  For
example, a class A may declare a private method f and a public method
g that invokes f, and a class B may extend A and override f with a
public method.  Now if we create an instance of class B and invoke g
on it, then the f called by g is the B's f, not A's, so the private
nature of the A's f has been somewhat lost.  We say "somewhat", because
A's f can still only be accessed by code that appears in A.  A similar
exercise for KOOL typed requires you to fix this problem, in that the
f called by A's g will always be A's f.

For simplicity, we assume that all members defined in a class, private
or public, are distinct.  Also, like before we assume that methods are
identified, for overriding purposes, only by their name (and not by
their result or arguments type).

The sample programs and their expected results should fully clarify
the desired semantics of private members in untyped KOOL.
