This document collects some notes about the design of Numba.   The design is a 
work-in progress and will evolve as the use-cases emerge.  I am not a compiler expert and I'm learning as I go.   Hopefully, later contributors will provide improved solutions. 

Each use-case will be written with a separate class.  Then, the use-cases will be merged into
a single Translator class with possible sub-classes

The plan: 

    * Create a Translate object that assumes input types and output types of a function and
      convert this object to a function inside an LLVM module. 

    * For now, there is a different translate object for each "use-case" of the function:
      	  * Ufunc creation
	  * Kernel Func creation
	  * Loops over Arrays
	  * Transformations on inputs

     * Decorators will transform functions that should be compiled into generic functions 
        that dispatch on input types to either pre-compiled code if it can handle the input types
	or the original code. 
	Input types to be handled: 
	      * strings, int, float, numpy arrays
	      * later maybe lists and tuples of the same type

      * For ufuncs, the decorator will allow specification of what fundamental loops to create. 
        This will be similar for kernel-func loops. 

Right now, the basic idea is to use the llvm-py interface to the LLVM API to produce LLVM-code from the Python byte-code.  Right now, I'm faking having knowledge of the input an output of the function being run.   I will have to fix this either by calling the function once and getting the output or allowing specification of the types in the decorator or doing some kind of type-inference the first time through the byte-code and then doing another pass through to actually generate the LLVM calls.  

I think I will start with type-specification in the decorator and then work to see how much of that can be removed later. 

Then, I create a function-pointer using LLVM's execution engine and pass that function pointer into C where the C-API for creating Ufuncs is used to create the ufunc object.  

I should pass in the doc-string of the ufunc from the doc-string of the function object as well at this point. 




