DN474822904

Subject: tcl/tk 9.0 - remove the warts! (?) - DN [1]

"Bryan Oakley" <oakley@channelpoint.com> - 06 May 1999 - comp.lang.tcl

 Ok, I thought it might be fun to discuss what the tcl communinity
 would like to see for tcl 9.0, since tcl 9.0 isn't even on the radar
 screen yet. Well, ok, I want to discuss what _I_ want to see for tcl
 9.0. Feel free to tell me just how in the weeds I am.

 On my bike ride in to work today I was thinking about some of the
 warts on tcl (I hate it when I do that!) and thought maybe we should
 put forth a plan to remove them. The nutshell idea, then, is to define
 a slightly revised tcl language and introduce it as tcl 9.0.

 This version would _not_ be backwards-compatible, but
 _would_ come with tools to automate the vast majority of the
 conversion required for old scripts, or at least identify commands
 that have changed (eg: tclsh --compat or something similar)

 So, what do I mean by warts? Here's my off-the-top-of-my-head short
 list of changes I'd like to see in tcl:

     * list command changed to be of the major / minor type:
         - list index, list replace, etc instead of lindex, lreplace,
           etc.
         - the functionality of the existing list command (eg: [list
           a b c] would be replaced with [list create a b c]

     * treating numbers with leading zeros as octal has got to be
       replaced with something that requires an explicit action
       (eg: \0o012).

     * all commands that do any sort of searching or pattern
       matching should have a common set of switches (-nocase,
       for example) and a common default.

     * all commands that do pattern matching on strings or lists
       should have a common set of switches (-glob, -exact, -regexp)
       and (maybe) a common default.

     * anything that takes a numerical index should accept things
       like "end - 1". (ala Jeff Hobbs' extended string command)

     * exec should be extended with a -commandline switch, to allow
       one to exec a command line with the default shell (eg:
       exec -commandline "ls *.foo"). That, or create a new command
       called "system" or "run" or something.

     * introduce major/minor or something similar, to make it easier
       to extend core commands.

     * remove the use of tkPriv and use a tk namespace variable
       instead.

     * get rid of all other pre-defined globals and use a tcl
       namespace variable (eg: ::tcl::platform(os))

     * maybe (_MAYBE_) add a "pure" comment character, as some
       have suggested. I personally don't see much of a need
       for one myself, but if the community at large wants it,
       this would be the time to do it.

     * all core commands would be defined in the tcl or tk
       namespace, and the base set would be automatically (or not?)
       exported. As new commands are added over time they can
       be imported on an as-needed basis to help keep namespace
       pollution to a minimum. (this might cause an interesting
       catch-22, as how can we define the namespace command in
       a namespace?). There might need to be a few exceptions...

       this could be used to keep the "kernel" to a minumum (eg:
       those commands that are automatically exported) but still
       have an expanded "core". Those that need only minimal
       tcl functionality could use just the kernel commands and
       then pick and choose what other commands to load in.

 I'm sure I'll think of others just as soon as I press the send
 button. And I haven't thought all these through a whole lot, so I may
 change my mind on some of them after a short debate.

 The idea here is to remove some of the things that generate
 FAQs. Sure, it would be painfull, but most of the changes would be
 easy to automate and in the long run make tcl easier to learn. I just
 hate seeing some of the same questions over and over again and think
 maybe it would be worth it to do something about them.

 Part of the process of developing this new version of tcl would be to
 define all of the changes up front, then add a switch to tcl 8.x to
 flag potential incompatibilities. We could maybe provide pure tcl
 libraries that implement many of the changes so people could start
 coding to the new method before the final release.

 I could probably ramble on for another page or two, but I'll stop now
 and ask for comments. I'm curious -- does anyone else think it would
 be a good idea to change the language somewhat in the interest of
 making it easier to learn and use, at the expense of backward
 compatibility?

 I'm not absolutely convinced of it myself, but am interested
 in debating the issue.