tcl for beginner?
Herbert Schmitz
is tcl the right language for an absolut beginner and non-professional? I
want to learn to write some small programms for using on a linux-machine
(without and with x-window). I have had a look on some
programming-languages, and most people recommended Python as best for me
... but i dont know if they know enough about tcl. Im not sure, but in my
opinion, tcl seems easier to understood for me.
Thanks for some comments!
Greetings_Herbert
--
~hersc...@gmx.de
~icq: 913 159 74
~:q!
Cameron Laird
Herbert Schmitz <hersc...@freenet.de> wrote:
>Hi,
>is tcl the right language for an absolut beginner and non-professional? I
>want to learn to write some small programms for using on a linux-machine
>(without and with x-window). I have had a look on some
>programming-languages, and most people recommended Python as best for me
>... but i dont know if they know enough about tcl. Im not sure, but in my
>opinion, tcl seems easier to understood for me.
.
.
Python and Tcl both are wonderful languages. I've argued at length
(<URL: http://www.itworld.com/AppDev/4061/swol-0202-regex/ > is an
example) that they're so similar in their "technical" capabilities
that "subjective" factors rightly determine rational decisions. If
"Tcl seems easier to" understand for you, then have every confidence
that you're choosing wisely to start with Tcl.
If you know that you have an interest in X windows programming, Tcl
gains a slight additional advantage over Python.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Larry Smith
> is tcl the right language for an absolut beginner
> and non-professional?
Tcl is the most bang for your learning buck.
it's syntax is much simpler than that of most
other programming languages, although the need
for the $ prefix to get the value of a variable
confuses people with small exposure to other
languages. It's close integration with X and
it's many libraries and adaptions to various
needs make it an unequalled tool for bludgeoning
programming problems into submission. However,
it does not have the saleability of Java, is not
as fast as C (but far simpler, easier, and more
powerful), and unlike C++ it cannot be used to
slice yourself into logical ribbons and leaving
you bleeding your tortured life out over the key-
board.
Python is not a bad choice, it's syntax is a bit
more convoluted, but it's design is a bit more
mainstream than Tcl. It's really not bad. I
never warmed up to Python, I'm not sure why. It's
just so...20th century, you know?
Perl will reduce you to helpless gibbering.
Asm is probably a bit more obvious. Visual
Basic is to programming what colorforms is
to impressionism.
--
.-. .-. .---. .---. .-..-. | Wild Open Source Inc.
| |__ / | \| |-< | |-< > / | "Making the bazaar just a
`----'`-^-'`-'`-'`-'`-' `-' | little more commonplace."
home: www.smith-house.org | work: www.wildopensource.com
Chris Nelson
> ... Visual Basic is to programming what colorforms is to impressionism.
QOTW!
--
"Custody" and "visitation" are for prisoners.
http://assembly.state.ny.us/leg/?bn=A01920&sh=t
Darren New
> languages. It's close integration with X and
> it's many libraries and adaptions to various
> needs make it an unequalled tool for bludgeoning
> programming problems into submission. However,
It also has the advantage of being portable, of usually doing the right
thing configuration-wise, your GUIs will run unchanged on the major
platforms, yet there's a bunch of platform-specific stuff available too.
You want the GUI to run unchanged on both UNIX and Windows, but you want
to be able to run another part as an NT "service" with a pop-up icon in
the taskbar? Go with Tcl.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
To the user, everything works just as expected,
assuming the user's expectations are correct.
Eric
looks at your indentation to figure out what you want to do?
Larry Smith wrote:
Cameron Laird
Eric <eta...@jpl.nasa.gov> wrote:
>I may have this wrong, but isn't python that language that
>looks at your indentation to figure out what you want to do?
.
.
Python is the most widely-known of several "white-space-significant"
languages for which indentation is a crucial aspect of syntax.
Eric Taylor
I just couldn't deal with the whitespace issue. I was a bit concerned
that this could lead to erroneous programs. For ex, what happens if you
mix tabs and spaces? Wouldn't you need to define tabsize properly?
Do you end up needing a special editor help to keep this straight? Every time
I switch between notepad type editors and my 4-char-tab preference I get
ugly indentation results, but at least I can make a quick change to my code.
This is a scripting language, no?
I used to complain about languages that required semi-colons. I felt they
were unneeded as statement terminators, since newline was a more normal
choice. My one claim to fame was when I wrote a critique of Pascal and
it's inventor (Wirth) blasted me. I didn't like the words begin/end and all
the semicolons.
But, getting rid of all syntax and using white space is a bit beyond my liking.
And often I construct scripts in a program and send them over a socket to
be run remotely. What a pain it must be to get the indentation right in that case.
So, IMHO Tcl/Tk is by far the best scripting language.
e
Cameron Laird
Eric Taylor <e...@rocketship1.com> wrote:
>Ahh, this is the language a friend raved about to me some 10 years back.
>I just couldn't deal with the whitespace issue. I was a bit concerned
>that this could lead to erroneous programs. For ex, what happens if you
>mix tabs and spaces? Wouldn't you need to define tabsize properly?
>Do you end up needing a special editor help to keep this straight? Every time
>I switch between notepad type editors and my 4-char-tab preference I get
>ugly indentation results, but at least I can make a quick change to my code.
>This is a scripting language, no?
.
.
>But, getting rid of all syntax and using white space is a bit beyond my liking.
>And often I construct scripts in a program and send them over a socket to
>be run remotely. What a pain it must be to get the indentation right in that case.
>
>
>So, IMHO Tcl/Tk is by far the best scripting language.
.
.
What happens when people begin to use Python is that
many of them panic for the first week over the issues
that you raise. After that, they either
*) decide they like the advantages of
significant white space so much they
wouldn't have it otherwise
*) conclude that Python has more important
aspects than its white space
In either case, white space becomes a non-issue. Over
and over again, that's what happens when people actually
give the language a try.
lvi...@yahoo.com
> From: cla...@starbase.neosoft.com (Cameron Laird)
>What happens when people begin to use Python is that
>many of them panic for the first week over the issues
>that you raise. After that, they either
>*) decide they like the advantages of
> significant white space so much they
> wouldn't have it otherwise
>*) conclude that Python has more important
> aspects than its white space
Or they decide that they don't care for Python and move on. And that's
fine as well.
I have watched over Python's shoulder since it was ABC. It's changed a lot.
I myself didn't like the white space issues, but eventually, I decided that
while I might force myself to deal with that, I really at this time couldn't
find enough reasons to invest more time in python as a
'real programming language' when what I wanted was simple scripting languages.
In fact, Tcl and Tk just barely make the cut here - I find myself doing
mostly Unix shell scripting via ksh, awk, etc. and python, perl, and
even Tcl/Tk at times require more design energy to solving my daily
programming tasks than I really care to spend.
For me, personally, I make the cut this way:
If I have something I want done quickly, and that I don't plan on using
frequently or more than a few times, I write it in ksh/awk/etc.
If I have something that is going to take a bit longer because it is going
to need more complex algorithms, or performance is going to be an issue, I
either write it in C, or I take a whack at it in Tcl, or I try to talk
someone into helping me write it in Perl.
There are other tasks that come along that get coded in whatever the person
(I am able to convince to do the work ) wants to use...
Back to the original requestor - it all depends on your background and
your intention. There are not many books designed to teach someone how
to program, using Tcl as the langauge for the examples. Most expect
some level of understanding of variables, program design, etc.
If you are wanting to write programs that do computations, then all 3
languages are probably sufficient. If you are wanting to write something
GUI, are not too concerned about specific look and feel issues, and Tk or
Fltk suit you, then Tcl/Tk are certainly what I would recommend.
If what you are wanting to do is to embed the language into an existing
program, I think Tcl would be the way I would recommend.
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
David Snyderman
> is tcl the right language for an absolut beginner and non-professional? I
> want to learn to write some small programms for using on a linux-machine
> (without and with x-window).
I know nothing about Python. Perl is not, IMO, a good language for
beginners-- although I do think it's good for people coming from a C
background: it's kind of a C-like syntax with string handling on
steroids. But I think that its syntax and actual practice leads to
confusing, hard-to-read code.
I don't know how credible my opinion on TCL for an absolute beginner
is; I came to TCL after a long time of C programming. But my belief is
that TCL is, in fact, the ideal language for a beginner-- and I've
been recommending it as such to friends who wish to start their kids
out programming in something.
There are a bunch of things that make TCL great for beginners (and for
those of us professionally developing applications). In no particular
order:
-- The syntax is simple, straightforward, easy, and often intuitive. I
don't know how to quantify this, but my gut feel is that I can write
TCL code in much larger chunks and have it just work with much less
(or no) debugging than I could if I were working in C.
-- The ease of creating GUIs is, in my experience, unsurpassed. While
there are graphical IDEs out there-- and some very good ones, like
spectcl and visual tcl-- the truth is that many (most?) of us just
don't use them because it is so easy to write TCL text that creates
the UI. That's a significant issue for a beginner-- you can create
something that looks great and performs a few tricks with very little
effort.
-- The facilities available in native TCL are terrific-- witness a
discussion a month or so ago about client/sockets in TCL. I had just
finished a test client/socket app myself and was able to really enjoy
that chain because it mirrored my experiences.
-- The facilities available in free (mostly, BSD) packages are even
more impressive. Specifically, I've been using tcllib, tclXML, tclDOM,
and BWidgets. Great packages, all of them, with a lot of utility. And
there are oodles more!
-- The learning curve is not too steep. Many people seem to go about
learning it by picking up Brent Welch's book
(http://www.beedub.com/book/). On his website, he lets you read
earlier editions of the book-- that's how I decided to purchase it.
I've got some other really great TCL books on my shelf now, too: Steve
Ball's Web TCL complete, Harrison and McLennan, and Foster-Johnson. I
refer to them and have learned different things from each one. But the
other book I find myself referring to as much (or more) than Brent's
is "TCL/TK in a Nutshell".
-- The community is wonderful. This usenet group is friendly,
tolerant, and helpful to a degree unmatched in my experience.
What is TCL missing?
There has been a lot of discussion about rolling in some of the
packages (especially tcllib) in to the TCL core. That would help
improve TCL's "out of the box experience".
Coming from a C background, I continue to be amazed at the lack of
numeric support without resorting to the [expr] command. I also still
miss multidimensional arrays and structures. Finally, we use the
[global] key word for both global and static; that troubles me. I'd
like a separate [static] key word for variables I'd like to have hang
around but not necessarily accessible by other procs.
There's a lot of concern about the general direction of the language.
It seems to me that Jeff Hobbs has been largely guiding it through a
time full of turmoil-- the whole Scriptics/Ajuba/ActiveState period.
He has been an excellent stabilizing influence; he's also the voice of
experience and one of the few people who seem to have a more-or-less
complete overview of the TCL picture (Cameron Laird is the other one
who comes to mind). But I, for one, can't help but worry where we'd be
without him.
There is no omnipotent corporate entity driving TCL, as with Sun and
Java. That's a good/bad situation. There's also no definitive,
reliable TCL-TK central site on the web; although there are many
distributed sites(ActiveState's, the Wiki, Zveno, the TCL foundry at
SourceForge, among others), each of which have one or more pieces of
the puzzle.
There's a perception among many people not in the TCL community that
it isn't a serious tool. To be fair, there are some performance issues
with TCL. But most of the traditional complaints against TCL (handling
of binary data, poor performance with arrays/lists/hashes, lack of
support for XYZ) have been addressed, as best as I can tell, in TCL
versions 8 and up.
The market for commercial tools for TCL seems somewhat thin. There are
tools out there; not as many for Java; and they seem not to be making
anybody rich. That's largely because of the wealth of free tools
available (Freewrap, Metakit, TCLKit, and the various IDEs). So that's
another glass half-empty/half-full situation.
Hope that helps.
David
Arjen Markus
>
> Coming from a C background, I continue to be amazed at the lack of
> numeric support without resorting to the [expr] command. I also still
> miss multidimensional arrays and structures. Finally, we use the
> [global] key word for both global and static; that troubles me. I'd
> like a separate [static] key word for variables I'd like to have hang
> around but not necessarily accessible by other procs.
>
[expr]:
If you study the various Wiki pages by Richard Suchenwirth, you
will see that you can make Tcl look like almost any language.
I made a small calculator with functions/macros myself based on
one of his examples. It has replaced UNIX' bc (not to mention that
for the first time in my life, I have some decent calculator under
Windows as well!)
I do agree that [expr] is surprisingly lonesome in its support for
numerics (coming from a Fortran background), but I would like to
see Tcl used for more math and mathematics than it currently seems
- it is one of my (many) pet projects in Tcl.
Know however that there are numerical extensions around, like a
linear algebra package in pure Tcl (http://www.hume.com, if
I remember correctly).
[static]:
A lot can be achieved by [namespace inscope] and [interp alias]
(Bother, I must work out this one - I have been crying this out
loud for some time now, but have not implemented anything yet)
Regards,
Arjen
Cameron Laird
Arjen Markus <Arjen....@wldelft.nl> wrote:
.
.
.
>I do agree that [expr] is surprisingly lonesome in its support for
>numerics (coming from a Fortran background), but I would like to
>see Tcl used for more math and mathematics than it currently seems
>- it is one of my (many) pet projects in Tcl.
>
>Know however that there are numerical extensions around, like a
>linear algebra package in pure Tcl (http://www.hume.com, if
>I remember correctly).
.
.
Also note that a fair number of Tcl users have
backgrounds in academic mathematics. A bit of
leadership might pull together a critical mass
to accomplish ... well, what *do* knowledgeable
mathematicians accomplish?
Arjen Markus
>
> In article <3C8628D1...@wldelft.nl>,
> Arjen Markus <Arjen....@wldelft.nl> wrote:
> .
> .
> .
> >I do agree that [expr] is surprisingly lonesome in its support for
> >numerics (coming from a Fortran background), but I would like to
> >see Tcl used for more math and mathematics than it currently seems
> >- it is one of my (many) pet projects in Tcl.
> >
> >Know however that there are numerical extensions around, like a
> >linear algebra package in pure Tcl (http://www.hume.com, if
> >I remember correctly).
> .
> .
> .
> Also note that a fair number of Tcl users have
> backgrounds in academic mathematics. A bit of
> leadership might pull together a critical mass
> to accomplish ... well, what *do* knowledgeable
> mathematicians accomplish?
> --
(Do not look at me - I am a physicist by training, well a
physical engineer, to be more precise by one or digits,
though this seems a strange non-anglosaxon denomination,
merely using mathematics, not inventing it).
Regards,
Arjen
lvi...@yahoo.com
According to David Snyderman <dave...@yahoo.com>:
:What is TCL missing?
:Coming from a C background, I continue to be amazed at the lack of
:numeric support without resorting to the [expr] command.
I don't understand your 'resorting to' reference here. Everything in
Tcl is done via commands. So one does not have support for anything
except by command.
So are you saying that you find the expr numeric support insufficient?
Perhaps you and some others here could write up a TIP and implement it to
enhance expr (or even provide a superior replacement). Many of us
are always in favor of new features such as this.
:I also still
:miss multidimensional arrays and structures.
I don't miss structures much, but I have a few times missed multidimensional
arrays. And yes, I know there are Tcl conventions for emulating...
:Finally, we use the
:[global] key word for both global and static; that troubles me. I'd
:like a separate [static] key word for variables I'd like to have hang
:around but not necessarily accessible by other procs.
Private variables would be useful.
:There's a lot of concern about the general direction of the language.
: But I, for one, can't help but worry where we'd be
:without him.
If you read through the TCT mailing list, you will see a number of other
names of people whose knowledge, at least of slices of Tcl, is quite deep.
And things could be chaotic if there were several strong charasmatic
personalities within the community - unless they were united in vision.
:Java. That's a good/bad situation. There's also no definitive,
:reliable TCL-TK central site on the web; although there are many
:distributed sites(ActiveState's, the Wiki, Zveno, the TCL foundry at
:SourceForge, among others), each of which have one or more pieces of
:the puzzle.
I myself find 'central site on the web' to be a dubious help - unless
there is a support structure underneath with multiple servers working
transparently to ensure 24/7 update, having all of one's eggs in one
basket is a way to get a spoiled omlette...
David Snyderman
> I don't understand your 'resorting to' reference here. Everything in
> Tcl is done via commands. So one does not have support for anything
> except by command.
Writing:
set i [expr $j%3]
feels much less natural than
set i $j%3
> I don't miss structures much, but I have a few times missed multidimensional
> arrays. And yes, I know there are Tcl conventions for emulating...
I'm with you-- the emulations don't provide the same ease of access
and conceptualization.
> If you read through the TCT mailing list, you will see a number of other
> names of people whose knowledge, at least of slices of Tcl, is quite deep.
> And things could be chaotic if there were several strong charasmatic
> personalities within the community - unless they were united in vision.
My apologies-- I did not mean to leave anyone out.
But Jeff strikes me as a great leader who really knows the width and
breadth of this language and its extensions. He leads not by throwing
weight around but rather just kind of handling a lot of things. And
he's always helpful to people with questions-- both on clt (I see him
do a lot of that) and by email (he and I have corresponded several
times).
I think he does most of this in an atmosphere without actual thank
yous-- I don't know how to let him know that many of us appreciate his
efforts and assistance other than to sing his praises in forums such
as this one.
David
marsd
> > From: cla...@starbase.neosoft.com (Cameron Laird)
>
> >What happens when people begin to use Python is that
> >many of them panic for the first week over the issues
> >that you raise. After that, they either
> >*) decide they like the advantages of
> > significant white space so much they
> > wouldn't have it otherwise
> >*) conclude that Python has more important
> > aspects than its white space
>
>
> mostly Unix shell scripting via ksh, awk, etc. and python, perl, and
> even Tcl/Tk at times require more design energy to solving my daily
> programming tasks than I really care to spend.
I have had exactly the opposite experience..maybe it is just because
my
skills are not as advanced as yours, but sometimes when writing
scripts that require some degree of checking and balancing, trapping
unwanteduser input(if interactive) or trying to get a shell script to
talk over a net socket effectively, I find myself missing tcl.
Most times these days the script gets rewritten in tcl, even if
the shell script would have been possible and challenging:
it just isn't worth the waste of time.
> If I have something I want done quickly, and that I don't plan on using
> frequently or more than a few times, I write it in ksh/awk/etc.
Several times I have wanted a way to return a random single character
from
within a shell script from a function arg.this seems simple. The
closest I ever came in the shell was this using awk:
function random(num) {
srand()
r = int(1 + rand() * num)
return r
}
function stringvar(str,num, arr,i) {
for (i=0 ; i <= length(str) ; i++) {
arr[i] = substr(str,i,(length(i)))
if (i == num) {
return arr[i]
}
}
}
BEGIN {
x = random(length(ARGV[1]))
ii = stringvar(ARGV[1],x)
print "String rand=", ii
}
(And I really enjoy writing in awk, it's C without the mess.)
compared to tcl:
proc random {num} {
return [expr int(1 + rand() * $num)]
}
proc stringvar {str N} {
for {set x 1} {$x <= [string length $str]} {incr x} {
if {$x == $N} {
#puts [string index $str $x]
return [string index $str $x]
}
}
}
set xx [stringvar [lindex $argv 0] [random [string length [lindex
$argv 0]]]]
puts -nonewline stdout "$xx\n"
flush stdout
the tcl script is cleaner and works: of course I attribute the awk
problems to myself, not the language., but it is very simple in tcl
as well.
> If I have something that is going to take a bit longer because it is going
> to need more complex algorithms, or performance is going to be an issue, I
> either write it in C, or I take a whack at it in Tcl, or I try to talk
> someone into helping me write it in Perl.
But you have the flexibility to do these things so maybe that is why
your view is not representative of the beginner.
I've only been coding a year+ so i find tcl very ideal indeed and
wouldrecommend to anyone as a good, effective language
to start with over any other , except possibly the shell.
Jeffrey Hobbs
...
> numeric support without resorting to the [expr] command. I also still
> miss multidimensional arrays and structures. Finally, we use the
But you don't have any problem with using arrays like so, right?
set a(1,0) hello
set a(1,1) goodbye
> [global] key word for both global and static; that troubles me. I'd
> like a separate [static] key word for variables I'd like to have hang
> around but not necessarily accessible by other procs.
This is where you would use namespaces and variable.
> There's a lot of concern about the general direction of the language.
> It seems to me that Jeff Hobbs has been largely guiding it through a
> time full of turmoil-- the whole Scriptics/Ajuba/ActiveState period.
> He has been an excellent stabilizing influence; he's also the voice of
> experience and one of the few people who seem to have a more-or-less
> complete overview of the TCL picture (Cameron Laird is the other one
Thanks for the kind words. While I do still have quite a dedication
for Tcl (inspired by earlier predecessors including in large part
John Ousterhout directly), there are many that manage the puzzle that
keeps Tcl together. While it would be nice to have more, I am happy
to work with so many other talented Tcl'ers!
> There's also no definitive,
> reliable TCL-TK central site on the web; although there are many
I would like to think that the new acquisition of http://www.tcl.tk/
will be one that stabilizes the central site problem. Even though I
do work for ActiveState, and we do generate $$$ from Tcl, I'm not
going to inflict the community with any other name confusion with
yet another company branded Tcl site (the above is also
http://tcl.activestate.com/, but I want to move away from that as
much as possible).
Having control over the full *.tcl.tk name space, we can also make
rational names that will live for a long time (wiki.tcl.tk already
exists, more to come).
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Arjen Markus
>
> lvi...@yahoo.com wrote in message news:<a65pqs$ov8$1...@srv38.cas.org>...
>
> > I don't understand your 'resorting to' reference here. Everything in
> > Tcl is done via commands. So one does not have support for anything
> > except by command.
>
> Writing:
>
> set i [expr $j%3]
>
> feels much less natural than
>
> set i $j%3
>
You could define:
proc setv { var value } {
upvar $var vname
set vname [expr {$value}]
}
and use:
setv i $j%3
By the way: static variables and such - have a look at:
<http://mini.net/tcl/3096.html>
Regards,
Arjen
Victor Wagner
> David Snyderman wrote:
>>
>> lvi...@yahoo.com wrote in message news:<a65pqs$ov8$1...@srv38.cas.org>...
>>
>> > I don't understand your 'resorting to' reference here. Everything in
>> > Tcl is done via commands. So one does not have support for anything
>> > except by command.
>>
>> Writing:
>>
>> set i [expr $j%3]
>>
>> feels much less natural than
>>
>> set i $j%3
>>
> You could define:
> proc setv { var value } {
> upvar $var vname
> set vname [expr {$value}]
> }
I'd rather do
proc setv {var args} {
upvar $var vname
set vname [uplevel expr $args]
}
You've got couple of errors.
1. If expression contain spaces, it wouldn' be evaluated properly
2. It would be evaluated in wrong context, so all the local variables
wouldn't be visible
3. Yes, expr does variable substitution even if argument is braced.
But in this case it treats each variable as operand.
Arjen Markus
Yes, you are right - I did not try the code first. Too much haste,
I should have learned by now :-(
Regards,
Arjen
Arjen Markus
Note: the braces with [expr]'s argument have effect!
set 1 1.0111
set 3 3.2222
[expr {$1/$3}] does not necessarily give the same result
as [expr $1/$3]
(The numerical differences are usually subtle, but they are there.
There are also performance differences)
The braces are recommended at "all" times.
Regards,
Arjen
Donal K. Fellows
> Also note that a fair number of Tcl users have
> backgrounds in academic mathematics. A bit of
> leadership might pull together a critical mass
> to accomplish ... well, what *do* knowledgeable
> mathematicians accomplish?
Depends on the mathematician! :^)
I know a fair few who are interested in putting the whole of mathematics on a
formal basis, and another who's interested in arbitrary precision arithmetic.
Then there are the people doing category theory and (many different branches of)
modal logic. Plus the people writing various kinds of theorem provers. And
that's all within my department. For these people, Tcl doesn't address what
they want from a computer language for mathematics, but then neither really do
other mainstream languages either (with the exception of the arbitrary precision
guy, who works purely in C for speed, and the theorem prover people who use C++
at the moment, but think it too slow and unsupportive of their work.) Don't
worry about them though; their needs are almost all *very* specialised.
Donal.
--
"If something like this happened in the real world, not only would I be under
NDA, but I would also be afraid of having my own personal butt involved in
the legal equivalent of the massacre of Little Big Horn, with the lawyers
starring as the Indians." -- Chuck Swiger <ch...@friday.com>
Donal K. Fellows
> I know nothing about Python. Perl is not, IMO, a good language for
> beginners-- although I do think it's good for people coming from a C
> background: it's kind of a C-like syntax with string handling on
> steroids. But I think that its syntax and actual practice leads to
> confusing, hard-to-read code.
Perl's designed so that people with a background in C, UNIX shell, sed and awk
can code something complex up without having to get rid of any of their bad
habits... :^)
> Coming from a C background, I continue to be amazed at the lack of
> numeric support without resorting to the [expr] command.
Tcl's a string language, unlike C (which is a sort-of high-level assembly
language!) Turn the whole thing on its head, and be surprised that you can't do
string concatenation in C without resorting to complex memory management and the
strcat() function...
> I also still miss multidimensional arrays and structures.
Look out for the new [lset] command in Tcl8.4a4. :^)
> Finally, we use the
> [global] key word for both global and static; that troubles me. I'd
> like a separate [static] key word for variables I'd like to have hang
> around but not necessarily accessible by other procs.
I take it you're after procedure-local "persistent" variables? (Tcl doesn't
have a notion of compilation unit so file-local doesn't mean too much.) They
would be nice, I admit. Sounds like a good idea to me (you'd need to store them
in the Proc structure, but that's OK since that's private to Tcl anyway...)
Please either log a feature request for this at http://tcl.sf.net/ so the idea
doesn't get forgotten, or (if possible) create a TIP and patch to introduce the
feature to the core (in which case, if you're fairly quick, it might even make
it into 8.4.0). If you're going down the TIP route, you'll want to study
http://purl.org/tcl/tip/ and maybe read through the archives of the tcl-core
mailing list (also on SF.)
Donal K. Fellows
> Writing:
> set i [expr $j%3]
> feels much less natural than
> set i $j%3
It helps if you remember that Tcl's a string processing language first and
foremost, and just happens to do a bit of math on the side. (By contrast,
FORTRAN is a math processing language first and foremost, and just happens to do
a bit of string handling on the side.) In this case, this has the effect of
making your second command set the variable 'i' to the concatenation of the
contents of the variable 'j' with the literal string '%3'. It's all a question
of priorities.
Cameron Laird
marsd <nomob...@hotmail.com> wrote:
.
.
.
>I've only been coding a year+ so i find tcl very ideal indeed and
>wouldrecommend to anyone as a good, effective language
>to start with over any other , except possibly the shell.
I'm going to try out this new song I've been
working on. It's called, "For (Unix) sysads,
Expect is the single most useful language you
can learn (even better'n the shell)."
Cameron Laird
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
.
.
.
>I know a fair few who are interested in putting the whole of mathematics on a
>formal basis, and another who's interested in arbitrary precision arithmetic.
>Then there are the people doing category theory and (many different branches of)
>modal logic. Plus the people writing various kinds of theorem provers. And
>that's all within my department. For these people, Tcl doesn't address what
>they want from a computer language for mathematics, but then neither really do
>other mainstream languages either (with the exception of the arbitrary precision
>guy, who works purely in C for speed, and the theorem prover people who use C++
>at the moment, but think it too slow and unsupportive of their work.) Don't
>worry about them though; their needs are almost all *very* specialised.
.
.
Serious reply: my own vision of mathematics is that proof
automation is going to take over, in the sense that semi-
formal (in a sense I can make precise) presentation will
become standard. 'Bet I could show how to improve category
theory and modal logic with Tcl, if I worked at it hard
enought. Maybe I should ...
Tcl's handy for some real mathematics; Richard has demonstrated
in the Wiki tiny little procs that turn Tcl into a handy
calculator for some graph problems.
Percolation theory's still young enough that Tk makes for
a good workbench (combined with fast C or Fortran extensions).
Same's true for wavelets, although I don't know anyone who's
implemented his or her work that way.
I utterly disagree with C as a vehicle for theorem-proving.
'Guess we'll take that up another time.
There's more--more than I have the patience to describe now.
What I really had in mind when I wrote earlier was more Tcl's
pedagogic potential. Think of it as a more inviting LISP,
with all that implies.
joe_english
>
>Writing:
>
>set i [expr $j%3]
>
>feels much less natural than
>
>set i $j%3
And, to me anyway, neither feel as natural as
set i [% $j 3]
--Joe English
David N. Welton
> There's more--more than I have the patience to describe now. What I
> really had in mind when I wrote earlier was more Tcl's pedagogic
> potential. Think of it as a more inviting LISP, with all that
> implies.
Isn't that what Dylan's for?:-)
More about 'inviting lisp':
http://www.paulgraham.com/popular.html
Looks cool to me...
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Cameron Laird
David N. Welton <dav...@dedasys.com> wrote:
>cla...@starbase.neosoft.com (Cameron Laird) writes:
>
>> There's more--more than I have the patience to describe now. What I
>> really had in mind when I wrote earlier was more Tcl's pedagogic
>> potential. Think of it as a more inviting LISP, with all that
>> implies.
>
>Isn't that what Dylan's for?:-)
>
>More about 'inviting lisp':
>
>http://www.paulgraham.com/popular.html
>
>Looks cool to me...
.
.
It's a good reference, and dropping "Dylan" into
a conversation's 'most always OK with me.
Tcl's got a pretty good record of adoption, or
at least digestion, by people who are NOT focused
mostly on computers. That's part of the motiva-
tion to talk about mathematicians. You can say
to them, "Tcl--it gives you a GUI toolkit, it
glues well, the syntax is minimal and regular,
and you can put the stuff you want in it." As a
mathematician, that appeals to me. Dylan's ad-
vantages over Tcl are mostly in aspects that are
meaningful only to software people, not to out-
siders, even when they're intelligent.
Bruce Hartweg
"Arjen Markus" <Arjen....@wldelft.nl> wrote in message news:3C8732A6...@wldelft.nl...
not quite - if you have operators stored in a variable you can't braces
try:
set v1 10
set v2 20
set op +
expr $v1 $op $v2
expr {$v1 $op $v2}
Bruce
Darren New
> Perl's designed so that people with a background in C, UNIX shell, sed and awk
> can code something complex up without having to get rid of any of their bad
> habits... :^)
QOTW!
> Tcl's a string language, unlike C (which is a sort-of high-level assembly
> language!)
Q: Will high-level languages ever completely replace assembler?
A: No, but C might.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
To the user, everything works just as expected,
assuming the user's expectations are correct.
lvi...@yahoo.com
According to Arjen Markus <Arjen....@wldelft.nl>:
:David Snyderman wrote:
:>
:> lvi...@yahoo.com wrote in message news:<a65pqs$ov8$1...@srv38.cas.org>...
:>
:> > I don't understand your 'resorting to' reference here. Everything in
:> > Tcl is done via commands. So one does not have support for anything
:> > except by command.
:>
:> Writing:
:>
:> set i [expr $j%3]
:>
:> feels much less natural than
:>
:> set i $j%3
But the first feels much more Tcl-like than the latter ...
However, if you want a language different from Tcl, Tcl allows one
to do quite a bit of modification of the syntax - if you look around
<URL: http://purl.org/tcl/wiki/> , Richard has written several pages
with code showing alternate 'eye candy' for the set command...
Donal K. Fellows
> "Donal K. Fellows" wrote:
>> Perl's designed so that people with a background in C, UNIX shell, sed and awk
>> can code something complex up without having to get rid of any of their bad
>> habits... :^)
>
> QOTW!
The thing is, I suspect that Perl people would agree with that and view it as a
desirable feature, whereas for us it is a clear demonstration of what is wrong
with the language. It must be a matter of attitude.
>> Tcl's a string language, unlike C (which is a sort-of high-level assembly
>> language!)
>
> Q: Will high-level languages ever completely replace assembler?
> A: No, but C might.
I suspect assembler will not completely die, if for no other reason than the
fact that you have to write at least some of the bootstrap code for C programs
in something else, given that it relies on being placed at the correct location
in memory. At the very least, it would require a language extension to do that
in C... :^)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- A large ASCII art .sig is the Usenet equivalent of walking around in
public with your asscrack sticking out past the top of your sweatpants.
You be the judge. -- Mike Hoye <mh...@prince.carleton.ca>
lvi...@yahoo.com
According to Donal K. Fellows <fell...@cs.man.ac.uk>:
:Look out for the new [lset] command in Tcl8.4a4. :^)
I was just reading the doc for this. I guess I am a bit saddened by a few
things with the command. Guess that serves me right for not paying enough
attention during the life of the TIP.
First, here's another one of those list specific commands starting with l,
instead of being an option in a general list management command that I've
always preferred. I guess that's a pipe dream that has to wait for Tcl 9.
The command appears to be an attempt to access 'slices' of a list.
And perhaps I am missing some beauty here after reading the docs and the
man pages.
There are two uses for slices that I can envision:
1. Return the value of a particular slice of a list:
For instance, show me list elements 3-7 of a 12 element list
2. Set the value of a particular slice of a list:
For instance, replace list elements 3-7 with 1, 5, or 20 new elements
From what I read, lset is designed for use 2 basically. Except, unless
I am mistaken, there is no way to modify _ranges_ of elements. Instead,
one is restricted to dealing with one element at a time.
Also, from what I read, there isn't a way to use lset to do "use" 1.
Considering that Tcl's _set_ is recommended for both setting and displaying
a value, I expected a symmetry to occur with a name so close.
While certainly there are ways to code procs to do this, it just seems like
it could have been a part of the command from the beginning, so that
if one had a list and indexs one would display the appropriate subset.
Roy Terry
lvi...@yahoo.com wrote:
>
> According to Donal K. Fellows <fell...@cs.man.ac.uk>:
> :Look out for the new [lset] command in Tcl8.4a4. :^)
>
> I was just reading the doc for this. I guess I am a bit saddened by a few
> things with the command. Guess that serves me right for not paying enough
> attention during the life of the TIP.
[complaints about lset's name vs. function]
I find the most unfortunate is that
the list must exist before I can "lset" it. This
is understanable but clashes again with plain old "set"
Whe're still in alpha. New names anyone?
I toss out:
lpoke
lsetnested
lassign (already in play elsewhere)
lsetnode
....
It seems apparent that the existing "lset" will create
incorrect expectations for most users of this
command and so a better name should be sought.
Roy
Donal K. Fellows
> First, here's another one of those list specific commands starting with l,
> instead of being an option in a general list management command that I've
> always preferred. I guess that's a pipe dream that has to wait for Tcl 9.
What would you call such a beast? The best name, [list], is already taken.
> The command appears to be an attempt to access 'slices' of a list.
No.
> And perhaps I am missing some beauty here after reading the docs and the
> man pages.
It is a way of updating an element of a (sub-)*list, which it was a pain to do
previously (particularly with sub-lists) and even worse to do efficiently.
> Also, from what I read, there isn't a way to use lset to do "use" 1.
> Considering that Tcl's _set_ is recommended for both setting and displaying
> a value, I expected a symmetry to occur with a name so close.
What do you expect [array set x] to do?
> While certainly there are ways to code procs to do this, it just seems like
> it could have been a part of the command from the beginning, so that
> if one had a list and indexs one would display the appropriate subset.
Talk to Kevin Kenny about that. It's his baby. :^)
Don Porter
>> First, here's another one of those list specific commands starting with l,
>> instead of being an option in a general list management command that I've
>> always preferred. I guess that's a pipe dream that has to wait for Tcl 9.
> What would you call such a beast? The best name, [list], is already taken.
Actually, the best name, [::tcl::list] is still available.
And the best form of the best name, [tcl list] is still to be implemented.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
lvi...@yahoo.com
According to <Joe English>:
:And, to me anyway, neither feel as natural as
:
: set i [% $j 3]
Joe, are you a closet FORTH programmer?
David N. Welton
> According to <Joe English>:
> :And, to me anyway, neither feel as natural as
> :
> : set i [% $j 3]
>
> Joe, are you a closet FORTH programmer?
Forth uses RPN - the above is more Lisp'ish.
gforth:
10 3 mod ok
.s <1> 1 ok
I agree with Joe, in any case... eliminating the expr mini language
would also be useful for the people working on reducing the Tcl
footprint.
lvi...@yahoo.com
According to David N. Welton <dav...@dedasys.com>:
:I agree with Joe, in any case... eliminating the expr mini language
:would also be useful for the people working on reducing the Tcl
:footprint.
The users I deal with would find this horrifyingly hostile...
Arjen Markus
>
> "Arjen Markus" <Arjen....@wldelft.nl> wrote in message news:3C8732A6...@wldelft.nl...
> > (The numerical differences are usually subtle, but they are there.
> > There are also performance differences)
> >
> > The braces are recommended at "all" times.
> >
>
> not quite - if you have operators stored in a variable you can't braces
>
> try:
>
> set v1 10
> set v2 20
> set op +
> expr $v1 $op $v2
> expr {$v1 $op $v2}
>
> Bruce
Good point: I was not aware of this one!
Regards,
Arjen
joe_english
>According to <Joe English>:
>:And, to me anyway, neither feel as natural as
>:
>: set i [% $j 3]
>
>Joe, are you a closet FORTH programmer?
>
No, I openly admit to liking Forth :-)
But my preference for [% $j 3] instead of [expr]
comes from my earlier Scheme habit. As everyone
knows, Tcl has a nice, simple syntax, completely
defined by the 11 rules in the Tcl(n) man page,
based on parsing a script into a list of commands,
and each command into a list of words.
Except for [expr]. And commands like [if] and [while]
that embed a call to [expr].
These bits have a completely different syntax, which has
just enough in common with core Tcl syntax to make it look
vaguely Tclish ($, [], ""), but is really a much more
complicated sublanguage.
I understand that [expr] syntax is a political necessity --
many, many programmers have a deep distrust of non-infix
notations for arithmetic -- but to me prefix notation for
numeric operations would feel more like the rest of Tcl.
--Joe English
Donal K. Fellows
> Bruce Hartweg wrote:
>> expr $v1 $op $v2
>> expr {$v1 $op $v2}
>
Storing things other than leaf values in variables leads to expressions that
can't be compiled to bytecode (well, not and have a bytecode sequence that can
be retained for reuse; all invokations of [expr] go through bytecode in any case
because actually generating the bytecode is fairly cheap once parsing has been
done - it's just a tree-walk.)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- If somebody in a suit or a uniform can sit you down and have you believe
every word he says, you've just surrendered your license to be a thinking
human being and traded it in for a zombie suit. -- mh...@prince.carleton.ca
Donald Arseneau
> I find the most unfortunate is that
> the list must exist before I can "lset" it. This
> is understanable but clashes again with plain old "set"
>
> Whe're still in alpha. New names anyone?
lreplace?
(Ouch! Don't hit me!)
Seriously though, most tcl (list) commands work like functions,
returning the new list, so the occasional command that works
like a subroutine is a big annoyance! It is complicated and
hard to remember that lappend operates directly on a list variable
whereas linsert and lreplace preserve the original variable,
returning the modified new list. (If any of them should have
been an in-place operations, it would be lreplace, alias "lset".)
Despite the inefficiency of
set l [lreplace $l 2 3 foo bar]
I LIKE this syntax for its consistent tclishness.
I too would like the list operation commands (including new versions
that worked in-place) to fall under an omnibus command, in analogy
with "string". Perhaps "lmod" -- modify list variables, with
lmod replace, lmod insert,... in exact analogy with lreplace, linsert,...
but operating in-place and more efficiently.
Donald Arseneau as...@triumf.ca
Kevin Kenny
> I was just reading the doc for [the lset command]. I guess I am a bit
If it were any lesser light than you, Larry, posting those comments, I would
probably not have troubled to reply. If you find yourself "saddened," though,
I feel that I must try to address your concerns. Clearly, you've an unmet
need. I'm sorry that [lset] doesn't meet it -- that doesn't mean that I don't
want to try to come up with something that does!
Please, in the following discussion, recall that most of the work on
[lset] was done nearly a year ago, when I had not been named to the TCT. I
was coming to this task as an outsider. My scope was constrained by two
concerns: what I had time to implement, and what I thought I could persuade
the TCT to accept.
(1) RATIONALIZING THE [L*] COMMANDS
> First, here's another one of those list specific commands starting with l,
> instead of being an option in a general list management command that I've
> always preferred. I guess that's a pipe dream that has to wait for Tcl 9.
Alas, you're absolutely right. Certainly, I agree that the list
management commands belong in a namespace called ::tcl::list, and have
names without the leading 'l', but at the time that I wrote the TIP for
[lset], I didn't dare propose that. The Naming of Names is a can of worms,
and the various ways to restructure the namespace engender tremendous
controversy. Taking Bismarck's advice that politics is the art of the
possible, I chose my battles with care. Any rationalization of the [l]
commands was therefore out of scope for this TIP.
Ensembles and a general cleanup of the global namespace must be high on the
list of priorities for Tcl 9. (Getting a general release of 8.4 shipping is
even higher, but be assured that the TCT has not forgotten this issue!)
(2) LSET AS AN ARRAY ACCESSOR
> The command appears to be an attempt to access 'slices' of a list.
The command is not accessing slices of a list, but rather individual
elements. Think of [lset] and [lindex] as a complementary pair of commands
that allow you to think of Tcl lists as linear arrays, analogous to the
arrays in C. Perhaps you will still be disappointed that [lset] is not
an attempt to do list slicing, but perhaps you will also be pleased that
[lset] exposes arrays with numeric indices (rather than the hashtables
that Tcl calls "arrays") to the Tcl programmer.
Tcl's lists, since the advent of the Tcl_Obj in 8.0, have been linear arrays
"under the hood." In C, a Tcl list is represented with a linear vector of
Tcl_Obj pointers.
I've long wanted to be able to access these objects as an array: this
style of access is a good bit faster than hash tables. In other words,
I wanted to be able to say something like C's:
x[i-1] = x[i+1] - x[i];
My first attempt at this style of array access was TIP #29, where I
proposed that Tcl's array syntax be extended to lists as well. (Note that
the proposed change would have been backward compatible except for cases
that cause errors today.) In other words, I proposed that
set x [list 1 4 9]
set x(0) [expr { $x(2) - $x(1) }]
would do what might be expected, with the result that $x would contain
{5 4 9} after the operation.
Alas, TIP #29 drowned in controversy in the TCT's deliberations. When the
vote was finally called, it achieved a simple majority of the votes but
failed to garner the necessary two thirds.
Still having a use for linear arrays, I searched for a more palatable way
to accomplish my goal. I decided to pursue it by introducing a command that
sets a single element of a list. The [lset] command was the result.
Because TIP #22 (extending the syntax of [lindex] to address hierarchical
lists) was related, I took it over as well. (The original author had by
then abandoned its prosecution.) Working [lset] and [lindex] into a
complementary pair, I came up with TIP #33 (later amended by TIP #45 to
correct a clerical error that I discovered at implementation time).
The combination of 22-33-45 gave access to matrices as well as vectors:
[lindex $list $i $j] is the $jth element of the $ith sublist of $list, and
[lset $list $i $j $x] sets that element to $x.
The following code is an example; it constructs a Vandermonde
matrix and subtracts the identity matrix from it.
proc makeVandermonde { list n } {
set matrix [list]
foreach element $list {
set x 1
set row [list]
for { set i 0 } { $i < $n } { incr i } {
lappend row $x
set x [expr { $x * element }]
}
}
return $matrix
}
set matrix [makeVandermonde { 1. 2. 3. 4. } 4]
# A
for { set i 0 } { $i < 4 } { incr i } {
lset matrix $i $i [expr { [lindex $matrix $i $i] - 1. }]
}
Here $matrix is a list of lists: at the point in the code marked '# A',
it contains:
{{1. 1. 1. 1.} {1. 2. 4. 8.} {1. 3. 9. 27.} {1. 4. 16. 64.}}
The loop below A addresses individual elements in the sublists and
decrements them to subtract 1. from each diagonal element. After it
completes, the value in $matrix is:
{{0. 1. 1. 1.} {1. 1. 4. 8.} {1. 3. 8. 27.} {1. 4. 16. 63.}}
(Another example, with vectors instead of matrices, can be found in the
'shuffle6' procedure in http://wiki.tcl.tk/941.html.
Code like this is much, much faster than the corresponding code using
hash tables. If you're interested in doing light-duty numeric calculation
in Tcl, you'll appreciate the [lset]-[lindex] pair as a means of dealing
with Fortran- or C-style arrays. (Of course, blt::vector is an even
better solution for numeric data, but at the time TIP #33 was submitted,
I felt that was more than I could cope with proposing.)
(3) ACCESSING SLICES OF A LIST.
Of course, I still haven't address your desire to address 'slices' of
a list. I presume that you wanted to do something equivalent to
set list [lreplace $list $index1 $index2 newvalue1 newvalue2 ...]
or perhaps
set list [eval [linsert $newValueList 0 lreplace $list $index1 $index2]]
but without the performance drain engendered by object sharing; these
naive calls are slow. Of course, some of the performance can be recovered
by Donal Fellows's [K] combinator. This performance, however, comes at a
tremendous cost in comprehensibility that no implementor should ever be
asked to bear.
I assure you that I dislike the mystery of [K] just as much as you do. The
issue of unexpected variable sharing comes up over and over. I think it
needs to be addressed in a more general manner.
My thinking is twofold:
(1) Some applications actually need mutable objects; if the objects are
shared, then all uses should see all changes to the object. This is
actually, in my opinion, somewhat contrary to The Tcl Way unless the
mutable object is "opaque" -- that is, its string representation is
an arbitrary identifier rather than reflecting its value -- because
the semantics of variable traces are otherwise extremely complex,
difficult to explain, and just plain un-Tclish. Feather gives its
users mutable opaque objects, but if I remember correctly, stops
short of implementing mutable transparent objects for that very
reason.
(2) Many more applications wish to modify a variable's value without
needing to make a copy of it if the variable is unshared. Right now,
such a thing cannot be done in Tcl without resorting to [K].
Examples of the second approach today include [append] and [lappend],
[incr], and [lset]. Each of these does a read-modify-write operation
on a variable, with copy-on-write semantics for installing the new value.
The performance of each of these is much better than the corresponding
Tcl code:
set list [linsert $list end $x]; #Very slow, particularly for long lists
lappend list $x; #Much, much faster
The performance comes from two causes:
1. Object copies are avoided. In the first command above, the value
of $list is ALWAYS shared when it is presented to [linsert]: there
is one reference in the variable and a second one in the parameter
list. This problem is the real killer, and is what [K] is all
about.
2. More subtly, the second code also allows the caller to take advantage
over the fact that the bytecode compiler expands [lappend] in line.
I'm convinced that we need a general approach for user-defined operations
with read-modify-write semantics. Some general thoughts on this can be
found at http://wiki.tcl.tk/AnatomyOfABytecodedCommand, beginning about
two-thirds of the way down the page.
--
73 de ke9tv/2, Kevin KENNY GE Corporate R&D, Niskayuna, New York, USA
Don Porter
> [lindex $list $i $j] is the $jth element of the $ith sublist of $list, and
> [lset $list $i $j $x] sets that element to $x.
YM: [lset list $i $j $x]
Donal K. Fellows
> Despite the inefficiency of
> set l [lreplace $l 2 3 foo bar]
> I LIKE this syntax for its consistent tclishness.
Note that it might be possible at some point to detect some common cases (e.g.
using [lreplace] to modify a single element of a list variable) and replace it
with [lset]-implementation bytecodes, though it'd need to be careful to not go
out of range on the list. Hmm; a complex but probably worthwhile
optimisation...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- If I teach this course thoroughly enough, none of you will attempt the exam
questions on this topic, and I shall consider this to be a complete success.
-- Arthur Norman
Kevin Kenny
> > [lindex $list $i $j] is the $jth element of the $ith sublist of $list, and
> > [lset $list $i $j $x] sets that element to $x.
Don Porter wrote:
> YM: [lset list $i $j $x]
Yes, of course. Which is what I get for trying to write a Jeremiad like my
original message after a difficult twelve-hour workday. My apologies for the
gaffe.
lvi...@yahoo.com
According to Kevin Kenny <ken...@acm.org>:
:lvi...@yahoo.com wrote:
:> I was just reading the doc for [the lset command]. I guess I am a bit
:> saddened by a few things with the command.
:
:I feel that I must try to address your concerns. Clearly, you've an unmet
:need. I'm sorry that [lset] doesn't meet it -- that doesn't mean that I don't
:want to try to come up with something that does!
And after an excellent description, I come to the realization that what
I thought lset was doing is not what lset is doing.
Differing expectations are quite often the basis for conflict, or at least
unpleasant encounters. In this case, everyone's been so very kind in helping
me understand the purpose for lset.
I do hope that others in the community read through the excellent reply
that Kevin wrote, and find useful ideas and understanding.
bo...@aol.com
Worse yet, it uses a 'main stream' name, but it's not a mainstream
capability. I don't want to put it down or anything like that. It's
probably a killer feature, but for more complex situations. So lets
stretch a bit here and find a better name. What about 'setlist' as a
new command with sub-commands where other things can be added.
Use:
setlist element ... to do what this lset does.
Then add more...
setlist xxx for other new things.
This avoids the 'l' prefix problem and might give us a way out for
other list commands. It's not terse, but neither is 'string xxx' or
'file xxx' etc, etc.
What do you think?
bob
Roy Terry
bo...@aol.com wrote:
>
> Roy Terry <royt...@earthlink.net> wrote in message news:<3C88CA62...@earthlink.net>...
[Larry and Roy with various quibbles re "lset"]
> > It seems apparent that the existing "lset" will create
> > incorrect expectations for most users of this
> > command and so a better name should be sought.
>
> Worse yet, it uses a 'main stream' name, but it's not a mainstream
> capability. I don't want to put it down or anything like that. It's
> probably a killer feature, but for more complex situations. So lets
> stretch a bit here and find a better name. What about 'setlist' as a
> new command with sub-commands where other things can be added.
>
> Use:
> setlist element ... to do what this lset does.
>
> Then add more...
>
> setlist xxx for other new things.
>
> This avoids the 'l' prefix problem and might give us a way out for
> other list commands. It's not terse, but neither is 'string xxx' or
> 'file xxx' etc, etc.
>
> What do you think?
I don't think there's any " 'l' prefix problem". I like the command to
follow existing convention in that regard until such time as they *all*
get changed. Also I think the lset functionality is indeed reasonably
mainstream - all the more reason to try for a more communicative
name.
>
> bob
bo...@aol.com
Too many commands is a creeping problem. I hope we don't wait until
there are two or three screens of minutia to hunt through to find
something before we recognize that it is a problem. Its just better
organization not to give everything a name at the top level.
By mainstream I meant a command that is used a lot. lset will be way
down the list in terms of usage(percent of commands used). Another
one of those useful but seldom used commands. When you have as much
depth as tcl does, there are a lot of those.
If you want an 'l' prefix then 'lsetelement' says what it does but
isn't as nice (to my eyes) as 'setlist element'.
I don't have a problem with a plan for migration to a new system, if
you can stay on track and get there. Sudden changes are too
disruptive. To my way of thinking you could add 'setlist element' or
similar with one subcommand. Then gradually expand the language in
that direction, while keeping the 'l' commands.
Everyone seems to have a different view and some seem to want tcl to
be as though it just fell out of the sky and everything was perfectly
symetrical with no errors in judgment, not even minor ones, and
nothing was ever corrected or changed. Unrealistic.
bob
Donal K. Fellows
> Too many commands is a creeping problem. I hope we don't wait until
> there are two or three screens of minutia to hunt through to find
> something before we recognize that it is a problem. Its just better
> organization not to give everything a name at the top level.
Agreed, but I (and I believe a number of other TCT members agree with this) feel
that the correct fix for this will be a bit more complex. And will involve some
concepts closely linked with namespace/ensemble dualisms. (*Hint*: It's
probably not a good idea to have namespaces with the same name as a command...)
And won't happen before 9.0, because it will probably be backward-incompatible.
And won't happen for a bit, because we've got 8.4 to get to final first...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- What's the reason of long discussions, if at the end someone says, "we have
not yet thought about it..." -- Andreas Leitgeb <a...@pc7499.gud.siemens.at>
Donal K. Fellows
> By mainstream I meant a command that is used a lot. lset will be way
> down the list in terms of usage(percent of commands used). Another
> one of those useful but seldom used commands. When you have as much
> depth as tcl does, there are a lot of those.
It fits with the general idiom of list commands *as they currently stand*. It
is hard to evaluate how widely used a command like [lset] will be used ahead of
time, because it addresses a deficiency that has (probably) led to people using
different idioms (with decidedly mixed results, performance-wise.)
lvi...@yahoo.com
According to <bo...@aol.com>:
:Everyone seems to have a different view and some seem to want tcl to
:be as though it just fell out of the sky and everything was perfectly
:symetrical with no errors in judgment, not even minor ones, and
:nothing was ever corrected or changed. Unrealistic.
Dan Smart
> According to <bo...@aol.com>:
>:Everyone seems to have a different view and some seem to want tcl to
>:be as though it just fell out of the sky and everything was perfectly
>:symetrical with no errors in judgment, not even minor ones, and nothing
>:was ever corrected or changed. Unrealistic.
>
>
Bad quote.
It's not clear to me whether this is an argument against the quest to
perfect TCL in which case my response would be: "I realise that perfection
is unattainable, but that doesn't mean that we shouldn't continue to seek
it." or whether it is an attack on those (like me on occasion) who are
resistant to fundamental changes to the language without being convinced
that the benefits really outweigh the costs.
Either way I disagree with the sentiment.
Dan
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com