Brandon Stewart
2015 June - July, October


*This file includes my main contributions/thoughts towards LISA development.
For a more explicit details, check lisa-changelist.txt, and grail-changes.txt.

******************Week 10***************************

October 12 - 16 (Lisa-0.2.2)

  Fixed problem with functions in if statements.
  Fixed issues with "next" statements.
  Began work on fixing memory leaks on the C++ side.


******************Week 9****************************

--October--

October 5 - 8 (Lisa-0.2.1)

  Allowed generators to use variable ints as parameters.



******************Week 8****************************

--final week (SUMMER)--

July 31 (Lisa-0.2.0)

  Complete.

July 27 (Lisa-0.1.7)

  I've made significant progress in implementing JSON into LISA.  Most things are functional,
 but due to the previously hard coded values in while/generator statements, not everything
 is working 100%.

  All that remains:

    - Change how the json is loaded in.  I don't like how I separated everything at the moment.
    The json files under src/data/not_used seem to have a better format. Each namespace should
    have one json file.

    - fix the generating/while statements, among other hard coded values.  The generated
    "heap#" objects are also causing some trouble.

    - more testing overall, once I fix the previous point.

    - clean up the code.  I still have a bunch of stuff I used for debugging purposes.

  Compiling bin/TEST.ls will show the major changes, along with the problems with generator,
  while, and heap#.  The current generated.cc is the current TEST.ls compiled.




******************Week 7****************************

July *20* - 23

  I implemented the early stages of loading symbols using JSON (using nxjson).

      This is going to take much more work, since LISA's current structure does not
    support my idea very well.


******************Week 6****************************


July 13, 14

  I added a simple stack data structure under src/stack.*.

	  This is useful when more than one backend is used, and the "using ..."
	statement is utilized for both.

  I've put modifying bin/lib/lisa/minigrail-adapter on hold.  All it needs
is the equivalent miniGrail functions.  Considering this, it is much more
important to modify the LISA source, and just have minigrail-adapter print
messages to check if the function is being called correctly.



******************Week 5****************************


  bin/lib/lisa has been restructured:

	  There are two new directories: grail-adapter and minigrail-adapter.
	grail-adapter has all the old files in bin/lib/lisa except lisastd.*.
	minigrail-adapter is similar to grail-adapter, but uses its specific
	theory objects (such as mGDFA), as opposed to Grail's (fm<char>).


	  minigrail-adapter still needs work.  This is taking longer than
	expected due to miniGrail not having everything Grail has.  I am also
	checking the functions in miniGrail and testing them to ensure that
	using them in bin/lib/lisa/minigrail-adapter performs the same task
	as the grail-adapter.  Once this is finished, it also needs to be
	implemented in the LISA src code.


	  Both new directories have had their classes wrapped in the appropriate
	namespace.


  I implemented the early stages of the "using ..." keyword in LISA.  With
Grail finally being in a namespace, this is currently the only way to compile
this version of LISA.  As it is, the functions (such as DFA::reverse) cannot
have a namespace:

	LISA example:

	grail::dfa myDFA;
	...
	myDFA = grail::reverse(myDFA); //currently not implemented


	  Since DFA::reverse, and the other functions, have been wrapped in
	namespace Grail, it will not compile unless "using grail;" is declared.



******************Week 4****************************


June 29, 30,
July  2,  3

  I removed all problematic "using ..." statements in Grail.  Grail no
longer has global namespace pollution.

	  The problem it solves:  Lets say grail, or whatever includes grail, has
	a "min" function.  If "using namespace std" were used, it could collide
	with std's min function.

  -----------------------------------------------------

  I have wrapped Grail in namespace "grail".  This will be useful when using
two or more backends.

  I have wrapped miniGrail in namespace "minigrail".


******************Week 3****************************

June 22, 23

  I implemented the early stages of namespaces in LISA.  Currently,
(namespace)::(keyword) works, but doesn't translate to usable C++ code.
 This is due to Grail not being in a namespace yet.

  -----------------------------------------------------

  Wrapping all Grail code in "namespace grail{...};" may not be
the best approach.  I am uncertain how often Grail gets updated,
but an update could require re-writing "namespace grail{...};" in
 all the classes.  If Grail is no longer getting updated this is a
non-issue.

  Grail also has a lot of files scattered around; forgetting to put
one in a namespace could cause headaches in the future.






******************Week 2*****************************

June 19

- Using multiple backends at once: every backend would require its own
namespace, or some sort of "wrapper" class to avoid conflicts.

Example:
	using grail;
	using miniGrail;
	...
	dfa A;

Assuming LISA has classes to utilize Grail and miniGrail DFA's,
is the above dfa from Grail or miniGrail?


Currently, under bin/lib/lisa, only Grail can be used.
These classes utilize Grail's implementation, whereas miniGrail
requires using its own theory objects (mGDFA/ mGNFA, as opposed to fm<>).

To solve this:
-Do not allow the "using" (or equivalent) keyword in LISA.
This will force grail:: and miniGrail:: to be used.

Or:

-Allow the last "using" statement to have priority.
This means that the example above would be the DFA from miniGrail.
Perhaps a warning can be displayed to the user that says that there
is a conflict.

Or:

-Fail to compile.  Tell the user that only one backend can use the
"using" statement at a time.

---------------------------------------------------------

For the time being, "using" is not a concern.

First, miniGrail and Grail need to have namespaces.  The LISA
compiler will need to know about the new syntax of
(namespace)::(some_obj).  Then, it will need a way to use
miniGrail similarly to how it already interfaces with Grail.
The structure in bin/lib/lisa/ will need to be changed.

Something similar to:

bin/lib/lisa/grail-interface/(current bin/lib/lisa/ files)
bin/lib/lisa/miniGrail-interface/
bin/lib/lisa/(x)-interface/

could work.

-------------------------------------------------------

Writing a script to trivialize adding new backends would be welcome.
Something that will add the new namespace to the parser, lexical
analyzer, intermediate code generator, and whatever else that needs
it would vastly increase the utility of LISA.

I'll need to think about this more.
