[Richard Suchenwirth] 2002-05-17 - In [Streams] I wrote: "Procs are data too, in some sense..." To clarify this, [proc]s ''are'' data, with the following properties: * Procs are global (visible from any call stack depth without need for declaration) * Procs are a structure consisting of a list and a string When a proc's name is evaluated in command position, the list elements are matched with the words following the name, to make a local stack frame, in which the string is then evaluated, and the result of that evaluation is [return]ed to the caller. But Tcl procs are more than C functions (where the compiler would complain at any breach of C syntax). Tcl procs are compiled (and similar problems may show up at that time) when first called. So what if a proc is never called? Philosophically, it seems to miss its destination, but then again, we can very well define and use a proc without ever calling it. Imagine we want to build up a database of poems. Many ways are possible for doing this, including - with procs! Consider this code: proc SillyPoem {author R.Suchenwirth written 2002-05-17} { Hey Doc this isn't a real proc should you ever call it you'll get a shock... } Perfectly legal Tcl, the interpreter doesn't complain. Calling ''SillyPoem'' of course leads to a number of error messages, ranging from no value given for parameter "author" to "SillyPoem" to invalid command name "Hey" But this poem wasn't intended to be called anyway. Rather, from any part of a Tcl program, you can access the two structure elements by info args SillyPoem ;# returns the list info body SillyPoem ;# returns the string That the ''args'' are indeed a list is evident when you put additional spaces between words - info args will always join the args with exactly one space. On the other hand, ''[info] body'' returns the input string exactly, with spaces, newlines and all, so the body is a true string. The list might for instance be used for property-value pairs (like in the example), the string is, well, just a string, and we can store just about everything in it. Changing a proc's "values" is just slightly more convolved, as all three arguments must be present in a call to [proc], but you can get them from where they came: proc SillyPoem {author W.Shakespeare written 1567} [info body SillyPoem] proc SillyPoem [info args SillyPoem] {yes, just silly} Again, this is a Tcl trivium for which I can imagine no practical use, but that's how philosophy goes - just thinking of something... ---- [TV] Don't forget the defaults for the arguments... [Bwise] proc_window does this stuff reasonably well, thought I think it adds one newline too many to end of file. Native version insensitive tcl code, I think. [JMN] 2004-05-02 Good Grief TV, Yet another tendrilous interjection that looks suspiciously like an attempt to make your Bwise WalledGarden appear more integrated with the rest of the wiki... You've been mildly called to account by at least one other wikizen regarding relevance - and it's a testimony to the friendly nature of the Tcl community that relevance and coherence are not 'policed' as such. I much prefer the more or less self-moderated state of affairs we currently have on the wiki, and I don't claim to speak for others in this regard - but please Theo, keep the pet-project evangelism down a bit. I realize this particular page was last edited a while ago, but it's just one of a few examples of apparent Bwise name-dropping such as [button], [exec], [introspection], [idiom], [label selection], [Good Looking Tk] Don't feel I don't value your contributions to the wiki - I think the electrical-engineering perspective on Tcl is interesting; it's just that I don't feel your Bwise extension has as big a mindshare in Tcl as your extensive wiki-authoring might suggest. (I'd hazard a guess, in part due to your choice of license and meandering style of prose) Feel free to move/remove this commentary at some point TV(and/or wikignomes) - I just wanted to register a friendly protest. ---- Afterthought: if you let the names of such "data procs" start with a # sign, you can be pretty sure that they won't be called by accident (except if escaped deliberately).. % proc # {} {puts hash} % # this is treated as a comment % \# ;# you'd have to escape the hash sign to call it: hash ---- [MS] notes that you can even make it a real executable that returns the saved data: proc SillyPoem2 {} { return [join [lrange [split [info body SillyPoem2] \n] 2 end] \n] - Silly Poem Revisited - by R.Suchenwirth and M. Sofer written 2004-05-25 Hey Doc this is a real proc should you ever call it you'll get a shock... } You can also write a builder for such procs proc buildDataProc {name str} { set basicBody [string map [list %NAME $name] { return [join [lrange [split [info body %NAME] \n] 2 end] \n] }] proc $name {} ${basicBody}$str } Note that the data string ''str'' cannot contain unmatched ", {, },[[ or ]] ... and now I notice I'm being silly ... proc buildDataProc {name str} { proc name {} "return \"$str\"" } ... I think you meant proc buildDataProc {name str} { proc $name {} "return \"$str\"" } Without the $name you just create proc named 'name'. ---- I'd like to see procs actually become data structures. That is, invoking proc creates a dictionary with key/value pairs for body, arglist, name (optional if it's a lambda), documenation, user defined properties, etc. Widget properties are just additional properties associated with the command. ---- [Procs as objects] - [Arts and crafts of Tcl-Tk programming] - [Category Data Structure]