Miscellaneous notes about this program
--------------------------------------

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

About this implementation of the OO paradygm:
   It was meant to be a meta-implementation, ending by itself written
   in itself.


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

About the FUNPTR() macro:
   Here are the two first tries for the macro.

   #define FUNPTR(RetType,ParamType,ParamList,TypeName) \
   struct TypeName { RetType (*fun) ParamList ; ParamType param ; }

   #define FUNPTR(RetType,ParamType,a,b,c,d,e,f,g,h,i,j,k,l,m,\
                            n,o,p,q,r,s,t,u,v,w,x,y,z ) \
   struct TypeName { RetType (*fun) (ParamType a,b,c,d,e,f,g,h,i,j,k,l,m,\
                            n,o,p,q,r,s,t,u,v,w,x,y,z ) \
                     ParamType param ; }

    In the first try, TypeName was put in last position in expectation that it
   would be an optional parameter; but the preprocessor complains when the
   proper number of parameters is not used, even if gcc -E is correct.
   This was overridden by the use of two different macros, with or without
   name. What is more annoying is that the macro requires the user to ensure
   that the ParamType parameter is the first parameter in the ParamList list,
   which must be given between parentheses; and the preprocessor offers no
   means of ensuring it, or of extracting ParamType from ParamList.
   When I tried to give 26 parameters to the function, the preprocessor
   sends a comma (,) for every parameter, even missing, and the compiler
   interpreted the result as an error So the only solution was having a macro
   for each different number of parameters. I even thought about using C++
   templates, but they couldn't manage the fact that ParamType must be the
   type of the first parameter in the ParamList.
    This shitty preprocessor is not good for anything ! (but, well,
   there's a preprocessor, whereas most other languages don't provide
   any). What is needed is not just a preprocessor, but a full meta-language
   (for example, lisp is its own meta-language; but lisp is too high level a
   language, not adapted to time-critical applications); too often have I seen
   horrible makefiles with shell commands producing code, thus serving as
   a meta-language ! The only powerful enough meta-language I know for a
   low-level language is the TASM macroprocessor; unhappily, 386 asm has
   got a very heavy syntax and semantics (even lower-level than C !), doesn't
   have optimizing compilers, and isn't portable at all !!!

   I HATE THIS F...ING C LANGUAGE ! HOW CAN ANYONE USE IT AND BE SATISFIED ?

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

About the ErrorDescription structure:
-------------------------------------
 I first tried to initialize the Handler field with DefaultHandler being
a ErrorHandler constant, but it failed: the C language doesn't understand
such abstractions. Initialization, assignation and use of a variable have
different semantics.

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

About really Compile-time generic modules in F?cking C language
---------------------------------------------------------------
 * Convention:
 -------------
 o  The FooBar module will must use one of these two macros in parameter,
   for use in instance-local global names. Instance-independant information
   must be provided in separate .c and .h files.
     #define FooBar_Prefix(x)	fOObAR##x
     #define FooBar_Suffix(x)	x##fOObAR
   each global name declared in FooBar must use the choosen parameter. By
   convention, we'll choose the prefix convention.
 o   #define FooBar_Instance	fOObAR
   won't work, as concatenation is always done before expansion; this would
   lead to one caller definition per global object defined by the callee.
 o  There is quite a problem for recursive modules, that have to include
   themselves (with different parameters). They'll have to use a compile-time
   stack. The Meta-C.mcc file will provide such facilities, up to a
   predefined depth.
 o  My conclusion is that the C Preprocessor is NOT Turing equivalent, and can
   only simulate finite machines, and with only at an incredibly high
   cost: a linear cost in the number of states of the machine with a high
   coefficient in the best case, to a quadratic in the worst. The lambda is
   not part of the preprocessing output language; any injection of the
   language in itself is exponential.
   With an external file to assign unique identifiers, we can have a first
   order language (with integer functions only).


-----------------------------------------------------------------------------
Implement the structured Clad stack.
  each thread has its Clad stack.
