Updated 2014-02-04 01:51:10 by AK ▲

CriTcl Extension edit

Areas The project areas
Good if student knows C, Tcl
Priority Medium
Difficulty Easy, Medium, Hard (specific to detailed project)
Benefits to the student Working the interface between C and a scripting language.
Working with dynamic code generation.
Benefits to Tcl Extended gluing abilities, supporting machinery towards
core work on optimization and performance through JIT
Mentor Andreas Kupries

Project Description edit

The Critcl package and application is a system for embedding C code into Tcl. It was recently refurbished and polished to be useful again after a longer period of inactivity.

There are quite a number of projects which can be done with the package itself, and around it. Examples:

  1. The utility/generator package critcl::class helps with the creation of bindings which looks like objects and classes at the script level. The generated C code is portable across all versions of the Tcl core. The disadvantage of that is that extending such classes at the Tcl level requires a facade class written in a Tcl object extension, like snit, or TclOO. On the other hand, the TclOO object system exposes a public API at C level which allows the mixing of C-level and Tcl-level methods in a single class. An example of the use of this C API is [1]. The project would be to create a variant of critcl::class which generates C code based on TclOO and its C API. Allowing the extension of the generated classes with Tcl methods the results would be restricted to Tcl 8.5 and higher.
  2. The project has more utility/generator packages than just critcl::class, which encapsulate common code patterns needed in Tcl/C bindings behind highlevel and simple APIs, for example management of literal pools, conversion from enums to strings, bit sets to sets of strings, etc. The project, more open-ended than the first, would be to collect one or more additional patterns found in existing C extensions to Tcl, and write generator packages for them which hide the complexity from the developer of new bindings.
  3. While refurbishment spoken of above did clean up the internals of critcl to some degree there are still entanglements, especially in the area of access to C compiler and linker. The project would be to refactor the internals to fully abstract access to compilation, linking, and loading of embedded C code from the highlevel machinery collecting that C code and then, as proof of the concept, create a new backend binding critcl to the tcc or llvm frameworks for in-memory compilers. There is a boot-strapping process here, as the binding to these C libraries should be written in CriTcl, compiled using the currently existing backend, making it then available as new backend. Such backends for in-memory compiler framework could then revitalize critcl's compile & run mode for on-the-fly use of embedded C code, opening up the way to more dynamic code generation and JIT. The current need for an installed compiler like gcc has given the package mode of critcl dominance, where Critcl code is pre-built into distributable packages.
  4. Create a set of packages for the generation of bytecode machines (multiple implementation variants) and associated (dis)assemblers from a machine specification. This can be linked into experiments with generating the (code of the) Tcl core bytecode machine, and also into the direction of Parsers and Compilers, with bytecode based parsing machines, regex matchers, and the like.

References edit

See also LUA lpeg.

Comments & Discussion edit

Some comments here, and discussion of the idea

GSoCCategory Critcl