TODO

   1 GMQCC is quite feature compleat.  But that doesn't address the fact that
   2 it can be improved.  This is a list of things that we'd like to support
   3 in the distant future.  When the time comes, we can just select a topic
   4 from here and open a ticket for it on the issue tracker.  But for the
   5 meantime, this is sort of a cultivating flat file database.
   6
   7 Optimizations:
   8     The following are optimizations that can be implemented after the
   9     transformation into static-single assignment (SSA).
  10
  11         Global Value Numbering:
  12             Eliminate redundancy by constructing a value graph of the source
  13             then determinging which values are computed by equivalent expressions.
  14             Simaler to Common Subexpression Elimination (CSE), however expressions
  15             are determined via underlying equivalnce, opposed to lexically identical
  16             expressions (CSE).
  17
  18         Spare Conditional Constant Propogation:
  19             Simultaneously remove dead code and propogates constants. This is
  20             not the same as indivial dead code elimination and constant propogation
  21             passes.  This is multipass.
  22
  23     The following are optimizations that can be implemented before the
  24     transformation into a binary (code generator).
  25
  26         Code factoring:
  27             The process of finding sequences of code that are identical,
  28             or can be parameterized or reordered to be identical.
  29             Which can be replaced with calls to a shared subroutine. To
  30             reduce duplicated code. (Size optimization)
  31
  32     The following are optimizations that can be implemented anywhere, ideally
  33     these are functional language optimizations.
  34
  35         Removing Recrusion:
  36             Tail recrusive algorithms can be converted to iteration, which
  37             does not have to have call overhead.
  38
  39
  40 Language Features:
  41     The following are language features that we'd like to see implemented in the
  42     future.
  43
  44     Enumerations:
  45         Like C
  46
  47     AST Macros:
  48         Macros with sanity.  Not textual subsitution.
  49
  50     Classes:
  51         Like C++, but minus the stupidity:
  52             - No type operator overloads
  53             - Keep operator overloading for basic operators though.
  54             - No inheritence
  55             - No virtuals / pure virtuals
  56             - Essentially "C structs but with operators" :)
  57
  58     Arrays:
  59         They're currently implemented, but support in the engine
  60         plus implicit bounds checks (and ability to turn the bounds
  61         checking off)
  62
  63     Exceptions:
  64         I feel like all languages suck at implementing this.  This would
  65         require support from the engine, but it would help catch bugs. We
  66         could make it fast using a neat method of "frame pointers".
  67
  68     Overloaded Functions:
  69         Ability to make individual functions with the same name, but take
  70         different amount of arguments or type of arguments.
  71
  72     Default Argument Subsitution:
  73         Ability to specify default values for arguments in functions.
  74         void foo(string bar, string baz="default");
  75         Supplying just one argument will expand the second argument to
  76         become "default", otherwise if two arguments are specified then
  77         the "default" string is overrode with what ever the user passes.
  78
  79     Character Type:
  80         A char type would be nice to have.  Essentially implemented as a
  81         string, we can both "get" and "set" indices inside strings with
  82         the help of builtin functions.
  83
  84         {
  85             string foo = "test";
  86             foo[0] = 'r';
  87
  88             print("it's time to ", foo);
  89         }
  90
  91     Array Accessor With C-Semantics:
  92         Also the abilit to use them as array accessors:
  93
  94         {
  95             float hugearray['Z'];
  96
  97             hugearray['a'] = 100.0f;
  98         }
  99
 100         Keep existing "pointer-like" semantics as well.  In C arrays
 101         simple work as pointers, a[1] -> *(a+1), or 1[a] -> *(1+a)
 102         so we should allow both forms of syntax.  As well as operand
 103         reversal.
 104
 105         {
 106             float h['Z'];
 107             *(h+'a') = 100;
 108             *('a'+h) = 'a'[h];
 109         }
 110
 111     FTEQCC Inline Assembly:
 112         This is still up for debate, mainly because a) it's syntax is
 113         just utter crap. b) If we do an assembler, it should be nice.
 114         we could provide a -std=fteqcc for the assembler itself :P
 115         just like the compiler; although I think that's just insane.
 116
 117         Please see Assembler below.
 118
 119     Namespaces:
 120         There is already a ticket open on this. They'd work just like C++
 121         identically even.
 122
 123 Standalone QCVM:
 124     The following are QCVM additions:
 125
 126         Proper ASM dissasembly:
 127             Proper dissasembly of compiled .dat files. Annotated if possible
 128             when -g (is used during compilation)
 129
 130         Debugging:
 131             A step-through debuger -d (with seperate compilation as well)
 132             Called -> qcdb  Optionally alias to qcvm -d :)
 133
 134             We should beable to see the assembly and source it matches to
 135             and the state of OFS_* and calls.
 136
 137 Testsuite:
 138     The followiung are things we'd like to see added to the testsuite
 139     in the distant future:
 140
 141     Multithreading:
 142         Chances are when we start adding more and more tests, executing
 143         them individually will be midly slow (even if that's a whole minute)
 144         It would be nice to add a -j paramater to allow multiple threads to
 145         be used and so we can execute many tests in parallel.
 146
 147     Interface:
 148         Ability to select individual tests, or set paramaters manually
 149         opposed to using the static task-template files. (A method to
 150         override them rather).
 151
 152
 153 Assembler:
 154     Possibly support for a future assembler for QCASM.  But we're not
 155     entierly sure if it makes sense.
 156
 157