Poor Yorick


Nathan Coulter
vim , emacs
t k dot t c l dot w i k i at p o o r y o r i c k dot c o m
wikipedia user page
Tcl theme song nominee
Who Do You Want To Be ? -- get your shimmer on !
"If something is worth doing , it's worth doing right ."
"Hang the sense of it all and keep yourself occupied ."
return -level 0 {*}[yieldto return -level 0]



Tcl Events Attended

Eighteenth Annual Tcl/Tk Conference (2011)
Nineteenth Annual Tcl/Tk Conference (2012)
Twentieth Annual Tcl/Tk Conference (2013)
Twenty-first Annual Tcl/Tk Conference (2014)
13th European Tcl/Tk Users Meeting 2015
Twenty-second Annual Tcl/Tk Conference (2015)
14th European Tcl/Tk Users Meeting 2016
Twenty-third Annual Tcl/Tk Conference (2016)
15th European Tcl/Tk Users Meeting 2017
Twenty-fourth Annual Tcl/Tk Conference (2017)
16th European Tcl/Tk Users Meeting 2018
Twenty-fifth Annual Tcl/Tk Conference (2018)


What's up with the weird punctuation on this page ?
I just like the way it looks . It seems more balanced to me . Feng Shui and all that jazz .

Tcl Thoughts

Tcl started off with an ingeniously simple and regular syntax , and has consistently followed through with a knack for exposing just the right foundational capabilities without overbuilding the language . Tcl attracts engineering types who already know how to build things , and provides a helpful toolset rather than a framework one would have to work around . If Guido has a time machine , then the Tcl Core Team has a timeless machine .


Here are my guidelines for editing this wiki . I'm not sure how representative it is of the expectations and guidelines of other editors , so feel free to edit , annotate , and express your opinion and make suggestions regarding these guidelines , particularly if they've caused you any discomfort as an editor yourself .

  • This wiki is a resource for the community , and all content is subject to editing by anyone .
  • This wiki aims to be comprehensive , but it does not aim to be just an encyclopedia .
  • This wiki is not an official reference .
  • This wiki is not a source code management system .
  • It isn't necessary to have a Ph.D. in computer science to contribute .
  • No individual owns any page , not even their namesake page . (MJ: it's true)
  • A page can be as trivial or as complex as one desires .
  • There is a lot of room on this wiki , and there is room for content of varying quality . More frequently-visited pages are held to a higher standard . Content not meeting that standard may be moved off to less-frequented page .
  • This wiki tries to find a balance between the single coherent narrative of consensus and the chaos of discussion and individual presentation . The primary strategy to achieve this is to keep each page true to the measure of its creation , often by migrating some content to other pages . Organization and reorganization are constant activities and part of every contributor's duty .
  • Like ethernet , a wiki is intrinsically contention-based . A contributor should be ready and willing to take the time necessary to defend their position .
  • Collaborative editing can require extreme patience and indulgence . A contributor should meet unwelcome edits with a good nature and a willingness to engage in the game . It's almost always best to resist the temptation to take offense at other contributors . There is usually something to be learned , even from the conversation with the jerk that's insulting your mother , kicking your dog , and questioning your sexuality .
  • Clever/smart content is prized . A dumb/lazy contribution will be called out . A contributor may abruptly be pointed to references on how to do things the smart way . This is an opportunity to avoid the temptation to take offense , to think about what the smart way might be , and improve . Being smart is just a matter of practice .
  • It is never necessary to ask for permission to make an edit .
  • It is not necessary use external side channels to get approval or build consensus in advance for controversial edits . The wiki is the side channel , and consensus can be hashed out right here on its pages . However , discussions may be moved off to another page .
  • In the case of an edit conflict , a contributor should attempt to explain their position and rationale – again and again and again , and also to rethink their position – again and again and again .
  • When there is a succession of alternating edits representing competing viewpoints , to avoid falling into a rut of disagreement each edit should provide some new information or offer some new non-superficial variation of a previous edit . The idea is to keep the content and perspectives evolving . In many cases , a permutation on an idea is a sufficient alternative to direct conversation , but in other cases , it isn't .
  • Contributors are welcome to make a mess while they play , and even more welcome to put their toys back on the shelves when they are done .
  • This wiki is a good place to chat with other Tclers .
  • This wiki may contain content that makes you look stupid to your boss and coworkers .
  • This wiki is a good place to contribute code written under the influence of hallucinogenic substances .
  • Personality and flair are welcome , but are no substitute for quality content .
  • Signal-to-noise ratio is perhaps the top priority for all content.
  • Any topic even remotely-related to Tcl is fair game . Sometimes just being a Tcler , and having some other interest , is sufficient . That said , the signal-to-noise ratio should remain high . Every contribution should add value . If it doesn't , it might be deleted in short order .
  • The wiki is a teaching tool . Beginning Tclers are encouraged to ask questions and even to make changes to established content if they think they can improve it . If they are wrong , more experienced Tclers will take the opportunity and time to provide the requisite explanations .
  • A contributor who is right , and gets angry because another contributor is wrong , might as well go off and maintain their own website , as they are bound to be disappointed here .
  • This wiki needs a greater diversity of editors . If you are a child , teenager , retiree , or otherwise total newbie to programming , or know someone who is and might want to take up a new hobby , please encourage them to start learning Tcl and contributing to this wiki !

Pages Authored

A Message User Agent
Originally based on A little NNTP reader , but undergoing continuous rewrite at the moment .
The Anatomy of an Object System
A walk-through of the design of an object system similar to ycl shelf .
Android SDK
How to make an image of a block device in an android system via adb .
Asynchronous Script Evaluation via Coroutines and Channels
A building block for distributed systems .
Contributed wordparts , exprlex , and funclex .
One of my early Tcl scripts .
Creating an Invalid Tcl_Obj via SQLite
Because SQLite doesn't encode a blob into the database encoding when casting to text , it is possible to create a malformed Tcl_Obj with just a Tcl script .
Improved description of intermediate and leaf nodes . Removed inaccurate information and described the alternatives for storing key-value pairs .
Threaded asynchronous pipelined backpressure-mediated pipelined death stations .
deep dict
A deep list in which each structured value is itself a deep dictionary .
deep list
A standard Tcl list in which each single value is encoded as a list containing only one item , and each sequence of values is a list containing more than one item . This makes it possible to differentiate e.g. , the single value one two three from a list containing the values one , two , and three .
Every Word is a Constructor
An argument for typed values .
Execute in Parallel and Wait
Execute multiple processes which run in parallel , and wait for them to complete .
Expect: Mediating an Interaction
Monitor user input and program output , making sure they don't say "Ni!" .
Expect: Prompt Detection
An attempt to automatically detect the prompt of a program spawned with Expect .
for in
A drop-in replacement for for that also accepts with iterators .
How to Write Quality Documentation
A companion to Tips for Writing Quality Software .
A small utility to create a pdf document from a bunch of images . Uses pdf4tcl .
inter-coroutine return
How cooperating coroutines can operate as a virtual call stack .
A small but complete(ish ?) macro system that leverages tailcall .
Alexandre Ferrieux's implementation of TIP 424 , Improving exec , rolled into its own package .
Like proc except that the body is a list of lists and no string representation of the body is generated .
Like switch , but each pattern is a list of patterns to match against the item in string at the corresponding position . All switch options are supported .
main script
How to determine whether a script is the main script of an interpreter .
my oh my
A response to a question by jbr in Ask, and it shall be given # 11 .
Nested eXtensible heterogeneous data Structures .
Playing newLISP
Procedures that modify themselves while they are being evaluated .
A drop-in replacement for proc that evaluates one command of a procedure body at at time , and a hook to inspect and manipulate the command before it is evaluated , and another to react to return conditions of the evaluation .
proc alias
The details of creating an alias for a procedure while avoiding the drawbacks of interp alias .
pure value
Pure values are values whose string representation has not been generated .
Regular Expressions Match Requirements
A set of expectations for regular expressions .
2022-05-08 , added initial description of the language .
Scripted List
Avoid backslash in multi-line lists while still retaining variable and command substitution , add comments into the list a-la Unix shells .
scripted templates
A Template and Macro processing/macro system based on scripted list .
simulating daily temperatures
A demo that simulates daily temperatures based on empirical data, and displays them using plotchart.
sneaky message passing
Out-of-band channels for passing data to components .
Give a routine a namespace to play in .
Tcl Minimal Escaping Style
An escaping style that hews closely to the functional description of braces and quotations in the Tcl language specification , not using quotations when braces would suffice , and not using braces unless some backslash substitution would otherwise be necessary .
Tcl Rules Redux
A restatement of the Tcl Rules that articulates the syntax of lists and defines scripts in terms of lists .
thread: -eventmark and send -async
An interaction in the thread package that stymied me over the course of two frenzied weeks until I understood what was going on .
An xeyes clone .
A Tcl-based alternative to JSON , HUDDLE , XML , etc .
My personal toolbox .
ycl coro relay
A small but complete system for communication between cooperating asynchronous coroutines .
ycl shelf
A simple yet effective prototype-based object system .

Edits to Other Pages

Replaced @memoize with an implementation that doesn't require an external variable , and is careful not to generate the string representation of its memory .
Converted program to event-driven style . Added some features and controls .
3D Maze
Modified code to not use update .
3D polyhedra with simple tk canvas
Modified code to avoid update .
A balance toy
Modified code to not use update .
A Graph plotter
Minor improvements to functionality and visual elements .
A Hypertext Help System
Trivial modification to not use update .
BNF for Tcl
Contributed to the EBNF description of the rules.
Added description of elision of call to empty procedures .
Characters, glyphs, code-points, and byte-sequences
Includes a link to What's the difference between a character, a code point, a glyph and a grapheme? .
Colliding balls
Fixed a bug where the loop in checkForCollision became infinite if the velocity was set too high .
commands pipe
Contributed a variant of pipe .
Modified code to not use update and vwait .
Coroutine cancellability, {2022 03 24}
Provided an example of a coroutine interface that handles both channel events and requests to end the coroutine.
Added an example where one package can import a C function exported by another package .
do...until in Tcl
Contributed a variant that uses tailcall .
Contributed the Octalogue .
Elevator simulation
Removed update idletasks .
Ensemble extend
Provided the implementation of extend that wraps an existing ensemble of routines , and where extension routines are organized into their own namespaces .
exec quotes problem
Investigated the phenomenon and rewrote the page .
Contributed the section entitled , "A Logical Conundrum" .
Flag signalling
Minor modification to not use update .
Functional imaging
Removed update , various changes to the user interface . Added object system to turn it into a widget that can be instantiated multiple times . Consolidated contributed code examples into one script .
Functional Imaging with a High-Capacity GUI
Change to the design of the system to fix existing issues .
Added a namespace and a test suite . Made generated code more robust by encapsulating interpolated values in list format .
Gear Animation
Removed update .
Graphs: BFS an DFS animated demo
Removed update .
Graphs: Dijkstra animated demo
Removed update .
Added section regarding how to modify GRIDPLUS2 so that it properly handles newlines that are not command delimiters in a layout.
How to embed Tcl in C applications
Added an example of using the stubs mechanism on posix systems to initialize Tcl , and another example of accessing the TclOO C interface when embedding Tcl .
Jittering toplevel
Removed update , added jitter parameter .
Moon Lander
Removed update , minor usability improvements .
More model railroading
Removed update .
Move an item on a Canvas Widget in a Straight Line (animated)
Removed update idletasks .
owh - a fileless tclsh
Fixed what looked like a bug: With the default split behaviour there was an error on an input line that wasn't a list .
Particle System
Removed update .
Playing with bits
Wide'ified the original code by RS .
Rain Storm - Take 2
Removed update .
Regular Expressions
Lots of touch-up .
Elaborated on the tailcall-optimizing call_eproc of Lars H .
Serial summing
Updated the system to use apply and tailcall .
Added examples illustrating the various EIAS violations of SQLite .
Replaced Larry Smith's Code with a rewrite that avoids proliferation of global variables by using stacks and indexes in namespace dictionaries instead .
Stubs - Another explanation
Revised the description of the stubs mechanism .
Added section on generating scripts and lists . Reworked description and other content .
TIP #431 Discussion
The issue of file mkdir behaving like Unix mkdir -p , and having no analogue to just mkdir .
Replaced update with coroutine .
Tool Protocol Language
Provided a more straight-forward example of using Tcl script format for passing messages .
Removed update .
Removed update .
{2022 03 25} Described the pecularities of using a transformer on a standard channel.
Added a description of a format for a value that represents a tree .
Described the proper use of attributes in tags as data about the document itself rather than as data about the subject of the document .
How to implement uplevel with yieldTo .
Vogel spiral
Started editing code to remove update from loops , but then it turned into a project to practice the art of programming in Tk . Any tips and/or productive modifications to the code are welcome ! This revision runs noticeably faster than the previous one , probably due to changes that take better advantage of byte compilation . It also illustrates a method for distinguishing true key events from auto-repeated ones , which is used to make the accelerating spinbox work with arrow keys . See revision 4 of this page for the previous version .

Other Tcl Project Activity

(sqlite) Tcl bytearray woes
Diagnosed and reported. [set v ""] = bytearray object? , comp.lang.tcl, 2005-06-21, is an earlier report of the same issue.
(tcllib) add end-of-line signaling to tcl::chan::halfpipe , {2022 01 25}
(tcllib) make coroutine::util gets/read more efficient, and also restore any existing handler when finished , {2022 01 18}
(thread) thread::errorproc is called twice for one error, once for "worker" and once for "main" thread , {2021 11 10}
Discovered and reported.
(thread) interp bgerror is ignored in thread, error sent to other interp instead , {2021 11 10}
Discovered and reported.
(sqlite) segmentation fault when closing a database from within a transaction , sqlite, 2021-09-14
Discovered and reported . Subsequently fixed by Dan Kennedy.
(tohil) Tohil issue 53, error {No module named 'tohil' (unable to import tohil module to python interpreter) , {2021 08 12}
Reported, diagnosed, and fixed in b5cebdf4f252a6ed .
(tohil) Tohil issue 52, package require fails after package forget , {2021 08 11}
Reported and diagnosed.
(tohil) (sqlite) conversion of literal values, or lack thereof , {2021 06 04}
Inconsistent conversion of string values to numeric.
(tcllib) testutilities, remove sensitivity to directory a test is invoked from , 2021-04-14
Makes it easier to run a test without using sak.
sqlite null character sorts greater than 0x7f and less than 0x80 {2020 08 01}
Discovered and reported .
sqlite Tcl coroutine , db eval ... script` , yield, segmentation fault , {2020 04 09}
Discovered , reported, and diagnosed.
Added support for TIFF images with group-4 compression .
tcllib: Isolate the evaluation of each .test file
A response to a test failure that arose from the interaction of two <code>.test</code> files .
(tcllib) mime package: rewrite
Uses temporary files and channels in order to keep the memory footprint low in all cases . Use a command instead of a token as a handle for a message . For header values , add support for parameters that are not key/value pairs . For cookies , add the HttpOnly parameter and make it the default .
(tcllib) mime package: new API
Offers the ability to read in messages from a channel , more consistent and straightforward manipulation of message headers , and more flexibility for use as a general Internet Message library . See also commit 37008172d910 .
(tcllib) Namespace resolution for relative namespaces in namespacex
Diagnosed and fixed .
MIME issue , Let ::mime::parsepart accept a header only with multipart
Fixed .
MIME , added a default value of multpart/mized when -parts is provided
This should make mime::initialize a little more user-friendly .
MIME issue , too much braced message header values (::mime::getheader)
Fixed .
MIME issue , Problems with qp_encode and encoded_word, no_softbreak
Fixed .
(tcllib) fileutil::magic::filetype issue , mimetype, filetype result empty for text files
Fixed .
(tcllib) fileutil::magic::filetype issue , TCL fileutil::magic::mimetype not recognising Microsoft documents or mp3
Fixed .
(tcllib) Another round of work on fileutil::magic
Fixed issue ::fileutil::magic fails to identify mimetype , and also other issues .
(tcllib) Tcllib ncgi issue , Correct Handling of quotes in quoted strings in parseMimeValue
Fixed .
Tcllib mime issue , Error in mime.tcl
Fixed and added a test case .
(TclX) Update the build files for TclX
Also replaced deprecated autoconf functions .
tclconfig: CFLAGS broken at configure time
Untangled the offending strings from CFLAGS and made the corresponding changes in sampleextension .
(thread) thread::send -async script varname aborts with "alloc: invalid block"
Reported and fixed , but then sebres produced a better fix .
(tdom) tdom: selectNodes -cache 1 and a syntactically incorrect xPath statement , 2017-06-16
(tdom) removeAttributeNS: segmentation fault when there are other attributes with no namespace , 2017-06-17
(tcllib) fumagic , 2016
Significant modifications to bring fumagic , aka fileutil::magic::filetype much closer to feature parity with file(1) , and to be capable of ingesting the latest magic spec files .
sqlite issue : Incorrect result from a UNION with an ORDER BY .
Discovered and reported .
thread issue : -eventmark + thread::send -async == deadlock , 2015-04-12
Discovered , reported and fixed .

Tcl Core Activity

bug reports
buffer allocation on every call to Write in tclIO.c , {2022 04 20}
Discovered, reported, diagnosed, and fixed in a62764efd4fcdad3 and d699b9b1453b6734 .
using the Thread package in a debugging build of Tcl results in a segmentation fault at exit {2022 03 21}
Discovered, reported, diagnosed, and fixed .
lsearch returns different results depending on order of -bisect and -exact arguments {2021 12 30}
Discovered and reported
'argument with no name' calling proc with args built in different frame , {2021 10 07}
Fixed in 75a9777184741e05 .
namespace ensemble subcommand name prefix matching and a subsequent error results in a segmentation fault , {2021 09 04}
Discovered , reported , diagnosed , and fixed in a2e801a3d6c1675b and d49a1b03291b4cde .
failure to yieldto is not the same thing as not calling yieldto in the first place , {2021 06 20}
Discovered , reported , diagnosed as duplicate , and added test case .
vwait is not NRE-enabled, and yieldto cannot find the right splicing spot {2021 06 20}
Discovered , analyzed , reported and fixed in eb50e83ee1d8f207 .
cesu-8 encoding fails on \u80 {2021 06 19}
Discovered and reported .
epoll, special files, directories, links, epoll_ctl operation not permitted, and abort {2021 06 17}
Discovered , reported , diagnosed , and fixed in 7587b7aeb9ce863c , with tests in dcb888ed85adeb86 .
namespace is removed from other namespace paths before deletion is complete , {2021 05 19}
Discovered , reported , diagnosed , and fixed in bdd005f3301eec51 .
Per-interp Loaded library structures not cleaned up on interp exit. , {2021 05 15}
Discovered , reported , diagnosed , and fixed in a4de334c5f297a92 , 723d1eb93779e81b , and ccfd61a7cf6bce85 , and more on the pyk-tclUnload branch .
Fix quoting issues in gdb-test and lldb targets. , {2021 05 13}
Makefile madness . valgrind and lldb targets now interpret TESTFLAGS (and other) arguments the same way the test target does .
Tcl_Unload, make gdb-test, segmentation fault , {2021 05 14}
Reported, diagnosed, and fixed .
tclZipfs.c exit handlers don't deallocate allocated storage. , {2021 05 15}
Discovered, reported, and fixed in 47601ca8e37b50f4 and 20117765bd03fc9f .
Segmentation fault when closing a channel in an event handler for that channel {2021 04 26}
And also some tests for the issue .
New test constraints , {2021 04 27}
"debug" , "purify" , and "debugpurify" .
with "make valgrind", safe-zipfs-5.5 fails with the error, 'can't set "path": variable is array' , {2021 04 25}
Reported , diagnosed , and fixed in ac18feaba778d8c7 .
zipfs-5.1 Valgrind, TclZipfs_MountBuffer, "1 blocks are definitely lost" , {2021 04-20}
Reported , diagnosed , and fixed in dd4f24fce90dc392 .
Tcl_AppendObjToObj and Tcl_GetUnicode lead to Valgrind "Invalid read of size". , {2021 04 21}
Reported , diagnosed , and fixed in c7100a073ba1e0b8 . More fixes in ec5b3d21f9b29ee9 for similar issues reported by Valgrind .
New test for segmentation fault , {2021 04 03}
Occurs when the handle on the routine that represents the object is accessed during deletion of the namespace for an object , but that routine has already been deleted and the handle nullified . Fixed in 3ddbaef3566385a2 .
Tcl interprets two adjacent surrogate code points as a character encoded using UTF-16 , {2021 03 06}
Reported and discussed .
imported namespace ensemble command name distorted during deletion trace on the import , {2020 09 02}
Discovered , reported , diagnosed , and fixed .
double free when deleting namespace containing the origin routine for some imported routine {2020 08 20}
Discovered , reported , diagnosed , and fixed .
trace on imported alias deletes alias and then calls import and triggers memory error , {2020 08 16}
Discovered , reported , diagnosed and fixed .
calling an imported alias in a deletion trace on the alias causes Tcl to cycle on routine resolution , {2020 08 10}
Discovered , reported , diagnosed , and fixed .
segmentation fault from deleting the the target of an imported alias during a trace on the target of the alias , {2020 08 16}
Discovered , reported , diagnosed , and fixed in 37243ff47659d65c , de751a349009f88a , b9d1a1ce1aef55c3 , with a test case at 2da1596304896026 .
zlib push/pop corrupts underlying channel {2020 06 16}
Discovered and reported .
[uplevel $list] , [uplevel 1 $list] and generation of string representations , {2020 05 05}
Reported , diagnosed , and fixed .
tis-620 encoding fails to load {2020 01 04}
Discovered , reported , diagnosed , and fixed .
ensemble unknown handler confused by tailcall {2020 01 03}
Discovered and reported .
tailcall does not trigger an namespace unknown handler {2019 12 24}
Discovered and reported .
tcltest::SetupTest and tcltest::EvalTest {2019 12 01}
Laying the groundwork to customize the behaviour of tcltest such that each test is evaluated in a separate interpreter for real test independence .
regexp (?:a*b)+c indices wrong , {2019 11 24}
Discovered and reported . See also Regular Expressions Match Requirements . Marked as invalid, but I want to take a close look at it sometime.
TclOO segmentation fault: direct call to a method called by the object destructor , and that deletes the object via rename before calling next {2019 11 13}
Reduced a reported issue in a complex systems to a reproducible test suite , diagnosed , and reported .
A change to the system encoding , a stale cached file FsPath object , and an incorrect result {2019 10 22}
Discovered , diagnosed , reported , and fixed .
changing [encoding system can corrupt [encoding dirs] {2019 10 21}
Discovered and reported .
write-only nonblocking refchan and Tcl internal buffers {2019 05 06}
Diagnosed , reported , and fixed . See also TCL_FILE_EVENTS cannot drive async I/O alone .
try interaction with local variable names produces segmentation fault {2019 04 08}
Discovered , reported , diagnosed , and fixed .
Fixed memory leak in TclOO.c:ObjectNamespaceDeleted, object mixins and object/class mutation. {2018 11 01}
return -code break/tailcall break from coroutine goes wrong at the top-level {2018 07 31}
Discovered and reported .
refchan , coroutine , and postevent from the "watch" proc {2016 08 15}
Discovered , reported , diagnosed , and fixed . Further analyzed and defended in a blocking memory channel no longer works , {2021 06 09} .
Fix more memory leaks in TclOO cleanup routines {2018 03 14}
Add tests that isolate leaks to certain TclOO facilities .
(tailcall|yieldto) failed to find the proper namespace Abort {2018 06 28}
Added script to reproduce . Fixed in 9198c16407f3 .
TIP 498 - Simplify Tcl_DeleteNamespace
Simplify the implementation of Tcl_DeleteNamespace in order to make behaviour more consistent , facilitate the resolution of outstanding issues , and pave the way for further developments .
NRE-enable package require
Allows for a coroutine to yield from a script evaluated during package require . A previous , less polished implementation no longer applied cleanly .
Delete a namespace for an ensemble having a deletion trace deletes its namespace: segmentation fault.
Fixed .
Further refactoring of TclOO object cleanup routines
Also resolved TclOO, segmentation fault: deleting a class mixed into an object that calls a method on the class in a deletion trace .
TclOO segmentation fault cleaning up objects that that have mixed themselves into themselves
Fixed .
Streamline TclOO object cleanup routines
ensemble: segmentation fault when -subcommands and -map values are the same object
Fixed .
namespace ensemble command named ":" is mistakenly given the empty string as its name.
Fixed . See also thefix for a followup issue .
Modify TclCreateProc to handle arbitrary argument names, not just ASCII
segmentation fault in TclOO.c/ReleaseClassContents() for a class mixed into one of its instances
Fixed .
TclOO - aborts when a trace on command deletion deletes the object's namespace
Fixed .
TclOO method with non-literal value for body argument causes segmentation fault
Fixed .
Avoid generating string representation when comparing against the empty string .
caching objects
Use duplicate Tcl_Obj structures to hang onto previous intreps . Eliminates the need to generate a string representation of a list that contains redundant keys when used as a dictionary . string length No longer causes intreps of items in a list or dictionary to be discarded . With a little more work , string range could be modified to take advantage of the cached objects and not generate a string for the entire list or dictionary just to derive some substring . The next step is to take advantage of this patch to never generate the string representation of a full list or dictionary . This patch introduces TclObjLookupTyped() , which returns a Tcl_Obj of the desired type , or NULL if there isn't one handy . Such an interface could prove generally useful in further development of Tcl .
alias trace did not find command in real command list of import references
Discovered and reported .
off-by-one address error in AppendUnicodeToUnicodeRep , 2012-02-04
Reported and diagnosed .

Tcl Core - Documentation

Reduced word count by 40% .
chan.n , 2022-01-22
Reduced word count by 26% .

Technical Contributions to Projects not related to Tcl

Instructions for updating the BIOS of an HP Envy m4 without using Windows

Reclaimed Programs

One of my ongoing projects is to give abandoned Tcl programs a new home . Here is a list of the rescues to date .


Open Questions

Should there be a fork command for coroutines ?

Seems like something that might be fun/useful

AMG: I've asked about this before on the coroutine page . Search for "Cloning" . Sorry , not going to happen . Quote from MS: "The real obstacle is that each coroutine has its own Tcl stack , which stores (among other things) pointers to itself . Making a copy of that stack implies fixing those autorefs , which in turn implies storing the nature of each entry in the stack to know if it has to be fixed or not (and how) , which in turn implies a redesign of the tcl stack ."

Should variable substitution be more script-like ?

Assuming the following alternate definition of variable substitution ,

In a word , $ and the variable name immediately following it are replaced by the value of that variable . The variable name can be a sequence of characters in the range 0-9a-zA-Z , or , if the variable name begins with " , [ , { , $ , or \ , the variable name is determined according to the corresponding rule for double quotes , command substitution , braces , variable substitution , or backslash substitution , respectively . Non-whitespace characters may occur immediately after the variable name , i.e. , immediately after the closing " , ] , or } . If the variable is immediately be followed by a string index of the form (index) , index , which may not contain a literal ) , is the name of an element with that array .

Tcl would behave like this:

# warning: hypothetical behaviour
% set {{}} hello
% puts ${{}}
% puts $[join { \{ \} } {}]
% set \{ goodbye
% puts $\{}
% set greeting greetings!
% puts $"greeting".yada
% set name {{}}
% puts $$name
% puts $"$name"
% set na \{
% set me \}
% puts $"$na$me"

This makes variable substitution more consistent with the other syntax rules of Tcl , and more flexible as well .

AMG: This functionality is provided by single-argument [set] . Tcl's $ notation is a shorthand for single-argument [set] that only works for variable names that are literal , though substitutions are allowed inside the array index .

I don't understand what you are asking for with your "greetings" example . Tcl already behaves like you show because the period following $greeting isn't treated as part of the variable name .

In Brush I propose a new $"..." notation that works like [set ...] , as shown in your puts $"$name" and puts $"$na$me" examples . If you want to get silly , this notation can be nested because opening $" is distinct from closing " .

$$name is explicitly disallowed because of ambiguity when combined with indexing . Does faux-Brush $$name{0} mean the same as Tcl [set [lindex $name 0]]] or Tcl [lindex [set $name] 0] ? Instead write $"$name{0}" or $"$name"{0} to make the intent clear .

Brush's proposed $[...] notation does not work as shown in your puts $[join ...] example . To get that behavior , instead write $"[join ...]" . Brush's $[...] is a mechanism for applying variable indexing operations to the result of a [script substitution] without having to first save the substitution result into a variable . For instance , Brush $[command](key1 key2){1 2} means precisely the same as Tcl [lindex [dict get key1 key2 [command]]] 1 2] . The C analogue would be roughly command()->key1->key2[1][2] .

PYK 2016-04-07: I've added quotes to the "greetings" example , which is there just to confirm that the behaviour in that case doesn't change , in spite of the fact that normally , extra characters aren't allowed after the closing brace or quote . The apparent ambiguity of $$name(index) doesn't seem too problematic to me ; interpreting it as the equivalnet of of $"$name(index)" is visually straightforward enough . In that last Brush example I think you meant [lindex [dict get [command] key1 key2] 1 2] .

Should info nameofexecutable be fully normalized if it's a symlink ?

info nameofexecutable is currently used in the code that sets $auto_path in init.tcl , so with the current behaviour , $auto_path is set differently for every symlink to a tclsh executable .

EMJ: Assuming that you mean init.tcl . If you have installed tclsh in some strange place then that place should be on your path anyway (as , of course , is the official location) . I really don't see why you would ever need a symlink to tclsh or wish at all .

Would it scale better to have commands like [append list ...] rather than lappend ?

AMG: I'd much prefer [list append] , but the [list] command is thoroughly taken . Tcl subcommand structures are typically named by putting the noun (class) first , at least when it's not the case that the object instance handle name is the command name .

PYK 2013-09-22: Been thinking about it often , and I still have this suspicion that the world might be a better place if we all went with [verb object ...] rather than [object verb ...] . It still seems reasonable to me that Tcl could dispatch based what type role the object most-recently played .

AMG: I'd be careful about the word "object" in this situation . To me , the word "object" , especially when next door to the word "verb" , is a specific thing being acted on , in other words an instance . In C++ notation , "myList.append(value);" , would have myList as the object , or more properly the instance . When you say "object" you really seem to mean "type" .

So , how would command dispatch work if the hierarchy went the other way around ? I see types as collections of operations , along with established schemas for values of that type . So types are above operations in the hierarchy . In the Tcl command ensemble dispatch concept , that means the type name must go first . Put it second , and things get funny , especially when the ensemble is more than two levels deep . You could implement this if you like , either by making procs for all operations , which take type names as their first arguments , or by making an unknown handler that does custom dispatch .

As for type inference , this is scary in situations where the type cannot be determined by static , lexical analysis , for instance when operating on an argument to a proc . The behavior of the proc would depend on what the caller had most recently done with the arguments . For instance , let's say the length of a list is the number of space-separated words in its string representation , but the length of a dictionary is the number of keys . How does a proc tell how many words there are in a value that was just passed to it ? It would have to do some dummy operation to force the value to be a list . Now this potentially screws up all the code (including extensions , the proc's caller , any holders of shared values) that assumes the value is a dictionary . Far safer to explicitly say "this is a dict" or "this is a list" every time an operation is performed . In other words , what Tcl already does !

should the string command be retired and its subcommands become "top-level" Tcl commands ?

DKF: Ensembles purely organizational . From 8.6 onwards — or is it 8.6.1 ? I forget when the commit went into HEAD — the built-in ones compile themselves out entirely in almost all cases (the exceptions are some of the complex cases , notably including namespace eval and info frame); the implementation is used just as if it was an independent command . This isn't done for user-created ensembles , because we suspect the performance cost to Snit is suspected to be too high there . (I ought to check that assumption . If it's wrong , it's trivial to turn on compilation for all ensembles . Contrast with TclOO where compilation of the dispatch doesn't make sense at all , and which uses other mechanisms to accelerate .)

AMG: I wish we could do this with [list]... :^(

Should [dict incr] return a single value rather than a key-value pair ?

It would be more consistent with incr if it did , and most of the time , the single value is what I need .

AMG: The goal was consistency with most of the other [dict] commands that take a variable name as their first argument . These commands all return the entire modified dictionary , not just the portion that changed .

If we were to generalize the concept of nested dicts such that a zero-length key path refers to the entire dict , and we were to make all dict commands support key paths , then [dict incr] with zero keys would behave the same as [incr] . (By the way , [dict get] and [dict with] support zero-length key paths , even though [dict set] and [dict unset] do not . However , they still expect their argument to be a valid dict , or at least an even-length list , so they do not exhibit the full generalization I just suggested .)

There are two other [dict] commands that take a variable name as their first argument , but they also take a script as their last argument . Even though they modify the dictionary , these two commands return the return value of the script . This is consistent with non-looping commands like eval , if , try , and [uplevel] that take script arguments .

To Do

Fix sqlite coroutine segmentation fault

See this post .


NRE-enable trace routines , starting with variable traces .


NRE_enable vwait .

Tcl_FSEvalFileEx and TclNREvalFile

Remove duplicate code . Also remove duplicate code in DivertUnloadFile and TclFSUnloadTempFile .

Tk build

macos, linux: configuration: unable to build using trunk
Address the issues leading to reversion of this work , and merge back into trunk .


Update documentation for encoding convertto and encoding convertfrom to clarify that those routines munge data
If a character can't be converted to the target encoding , it is replace with a character that can .

Logical Strings

In the following example ,

set mylist [list some huge list]
set script "lappend somevar {*}[list mylist]"
eval $script

A string representation is generated for $script , and that representation unfortunately includes the string representation of $mylist . In some future version of Tcl where each type of value has an interface which includes the standard operations of a string abstract data type , A "concatenated value" type could provide the logical equivalent of the string representation in $script while not actually generating the full string .

This is one of the fundamental pieces that remains to be added to Tcl in order to give it more of the power of other Lisps , making The Best Lisp (TM) .

Another example:

proc p1 {} [list ::apply [list hugelist {lindex $hugelist 1}] $hugelist]

Ideally this would not trigger the generation of a string representation for $hugelist .

package require

package require could return a handle for the required package . Commands that operate on a handle could include:

package namespace
Returns the namespace of the loaded package .
package version
Returns the version of the loaded package .

sorted-aware lists

Would this be a performance win in the large?

Make [upvar 0 othervar myvar] work with env

Also fix traces so that traces on the array , not just the individual element are fired for $myvar .

[L1 ]

fix 1-argument invocation of uplevel

Modify uplevel so that when only 1 argument is passed , it won't try to interpret that one argument as the optional level argument .

Add Moose-like Convenience to a Tcl object system

In the Tcl Chatroom on 2014-02-26 , mst described how convenient it is in Moose , an object system in Perl , to create objects with slots for lazy variables , which the ability , if desired , to initialize those variables at the time of object creation . I think something like that would be almost trivial to add to a Tcl object system , perhaps to ycl::ns::object

AMG: How is this different than initializing those variables in the object's instance constructor ?

PYK: mst described a system where the attribute would not be computed until first accessed , but then optionally could be initialized in the constructor . Apparently in Moose there is a nice terse syntax to express this . The difference , of course , might be felt when deriving the value is relatively costly , and that cost can be deferred until the value is actually needed , and then the value could be cached for future reference .

AMG: This can be done with read traces .

Modify tclsh treatment of stdin

Currently , tclsh switches to interactive mode whenever the Tcl script is read from stdin . This is even true when stdin is a pipeline . One consequence of the current behaviour is that when there are errors in a script that comes through a stdin redirection , the interpreter exit , or to display a stack trace . This can cause a script to behave quite differently depending on whether it is in a named file or redirected from stdin .

Modify tclsh to accept scripts whose name begins with "-"

AMG: I propose the opposite: make tclsh bail out if its arguments , prior to the filename , can't be interpreted as valid options . The current behavior is bizarre . If the first character of the first argument is "-" (and the argument's not "-encoding") , tclsh drops into interactive mode with all arguments placed in $argv . What good is this ?

Right now the only supported option is "-encoding" . I'm not comfortable with allowing scripts whose names being with "-" because we unavoidably get in trouble when the script's name is "-encoding" .

PYK: I don't think Tcl needs to do that much babysitting . If someone is reckless enough to both have a file named -encoding and be using tclsh -encoding , they're asking for it . On the other hand , why should Tcl be able to interpret any file , regardless of name ?

AMG: Why "should" ? I'm going to assume you meant to say "shouldn't" . It may seem unfortunate , but every system must define some limits which its users must observe . In this case , Tcl doesn't allow the startup script's name to begin with a dash . This is done to avoid ambiguity with command-line options . There's an easy workaround though: prefix the script's name with "./" , an absolute path , or any other such construct containing a slash . Many other workarounds exist involve renaming , copying , linking , or sourcing the file .

RLE: There is another alternative . First , tighten up tclsh's (and wish's) option parsing to accept only valid options and refuse invalid ones . Then add support for the "end of options" option "--" , at which point if one wants to have a script named -encoding , one would do:

tclsh -- -encoding

And if one wanted to set an explicit encoding , for a script named -encoding , one would do:

tclsh -encoding utf-8 -- -encoding

This would be consistent with a bunch of tcl commands that already implement the end-of-options option "--" , and with a bunch (most , at least of the GNU variety) command line programs that also accept the end-of-options option .

memory characteristics of string replace

In the following example , when the first command sets b , the memory usage quadruples . In the second example , it doubles . If possible , modify string replace so that the first example only doubles the memory usage while the second example doesn't change it .

set a [string repeat a 10000000]; set b [string replace $a[set a {}] 0 0 b]
set a [string repeat a 10000000]; set b [string replace $a 0 0 b]

AMG: You sure you don't have that backwards ? I would expect the second line (example?) to cause the larger growth in memory because now both $a and $b contain 10000000-character strings . In fact , I just tested this on my system , and indeed it behaves as I describe .

Run 1:

% set a [string repeat a 10000000]         ; exec ps -o size --no-header [pid]
% set b [string replace $a[set a {}] 0 0 b]; exec ps -o size --no-header [pid]

Run 2:

% set a [string repeat a 10000000]; exec ps -o size --no-header [pid]
% set b [string replace $a 0 0 b] ; exec ps -o size --no-header [pid]

I'm not entirely sure I know what you're asking . My best guess is a request to make [string replace] not return a new pure string but rather some Tcl_Obj that references its source string value but contains an annotation saying to replace its first character with b when a string representation is demanded . Indeed that would cut memory usage in half for the examples you give , but creating a new "string replace result" intrep would be a special case of dubious benefit . Indeed , that benefit would vanish as soon as a string representation is needed , which will be pretty much right away , unless you were to never look at or use the value you got .

PYK 2014-04-24: Yes , I had it backwards . My idea for improvement is that if the number of characters being substituted in is the same as the replacement value , and the object is unshared , could the string representation be modified in-place ? Those criteria should be true for the first example:

set a [string repeat a 10000000]; set b [string replace $a[set a {}] 0 0 b]

AMG: This first example already works just fine . My simple profiling above shows no appreciable increase in size . What's the problem ?

Modernize Ffidl

Fix [file link -symbolic]

so that it doesn't require the destination to exist in order to create the symlink

Fix [[trace] facilities so that errors never disappear into a vortex

Also work towards consistent behaviour of trace . Make sure commands like [append] and [[lappend] consistently trigger traces at the logical points .

This is well-underway . See my branch of tcl .

Modify trace add command ... enter somecommand

See proposal on the trace page to use the result of somecommand as the actual command to run

Expect Bug

#! /bin/env tclsh
package require Expect
spawn tclsh; fileevent [set fh [open /dev/random]] readable {expect something {}}; vwait forever

eliminate newline substitution in comments ? (tclParse.c/ParseComment)

AMG: How about eliminating backslash-newline substitution inside braces ? No one seems to know what it's good for , and it has caused strange problems for me with templates and subst . Specifically , long lines continued with backslash must have percent signs at the beginning of each physical line when the data is [read] in from disk and must not have percent signs at the beginning of subsequent lines when the data is inside braces .

PYK 2013-03-08: That's an interesting point . I'd never really paid attention to that , but now that you mention it , it does seem odd/useless/obstructive . Maybe it's just an artifact of the original implementation of the parser . If anyone out there can shed more light on the subject , feel free to comment on this page , and I might move the discussion to another page later .

PYK 2013-04-15: I found an example of backslash-newline substitution being put to use at scriptSplit , where it allows the error message to be indented in the source code , but come out de-indented at runtime . That use case led me to wonder if the \<newline>whiteSpace rule shouldn't be changed to \<newline>\<newline>*whiteSpace instead

AMG: Even if backslash-newline substitution inside braces were to be eliminated , the code you reference would still produce error messages all on one line , with indents and line breaks removed . This is because the parser already has special handling for backslash-newline-whitespace when outside braces . Inside quotes , it's a single space . Outside , it's a word (argument) separator . I find it redundant and destructive to do this processing at multiple layers of interpretation .

write a port of the DOS game , Slicks'n'Slides , as mentioned at Car racing in Tcl

a Tcl alternative to TeX

AMG: Great idea , I had been considering the same thing . But perhaps there's a way to make a Tcl frontend for TeX or for one of the frontends TeX already has (e.g. LaTeX or DocBook) ?

PYK: I think a front-end for TeX would most definitely be the way to start .

PYK 2014-08-19: Another starting point might be to write a Tcl patoline extension and build on that

Tcl implementation in RPython . May involve writing a Tcl analogue to Rpython

[binary set]

AMG: I assume this would modify individual bits and fields of a structure in-place , thereby avoiding the need to reconstitute the entire structure each time a piece has to change . Kind of like [lset] ...

PYK: right .

fix lindex so that [lindex $somevalue] throws an error if $somevalue is not a list

AMG: I'm assuming you're talking about single-argument [lindex] which simply returns its argument . What's the problem with that ? I believe it currently has the correct behavior . [lindex]'s subsequent arguments specify what list indexes should be applied , so if there are no list index arguments , no list indexing should be applied . If no list indexing should be applied , there should be no requirement that the data be a list .

Let's look at it from another perspective . Take this code:

lindex {{{asdf}fff}} 0

This returns {asdf}fff , since that is the one (and only) element of [lindex]'s first argument , which is indeed a list . The fact that {asdf}fff itself isn't a list is totally irrelevant . But then take this:

lindex {{{asdf}fff}} 0 0

Now we have a problem . [lindex] is being asked not to return {asdf}fff but instead to drill inside it and take its first element . Since it's not a list , there is an error .

In summary , it's already the case that [lindex]:

  1. is capable of returning values that aren't lists , and
  2. is unconcerned about the listhood of values (or nested values) when it's not being asked to index into them .

I see no reason to special-case the situation where [lindex] is given only a single argument .

PYK 2014-08-22: I've since become accustomed to using lindex as the identity function , and because anyone providing it with ony 1 argument has surely read the documentation , I no-longer see it as broken . So now , on with the critique of your analysis ! The fact that elements of a list don't themselves have to be lists isn't particularly relevant to the argument , and lindex without an argument already is a special case , both because it is the only time that lindex isn't actually being asked to return an element from a list , and because it's the only time that the first argument is not required to be a list . This special case is a hole that like other such holes , was ingeniously exploited . It's an easter egg , and a very useful one that spices up any script with a touch of wizardry .

AMG: I argue the opposite , that single-argument [lindex] is not a special case nor a hole but rather a natural consequence of the generality of [lindex]'s definition . Furthermore , I argue that the fact it doesn't require its lone argument to be a list is to be a direct consequence of that same definition .

I know I'm repeating myself , but I'll try it anyway to see if I can make my point clearer .

[lindex] must be given one data argument followed by any number (even zero) of list index arguments . Initially , [lindex] lets the data argument be the tentative result . For each index argument n , [lindex] obtains the nth element of the result and lets it be the new result .

That's almost the entire definition . The only part I left out is that the indexes can either be separate arguments or a single list .

From this I'm sure you can see that if there are no index arguments , no list indexing is performed . And if no list indexing is performed , there's no need for the first argument to be a list . It's the result and that's the end of the story .

As for your argument , I will now use similar logic to show that four-argument [lindex] is a special case . It's the only time [lindex] is being asked to return an element from a list in a list in a list , and it's the only time its first argument is required to be a list nested minimum three levels deep along the selected path . Basically I'm saying that the number zero is no more special than the number three .

PYK 2014-08-23: That is a most illuminating and satisfying reply . As long as lindex is going to accept only 1 argument , that operational description of why the current behaviour is the correct behaviour makes perfect sense . I appreciate the twist on my logic for the four-argument case , but it had to drop the key word , isn't , for the word is . Saying that lindex is implicitly not being asked to extract anything from its final result is a bit of a tautology — but wait — what could be more fitting than a tautology to express an identity ? I give up !

[lsearch -filter] . Or even better , have lindex interpret its arguments as lists of indexes

AMG: [lindex] already supports having an indexList argument , and {*} can be used to make any argument work as an index list . Please post an example showing what you have in mind .

PYK: I mean that

lindex {uno dos tres quatro} {1 3}
# -> {dos quatro}

For compatibility with current usage , it might have to be

lindex {uno dos tres quatro} {{1 3} {}}
#-> {dos quatro}]

AMG: Ah , we're talking about two different kinds of index lists . I was talking about a list of indices forming a path to a single element located within nested lists . You're talking about indexing multiple elements . The [lmap] command may help:

proc lindex_multi {data indexes} {
    lmap index $indexes {lindex $data $index}
lindex_multi {uno dos tres quatro} {1 3}

A Tcl implementation of or binding for a hierarchical temporal memory system

Contribute to a Tcl project competing with pandas


AMG: Many pages on this wiki now use markup like this:


The second close bracket is missing . I could be wrong about this , but I seem to recall that you did this format conversion in some kind of batch process . Do you still have a list of pages you edited in this way so the formatting can be corrected ? I've found and fixed a few by hand , but it's a tedious process .

PYK 2013-12-19: I just saw this comment , subsequent to the discussion we had on it at RLE . I'm not encapsulating inline code in brackets anymore , so it's probably a moot issue , but I still think that given the current wiki markup rules , the example above is perfectly valid . I don't have any list or batch process for this -- they were just edits as a went along .

EMJ: I don't understand what you mean by the "Response" heading you have added to a number of wiki pages . Response to what ? Definitely not the section above it . I think maybe a different word is needed .

PYK 2013-12-19: "Response" was supposed to mean "How it was received by people" , but maybe it's too terse . I'm open to suggestions . Maybe "Comments" , or "Opinion" ?

RLE (2013-12-18): Compare historical version 22 with historical version 21 of ANSI color control . Version 21 is the correct page . Version 22 is a completely different page . Whatever you are using to make updates is now replacing page content with completely unrelated pages . I don't want to just reset to version 21 , as that will lose the incorrect V22 contents which belong to some other page . Since you made the edits , it will be easier for you to track down where the now incorrect page belongs and put it back . Please fix .

PYK 2013-12-19: Oops . Fixed .

PL 2014-02-28: Re: our previous debates about the content of the RMS page: in my view your recent edits to the Richard Stallman page are fine . The differences in how certain assertions are formulated are subtle but , again IMV , significant . It helps very much that the text now provides context and makes the assertions part of a , well , narrative . Certain phrases are still shocking (as they were apparently intended to be) but no longer seem like mere pejoratives .

PYK 2014-02-28: Stallman himself either intends to shock his audience at times , or is truly oblivious to the effects of these behaviours on people . I tend to think it's the former . After spending one long day immersed in Stallman material , I had the following impressions:

  • Stallman's childhood years were traumatic , and left a deep impact . There's not much information available about this , but there is a distinct trail of comments by Stallman himself that , taken together , tell a sad story .
  • Stallman adapted to cope with early social failures by deciding not to give a fuck .
  • He opens his life up for scrutiny to an extent that most of us would never dare approach .
  • People are often offended by Stallman , but he considers that their problem for buying into whatever social protocols provide the rationale for the offended reaction , and is not in turn offended by the behaviour of others . He finds many human behaviours silly , and people often take him seriously when he is being humourous .
  • He is consistent in his loyalty to his cause , which seems primarily to be to leave the world in better condition than he found it in .

I think the most glaring contradiction in his body of work is the GPL itself , which prohibits modification .

PL 2014-03-01: did you get permission from Jean-Luc Fontaine before rearranging his page ?

PYK 2014-03-01: No . Do you see that as a problem ? I'm not sure he's very active on the Wiki at present , and there certainly wasn't much information on his page to begin with . If he objects , I'll certainly try to make it right by him .

PL: I do see that as a major problem , and , frankly , I find your rather cavalier attitude to this quite upsetting . Regardless of whether he's active or not , the amount of and layout of the content on his page is his business , not yours . It is up to you to get his approval first before changing it , not up to him to set you straight afterwards .

PYK 2014-03-01: I'm sorry , Peter , but I completely disagree with that . I see a highly-dynamic , contention-based wiki as the only way forward . I'm not sure where the idea crept in that we should not be bold on this wiki , but we absolutely should be ! This wiki has ossified . It's full of clutter and obsolete information . I'm all for preserving the fantastic content of the wiki , and the years of wisdom that have been imparted to it by amazing , even legendary figures in the history of computing , but someone must sweep under the rugs from time to time . The ethernet protocol is dominant primarily because it scaled , and it scaled primarily because it is contention-based . By their nature , wikis sacrifice some level of control in return for fresh content . The readers of this wiki may age and die , but to serve Tcl , this wiki must remain dynamic and relevant . If you see something you think could be better , then by all means , dive in and change it ! Don't worry that someone might get offended or think your changes are wrong . If they think so , they'll tell you , and together you can work out something even better . I should also say that I'm happy to see you back and active on the wiki , because we are desparately short-handed !

PL: This wiki is not in any way ossified: it's alive and vibrant -- it's a pity you're not able to see that . People are constantly working to improve it and , yes , that includes changing the content of existing pages , though perhaps not in the radical way you seem to revel in . Changes need to be justified , and an editor must be able to balance the need for change against the value of existing structure . Your "Don't worry that someone might get offended or think your changes are wrong" attitude is alarming and completely inappropriate for a wiki editor . And you need to stay off personal pages . It's disrespectful as well as unnecessary to rearrange such pages . I'll revert Jean-Luc Fontaine's page for you , but I hope you'll avoid this mistake in the future .

PYK 2014-03-01: Them's fightin' words , Pistol Pete !

EMJ: And that is a totally inappropriate response . This is not some social media site , it is a Wiki for users of a computer language . It doesn't have to be totally serious , and differences of opinion are definitely allowed , but it is not the place for someone who now seems to be basically looking for an argument . On the other hand , it is also not Wikipedia , there is no reason why all pages should have the same structure and headings , which seems to have been your goal for the past few months and which , in my opinion , has made some pages far less readable than they were originally .

PYK 2014-03-01: I'd say "reverting Jean-Luc Fontaine's page for me" was the totally inappropriate response , but anyway , there are bound to be differences of opinion on how to improve the wiki . One thing that might help is a style guide for the Wiki , where we can hash out opinions on such matters . I do think uniformity is an important visual aspect that can help make the Wiki more readable . I'm not hard-set on a certain structure for pages , but I have found that most things that are noted on pages do seem to fall into a certain fairly small number of common categories . I do a lot of tedious work on the Wiki that I wish I didn't have to do , but when I see a page that is difficult to consume because things aren't laid out in an organized manner , I really want to to be the last person who has to dig through the entire text to find that one piece of information I'm looking for . Grouping similar bits of information is one important element that I think can contribute quite a bit to the legibility of a page . Removing excessive narrative is another . Sometimes , when I find an important piece of information embedded in a long narration , I don't delete the narration , but duplicate the information in a spot where someone browsing for "just the facts" will see it more quickly . I don't think my edits are perfect , but obviously I think they are an improvement , or I wouldn't make them . I'm interested to see people making changes to my edits , because it gives me feedback on what I could do better . RLE and I have gone back and forth on a few issues , and to my knowledge , each time I've ended up adopting his approach , either because I see the light , or because I don't think it's worth fighting bout .

What pages are less readable as a result of my edits ?

PL 2014-03-02: I have noted , and I do appreciate , the hard work you have put in e.g. to make valuable corrections and to improve the layout of pages . However , working hard does not in itself mean doing good work . You're not the first person to come to this wiki with a mission to save it , start off by doing a lot of well-needed cleanup , and (in those earlier cases) end up causing a lot of more-or-less irreparable damage before leaving in a huff , declaring us all to be ungrateful bastards . I'm not here to fight you: I'd like to salvage you from ending up like that , if I can . I'd much prefer if people were saying "that PYK , he (she?) really knows how to put a wiki in order" compared to people saying "yeah , I used to work with the Tcler's wiki , but it's no use now when that PYK guy can turn up any moment and revise it all to hell" . You're obviously a hard worker and have quite some eye for page organization , which is good , but there are a lot of things you seem to need to learn about wiki editing , and respecting boundaries and conventions is one of them .

(To start with , it would be really helpful if you would quit breaking up paragraphs into packed lines . It's unnecessary , and makes it very hard to compare your new version with the old version either by diff or eyeball , which means mistakes can easily go unspotted . And when a mistake is spotted (or , for that matter , if someone wants to revise the text further) , your linebreaking makes it so much harder to fix the error without making the source text look ridiculous . It's not just a bad habit , it's counterproductive and you need to stop doing it .)

(ETA: I just spent some time fixing the dynamic language page (and have tabbed up three or four other pages where you may possibly have introduced errors , to look at them more closely when I have time) . You seem to have been in such a hurry to edit as many pages as possible that you accidentally(?) replaced a fairly correct definition with an incorrect one (two glaring errors) . I could have just reverted it , but 1) I wanted to keep the rest of the changes you made , and 2) I felt the subject needed a better introduction . Slow down . There's no award for highest number of page edits , but we do need our content to be as correct as possible .)

PYK 2014-03-02: I looked at the dynamic language page just now , and I still don't see the "two glaring errors" you mention . I actually prefer the first paragraph I wrote to the one that is there now .

Regarding breaking lines at the 79th column , for source code that rule has been around for a very long time , and for good reason . Yes people have larger screens now , and more sophisticated editors , but all my terminal windows , for example , are still 80 columns wide . Breaking lines up only really has an big impact on the "line compare" functionality of the wiki when an entire article has been converted from long lines to 79-column lines . After that , it's sixes . I'd say long lines is rather the break with convention . If a Wiki style guide arose , I would add the 79-line rule to the guide , and I guess then we'd have to find a way to resolve style-guide conflicts . In the meantime , I'll make sure that I don't combine content edits with layout edits . I'll make the content edits first , followed by the layout edit . That will make it easier for someone who wants to revert just one or the other .

There was an instance where I spent a good deal of time (days , actually) modifying the BWidget page , but Harald didn't like the changes at all and I couldn't find a way to reconcile the changes with what he wanted , so I eventually just reverted all my changes . If there's a systematic problem with my edits that people see as irrereparable damage , I definitely want to know about it ASAP !

Regarding Jean-Luc Fontaine's page , I'm not sure why you're so up-in-arms about that one . Do you know him ? Is he still alive ? People do not own pages on this wiki , not even pages named after them . This is a wiki , and anyone editing it should have thick skin , and not get any ideas that the "own" some shred of content on it . Yes , a personal page is to some extent a place for a person's own observations , but certain things belong on a personal page , and I'm not going to go around asking each and every person if I can move contact information from another page onto their personal page . If you insist on reverting it , though , starting immediately , I'll adhere to the Wikipedia policy on only reverting your reverts only once in a 24-hour period (in this case) .

PL: On the dynamic language page , you wrote "source code for a program cannot be completely compiled prior to runtime" , which is wrong , and "the source code itself is subject to modification at runtime" , which is wrong . How is that preferable ? Don't you think it matters if the text gets the facts right or not ?

Breaking long source code line remains a good idea (and the limitations of old TTY devices are only part of why that is the case) . Breaking long text lines , not so much . You're transferring a convention from a context where it makes sense to a context where it's just in the way . You might as well , if this is all about respecting old conventions , require everyone to write in 7-bit ASCII only (it makes about as much sense , really , and would be less intrusive) . Now , imagine adding a few sentences in the middle of your carefully formatted paragraph above ? After doing all the work required , consider how your paragraph differs from mine , once the page is rendered . See ?

The damage can become irreparable in many ways , for instance when other people's edits become too entangled with yours .

Pages created by a member/editor and named after them belong to them , simple as that . Minor edits can still be made to them , but restructuring the pages is out of the question , except with permission . And yes , I'm going to keep reverting the page .

PYK: The paragraphs don't differ at all in the rendering , but the line diff is likely to be smaller for the 79-column-constrained text . With long lines , a single change to a paragraph pulls the whole paragraph into the diff , which is less desirable . Regarding the two statements about a dynamic language , the current version uses the word "definition" instead of "source code" but the sense is the same . "definition" is probably technically a bit more precise , but "source code" is more descriptive . Including the word , "compilation" , which is certainly one of the factors used to deternine whether a language is dynamic , gave some extra context to the beginning reader .

Regarding Jean-Luc Fontaine , the dude hasn't updated his own website 8 years . Has it occurred to you that he may never come back ? I've spent an enormous amount of time tracking down "lost" Tcl things , and I'm proud of some of my finds , and of some of the links I've been able to make live again . I'm pretty sure no one was going to put in the time and effort on some of those things , and I doubt my own sanity for doing it myself . Things disappear , people disappear . It's our job to keep the place current . If Jean-Luc Fontaine shows up and reverts my edits to his page -- hey , I respect that ! Richard Stallman is welcome to do the same . And in direct response to your statement that pages created by a member/editor and named after them belong to them: No they don't .

PL: For source code lines , where you typically add , remove , or alter a small substring , and where changes in one line typically don't affect or spread to the surrounding lines , the line diff is likely to be smaller . It's another matter with text lines . Changes tend to affect larger substrings to begin with , and after that you're going to have to justify the whole paragraph to 79 characters again , which will most likely propagate the change to the end of the paragraph (yes , even a single character changed in the first line might end up changing every line in the paragraph) . In the end , you'll still have a big mess , only it's going to be less readable than if the paragraph was joined up to begin with . About the only convention that will avoid diffing problems is to stick to one-word lines , and we don't want that .

Source code is a text string that provides one of the bases for the program definition . They are most certainly not the same thing and exchanging the terms alters the sense of what you are saying . Compilation is used in both static and dynamic languages and does not as such mark any difference (and you didn't say that anyway , you said that the source code of a dynamic-language program can't be completely compiled prior to runtime , which is untrue) .

Even if he never comes back , keeping the structure of his page does not cause any problems for us . Richard Stallman is not a member of the wiki community and has not started the page that bears his name , and consequently has no special rights to it . Conversely , his page is fair game for any wiki user to edit .

You say "No they don't ." Well , it's not your call . Even though you work hard and contribute a lot , you are still just another user , and even you will have to respect things like page ownership .

PL 2014-03-03: this is to inform you that I've cleaned up the mess you made in the Splitting strings with embedded strings . If you wonder what it's about this time , you "improved" the solution so it didn't produce the correct result anymore . While I was at it , I rewrote the whole answer to be more educational .

PYK 2014-03-03: What was it you objected to in Splitting strings with embedded strings ?

PL: I usually try to be patient with you , but right now you are making it very hard for me to do so . What was it I objected to ? Let's see , could it possibly be the thing I mentioned in my previous comment ? That you changed the solution to produce the wrong result ? Nah , can't be , too easy . Right now , however , I mostly object to you messing with the page again . I found , and kept , one useful addition , the comment about using an XML parser: the rest was just you semi-randomly replacing content with garbage . Can it really be that you don't know that double quotes are illegal inside a double-quoted attribute value string in HTML ? If you didn't know that (and this has to be considered fairly basic) , please leave the editing of pages like this to people who do know what they're talking about .

PYK: Yeah , I've actually had the notion for a very long time that double-quotes in HTML attribute values could be backslash-escaped , but I just checked the HTML , XML , and even SGML specs and sure enough , no backslash-escaping . It's been a long time I've used anything other than a full XML parser to consume or generate XML , so I've never had any occasion to disabuse myself of this wrong notion . On the other hand , the examples at Splitting strings with embedded strings don't take into account other complexities of HTML markup , such as attribute values delimited by single quotes rather than double quotes .

Regarding producing the wrong result , I looked through the examples that were on the page before you rewrote it , but failed to find the change that produced a wrong result in the time I had alloted , so still don't know what specifically you were referring to .

PL 2014-03-04: What your code did was return the tag name instead of the name of the first attribute . It might seem like not a very big deal , since it's easy to notice that the code is wrong , and easy to correct it if you're in the mood . It looks bad , though , if someone randomly tests that snippet to assess the quality of the code on this site . I know your editing policy is rather the other way around , but at least when changing code one must be careful not to break things . OTOH , it would seem I just validated your policy of not bothering with the quality and correctness of the edit , because someone else is going to check it for you and fix it if it's no good . Can't say I feel great about that , but it would have been unsatisfying to just revert your changes since the page did need an overhaul .

Speaking of reverting , I actually don't have a big problem with you copying Jean-Luc's mail address to his personal page as long as it is munged (which you have taken care of) and as long as he himself has provided the address at some point (which he has) . You should have left a note pointing out that you are responsible for the addition , though . I don't know if RLE will approve -- that's his decision . What's a bit eyeroll-inducing is your complaining about that since you've removed the address from the stooop page it will be lost if we meanies won't let you put it on the personal page . Just add it back to the stooop page and everything will be solved . It's not a requirement that all personal pages have an email address , or that personal addresses only appear on the personal pages . It makes things a lot easier if people follow that practice , but it's both too much work and too intrusive to enforce it by rules or by editing . As a side note , you did scrape up Jean-Luc's address from somewhere else on the wiki , but something tells me you haven't tried contacting him ...

Lastly , you left a note , which I deleted very quickly due to being very angry at that point , about using % pseudo-prompts and # -> return value markers (and # => for output , which I didn't use here) . I'm afraid it's a rather common convention both on this wiki and in many other places , and it does make the listings clearer . It's too bad if you find it ugly , but I'm not about to change it right away (I might some time in the future , of course) .

PYK: It's a common convention , but it's uncommon to use it in combination with %-style shell emulation , because the whole point of emulating an interactive shell is that the shell prints output to the screen . Many snippets on this wiki use one style or the other , but not both simultaneously . Your examples at Splitting strings with embedded strings would be more readable if you chose one style or the other for them .

BTW , there's no record of Jean-Luc actually ever creating or editing his namesake page on this wiki .

PL 2014-03-09: I'm going to have a lookaround to see what other people use . Myself , I actually prefer omitting the prompt characters since that format allows you to just copy and paste code into the interpreter . I was using this style mostly because I saw it as the standard convention for this wiki .

Now , speaking of ugly , you seem to favor breaking lines containing nested commands directly after the opening square bracket . That is unusual and looks very off . Most people break the line before the opening square bracket or after the command . Your way of breaking the line saves you a backslash , but that may not actually be advantageous as the backslash provides a visual cue that the invocation continues on the next physical line . Strictly speaking , the opening bracket should provide a cue as well , but it's not as familiar .

In the absence of evidence that someone else created the page , we should assume Jean-Luc made it .

PYK 2014-03-19: I've been wondering how many people out there use that convention . I really like it . Yes , it's unfamiliar on this wiki , but familiarity is only a matter of time , and I think it's a fantastic way to avoid backslashes , which just make me itchy all over . For anyone else wondering what exactly we're talking about , here is an example from Additional list functions :

proc lsplit {ls index} {
    return [
        list [
            lrange $ls 0 [expr {$index-1}]] [
            lrange $ls $index end]]


proc lsplit {ls index} {
    return [list [
        lrange $ls 0 [expr {$index-1}]] [
        lrange $ls $index end]]

The backslash alternative looks like this:

proc lsplit {ls index} {
    return [list \
        [lrange $ls 0 [expr {$index-1}]] \
        [lrange $ls $index end]]

PL: I find it atrocious , but to each his own . If you want to use it in your own code , by all means go ahead . If you change other people's code in this way (as you have on the page mentioned) I might change it back to the original author's style . That's another boundary you need to respect: coding style .

aspect: While I'll usually use intermediate variables to avoid long and hard to read lines , sometimes a variation on this indenting style will make its way into my code . I find it more pleasing than the above because it resembles convention for indenting with braces , can generally be read without counting brackets and permits comments in a natural style . A second level of such indentation (such as breaking out expr into its own line) quickly gets unwieldy though .

proc lsplit {ls index} {
    list [
        lrange $ls 0 [expr {$index-1}]
    ] [
        lrange $ls $index end

AMG: Sorry to drag the discussion away from backslashes , but there's something else I think is worth mentioning . Per tip 176 [L2 ] , the above can also be written:

proc lsplit {ls index} {
    list [lrange $ls 0 $index-1] [lrange $ls $index end]

I avoid this feature because using [expr] is faster . As expected , [tcl::unsupported::disassemble] shows that this version of [lsplit] involves string concatenation , whereas using [expr] performs subtraction directly . A more ambitious bytecode implementation of [lrange] could optimize this .

PYK: Really ? Isn't the concatenation already done by the time the lrange implementation sees the argument ? I'm missing something here .

AMG: Yes it is , which is almost certainly why the current bytecode system doesn't attempt to optimize . Just run [disassemble] and see for yourself . For comparison , try again but with $index-1 replaced with [expr {$index - 1}] .

aspect: I know I'm breaking the flow of discussion on this page , but I'd like to add my voice to PL's in suggesting that you please refrain from line-wrapping paragraphs in wiki pages . Regardless of arguments for or against adhering to 80 columns (which I submit are completely irrelevant to text that is edited in an html textarea) , the diffs for edits which enforce this limit are entirely confusing and obfuscatory . As someone who likes to keep an eye on wiki activity via recent changes , this is quite painful and frustrating - I simply can't tell what changes you have made using any of the wiki's builtin diff capabilities . It's also worth observing that for other wiki editors to adopt your convention they would have to use an external editor which performs the line wrapping , which is not always an option - I can tell you that hand-wrapping paragraphs in a textarea is a tedious exercise :-) .

PYK 2014-03-28: OK , Done . It's a deep part of my editing groove , so bear with me while I make the switch .

PYK a little later , wishes the world could just accept RFC 2646 . Yer all unwashed heathens ;)

EMJ RFC2646 says
Note that this memo describes an on-the-wire format . it does not address formats for local file storage .

Were you thinking the Wiki should apply RFC2646 on save ? And convert back for presenting for edit ? I can't see any way that this wouldn't upset the Difference mechanism as badly as re-flowing by an external editor .

This is a conflict between three different needs:

  1. Wiki editing is meant to be easy , you follow the Formatting Rules , that's all , no other prescriptions . The renderer , whatever it is , follows the Formatting Rules , that's all . I don't know of any wiki markup (or even "simple text" markup) that isn't like that .
  2. The difference display is used by many to see what has changed . It was added to this Wiki , first externally , and then built in , because it was very useful and popular . It is , as has been said , ruined by re-flowing .
  3. The perfectly understandable desire to use your favourite editor for anything other than a trivial edit .

As far as I am concerned , that is also the priority order of those needs . Easy for me :) , my external editor (Textpad) will soft-flow for easier editing without introducing any actual line-breaks (unless I tell it to) .

PYK 2014-03-25: Apparently , not everyone is into long lines . After I edited Simple Base64 Gif encoder , the long lines were reverted to the original shorter lines . I'm going back to 79-char lines :/

EMJ: but it's not about the length of the lines , it's about not changing existing line boundaries for lines you aren't actually editing !

PYK: For me it's about giving pages a uniform text style . I want the raw text to look as good as it can . One problem with long lines is that even though many editors , including vim , can soft-wrap long lines , they won't "soft-indent" them to match a previous indentation . Lines with a 79-character limit solve that problem .

EMJ: Is there anyone else who cares what the raw text looks like ? I care about the difference between "someone has fixed two spelling mistakes and added one new link" and "someone has re-written the whole thing" , and this is a difference your edits are concealing ! For pages that I care about , that difference is enormous , and I have to do my own comparison in the second case in case I have corrections .

PYK 2014-03-26: Yes , I can see that that's a problem . I wonder if it could be solved with a more appropriate diff algorithm .

RLE (2014-03-26): Probably , but the wiki does not yet have that "more appropriate diff algorithm" installed . It has its current diff algorithm , which creates a lot of false differences for changes in line lengths , quite obscuring the actual changes in many instances . So until you've 1) discovered that "more appropriate" algorithm and 2) managed to get it installed as the wiki's diff algorithm , please don't change the line lengths for existing pages . It gives your edits an extremely low signal to noise ratio , making them much harder to follow for anyone else than they would otherwise be .

aspect: fwiw , while I think writing a text-wrapping-aware diff algorithm would be a thankless task , I can see merit in a wiki page renderer for text/plain that reflows paragraphs to 79 characters (or any other specified width) . This should be a pretty straightforward matter , applying the wiki's formatting rules to text-blocks that have first been un-wrapped to show their logical structure (wink) .

AMG: Whatever external editor you're using doesn't play nice with non-ASCII characters . See [L3 ] for an edit you made which had the side effect of converting "Евробайт" (Eurobyte) to question marks "????????" .

AMG: It happened again ! Now see [L4 ] .

AMG: And again . [L5 ] . Please , please fix your editor ! This Wiki used to be plagued with encoding corruption problems due to bad browsers , and lots of time was sunk into cleaning up after everyone's edits . Don't bring this old problem back . Question marks are even worse than the mojibake we were getting because they're stealthy .

PYK: I've got this fixed now , and will try to make sure vim doesn't end up in latin-1 mode whenever I'm editing this wiki .

AMG: The problem happened again . See [L6 ] . I fixed it in the subsequent edit .

AMG: Haha , in the process of editing this section , I see the above Eurobyte was also corrupted at some point .

PYK 2015-02-23: Arggh ! I've been playing musical laptops lately , and every time I install gvim in Windows and forget to add "set encoding=utf-8" to the rc file , I end up in gvim's default latin1 mode . If only the gvim default was utf-8 ! Thanks for catching it (again) . I've added the configuration to my rc file on this computer . I know , I know . I should be using fossil to manage my rc files across computers . It's on the to-do list .

AMG: You lost my sample code at [L7 ] when you moved the terminal stuff from ANSI to terminal control sequence . I added it back [L8 ] . Please be more careful !

EMJ: Fixed the character set above .

EMJ: In normal English usage , a comma immediately follows the preceding word and is followed by a space . There may be cases where an extra space in front is a good idea , but there is always a space after .

PYK: I prefer to place the space before the comma ,like this . Language is a bush .

EMJ: So what other easily accessible things may I read that consistently do that ?

PYK: Transact-SQL Formatting Standards (Coding Styles) ,Robert Sheldon ,2009-08-25 . I think the space-before-comma style makes more sense in English as well . Come to think of it ,I rather like this space-around-sentence-terminators style as well . Come to think of it , maybe commas would also look better that way . Yeah , they do ! pyk walks off enormously-satisfied with this new puncuation scheme . . .

EMJ: He doesn't actually recommend any single format , and he's talking about a computer language !!! In case you didn't notice , every comma in the English text of the article has a space after and not before . If he didn't write it like that someone at the publishers will have changed it , because it's the normal standard for written English .

PYK is amused by the irony of Tcltrippers that have problems with non-standard use of punctuation marks !

EMJ is not particularly amused at being referred to as a "Tcltripper" . You seem to have made up the term (nothing in Google) and it doesn't sound to me as if it's meant to be complimentary . I like Tcl , I have written lots of stuff using it (never for money , though I have written lots of stuff in lots of computer languages for money) , but there is no way I am comfortable with that term .

More importantly , there is no correlation whatsoever between the use of punctuation characters in any computer (or mathematical) language and their usage in a written human language . Computer languages need to use punctuation (and other non alpha-numerics) for special purposes - trying to avoid that leads to COBOL at one end of the spectrum (though a missing full stop can be a nightmare bug) , or APL at the other (invents loads of its own characters , though many of them are "borrowed" from somewhere) . Human languages have their own rules , which do evolve , but written language evolves much more slowly that spoken language , and unusual usages in writing tend to say "subculture" or "unprofessional" or "ignorant" . Even the first is often viewed as a negative .

PYK 2014-05-10:

Yes , that's precisely the irony I'm refering to . The unusual use of punctuation in Tcl has lead programmers to be biased against it in exactly the way you describe , even as they fail to see its superiority ;)

The correlation between the use of punctuation characters in computer and mathematical languages is that they are used for similar purposes , and in many instances have the same semantics . Language evolution is often propelled by those who come to be acquainted with more than one language . pidgins , creoles , and dialects illustrate the influence environment has on language . Written language is less fluid than the natural language it attempts to encode since it is often conceived in an academic setting , imposed through politics , and transmitted via laborious mechanisms . I notice that you only use one space after a full stop . Until quite recently , this would have been proscribed , but it isn't so relevant in the electronic age . Linguistic studies lead to greater awareness of , though not necessarily more respect for the "rules" . Who better to evolve the punctuation style than computer programmers , a sub-species that is multi-lingual by nature , and for whom punctuation is often the very point of the matter ?

I like the term "Tcltripper" because it alludes to the psychedelic euphoria that one experiences when coding in Tcl :)

uniquename 2014-05-28 :

I would just like to let 'PL' and 'EMJ' (whose comments on PYK's 'behavior' on this wiki are posted above) know that I agree with them . In particular , I think PL's statement that PYK's "attitude is alarming and completely inappropriate for a wiki editor" is right on .

I think PL is showing amazing restraint in his 'discussions' with PYK .

A growing number of my code contribution pages on this wiki have suffered at the hand of PYK . For example , I take offense to the fact that he changes section headings so that they have a little blue 'edit' link next to each section heading . I think this is a distraction for the reading of the text . Furthermore , it serves no useful purpose because anyone who wants to make a comment can make it by simply inserting their name and date along with their comment ---preferably at the bottom of the page unless there are compelling reasons to alter the author's text flow by inserting the comment in the body of the text . (There needs to be a few 'sign-posts' on this wiki that advise people to add the day's date along with their added comments . Examples of the failure to do this abound just above .)

How are wiki editors (a.k.a. wikignomes) 'licensed to edit' (OTHER PEOPLE'S content and formatting) on this wiki ? Are they approved by Cliff Flynt or some governing board ? Are they self-appointed ? I think any wikignome should be required to contribute at least 10 original scripts on this wiki before they qualify to be a wikignome . And there needs to be some clarity on who is the contact for complaints about the behavior of 'wikignomes' .

PYK 2014-05-28 : Blaise , no need to speak in third person on my namesake page - I'm right here !

I think there are a couple of good approaches to take to influence another wiki editor . The one I tend to favour is to just make edits that you think are an improvement . For example , this is the first time I've had this particular complaint about my work in organizing things under headers . I'm doing this on a lot of pages becuase I think a uniform style looks good . I'm not sure which page you are talking about , but if you just undo my changes there , that would alert me that you didn't think the changes were appropriate , and give me a chance to compare my attempt with yours . As I've said before , I think wikis , like Ethernet , are designed to be contention-based . That's not to say that there's no place for etiquette , and it's often a nice touch to leave a message for another editor about your rationale for any conflicting changes . Now that I'm aware of your negative reaction to the organizatino of a page under double-star headers , I can avoid doing that on pages primarily authored by you , and also reconsider whether it's good style for other wiki pages as a whole .

Another suggestion I have , which I've also mentioned before , is that it might be a good time to start a page for building consensus , or at least voicing opinions on a common style for pages , e.g. a wiki style guide . I was editing the wiki fairly actively for over a year before I heard a single peep of feedback from another editor regarding my changes . I was aware that I was doing things a little differently , but had no idea whether or not the changes were welcome . I have no intention of trying to please all of the people all the time , but definitely want to work in tandem with other editors rather than at odds with them . Here is the feedback I've received so far , and how I've responded :

[expr] is ugly syntax
as a result of this conversation , I hit upon another style where commands like expr are presented in a fixed-width font with no enclosing brackets . So far I haven't received any feedback at all about this new style .
permission is needed to edit pages of individuals
I disagree , but at the same time , I would defer to the wishes of the person who is represented by the page . I've never had a conflict directly with an individual who was the subject of a certain page .
breaking lines at the 79th column
I've submitted a patch that would make this a non-issue , and until the patch is implemented in production , I've stopped reformatting lines to a certain width , even though not doing so is a hindrance to me personally .
non-standard spacing around punctuation in English text
I think commas as well as periods that end a sentence look better when they are separate words , i.e. surrounded by whitespace . This opinion is in conflict with standard style . This issue is a good example of how accepting a contention-based approach to wiki editing plays out . I write in the style I think is best and , other editors change it to the style they think is better , and I don't fight that because I'm aware that my opinion is in the minority .

ETA didn't refer to another an individual . It was acronym PL wrote . (uniquename 2014-06-09: Duly noted . Thanks .)

PYK 2014-06-02: I've been reviewing the use of the double-asterisk section headings , and I agree that they are visually annoying , taking up too much vertical space . I think the best way to address that , is through modification of the wiki style sheets , because logically , the double-asterisk headers are probably the right section dividers to use . Wikipedia uses == for that level of section heading , but the visual presentation is more palatable .

AMG: Concerning your preferred punctuation spacing style .

Your edit history suggests you place a great deal of importance on consistency , especially when you reformat entire pages to resemble the style developed on other pages . But please do give a care to respecting consistency in grammar . The grammatical style of this wiki has been long established by the overwhelming majority of experienced English-speaking wiki editors , essentially everyone other than yourself . You introducing your preferred spacing has diminished the consistency of this wiki in ways instantly visible to all readers . I find it especially jarring when you modify (or adapt , as you may prefer to say) the words of others to suit your style .

Much time has been spent undoing your spacing , and no one but you has spoken up in favor of your actions . This wiki is a means of communication . It's not for one person to record notes to him or herself . It's not even for editors to collaborate . It's for everyone , especially read-only users who never make their presence known . And so , its conventions must suit the majority of its users , not just a single individual , no matter how highly motivated . When time is spent undoing your spacing changes , that counts as a vote in favor of traditional grammar , as does the nonexistence of your spacing style in the wild outside the Tcler's Wiki .

As with many things in this world , technical superiority is not the last word . Quite often , inertia trumps everything else . Grammar is such a case . Allow it to change gradually , but if you take a leading role , you will only succeed in upsetting everyone with whom you communicate , and they will come to resent you and stubbornly defend their positions even when it is illogical to do so . It's basic human nature . Please respect it even if you disagree , or else you will not be seen as an effective communicator .

And again , this wiki is a means of communication between a great many people , including some who are no longer alive , and hopefully including innumerable people not yet born . But when one person widely edits it in a way that is off-putting to its readers , it unfairly reflects poorly on the entire Tcl community , more than negating all the positive aspects of your work and that of the Tcl community in general .

PYK: AMG , since you feel strongly enough to allocate the time to compose this response , I probably won't do it anymore . I still prefer it , and I'd also prefer to see the wiki remain wild and experimental , but without sacrificing accurate content .

uniquename 2014-06-09: I know you are right here . That is why I put these comments on this page . So you can see the comments . But you have proved by many of your comments above that you are insensitive and clueless . There is no sense in me trying to change your mind on anything because it is made up . So I talk to 'PL' , not to you . Like 'PL' says above (on your drastically changing people's pages , even when they are still alive , without checking with them first): "I find your rather cavalier attitude to this quite upsetting ." I would replace 'rather cavalier' with 'extremely cavalier' .

You seem to think we all have time to check all our pages on this wiki for changes that you have made , and then undo them if we do not like your changes . No . That is not the right approach . (Especially since we will have to keep checking the pages to see if you changed them back again because you are convinced that you are The Arbiter-in-Chief .) Unless it is something minor (like a spelling error) , you should not be making major changes to people's pages . I do not have time to be checking for changes you have made .

By the way , I just saw (a couple of days ago) that you replaced the code of a large script on one of my pages and left the message that if I wanted to change it back , I could start a new page . No . That is not appropriate behavior . You should start the new page , not me . In fact , I was going to return to that script in the next few months and add a pretty significant enhancement .

I am not dead (yet) . And I am not inactive on this wiki . Keep your clueless hands off of my pages until you check with me . And keep your hands off of most other pages , like the Fontaine page that you and PL talk about above . If I look at Fontaine's page , I would like to see what he wrote --- not your droppings .

By the way , your website link at the top of this page and on the Tcl'ers page seems to be dead . How about editing that ?

PYK 2014-06-10:

The page uniquename is referring to above is Functional Imaging with a High-Capacity GUI . Contrary to what uniquename states above , the message I left there said that I would be happy to start a new page . I was not asking him to start one .

I made a significant and actually pretty interesting modification to the code , and left an analysis of the interesting technical issues in the code and of how it had evolved from RS to uniquename to myself . Fixing the code was tricky , and I worked on it for a couple of days to find some kind of solution . I actually expected uniquename to take an interest in the changes and then decide whether he wanted to let them stand or revert back to the original code . I see this Wiki as a great medium for collaboration , and am frustrated that uniquename is so upset by my changes . My stance on the issue is that the history function of the wiki allows an editor to revert a change in moments , and also allows readers to use the history function to see the evolution of code over time . Good-faith edits like the one I made to Functional Imaging with a High-Capacity GUI should not be met with vitriol , but should be encouraged . uniquename is always free to revert the edit , in which case I'll find my changes in the history and put them on a new page .

uniquename has created a large amount of valuable content on this wiki , practically a book , complete with a table of contents on his home page . While I applaud an effort like his , the fact of the matter is that this website is fundamentally intended for collaborative editing , and it behooves all of us to remain good-natured about conflict that arises . I suggest that anyone who really wants to retain editorial control of their comments and code should publish it elsewhere , not on this wiki . Chisel is a good place for such content . It is currently maintained by Roy Keene , and is likely to be continuously maintained by the Tcl community .

If the edits of an individual become disruptive to the wiki , the people to contact are Jos Decoster , Clif Flynt , Steve Landers , Colin McCormack , Steve Redler , or (ahem) me .

This discussion was imported from JSON .

PYK: JSON is yet another syntax that is inferior to Tcl , yet somehow has gained more traction .

samoc: What a load of .... A syntax is "inferior" ? It has "gained" what ? How is this useful information for Tcl users . I for one have had enough of the attitude of "PYK" . If I want streams of ignorant opinion I'll go and read YouTube comments . This wiki is intended to allow Tcl professionals to share experience and information . This page is here to help people who need to use JSON with Tcl . PYK , please act like an adult . Your behaviour is not welcome on our wiki . Some of us are trying help each other to get serious work done .

PYK: regarding samoc's criticism , my criteria in this case are conciseness and legibility , which happen to be the primary design goals of JSON , so by its own criteria , its syntax is inferior . Here is a comparison so people can judge for themselves:

JSON syntax:

    "title": "Example Schema",
    "type": "object",
    "properties": {
        "firstName": {
            "type": "string"
        "lastName": {
            "type": "string"
        "age": {
            "description": "Age in years",
            "type": "integer",
            "minimum": 0
    "required": ["firstName", "lastName"]

How it would look in Tcl:

    title {Example Schema}
    type object
    properties {
        firstName {
            type string
        lastName {
            type string
        age {
            description {Age in years}
            type integer
            minimum 0
    required {firstName lastName}

aspect interjects 2014-07-28: The major disadvantage with Tcl for storing this sort of data is that you need to know the structure before you attempt to parse it . Is "Example Schema" a string , a list or a dict (this problem is elaborated in 23526) ?

Worse , the problem sticks around if you hold the structure in memory as a native Tcl data structure . Short of unsupportable hacks like tcl::unsupported::intrep , the only way to perform a "generic" traversal (say .. to pretty-print) is to pass along information about the schema . Contrast this with XML or JSON where you can trivially map over the object , dispatching on the type of each value , which is carried with the value . To achieve this in Tcl one needs to use a higher-order format such as Huddle or some sort of object . I think there's a good example somewhere of representing JSON as a pair of parallel arrays , where the above document would contain entries like:

values(properties,age,description)  = "Age in years"
types(properties,age,description)   = string

Ironically , I have found that a good object structure to represent this sort of data in memory is ... XML ! We can parse a structure like above into a dom object , typing nodes and attributes according to our schema (which is guiding the parser) and then we have an object which supports generic traversal *and* mutable references to its parts . Neither of these features is supported well by Tcl's native collections , but with tdom we get a really nice API for doing tree-like things to tree-like data .

I find this both ironic and satisfying: for all my loathing of XML as a serialisation format , it turns out to be a quite good intrep for tree-structured data - even when that data is stored to disk (or transmitted to other processes) in a friendlier form , such as a Tcl script .

PYK 2014-07-28: The only types that JSON provisions in its syntax are string , number , object , array , true , false , and null . I'm not sure that's so necessary to convey , since the consumer would probably already know the intended interpretation . If it turns out to be necessary , this could be addressed in Tcl with a rule that all values are lists . Interpreting everything as a list also solves the disadvantage you point out of holding the structure in memory as a native Tcl data structure , at least as far as a comparison with JSON is concerned . This list-oriented syntax is still easier to read than JSON:

    title {{Example Schema}}
    type object
    properties {
        firstName {
            type string
        lastName {
            type string
        age {
            description {{Age in years}}
            type integer
            minimum 0
    required {firstName lastName}

I haven't worked with JSON , but as far as I can tell , this syntax conveys all the relevant information that JSON would , no ? True , it substitutes "this is an atomic value" with "there is only one value here" , but where in practice would this matter ?

JSON syntax results in some quoting issues that are fairly subtle , so even taking some of the complexity of Tcl list formatting into account , I think Tcl still wins .

Yes , the main contribution of XML is not its syntax , but the data model it specifies . I have to say , though , that whenever I use a serialization format lacking closing tags , the loss of potentially valuable error-recovery information makes me uneasy .

Here is the example from json.org , in Tcl , JSON , and XML:

    glossary {
        title {example glossary}
        GlossDiv {
            title S
            GlossList {
                GlossEntry {
                    ID SGML
                    SortAs SGML
                    GlossTerm {Standard Generalized Markup Language}
                    Acronym SGML
                    Abbrev {ISO 8879:1986}
                    GlossDef {
                        para {
                            A meta-markup language, used to create markup
                            languages such as DocBook.
                        GlossSeeAlso {GML XML}
                    GlossSee markup
    "glossary": {
        "title": "example glossary",
        "GlossDiv": {
            "title": "S",
            "GlossList": {
                "GlossEntry": {
                    "ID": "SGML",
                    "SortAs": "SGML",
                    "GlossTerm": "Standard Generalized Markup Language",
                    "Acronym": "SGML",
                    "Abbrev": "ISO 8879:1986",
                    "GlossDef": {
                        "para": "A meta-markup language, used to create markup languages such as DocBook.",
                        "GlossSeeAlso": ["GML", "XML"]
                    "GlossSee": "markup"
<!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
    <glossary><title>example glossary</title>
                <GlossEntry ID="SGML" SortAs="SGML">
                    <GlossTerm>Standard Generalized Markup Language</GlossTerm>
                    <Abbrev>ISO 8879:1986</Abbrev>
                        <para>A meta-markup language, used to create markup
languages such as DocBook.</para>
                        <GlossSeeAlso OtherTerm="GML">
                        <GlossSeeAlso OtherTerm="XML">
                    <GlossSee OtherTerm="markup">

AMG: JSON gained traction because it is implemented terms of a foundation already widely available in web browsers , that being JavaScript/ECMAScript . Anything other than JSON , XML , or unstructured data would have required implementing a slow , costly parser in JavaScript , so of course JSON succeeded .

Also PYK , if you are going to make a comment that is editorial in nature , please sign it with your name . Otherwise someone could come to this wiki for the first time , see your words , and wrongfully conclude they are representative of the Tcl community as a whole and be turned off by their perception of us as sore losers who take any opportunity to bemoan the fact that Tcl was not adequately promoted as the language of the web way back when it was the first and only browser scripting language .

PYK 2014-07-27: "Losers?" Speak for yourself ! :P I'm on the fence about discussion-format on wiki pages . I tend to think it would be better if everyone just jumped in and edited stuff they thought was inaccurate . Attributed statements tend to fossilize because no one wants to touch "someone else's" writing .

samoc: PYK , calling AMG a "loser" is completely unacceptable . I for one think it would be best for all concerned if you took a break from the Tcl wiki for a while . Name-calling is not welcome here . Please try to show some decorum .

PYK: That was joke . I know AMG , he knows me , and we're not all always completely straight-laced around here . Especially me . I'm usually unlaced . For the record , I hold AMG in high regard .

Moved from samoc page (PYK , the samoc page is not intended as a place for discussion . You have been informed): PYK 2014-07-28: I undid your last reversion of JSON because it entirely removed the examples I posted , which I intend to remain on that page . If you really think they shouldn't be there , could you provide a rationale for that decision ?

samoc: The premise that Tcl is has a relationship of inferiority or superiority with JSON (or XLM) is inherently flawed . They have vastly different design goals and they have vastly different real world uses . Read the detail of the JSON page for more info . Read what TCV slebetman say on that page . I have considerable experience with Tcl and JSON (and XML) . I don't think that there is any value to the JSON page additions flowing from the comment: "JSON is yet another syntax that is inferior to Tcl" . The issues of Tcl/JSON conversion/equivalency/expressiveness are well covered already .

If the "inferior" comment was supposed to be some kind of advocacy , take it to an advocacy page . Please don't deface an important professional resource with uninformed declarations . Show some respect to the people who have real knowledge on the subject and have taken the time to share that knowledge on the wiki . If you have read a page , and done some research . and written some code , and still can't figure something out .... ask a polite question at the bottom of the page if you must . But really , newby questions are better suited to a forum , or mailing list or stack-overflow . You will find that asking people to help you understand something is much better received if you have obviously made an effort to research it on your own first .

PYK: I'm sure it is nice to be a seasoned professional who has no time for newbies and their laughable ignorance , but not every reader of this wiki has got 20 years of programming experience under their belt , and I *want* newbies , including myself , to feel at home discussing things of interest to them on this Wiki . I'd rather see newbies post their questions and ideas here than on a forum or a mailing list . I do not share your view that pages such as JSON must be off-limits to newbies . On the other hand , I appreciate the challenges of making technical information easily locatable . I believe that judicious copy-editing and careful organization can go a long way toward improving the situation . This wiki could grow various features that would facilitate content navigation , such as page scoring along dimensions like level of expertise , signal-to-noise ratio , primary format (discussion , tutorial , encyclopedic) , applicability to current versions of Tcl , etc . I intend to contribute to the development of such features .

Regarding your namesake page , how then do you expect individuals on the wiki to communicate with each other when the need arises ? -- samoc: To me , the wiki is about pages , not about individuals . Communication relevant to a page happens on the page (sometimes behind a "discussion" button)' . For communicating with individuals I use email mostly , and GitHub and forums a bit .

Regarding JSON , TCV is discussing a lossless representation of JSON in Tcl , and slebetman's topic is the representation of Tcl data structures in JSON . The content I added was about something entirely different: A Tcl syntax that could be used as a more readable , but equally effective alternative to JSON . The point was not that it was commensurate feature-by-feature with JSON , but that , like the lack of lack of linked lists in Tcl , what is missing is no real loss . Rather than deleting the content without explanation , you could have moved it to a lower position on the page , or even to another page entirely , and applied your knowledge on the subject to an explanation of the flaws of the proposal . So far , all you have done is cite your own expertise , point to the content of other people , and proclaim my content worthless . Here's a question for you: JSON syntax makes it possible to have a value , "3.14159" , which is manifestly a string rather than a number , but JSON lacks schemas , implying that the consumer is aware of the nature of the content . Have you ever run across a real situation where this additional information matters to the consumer ? If so can you provide examples that would not be resolved by trivial changes to the communicated content ?

samoc: For (almost*)all intents and purposes , JSON is a object-serialisation notation used by web service APIs . To say it "lacks schemas" is not really true . Every relevant web service has a concise definition of the relevant "schemas" .




The software engineer writing Tcl code to talk to a JSON web service has two main tasks:

1) Parse JSON from the web service into some form that your Tcl code can easily access . Tcllib's json::json2dict does this nicely http://tcllib.sourceforge.net/doc/json.html .

2) Generate JSON to send to the web service . The JSON page as a few examples of this (I added another one today in case that helps someone) . http://docs.activestate.com/activetcl/8.5/tcllib/json/json_write.html is another . In this case the task is to generate exactly what the web service expects . The idea that the web service might have used a different format that looks like a Tcl list is perhaps interesting , but it doesn't help to get things done .

So , "...a real situation where this additional information matters to the consumer ?" yes . If the API spec says "send blah as JSON" then that's what you do . You can't leave bits out because you feel that they are "additional" .

If you want to propose or invent a new data serialisation format for web services (or anything else) that's great , propose away , argue the merits etc . Maybe put a link to that from the JSON page . But writing "this is better than that" on the JSON page is not useful . JSON is what it is .

You can go to http://en.wikipedia.org/wiki/French and write "French is yet another language that is inferior to Korean , yet somehow has gained more traction ." but what does that achieve ?

You say "...I want newbies , including myself , to feel at home discussing things" . That's fair enough , but this wiki is not your home . Try to behave with the manners and respect that you would if you were visiting someone else's home .

* If you're writing Javascript code you might be using JSON as a way to serialise objects to file or to a database . In this case the , "schema" is implied by the types of the serialised objects . If you are writing Tcl code to read a file like this you can treat the original JS code as the "schema" .

But really , if you had taken the time to play with some code that talks to a web service , you could have learned all this on your own .

I think one of the first ones I tried was Github Issues , it's about 5 lines of code and 30 mins of experimentation to try it out .


proc github {api query} {

    set http [http::geturl https://api.github.com/$::github_repo/$api?$query_string \
                 -headers [list Authorization "Basic $::github_auth"] \
                 -query  [http::formatQuery {*}$args]]
    json::json2dict [http::data $http]

proc new_github_issue {title body} {

    set query [json::write object title [json::write string $title] body  [json::write string $body]]
    github issues $query

PYK: Nothing in this reply is new information for me , and most of it doesn't address my question . Therefore , I think you're misapprehending what I'm getting at . The part that does address my question (do consumers of JSON really need the type information JSON supplies ?) illustrates my point : The provider publishes an API that lays out , in a format understandable by the developer , but not the program , the schema for the content passed via JSON . Therefore , the consumer already knows what type of data to expect , and the type information provided by JSON , being redundant , being redundant , is not particularly useful other than as a machine-parsable format . This is certainly true for the Githup "Issues" API you refer to . The Amazon DynamoDB does specify that AttributeValueList is of variable type , but given the Tcl syntax I proposed , it would be trivial to amend the API (-- samoc: I'm sure if you ask Mr. Bezos nicely ...) to include an additional element specifying the interpretation of AttributeValueList . Overall , it seems that you are interested in discussing working with JSON as it is , and I am interested in discussing the merits of an alternative serialization format . Our divergent interests do not warrant attempts by one to suppress the content of the other , although some reorganization may be in order . I also think its relevant to a certain kind of reader accessing the JSON page that there is a Tcl syntax which beats JSON at its own game . Not all of us are beholden to "industry standards" that dictate that we should use the technology-du-jour because the boss said so . Many hobbyists and tinkerers (I consider myself one of these) are just interested in what interesting ways they can employ their nifty tools .

Regarding French , if the Ministry of Culture proclaimed that the phonetic system of written French was the best in the world , someone would almost certainly point out that that distinction in reality most likely belongs to Hangul .

samoc: PKY writes:

 * "JSON is yet another syntax that is inferior to Tcl" ,
 * "I haven't worked with JSON" ,
 * "I am interested in discussing the merits of an alternative serialisation format" .
 * "there is a Tcl syntax which beats JSON at its own game"

Perhaps you should start a new page for your new syntax .

PYK 2014-08-02: Done .

aspect 2014-11-03: I see some changes to list (revision #195) that seem to be in response to an teacup-storm on usenet . I think this is a mistake: casual readers are going to be confused that list is talking in the first sentence about backslashes and eval , the mistake of treating a list as a string (demonstrably by the usenet thread) is quite uncommon and the pre-existing , bolded reference to "Canonical lists" is sufficient to make the necessary information readily available .

PYK 2014-11-03: Yes , I worried a bit about the complexity that I was introducing into the first paragraph of the description , but the quoting operation of list is pretty fundamental to its operation . The contents that were previously there were also largely mine , and I felt that the phrase "armors its arguments" left something to be desired . I almost left the reference to Canonical Lists in , but finally decided that section was accessible enough without the reference . The description of the quoting operation of list could go back where it was , in the third paragraph . Feel free to hack away at that page , and I'll give it some space until some future itch to revisit it bites .

PL 2015-02-17: I see you have been busy changing occurrences of "element" or "item" in discussions about lists to "words" . The problem is , in very many cases elements/items in lists aren't words , so unless one is absolutely certain that the code under discussion will only ever deal with words (list elements without white space in the loose sense , list elements with only alphabetic characters in the strict sense) , it is much better to use terms like element or item .

PYK 2015-02-17: A list , by definition , is composed of words . Of course , this is by the definition I just added to list , but it's correct :P

(PL): that's the rub , isn't it ? You prefer your own definitions to the ones used by the documentation and by the Tcl community . In most of your edits , it seems , you use your own idiosyncratic definitions , some of which aren't even internally consistent , which mostly serve to obfuscate or distort the content . No , it's not correct to define a list as being composed of words . Not in Tcl , not anywhere .

PYK 2015-02-17: In this case , it's not idiosyncratic . A list has a specific relationship to the dodekalogue which has remained in want of better articulation . The list format is specifically designed such that a list can be passed to eval as a script containing a single command . Clearly defining the format of a list in terms of the dodekalogue will hopefully serve to hasten the progress of those on the road from acolyte to high priest (including myself) . A list is indeed a script containing exactly one command . Therefore , the proper term for an item in a list is "word" . If I'm wrong , prove it rather than issuing ad-hominemn attacks , but I'd prefer as a response excitement over the progress in bringing consistency to the terminology of Tcl .

(PL): you've got it backwards . A command (and , obviously , a single-command script) is one of the things that has a proper-list representation . Due to the flexibility of the language , most if not all possible lists could be the invocation of a command , but that does not mean that a list , in the general case , is a command . The structure of a list constrains a command , but the rules that define a command does not constrain a list . Ad-hominems ? Please point out where I cross that line . I'm not criticising you , I'm criticising the way you edit . You are not bringing consistency to the terminology by redefining terms in ways that are counter to the documentation and common usage .

aspect: purely in terms of consistent terminology , I much prefer "element" . Things in lists are referred to consistently as "elements" in programming books , the Tcl manual , references for C++ vectors , Ruby , Python , Javascript , Bash , Scheme , PHP , Haskell , Factor ... I don't think it serves clarity at all to use "word" in this context . Possibly the reverse , as "word" invokes syntax , which is not what one should be thinking about when manipulating lists with list commands .

(PL): search for the word "word" on the man pages for the list commands . Apart from matching the KEYWORDS heading , you will find very few occurrences of the word . Only three pages have the word in any context at all , and none of the pages define the structure of a list in terms of words . The term "element" is used throughout . You might want to pay special attention to the documentation for llength , which spells out that an element isn't always a word .

pooryorick: The most important usage of the word , "word" is in rule 2 of the dodekalogue . Whether or not it gets articulated in various wiki pages or the Tcl man pages , the format of a list is inexorably tied to the dodekalogue . Some of the rules of the dodekalogue are relaxed because they aren't needed when a script only contains one command , and the command substitution rule is relaxed to achieve the design goals of a list . PL's characterizations are incorrect on a few counts . First , a list is , in the general case , a script containing exactly one command . There is no such thing as a list which is not a script containing exactly one command . Second , "element" is a general term , but in the case of Tcl lists , the elements are words , every last one of them , and that's established by the dodekalogue . Third , the documentation for llength only points out that elements of a list are not words in the dictionary sense . The whole point of that statement is to distinguish between "word" in common usage , and "word" as defined by the dodekalogue and applied to lists . It isn't wrong to call components of a list "elements" , but it's more apt to call them words . There is no such thing as a list element that is not a word .

(PL): Nearly everything you wrote in the preceding paragraph is wrong . The dodekalogue does not describe lists (the data structure) . The only thing in Tcl the dodekalogue sets up rules for is how commands are evaluated . Yes , that means that the meaning of "proper list" depends on the dodekalogue , but it doesn't mean that the terminology used in expressing the dodekalogue spills over into the terminology used in describing e.g. lists . Every list is isomorphic to a command , but only a select few lists are innately commands (some more lists can be made to be commands , but that's spurious) . Elements aren't always words; for instance in the list {a {b c} d} the first and third elements are words but the second isn't . The most correct term for the components of a list is element or item , the term word sometimes applies but very often doesn't . Ask around , put it to a poll . People who are knowledgeable about Tcl will inform you that you're wrong and that they'd please like to keep the terminology we've been using since the 1980s .

aspect (written simultaneously with PL's last comment above , and not having read it): The DDL defines syntax . You refer in your second sentence to the format of a list , which is a purely syntactic matter . I don't understand the diversion into scripts -- most lists have nothing to do with either scripts or commands , certainly not when one wants to sort or search them .

Word is an important term in the DDL when reflecting upon syntax . It has no place in discussions beyond that . I should think half a century of CS literature writing of lists with elements , itself drawing on a few centuries prior of related mathematical use , and good standing in touchstone literature of the field today , ought to sufficiently qualify the word for its ordinary employment . The list I gave above was not made up , by the way : Sedgewick and Norvig happened to be on a shelf next to me , and a few minutes searching documentation confirmed the rest . I didn't include links through laziness and hoping you were as quick with a search engine .

I think your edits obscure meaning rather than clarify , particularly for newcomers . They introduce an inconsistency in documentation that has existed for decades adhering to the common language of our field to no advantage . It doesn't help that in the below script , {1 2 3} is a word and the further elements of l never appear as words:

set l {1 2 3}
for {set i 0} {$i < 100} {incr i} {
    lappend l [lindex $l $i]

Here , I would say the command substitution on line 3 is a word . Its result is a value -- calling that a word when it never has a string representation in a command is bound to confuse : this just encourages beginners to think of the syntactic structure of a list when it's irrelevant and unhelpful to do so .

Conveniently , a fresh extract from the chat illustrates another source of confusion:

<newguy> What is it to get the first word of a string variable? <regular> newguy , lindex $str 0 ? <otherreg> Not , please . That uses a string as list . That mostly (most times) work - and then it breaks .

"Word" has a common meaning outside Tcl , and using it universally to mean "value" is needlessly confusing and alienating . In the case of lists , it evokes complex syntactic rules , when containment (as in "element") is the only salient characteristic .

My mind boggles that you think defining a list as "a script containing exactly one command" is anything but torturously confusing . As with talking about the command list "adding braces and backslashes" , but I see we've had this discussion before :-( .

Note that I'm not saying you're wrong : these identities exist and are useful to understand . But mixing them into discussions of lindex seems foolishly , even deliberately obscurationist . I think you could much more usefully elaborate these insights on a dedicated page (perhaps called something like composing commands , linked prominently from uplevel and less-prominently from list) , and leave the pages whose topic is list algorithms to use common terms of the art , consistent with nearly every other piece of data-structure literature on the planet .

PYK: I appreciate these comments and the thought that has been put into them , but my opinion is that they represent a deeply-ingrained yet inadequate mental model of lists in Tcl . First , there is the misapprehension that a list is a data structure . In any other language , that's true , but it isn't true in Tcl , where a list is merely a string conforming to a certain format (syntax) . Any structured representation of the list is just an implementation detail . This is a significant departure from the standard concept of lists as data structures , and warrants the domain-specific terminology served up by the dodekalogue . Did Ousterhout shy away from using "word" in a domain-specific sense just because it already had a common meaning ? No ! And neither should we .

Aspect comments that the format of a list is purely a syntactic matter , but it's also the only matter that matters ! Such is the nature of Tcl . everything is a string , not a data structure , but a string . The dodekalogue introduces the term , "word" , and regardless of its usage in other domains , including English , it has a specific meaning in Tcl -- one that applies to the elements of a list . Take , for instance , PL's contention that in the list {a {b c} d} , the first and third elements are words , but the secod isn't . This contention is false . The second element is indeed a word . When written as a command substitution , [a {b c} d] , it becomes clear that it is . Just as [ marks a fresh context for the purpose of finding words in an embedded script , a string value that is interpreted as a list is also a fresh context . List evaluation is a specialized form of script evaluation , as I have detailed on the list page . That's an important point that bears repeating:

List evaluation is a specialized form of script evaluation .

The entire dodekalogue is the specification for Tcl lists , except that some of the steps don't apply . command substitution is not performed , # does not signify a comment , newline and semi-colon lose their special meaning , and no routine is looked up and invoked based on on the name of the command . That's it . Strike those few things from the dodekalogue and you have the complete description of list evaluation . But I think describing it the other way around gets even closer to the truth:

Script evaluation is a specialized form of list evaluation : # where the beginning of a command name is expected signifies a comment , newline and semicolon gain special meaning as command delimiters , command substitution and {*} word splitting are performed on the words of the command , a routine is looked up using the command name , and that routine is then invoked .

Experienced Tcl programmers often advise avoiding hand-crafting lists , and yet everywhere you turn in a Tcl script , there are hand-crafted lists . The most blatant example is the arguments passed to proc , or maybe the most blatant example is commands themselves . Whenever one writes a Tcl script , one is basically doing nothing more than hand-crafting Tcl lists . aspect says the definition of a list as "as a script containing exactly one command" is torturously confusing , and yet when I finally lit on that definition , my doubts about the formatting of a list melted away . If I know how to write valid Tcl script , I know how to write a properly-formatted list . PL says that "the dodekalogue does not describe lists , but now that I've seen the description hidden there in plain sight , I can't unsee it . The dodekalogue contains the entire specification for lists . It's there by implication -- not implication in the common sense of the term as a suggestion , but in the formal sense of the term as a logical consequence''' .

aspect states that containment is the only salient characteristic of list syntax , and that we should use the terminology established in the literature about list data structures to describe Tcl lists . I heartily disagree with both these arguments . Tcl lists may take advantage of nearly all the richness offered by Tcl syntax for scripts . Word splitting is prominent , but it is not alone . Whatever Sedgewick , Norvig , or whoever else says about data structures , Ousterhout had things to say about Tcl . There's no point in muddying the waters by watering down the specific terminology he introduced with generic terminology from similar , but separate domains .

Using established terminology to describe Tcl has often met with failure , as people try to pretend Tcl is something it's not -- some other shell , for example . They initially have some success , but then hit a brick wall and go away perplexed and disturbed . It's better to confront beginners right from the get-go with the expectation that Tcl is a domain-specific language that assigns domain-specific definitions to the terms it employs . To hide these things may at first seem beneficial for the sake of speedy initial progress , but in my experience , this tactic invariably backfires . We do a better service by embracing the unique terminology offered by the dodekalogue and using it to the fullest advantage .

PL 2015-02-18: again , you are using an idiosyncratic interpretation of how the dodekalogue applies to the rest of Tcl . I doubt if there is anyone else in the world (including John Ousterhout) who would subscribe to your view here . I've worked with Tcl for a very long time , back when the dodekalogue was still the endekalogue (heck , I coined the term) , and I have never before encountered anyone who would describe lists the way you do here . Well , I give up , you are apparently not going to listen to reason . It's really sad to see poison this wiki with your misconceptions and fake terminology , but I suppose all good things must end .

PYK 2015-02-18: So there exists this weird beast in which some elements are words and others aren't ? What clarity does that model bring to programming in Tcl ? If there is such a thing , why not describe how the second word in {a {b c} d} is not a word , if it really is not ? Those inner braces seem to be there for exactly the same reason that any word in a command is enclosed in braces . If it acts like a word , and words like a word , then why not let it be a word ? Tcl is replete with little languages , and would recognizing and articulating the little language of the list that is woven into the dodekalogue not better expose its nature as the chameleon in the woolly world of computational expression ?

bll 2015-2-19: I like the new explanation of list better . Can you greatly expand the documentation for word ? Since a word is the basic unit of Tcl , can there be examples and explanations of what a word can expand to ? e.g. A word such as {a b c} can be interpreted as a list . A word such as { set a b; set $b c } can be interpreted as a list of commands , etc . I think PL's comment on comp.lang.tcl "Human reasoning about list elements does not completely match how the value of the list is handled by the implementation layer" is the whole problem . And there are so many different ways of reasoning . I will always view a list as list ::= list | word , from the outside in , but Tcl is inside out . This will occasionally cause me (and other people) problems , but I will deal with that .

PYK 2015-02-20: I think you're referring to some of the modifications I've just made as a result of all the feedback . I'm going to keep trying to come up with a description that gets more support . I've been pondering all the feedback received , particularly the detailed feedback on this page by PL and aspect , and have hit on the idea that the proper place to use the term , "word" , is in discussions of the string format of a list , while the term "element" is better in discussions of how various commands work with a value as a list data structure . This is probably obvious to all the Tcl gurus , but I haven't ever thought through it like this before . Accordingly , I'll be revising many of my recent edits . I'll spend some time on the page for "word" as well .

aspect 2015-03-06: for my blood pressure , I'm going to have to stop watching recent changes . Your latest batch of edits have removed useful information from some pages (I restored only one - the note about "last updated in 2003" in FBSQL) and reintroduced a bunch of stylistic issues that have been discussed to death a year ago (RLE has been fixing space-comma) . I still find "A list is not a data structure" in the main text of list highly disturbing . I'm clearly not alone in feeling you respond incredibly poorly to feedback , and finding you impossible to collaborate with . I feel a bit silly getting so worked up about a wiki , so time to join less patient folks like EMJ , PL and others who in vain voiced their concern on the recent clt thread . Good bye and good luck .

PYK 2015-03-06: In today's edits I did remove a good amount of information that I deemed unhelpful or outdated , and I think the wiki is better off without that info . Did you see all that old junk on the SWIG page , and the redundant SWIG information here ? It clearly needed to be removed . I thought your additions to FBSQL were good . I'll be paying attention to what people bring back and will use that information to inform subsequent edits , but there's no point in keeping distracting obsolete information around . If I deleted information you thought should not have been deleted , bring it back . I'll notice . The space-comma occurrences that RLE has been removing are what remain from older edits from last year , not any newer edits . I'm trying to remember to search through pages that I edit and change space-comma to comma-space , but so far RLE has been more vigilant about that than me . I think the "list is not a data structure" statement is on-point , but you could always add a rebuttal on the list page . I spent about 12 hours on today's wiki edits , and managed to clear a few pages that were filled with redundant information . It's easy to overlook how painstaking cleanup work is , and I seem to be the only one doing it .

AMG: Here's rmax's clever solution to the number class problem you posed:

proc numberclass {n} {expr {($n > 0) - ($n < 0)}}

PYK 2015-03-26: Nice ! Where did this come from ? I'll make an answer page for that problem .

AMG: I don't specifically recall which page he posted it on first , but I've held on to it as being rather clever .

AMG: Moved from New Control Structures:

pooryorick , please refrain from changing the style of my code , particularly if you do so inconsistently . I see you deleted the braces around the single-element parameter list of [good] but not [bad] . You and I both know the braces are optional , but they also do no harm . My preferred style is to brace the second argument of [proc] even when not required . The rationale (which I admit is weak) is to have the braces already be in place for future changes to the length of the parameter list . I know an argument could be made that using braces when not required could confuse new Tcl programmers into thinking they're somehow magical when used in certain places . Reviewing my earliest Tcl code , I see I used "quotes" in many places not needed , and it did indeed reflect my C-inherited confusion regarding the language , so I have some sympathy for the argument . But not enough sympathy to override my stylistic preference and my desire to reduce the likelihood of error when changing the length of the parameter list .

You also changed my prose a tiny bit , not in a way that negatively impacts it , but I don't see why it was important to make the change at all . I would also ask you to refrain from changing other people's prose unless it is for obvious , uncontroversial , and beneficial reasons such as fixing spelling (e.g. , changing "cplor" to "color" is fine , but not "color" to "colour") or adding reference links . If you wish to fix a factual error in text signed by another , just add a comment signed with your name .

PYK 2015-04-08: Yes , I do believe that the code style guide of the wiki should prescribe minimally-necessary quoting throughout , and for the reasons you've stated . I see misapprehension of the nature of quoting in Tcl not as a big stumbling block for beginners , but as an enormous one . I'd like to see every example in the wiki beat them over the head with the proper notions . I'll try to honor your request to not make such changes to code that you've written , but The error you're trying to avoid is not subtle . Would you consider sacrificing those braces for the greater good ?

Regarding the changes to the prose , the wiki is littered with instances of the pattern

the command [somecommand] does stuff" .

In some instances it only makes the description a slightly more stilted , but elsewhere it is decidely confusing . I would like to see it fixed everywhere to read like this :

somecommand does stuff .

Regarding statements of fact , Unless I'm confident the author would have no qualms with the change , I do try to leave a signed note to the effect when I change the meaning of someone else's signed statement .

Although one , ten , or 100 small changes to improve readability may not have a significant overall effect , thousands of such changes will , and I consider it important to make them . The wiki doesn't have to read like a rigourously copy-edited publication , but if it can , why not go for it ? I understand that the numerous changes are visual clutter for those scanning only for modified content , but I'm relying on improvements to the feature set of the wiki to solve that problem .

AMG: I'm sorry if this comes off as rude , but I'm struggling to take you seriously and not just laugh when you talk about having every Wiki example beat the reader over the head with proper notions , likewise about making the Wiki read like a rigorously copy-edited publication , when in your writing you go out of your way to use a punctuation style that I have only ever seen used by people with extremely limited English ability . You defend to the death your right to use this style and will not hear arguments about how off-putting it is to every other reader , though you have moderated on your position and largely confined your use of such to this single page . But nevertheless , you insist you have a monopoly on proper coding style and writing style throughout the rest of the Wiki and freely reformat other people's code and prose in the name of not confusing beginners and not hampering readability . It's just so hard to reconcile your various positions and mannerisms and behaviors that I wonder if I haven't mistakenly wandered onto the stage of a satire play . But no , I know you are serious and you are convinced in the value of your positions , so I will try to be serious in my discussion with you . Well here it is: you believe as you do for reasons personal to you . But so do we . Each contributor to this Wiki has his or her own preferences for reasons sometimes personal , sometimes learned , sometimes reasonable , and sometimes nonsensical , but they do not need to defend those reasons in order to deserve being shown the respect of not having their preferences overridden by those of a self-appointed copy-editor . The fact is that this Wiki is not , never has been , and never will be a rigorously copy-edited publication . It is a collection of writings by many people of disparate styles and viewpoints , yet we all have chosen to work together to form a loose federation of technical writers . We are free from obligation to any particular leadership structure or style manual . We are answerable only to our shared goal of getting our thoughts out on the Internet in such a form that we (individually) feel will be beneficial to the world . True , wikignomes continuously curate the Wiki to address organizational and technical issues , but not remake it in their image . At the risk of repeating myself , I ask that you please respect us . That means respecting our individuality . Tcl is a playful language , an individual language , a language flexible enough to permit modifying itself . Let Tcl's Wiki reflect this fact . Tcl isn't Ada , it's not a bondage and discipline language [L9 ] , rather , it is whatever we make of it . Again , we did not appoint you (nor anyone) as designated editor , nor did we agree to conform to any rules other than the Dodekalogue , and even then only when writing standard Tcl which isn't all the time . Many gifted contributors have recently left this Wiki in protest over seeing the individual flavor of many years of contributors flattened to comply with the preferences of a few . Or to be honest: of a single person , that person being you . While I commend you for having the energy and the desire to make this Wiki a better place , I must ask you to reconsider your goals . This Wiki has suffered from compulsive reorganization perpetrated by a few other folks over the years , most famously one now known as unperson . Please don't let yourself become him . Please take a break from reformatting and reorganizing . Instead I suggest you , for a time at least , concentrate on contributing code .

PYK 2015-04-09: Oh come on , now . As you've noted , I confine that punctuation funkiness to this page , and it's just for fun . The "proper notions" part referred specifically to how a beginner approaches and understands Tcl syntax . I just happen to think that the minimal quoting style is really helpful to that audience . I can't tell from your response whether you agree or disagree with that , but clearly at this point you don't want code on the wiki modified to conform to that style . Fine . Instead of ranting , why not just come out at the beginning and say , "I'd rather not have all code on the wiki modified to fit that style" ? Jeebus .

AMG: I did start by saying so . My longer response was due to you asserting the superiority of your approach to the point of justifying restyling existing code on the Wiki . I felt it worthwhile to elaborate as I did because this current activity of yours is just the latest in a long line of overaggressive edits which have been protested by several , even to the point of leaving the Wiki . As for you not being able to tell whether I agree or disagree with omitting braces where possible , it's because I'm ambivalent on that point . What I am not ambivalent about is restyling existing code written and signed by others , and that is what I addressed .

PYK: Point of order : You started by asking me not to change your edits , which I agreed not to do . Also , I did not assert that my approach is superior , only that it is helpful to newbies .

AMG: Thank you , that much is appreciated . And as for your approach being helpful to newbies , it is possible you are correct , but that was not the thrust of my earlier statement . This brings us back to the argument about whether the Wiki content as a whole should be , shall we say , refactored . If you wish to disregard my discussion on same and refer to it as a rant , then I see no point in talking about it further because I would only be repeating myself . Let's just go forward and see how things shake out .

PYK Your response was a rant , but that doesn't mean I'm disregarding it . We're now coming around to articulating the issue : Does the wiki need a shakedown ? I think it does . In its current state , it's actively repelling newcomers . That's too bad because as we all acknowledge , it's a trove of hidden gems . In my opinion , if someone doesn't want others messing with their code , they shouldn't post it here . I want a Tcl wiki that's copy-edited to hell and back , and scrupulously updated at every chance . I also want a wiki community that understands and plays the wiki game , and where people don't get some false sense of ownership over content they contribute . It doesn't have to be this wiki . I'm more than happy to go off and play in my own sandbox . I might be much happier with that arrangement , as all this antipathy isn't the most pleasant thing in the world . A collaboratively-edited website does need to find its voice , and it really can't be all things to all people . This wiki may already have found its own , and my attempts to reshape it may truly be unwelcome . The trick is to determine how irreconcilable the differences are . If a few key people , including yourself , think my direction is not the right one for the wiki , I have no problem striking out on my own .

HE 2015-04-10: I have to interfere in your discussion. I can remember good enough the times I was a newbie to this wiki.

I still impressed about the freedom we all have in the place. We can write about TCL how we want, what we want, when we want.

The creator of this great wiki software allows all the freedom also in writing style.

What does it matter if the categories at the end of the side are right, left or middle aligned? Nothing.

But when you are a newbie and you find out that one good way to follow things in this wiki is the "Recent Change" page, it is very useless if this is filled by formating changes. By the way, Even not as a newbie this is un-enjoying.

In case some change the describing text he/she should be careful not to change important things. Perhaps he/she isn't aware about the special meaning. Or someone like to use American kind of writing. Or the English one. Or to mix them?

If someone changes code, he/she not only should guess that this change works, he/she should prove it! And the changes should change something. Don't change code because it looks more beautiful to you.

And if TCL let you express something in different ways, why should this be changed! What is the 'right' way to do things! I remember a lot of sides here which claims the 'right' way. And doing it in a different way never lead me to problems and unsuspected behaviours.

If someone will help newbies and other people, than, for example, provide more examples in the description of the different procedures. Not only providing the contents from the current man page.

Or ff you think something should be implemented in a different way, describe it in a different part of the page. And show that is your opinion.

I had some code here which was very slow. Instead of changing it stealthy, they wrote me what is the reason, so that I could change it. Since that time I make braces around the arguments of proc, if or expr. At least as long it is valid for the wanted behaviour. This is what I think could be 'right'. But other ways are allowed too. I hope you will never find a "if 0 {do something)" in my code. It should always look "if {0} {do something}". This is my 'right' way. You will have your own one.

I'm always happy if someone corrects real syntax errors in my writings. And as a reader I like it if someone add additional useful links between the sides.

All the writers here in this wiki are a community. And the most important thing is respect. Respect the person who are reading, respect the writers, and have respect about the written.

Have all a nice weekend!

PYK 2015-04-10 . I agree with all your points , and I understand that the appearance of copy-editing changes in the "recent changes" list is a nuisance to those not interested in that kind of change . Is the solution to not engage in copy-editing ? I don't think so . Instead , the problem can be solved technically by providing some feature that allows users to filter those kinds of changes . In the meantime , believe it or not , as of about a year ago , I've actually greatly curtailed my wiki activity until this technical issue is addressed .

The "beat them over the head" quotation should not be taken to mean anything other than the idea that new users benefit when they consistently see Tcl code quoted only as necessary . In your response , you've implied that my words carried a broader meaning , and that's not fair .

Where quoting is concerned , we may not all agree on a right way , but when we see a newbie doing it wrong , we certainly can agree on that ! Quoting misconceptions are probably the number 1 reason an individual doesn't adopt Tcl after playing with it . If code that misleads newbies can be fixed with some minor style changes , why not do that ?

There is a lot of diversity here on the wiki , and I'm all for it . Discussions that step through the process of improving code are great . I appreciate them very much and try to preserve them .

Respect has been mentioned many times on this page . I think its a mistake to factor "respect" into editing decisions . The information is king . An edit is either good , bad , or pointless , and is dealt with based on that classification . I don't think it's disrespectful to try to improve content someone else has posted on the wiki . In fact , I think it violates the spirit of the wiki when an individual gets bent out of shape by that . When a wiki adopts the conflict-free style of never modifying what others have written , it suffers . When people are free to make changes to anything , knowing that others will happily revert unhelpful changes , the content quality improves over time . Original content is always preserved in the history .

HE , can you point me to changes I've made (apart from the few covered by PL in previous conversations on this page) that you thought were to the detriment of the page ? I've requested that before , and not gotten a response .

Incidentally , if {0} {do something} is not technically superior to if 0 {do something} . What you've got there is a cargo-cult quoting concept . You probably picked it up from the examples on the wiki ;)

HE 2015-04-11: Hello PYK . Perhaps, you had find out by reading my comment, that I made them as most as I can in a neutral form . The most important reference to you is because it is on this side. But well, the discussion is also on this side. What should I do?

As I read the discussion between you and AMG, I thought it could be useful for you both to read what other persons are thinking about copy-editing and other changes. And I wrote it from my experience and not what you PYK changed in detail.

I would replay to your answer. I wouldn’t read everything what is written before at this page. I never want to discuss with you. I only want to provide a different few for taking it into account. Nothing more.

If you want to discuss, fine. Here the answers:

You wrote that you curtailed yourself until copy-editing could be filtered in the recent changes? I saw you editing a lot of layouts, like where to align the categories at the end of the side. When it is so important for all of us, why should the wiki not keep an eye on it and do such corrections itself? Wouldn’t it be a great support for persons like you which don’t like the different alignments? No one could do such “ugly miss-layout”. And you can do much more copy-editing in other domains. I guess, that the author of this wiki software believes in the freedom of every writer of new contents to design the side and the information in a way how he/she is believing that it the best. And for sure some or perhaps a lot of persons don’t care much about layout.

If I look in leo.org what copy-edition means, than it stands for a function by the publisher. For sure an author can ask such service also before going to the publisher. Nevertheless, there has to be an agreement what should be checked. The editorial office will give the feedback and the publisher and the author should decide together what changes should be take.

In such a scenario, which isn’t far different from ours here, the lector should never change things without allowance by the publisher and/or the author.

This could be different in the process of newspaper. There copy-editing is part of a defined process. But again, from the beginning both sides, the writers and the publisher have agreed to this.

But even in the last example it is clearly defined what the lector has to look for. In best case, the writers or the tools they use will do everything and the lector has less work. Please point me to the side here in the wiki where it is written, what kind of copy-editing is defined and agreed. I would try to respect it in the future so you have not so much work.

If such a side doesn’t exists, all what you are copy-editing is because it is your own opinion.

You claim to know why beginners have problems with quoting. Let me tell you, that I, as I was a beginner in Tcl, had the most problems with examples because sometimes there where curly braces or quotation marks and sometime not. And it was not clear when to do what. And why it brakes code and why not. In contrast the difference between curly braces and quotation marks were easy to understand.

Over the time (and not as you guessed from the examples here) I found out its more save writing to use curly braces even if they are not needed. It doesn’t harm, is more save and makes in some cases your code much faster. The last point explains itself only with knowledge about the internal implementation of Tcl. If someone wants to help beginners let us provide sites where everyone can read when it is useful, when it doesn’t matter and when it is harmful to use which kind of braces. I stumble over a couple of them here in the wiki. But all showed me leaving curly braces away could be harmful. Every writer prefer his kind of code writing for a couple of reasons. We should show everyone how flexible Tcl can be used. Keep even beginners in the duty to decide by themselves what is better for them. Show them on knowledge pages what is possible and what could be harmful. But let the code from others untouched in sites where they show how they solve a task or a problem. As long as you not find an true error for sure ;-) But even then it is better to inform them than changing their code covert.

Now about respect: You wrote the information is king. But who decided what is the information? You? As what? As the writer? Yes. You wants to provide something you think it is an information for others. As a reader? Yes. You read what is written and think that could be an information to you. As a lector? Never. It’s not the task of the lector to decide what is an information and what not! Most of us are glad when someone corrects where we made simple writing mistakes. And I guess non native English speakers are also glad when someone correct grammar or phrasing as long as they don’t feel the contents has changed. If you change as a lector and harm what the writer see as the information this creates trouble. If you change as a lector and harm what the reader could see as the information this is information is lost for future readers. Perhaps also for you. One aspect of respect is carefulness.

Of course there are writings out there which are difficult to understand. Perhaps my own writing here belongs to it. But, important literature was created by writing which other would postmark as ugly.

You wrote “Discussions that step through the process of improving code are great“. Yes, they are. I agree fully. But, written discussions can be followed also for the later readers. But when someone change braces in code without such a discussion or a at least without a hint this is disrespectful. Why not writing below the code that the curly braces could be omitted. And point to a side where the reasons are described and where all of us cam discuss about it. If someone do so on only some prominent sides a lot of beginners will stumble over it and can decide by themselves.

You wrote “When people are free to make changes to anything, knowing that others will happily revert unhelpful changes, the content quality improves over time“. I agree mostly with this because this is the spirit of a wiki. But again, be respectful and as a part of it careful. I saw layout changes made by you and others. Some of them are not helpful for me. Should I change the side back stealthy. And the lector stumble over it some month in the future and the play starts again? The change but also the reaction is not helpful. Moreover, it is wasting time. But let lectors doing this without an agreement, make them think they are right. And who should decide what is helpful?

You wrote “HE, can you point me to changes I've made”. I don’t want for a simple reason: As I wrote I want to point what I like and what not, regardless who does it. Because you are not the only one who work as a lector. Regardless if all of you are working official or on your own terms.

And the last one the “if {0} against if 0”-thing. Technical means in sense of the Tcl internal source code? Or in which other point of view? What I understood over the time ‘0’ means the zero will be substituted which leads also to zero and than be used by ‘if’. Perhaps the internal code knows that ‘0’ can’t be substituted and shortcut substitution. This would what I expect by byte-code compilation. But, if this happens shouldn’t care me as a tcl user. If I use ‘{0}’ I express as the writer , that I don’t want any substitution . The ‘0’ will be directly given to ‘if’ as the result of the expression . As I wrote I would guess (but don’t know because I don’t work on there internal code) that it does the same if byte-coded. To say I have this from examples here I must disagree. As you know “if 0” or “if {0}” is the way how multi-line comments are written in Tcl. As a beginner, at the time I first need it, I found “if 0”. I used it a couple of time but it looks ugly for me. Because, the result is the same I use “if {0}”. If you like to grumble it “cargo-cult quoting concept” I have to say that I have to accept this because it is written in Wikipedia. From Wikipedia “Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose“. Do you think this has no real purpose? Do you ever used an IDE. Most of the code generated by it is useless from the software you write and can be called “Cargo cult programming.” But from the point of view of the IDE it has a real purpose. That’s the same here. I know I can drop the curly braces here. But as I wrote far above it is save to use curly braces. I don’t want to decide at every usage of ‘if’ if it is useful or not. The same by proc or exec or while or .... Every decision you need to take, takes time. If you make syntactical errors because making the wrong decision it takes more time. If you make logical errors which pass all the syntax checks, you will loose much more time. Most of the time I’m not programming for myself. It should keep my working life easier. So avoiding simple errors by using roles other call useless or “without a real purpose”, save time. And therefore, there is a very real purpose. And most of the beginners would be glad not to struggle with such decision. From my point of view, not to use bracing (curly or where needed quotation marks) is for the programmers which had made their first steps with Tcl and had some successful running code and wants to improve the Tcl knowledge. But this is my personal opinion. They should decide by themselves. As long as it doesn’t harm the result they want to archive and not harm the users of their software every way would be OK, what doesn’t matter what way they are using? So please, why it misleads beginners when we use curly braces where they can be harmless dropped? The other way is much more risky:

set a “echo DELETE ALL”
if $a {do noting} ;# Here ‘a’ could be executed
if {$a} {do something with $a} ;# Here ‘a’ reaches the if body.

You know what I mean. I know this is a different situation. But not for most beginners. And perhaps not when someone is in hurry. So if you decide to drop curly braces where you can, its your choice. Let me and the others the choice to use curly braces, if we think it’s better for any reason.

if you don’t want accept more than your own opinion you will find very fast also in discussions about indention of code and other things where a lot of people have different opinions, too. I, for example, accept that a lot of Tcl code is intended in the way:

  1. intending 4 spaces.
  2. intending 1 tab
  3. intending 1 tab 4 spaces
  4. intending 2 tabs

and so on. Or other take a fix amount of spaces for every intending. I’m one of the persons which like to intend with tabs because than I’m able to configure the editor how many spaces to use. By the way. For me tabs should never used to align text/code other than at the beginning of the line and some exceptions. It’s my way. You don’t need to follow.

Would you like to discuss which of the types should be used in the free world or here at the wiki. I’m not. The users decided why they prefer the one or the other way. This should be ok to everyone here.

If you would know me private, you would know that I hate to write so much. You would know that I do this only if I think it is important and moreover, it helps to clarify and calm the situation.

Perhaps I argued against something you never changed. But again, in my first comment I wanted to provide my personal view about editing of sites in this wiki, not about your editing. If you take this as your own, I had to answer.

I hope you understand my point of view and that you also understand that it’s not against you. I also hope that you can accept my and other opinion and keep them in consideration by your next Wiki-Gnome tasks. I hope it is also clear, that I appreciate the work of the Wiki-Gnome. But I hope that you also understand that not everything a Wiki-Gnome could do is accepted and welcomed. There are so little amount of Wiki-Gnomes and so much other work to do which would be more helpful than fighting about the style of bracing . Or changing English words to American or the other direction.

I will stop here.

Have a nice Sunday,

PYK 2015-04-11: I prefer to indent with tabs too , but for the wiki it seems like 4-space indentation is the safest style , so that's what I use here .

AMG: HE makes really excellent points about the value of using braces even where not strictly required . He expanded on my notion of avoiding future error if the parameter list is changed to not have unit length by saying that always including the braces saves the programmer the time of even considering whether it's legal to take that shortcut in each particular instance . I will definitely consider that and recommend others adopt the same thought process .

Sure , there are shortcuts I will take when I can (extreme example: "not" "quoting" "every" "single" "word") , but only in places where the code is already customized for and close to the problem being solved . Creating a proc is a very generic operation , done the same way regardless of the actual programming task . His example about how to call [if] is also very good in that he shows how omitting the braces is exactly as dangerous as doing so with [expr] . I recently reviewed some code I wrote a decade and a half ago and found it full of [if]s whose second argument was not quoted at all .

There is one thing HE said I wish to correct . Changing the alignment of category lists actually does serve a purpose beyond style . This wiki introduced the <<categories>> tag to make the Add Comment feature work . Without <<categories>> , Add Comment would put the comment below the category list since the wiki cannot recognize it as such .

RLE 2015-04-11: I have to side with AMG and HE here regarding use of a few technically unnecessary curly braces . I also do the same , even though I know full well they are not , actually , required in many of the situations where I add them . In part it is stylistic , in that it sets off the "expression" part of if , while , and friends , making them slightly more visible without needing a color highlighting editor to do the same . In part it is simple habit , in that there are enough situations where they are necessary that it is easier to get into the habit of just adding them and being done with it (i.e. , reducing the mental load by just adding them rather than needing to think "do I need them here" each and every time) . And finally , it is part pragmatic , in that if I do go back later and change the expression , I now don't have to think "do I now need to add braces..." (again , reducing cognitive load ever so slightly) .

PYK 2015-04-11: I speak a few languages , and am sensitive to the position of the non-native speaker , but in this case , that phrase literally can not be taken literally ;) so I think it is just HE being obstinate , particularly when I already spoke up about the phrase being taken out of context . I am sure that such colloqualisms exist in HE's native language , and that as a non-native speaker of English , and an astute one at that , it's reasonable to expect him to admit the possibility that an idiom is at play . Even if I had not used a cliché'd colloquialism , ad-hoc usage of phrases in a non-literal sense springs up all the time , and the context usually provides some clue as to whether it should be taken literally . This is not so much a second language issue as an individual approach to communication from a standpoint of political correctness . I'm sure that even the first time I heard the Russian word «врубился» , I didn't really think someone was taking an axe to someone's head !

Regarding quoting style , the arguments in favour of employing quoting that isn't strictly necessary are all those of convenience to the programmer , and I acknowledge their advantage in that regard and in my own code . Because of the wiki's status as a teaching tool , I think that here special consideration should be placed on the teaching utility of the provided code examples , especially since this is such a thorny issue for those learning Tcl . Take HE's contention that ‘0’ means the zero will be substituted which leads also to zero and than be used by ‘if’ . That statement reflects a foggy underestanding of the issue . HE is not a novice , but his lack of clarity about this issue is stereotypical . People come to Tcl , grope around until they find a quoting style that seems to work well enough , and then run with that , and thus miss out on the benefit of having a precise grasp of Tcl quoting . In my own case , I determined to get to the bottom of it and I believe I did , but it took far , far more effort than it should have . I want to alleviate that problem for others by means of the wiki . If a newcomer can trust that every single code example on the wiki is only quoted as necessary , they can look at each example and analyze why quoting is or isn't there , and from repeated encounters with examples where they did or didn't expect certain quoting , derive the entire ruleset . On the other hand , if multiple quoting styles proliferate , the opportunity is completely lost at every instance . The newcomer can never look at a single example on the wiki and know for sure whether the quoting is necessary or not . That's quite a big lost opportunity , and it's why I think it is important for the wiki to guarantee to the reader that all the examples use quoting only as strictly necessary .

Many people come to Tcl via Expect . Its manpage is all over the place in its quoting style , and while each example is "harmless enough" since the code still works , overall it paints a very confusing picture to the newcomer . Hang out long enough in the Tcl Chatroom and you get a sense of just how much people struggle with Expect syntax . I've never heard it articulated , but I think a good portion of the confusion can be traced directly to the inconsistent quoting in the manpage . Here are some examples that document , each harmless enough by itself:

send_user "password?\ "
send "$expect_out(1,string)\r"
send password\r
send "\r"
expect {
    busy       {puts busy\n ; exp_continue}
    -re "failed|invalid password" abort
    timeout    abort
"failed|invalid password"
busy               {puts busy\n ; exp_continue}
"invalid password" abort
expect "cd"
set expect_out(0,string) cd
expect -indices -re "b(b*).*(k+)"
expect_after {
    "p" {send "\r\r\r"; exp_continue}
interact {
    foo    {send_user "bar"}

These examples are no big deal to the seasoned Tcl programmer because they all work , but they are a big deal to the newcomver . Maybe the Expect manpage intended to show off just how many not-incorrect ways there are to quote things in Tcl , but the end result is that the new user is left begging for some indication of what the quoting rules are . If the wiki takes the track of uniformly presenting examples in which quoting occurs only strictly as necessary , it will have a huge influence on those learning Tcl .


By the way, did you know the word by word translation of «врубился» as you heard it the first time?

Next point: Since when is the wiki a teaching tool? Is it your definition? Or whose?

For sure every source of information is also a kind of teaching tool. Teaching is nothing more than providing information. But in a more special way.

But I see wikis only as a information source where we can share how we use Tcl and how we solve problems with Tcl.

About bracing you wrote that my knowledge about is foggy. And you mean my knowledge about how Tcl works internally. I say to you: Yes it is. I don't deal a lot with the source code of Tcl. And in the ideal world I should not need any knowledge how a programming language is working internally.

The only what should be needed is the description of the language. Because the internal working of a programming language can change at every time without notice.

And we know that Tcl changed inside one Major release a couple of time at significant points.

At the end you came to the point: Beginners reading documentation. And the expect documentation is ugly in describing quoting. But this wiki is not the expect documentation. It is even not the Tcl documentation. Which, I think, needs also improvement.

If there is something wrong with the documentation, let it fix there. I guess most projects are happy if someone would help to make better documentation. A proper documentation is what everyone from us need.

But why changing the wiki which has a different purpose instead of changing the documentation?

As you can read at another place here in the wiki I struggled by playing with "try ... finally" and tailcall. With the explanation I got from the wiki I could construct myself the explanation from the documentation . But the should be in the other direction.

But again. The wiki is not the Tcl documentation. It should show the multiple possibilities all of us are using.

And as I suggested some comments before: Create a side where you explain what are the advantages and disadvantages from using braces in one or the other situation and why you thing other kind of braces should not be used . And allow others to comment your meaning. Provide the beginner and all the other readers with the information in one place and let the beginner and all the readers decide themselves how they want to write.

Changing only the code without explanation doesn't help someone. The reader still don't know why this is sometimes with braces, sometimes with quotation marks and sometimes without any bracing. The explanation is needed in a understandable way. That's what help beginners and all of us. And if you are able to fix it everywhere in the wiki as you want, the reader would have a situation in its own code where it is different and doesn't know why it works as it works. He has no chance to find an example at the wiki to get perhaps a explanation.

We are a community which use the same platform. We have to find ways how we can work together. If writers doesn't like that someone change their working code, this should be accepted . Instead a different way has to be find to reach the goal.

I suggested an alternative. It's up to you to take this in consideration or make a different suggestion for the next round of discussion.

The Trouble with RLE

PYK 2015-12-29:

So RLE has decided to censor my contributions to the wiki . I first posted to How to embed Tcl in C applications an example of how a program can embed Tcl and also become an extension to the Tcl interprer it embeds . The code I posted also happens to be the only piece of code on the wiki that shows how to use the TclOO C API to get a handle on the root TclOO Class object . RLE didn't like the placement of commas in my code , so he reformatted it . After I reverted his changes , he eventually decided to revert the entire page to an outdated version that didn't contain any of my contributions . Nevermind the fact that reverting to this outdated page loses a number of other updates to the page . Later , I started another page , How to embed Tcl in C applications 2 , to hold the version of the page that contains my code and other updates . As of the current time , RLE deletes this page whenever he notices I have revised it . Essentially , RLE is on a campaign to ensure that my contributed code doesn't appear on the wiki at all . I propose he and I meet at the flagpole after the bell rings to settle this the old farmer way .

RLE: All you have to do is drop the disrespectful arrogance and put the commas in your wiki contributions where the community has told you they belong , and your problems come to an end .

PYK: Arrogance , eh? Using my preferred style on my own code . Hmmm . But deleting someone else's code isn't arrogance . I see .

RLE: On your own code - fine - once posted to the wiki then you follow the community conventions .

PYK: Otherwise you'll delete it? I see that as a real problem . I hope the rest of the community does , too .

RLE: Fine - your code is back - but with community formatting conventions . Leave it formatted that way , and it can stay .

PYK: How I format my code is not your concern , mate .

RLE: The disrespectful arrogance just never ends with you .

PYK: I know , right? Like , who exactly do I think I am , spending hours and hours , Friday nights and weekends , updating the information on this wiki and posting code to help other people? It's just obscene . And on top of it all to insist that you leave my code the way I posted it? I should be taken out and shot .

RLE: Considering that your arrogance and disrespect drove one ex-wiki contributor to produce this page: PYK: link deleted -I'm certainly not going to sponsor it here! " ... why he must go" , yes you should .

PYK: You realize that posting a link to that site is about as classy a thing to do as authoring it in the first place , right? I'm surprised , RLE , that you want to be associated with that .

RLE: You realize that a sane individual would look at that site and think: "Wow , my attitude and actions have had this much negative effect on others , maybe I should reconsider my attitude and actions in the future?" . And then they would attempt to improve themselves .

An arrogant individual would simply dismiss the site out of hand .

You dismissed the site out of hand .



"And on top of it all to insist that you leave my code the way I posted it?"

That statement on your part is so full of hypocrisy that the hypocrisy is just dripping off the words . More than once over your several years of wiki defacement others have challenged you to leave their pages the way they posted them . And always , the answer was the same arrogant disrespectful response . One that can be summarized as: "The wiki pages belong to everyone , so PYK can edit them the way PYK sees fit , so deal with it . "

This , dear wiki community , is PYK finally showing his true colors . PYK can edit however he sees fit , but no one is allowed to edit postings by PYK . The very definition of hypocrisy .

APN: Not that anybody has asked my opinion but may I suggest RLE that given that there is no such thing as community opinion with regard to code formatting , code should be left alone except to fix obvious typos and such . At the same time , PYK , imho when you refactor / rename stuff like cmdsplit and other pages , you are engaging in something similar which makes it difficult to sympathise when someone reformats your code . I appreciate the time PYK has spent on the wiki but I do feel channeling your contributions into your own blog would have (a) made for a clearer presentation of your thoughts , (b) more benefit to the community and (c) better for your sanity .

There , now I've annoyed both of you equally . Some might call that being fair :-)

PYK: I think the difference is that if someone had objected to that change to cmdSplit , there's a high probability I would have reverted my own changes . I've done that on numerous occasions . In the case of cmdSplit , I approached the author about the change to see what he thought . That change wasn't gratuitous , but was done to have an intuitive set of names for other commands in the series , which I contributed to the page . APN , if you actually care about the renaming of cmdSplit , let me know and we can work it out .

In every instance I can think of where someone has objected to a change , I've either reverted the change or tried to come up with something more palatable until we reached a consensus . In this case , however , RLE's only real goal is to establish himself as top dog , which of course I'm not going to take kindly to .

Regarding RLE's accusation of hypocricy , he has misunderstood . No wiki page is owned by any individual , and anyone is welcome to jump in and edit any page . When there's conflict , however , it needs to be sorted out . I've backed off many , many individual edits and overall approaches in such cases , and when the author of the content in question objects , I'm particularly quick to back off . Authorship doesn't make one the "owner" (as far as I'm concerned , wiki content is owned by no one) , but it does carry some weight during conflict resolution . In this case , I'm the author , and I expect my desire about the content to carry some weight . This is absolutely consistent with the way I've handled every single past conflict over content . RLE , on the other hand , is showing some inconsistency . He has in the past supported people who want their content styled according to their personal tastes , but in this case he's demanding that it can't be so . I've never before seen a case where one editor insists on repeatedly deleting an entire page created by another editor .

Somewhere along the line , RLE got the opinion that I ride rougheshod over other people's content , despite their objections . This is simply not true . Yes , I edit other people's content . No , I don't insist on my edits over their objections . I challenge him , as I have before , to point out some place on the wiki where this has happend . I also challenge him to avoid over-the-top proclamations such as " ... the very definition of hypocrisy ." Let's keep it rational .

As I've said before , I'm willing to take my efforts to my own website , if people really would rather I do that . My goal is to have a comprehensive , organized , and up-to-date wiki of all things Tcl . At this point , I'm far from convinced that this wiki isn't that resource .

aspect: taking your efforts to your own website seems a fine way to avoid these bitter conflicts that seem to come up a few times a year , drive people away and tarnish the experience of everyone who keeps an eye on the wiki . I would prefer to look elsewhere for your content than having to watch wiki-fights .

APN PYK , at least part of the issue I think is that while you may be willing to go back and forth arguing points etc . many people do not have the time , the patience or the inclination to do that . That leads to irritation when "their" content is changed and then have to spend time arguing about it .

APN I do agree that deleting entire pages is simply not done in a community-owned wiki .

PYK: If I may be so bold , if someone doesn't have time to engage in wiki work , perhaps it's a good indication they would be happier working on a set of pages they have exclusive control over . Curation of the wiki is important , and the bottom line is that those willing to put in the time are going to have more influence . They're also going to draw more criticism .

But to APN's point , I continually try to gauge what changes might be unwelcome by the author , and consider that before making a change . I sometimes make mistakes , but considering the volume of changes I make , I the error rate is reasonable . The only way I have to assess that is to take into account feedback I've received .

wheeldog First , PYK , let me thank you for your contributions . What seems to be lost , deprecated or totally forgotten is that they are contributions that reflect a personal style and method of solution . They are not an attempt to establish truth , authenticity or validity . Consequently , while one might disagree with the form , content or even value of another's contribution , there may be other who find value in it . Hence , for those reasons alone it should be left in its original form , with any conflicting beliefs documented in a 'Discussion' .

PYK: That's a good general guideline . Is there a particular piece of code you're talking about ? Recently , I replaced the code at stacking with my own rewrite . It's conceivable that Larry Smith or someone else would object to that , but chances are , they won't . First , the new code is better , and it does the same thing . Second , I don't think Larry Smith comes around much anymore , and the Wiki doesn't owe it to people to preserve their code in memoriam , forever , on some page . If someone does object to a deletion , it's easy enough to bring back the old code and keep them both , side-by-side on the page . Why not do that initially ? Well , I don't think readers necessarily benefit from having all code ever posted to the wiki preserved . A lot of it , frankly , is no good . A lot more of it needs to be brought up to date with modern versions of Tcl . If we have a rule that we can never delete anything then we have to keep it all and try to find other ways to help people navigate to what they need without having to spend too much time reading useless stuff . I'm all in favor of continually assessing pages , and deciding what to keep and what not to keep . If one editor throws out something another editor wants to keep , it's easy enough to bring it back . Now , one response to this is , "But we don't have time to do that." My response to that is , "Then keep it on your own host so other wiki editors don't have to worry about it ."

YamikaniTafadzwa 2018-01-02: (bll Relocated: Commenting on the last bullet point under expectations): "Quite an ironic statement there given that you are the reason why so many previous editors no longer edit the wiki .'

bll 2018-01-02: PYK's doing something rather than making snide remarks . If you don't like how he does it , open a discussion with him and discuss alternative /page layouts/formats/ideas/methods/ .

gold 2018-12-12: PYK , let me suggest a Mission Statement to be approved for the TCL WIKI . That is an old fashioned management idea , but it may help resolve some issues on this page , that we are all striving for the same goal . I loaded a "Draft and very unofficial Mission Statement" on the gold bio page , largely derived from the Fortran Wiki Mission Statement etc . PYK , Thanks for your hard work .

Archived Discussions

The discussions below have been archived at the the indicated revisions of this page .

revision 550
Conversation regarding modernizing scripts on wiki pages.