
Brandon Stewart
June/July 2015


********************************************************************
* Overall what needs to be added
********************************************************************

- The functions/objects need to be accessable in C++.  This will involve including
the backend in bin/generated.cc, or more specifically, bin/lib/lisa/include.h.

- The backend should be in a namespace.

- Optionally, an adapter can be made to make interfacing with a new backend simpler.

- Now, the functions/objects need to be useable in Lisa.  Make a json file in
src/data/symbols with a similar style to other backends.



********************************************************************
* Implementation details
********************************************************************




- If an adapter is going to be made, follow how grail was implemented.  Each type
that Lisa supports (dfa, nfa, re) has their own class.  These classes contain the
functions that will be used in Lisa.  This also lets these particular functions get wrapped
in a namespace easily.

	  There are also classes for reading/writing theory objects to files.  In addition to
	this, the generator class allows FA to be easily made.




- Each json file is currently split into four parts: namespace, operator, keyword, function.
The symbols under these subsections are in alphabetical order, and it is recommended that
all backends attempt to be as well.

	* namespace: contains information about what this namespaces symbol node in the symbol
	table will hold:

		value_name: is what is written in Lisa source files to access the backend.
		value:		what value_name becomes when it is translated to C++.
		token_type: enum,  TOKENTYPE_NAMESPACE is 6
		node_type:  this is node_type null, since this does not contain a type.


	* operators: allows operators such as "+=", and other symbols like "{" to be loaded.
	Adding new symbols does not allow them to be used, as each symbol has a particular use.
	In other words, these are tightly coupled with the program, and would have to be
	written in the Lisa src/ files.

	  These will probably only be included in the standard.json file, unless some backend
	wants their own special syntax.

		token_type: these are all enum TOKENTYPE_SYMBOL, which is 5
			operators : [
			  value_name: what the operator/symbol is in Lisa source files
			  node_type:  these should all be 0 (nodetype_null), because they have no type
			]


	* keyword: allows keywords such as dfa, nfa, bool to be used.  Adding usable keywords is
	very simple. All that needs to be done is to add another block to the "keywords" json
	array, as long as the new keyword's type exists in nodetype

		token_type: these are all enum TOKENTYPE_KEYWORD, which is 3
			operators : [
			  value_name: what the keyword is in Lisa source files
			  value: 	  what will be written in c++, if its one of the nodetype's Lisa supports
			  node_type:  these will differ depending on the type of the keyword.
			]


	* function: this allows functions to be added into Lisa.  Like keywords, adding functions
	very simple.  All that needs to be done is adding a new block to the "functions" json array.


		token_type: these are all enum TOKENTYPE_PREDEFINED_FUNCTION, which is 4
			operators : [
			  value_name: 		what the function is in Lisa source files
			  value: 	  		what the function is in c++ (minus namespace)
			  node_type:  		these will differ depending on the type the function returns.
			  returns_pointer:  is "true" if the function returns a pointer
			  parameters:		contains a list of nodetype that defines the parameters' types.
							  Example) function(string, dfa) will have the parameters [4, 1]
			]
