is a predicate for applications which consist only of Tcl code (no C extensions or packages).
PRO:
CON:
In general, it is sensible to start coding an app in pure Tcl, and replace only those parts (if any) with C code that are just too slow. (But CPUs are picking up speed considerably faster than C coders ;-) (RS)
LV writes: So does pure-tcl mean that the application does not use Tk, given that Tk is a C extension? Seems technically that would be the case.
There are several subtleties and even polysemies to this term. Sometimes we say, "pure Tcl" in contrast to Tk; thus the 2.0 version of sockspy is useful for certain contexts because it can be run as "pure Tcl" without the requirement for a Tk interpreter.
Sometimes one uses "pure Tcl" to exclude not only extensions, but also exec. This partially invalidates the more general conclusion that pure Tcl implementations are more transparent; for example, in a pedagogic situation with Unix adepts, I might choose to write
set content [exec cat $file]
rather than
set fp [open $file]
set content [read $fp]
close $fp
Is an example "pure Tcl" if it uses tcllib (a bundle of extensions, each of which are themselves pure Tcl)? Our community seems to answer both "yes" and "no", at different times, simply by the evidence of the way it speaks.
While preferring a Tcl extension over a compiled extension is an admirable one - particularly if the reason is to make it easier for the user to modify, or easier to deploy (no need to worry about what, if any, compiler is on th eother size), at times people go too far along this line.
The question sometimes is whether it really is better for someone to write some code, from scratch, in Tcl to try to avoid the issues, rather than use the established work of someone else who happened to choose a language that requires compilation. It does mean at times that , beginning with untested code, one has to begin again from the debugging steps to prove the reliability of the code.