November 2001

CriTcl is pretty exciting stuff.  It has radically changed the way I mix
Tcl and C code these days.  It opens up a whole range of options for the
future, both as development tool and for greatly simplifying deployment.

Below is a list of things which have come to mind or have been suggested
so far.  If you have more suggestions or comments or, better still, would
like to participate in the evolution of this package in any way, please
get in touch - or create a page about your plans/work on the Tcl'ers Wiki
with a reference to it in http://mini.net/tcl/2516.html - I'll do my best
to accommodate you and to adapt/integrate things where possible.

-- Jean-Claude Wippler <jcw@equi4.com>


DEVELOPMENT USES:

- the most obvious one: surgical replacement of hot spots with C code
- support more platforms, more compilers, verify with all Tcl's >= 8.1
- CriTcl as test bench for trying out new C features to be added to Tcl
- hide sensitive keys or proprietary algorithms in C code
- add package to report compiler's type width/alignment choices
- use C code to poke at Tcl's internals


ENHANCED DEPLOYMENT:

- automatically create a custom tclsh or wish (solved: critbind)
- automatically wrap scripts and generated libs for use elsewhere
  (could be a tar.gz, or a scripted doc for TclKit, or in *Wrap-style)
- combination of above two: auto-generate standalone application


WEAKNESSES TO FIX:

- make automatic recompilation work when "outdir" is set
- restore outdir after each package (e.g. typcl during pkgtest)
- allow "define; call; define; call" to work, also interactively


RADICAL IDEAS:

- redo parts of the Tcl core with CriTcl and ultimately replace them
- deploy major extensions with CriTcl (and why not, ehm... Tk?)
- parse C headers and generate bindings on-the-fly (SWIG-like)
  (gcc's -dD, -dM, and -dN can help with the extraction)
- parse std include files to create a very rich interface to the OS
- package for access to machine code (GNU Lightning comes to mind)