Fix GrapParser

[Duncan McGreggor]

Currently, GrapParser is useless: it converts graphs with strings and integers to graphs with grap.symbol objects (e.g., symbol.FunctionObject and symbol.NumberObject), however, it does not retain the relationships with object instantiation.

An example will make this more clear. Given the following graph for the expression "1 + 2":

g = Tree()
g.add_edge('+', 1)
g.add_edge('+', 2)

GrapParser will produce a tree graph with two *different* instances of FunctionObject('+') instead of just one. If the parser can accurately analyze the graph, only one FunctionObject('+') will be created for the example above. At which point, the GrapParser class will actually become useful.

[Duncan McGreggor (oubiwann)]

The GrapParser has been removed, so I will mark this as "won't fix". Here are the code comments that also got deleted, and demonstrated the uselessness of the class:

-# XXX The primary functionality offered by this class may very well be
-# completely flawed: it is useless to parse a bunch of edges with "naked"
-# operator strings (e.g., "+", "-"), as each FunctionObject instance will be
-# unique, even if it's not supposed to be. As such, grap graphs should probably
-# only be constructed in the following ways:
-# 1) manually, or
-# 2) very cleverly (possibly with a lisp parser)
-#
-# XXX The new graph walker class might be able to handle this properly...
-#
-# XXX Hrm, no... the more I think about this, the more I don't think it's
-# possible. A graph with lots of raw (string) '+' and '-' will be meaningless;
-# the edges will not retain the relationships because the names wouldn't be
-# unique. A graph that has appropriately unique (or not) nodes will have to be
-# built using the API. A graph parser will be necessary for converting
-# s-expressions to g-expressions, but not a raw graph to a symbol'ed graph.