Things to consider for future Tcl enhancement
Michael Tiller
I've used Tcl for quite some time now. I've embedded in a couple of
simulations tools, I've used it to build graphical user interfaces and I've
written lots of scripts with it. However, I also try not to become too much
of a zealot and occasionally look for other useful tools to help me out.
Recently, I decided to have a serious look at Python and there were many
interesting things that struck me in the comparison.
As a result, I wanted to catalog some of the interesting differences. I
don't have any specific agenda in writing this message except to share
information. I tentatively considered giving the subject of this message as
"Tcl vs. Python" because I wanted to make an honest comparison of various
features. My concern was that this would trigger a language war which is
not my goal. So, I tried a more subdued title in the hopes of dropping
below the radar of those with tremendous religious fervor.
I want to be clear that I'm not advocating people switch to Python.
Furthermore, I'm *not* an expert in Python at all (I've only been using it
for about 2 weeks and I haven't done any big projects in it...yet).
Instead, I'm just trying to call attention to some things that I think are
nicely implemented in Python. Some of these things are basic design
decisions so I'm guessing there is very little possibility for similar
features to be incorporated into Tcl (i.e. because it just violates some of
the core language principles). Many of them though could be taken into
account as new language features are introduced. So, without anymore
qualifications and caveats, here are some of my thoughts on various topics:
CONTROL STRUCTURES
One of the things I thought was cleverest about Tcl's design (and I love
showing this off to people) is how I can create my own control structures
that look as though they are built in. This is due to Tcl's very clean
grammar (one rule: command arg arg arg ...) and quoting features ({} vs.
"").
I was quite enchanted with this but having looked back on it, cleverness
isn't always such a good thing. I would say that one of the striking
differences between Tcl and Python is the fact that Tcl is perhaps too
liberal in its syntax. While Python is a little more restrictive (for
example, their "for" loop is very much unlike C and Tcl in that it must
iterate over a list of things), this also leads to a certain elegance
because it prevents people from really perverting things too much (although
I'm sure this is possible in Python as well).
The point is that looking at Python code, it is a little easier for me to
follow what is going on because the code is restricted to only a few control
structures and quoting is much less important.
DATA STRUCTURES
Tcl has done some amazing things with just lists and associative arrays.
However, it has always bothered me that these data types are somewhat
limiting and asymmetric. For example, you cannot pass associative arrays by
value into procs but you can do that with lists. Furthermore, there really
isn't any support for stacks, trees, etc. Python has a slightly richer
choice of data structures (tuple, list, dictionary) although lists and
tuples are essentially equivalent (and actually the semantic differences are
a bit confusing). The important point is that they are more consistent
(i.e. I can pass all of them, by value, to functions). The fact that the
data structures are *not* represented as strings means that it has a more
rigorous type system than Tcl. The object system (see below) essentially
allows the list of potential data structures that can be represented to be
expanded but keeping some sense of type checking as well.
PACKAGE STRUCTURE
Now here is where I was very impressed with Python. Having worked with
tclIndex and pkgIndex.tcl files (and auto_mkindex, etc), I found the Python
system so simple by comparison. If I want to make a package, I just put
procs (well, defs) into a file and thats it. The file automatically
constitutes a package (although I can make more complex hierarchical
packages utilizing directories of files if *and only if* I want) so long as
it is in my PYTHONPATH. Not only that, the namespace issues are handled
seemlessly as well (i.e. the procs are placed in the package namespace
unless I explicitly import them into my current namespace.
Just to give you a flavor for how simple all this is, if I have a file
called Foo.py and it contains the following:
---------Foo.py-----------------
def calc_sum(x,y):
return x+y
def calc_prod(x,y):
return x*y
---------Foo.py-----------------
This package can then be used as follows:
---------Example----------------
# Use a package
import Foo
z = Foo.calc_sum(2,5)
# Import functionality from a package
def Bar(x,y):
from Foo import calc_prod
return calc_prod(3,7)
---------Example----------------
This is an example of where Tcl could implement something very similar.
Because of the flexibility in Tcl, somebody could probably create yet
another package handling system that worked in a nearly identical way (and
it probably wouldn't be that hard). While the Tcl package system is quite
flexible (i.e. package authors can write their own custom package loading
Tcl code), this seems quite complicated when compared to how Python does
things.
In addition, Python includes a facility for reloading packages (modules in
Python). As far as I know, Tcl doesn't include any facility for reloading
of packages. Furthermore, I find it somewhat confusing in Tcl to understand
exactly when various things are loaded.
Finally, because the Python package structure is nicely standardized, it is
possible for "wrapper" programs (e.g. Prowrap or freewrap) to easily bundle
extensions into a wrapped program.
OBJECT SYSTEM
Python's object system is OK (i.e. it didn't exactly bowl me over). I think
the "[incr Tcl]" framework is a much nicer design but that is perhaps
because I come from a C++ background and so therefore [incr Tcl] is closer
to what I'm used to. Somebody who has used more dynamic object systems
(Smalltalk, CLOS?) might prefer the Python system. The Python object system
is adequate which is better than nothing. Which brings me to the point that
*nothing* is exactly what core Tcl has. I'm not necessarily saying this is
a bad thing in general, but it is a bad thing when you want an object
system.
Granted, there are lots of object systems in Tcl and some of them are very
nice ([incr Tcl], XOTcl, etc). The point is, once again, that "freedom" and
"choice" are not necessarily always good things. The danger is that one
person write an extension in XOTcl while another writes in [incr Tcl] and
the code ends up looking like:
--------------------------------------------
itcl::class Player {
variable name ""
method kickBall {} { puts "Goooooaaall!" }
}
Class SoccerTeam -parameter {name location type}
SoccerTeam instproc newPlayer args {
# we use a unique autoname for the object to prevent name
# collisions, like ::player01, ::player02, ...
eval Player [self]::[my autoname player%02d] $args
}
SoccerTeam chelsea -name "Chelsea FC" -location "Chelsea"
SoccerTeam newPlayer -name "Pele"
--------------------------------------------
EXTENSIONS AND DISTRIBUTION
Another area where I was quite impressed was in the handling of extensions.
At first, I was quite disoriented because I came at this with a Tcl mindset.
I had a C++ library that I wanted to call from a Python script. So, I got
out SWIG and generated the wrapper code. Then came the compile phase. I
couldn't find any information about how to write a Makefile to build a
Python extension. It took me a little time, but I finally figured out that
Python comes with a standard module called distutils that handles building
extensions.
So I thought..."Neat, a special sort of 'make' for Python extensions". I
told it what files were in my extension (C files, Python files, data files,
etc) and it took care of building my extension. Very nice! Now,
"reinventing the [make] wheel" does cause certain problems (it wasn't the
best at figuring out when things needed to be remade) but it was so simple
(and standard).
BUT, that was just the tip of the iceberg. The same system can build, for
example, self-installing windows binaries or RPMs for distribution of my
extensions to other users. These extensions can then automatically install
themselves into the user's package hierarchy (this can be both good and bad
depending on whether you *want* them to do that or not). Not too shabby.
STANDARD LIBRARIES - Batteries (and lots of them) are included!
The standard Python library is really quite impressive. The amount of
functionality in it is a bit overwhelming. To see what I mean, just on over
to http://www.python.org/doc/current/lib/lib.html and have a look. A few
highlights include libraries for string handling, regular expresions, binary
file data structures, unit testing, persistence, threading. building
extensions, using various internet protocols and XML/HTML related
tools/parsers. In addition, the library includes python language tools like
a debugger, profiler and compiler.
Futhermore, the Python community seems to have a much more uniform way of
dealing with documentation. Apart from the fact that the language includes
some self-documenting features (using doc strings) akin to Emacs which allow
things like:
-------------------------------
>>> import re
>>> dir(re)
['DOTALL', 'I', 'IGNORECASE', 'L', 'LOCALE', 'M', 'MULTILINE', 'S', 'U',
'UNICODE', 'VERBOSE', 'X', '__all__', '__builtins__', '__doc__', '__file__',
'__name__', 'compile', 'engine', 'error', 'escape', 'findall', 'match',
'purge', 'search', 'split', 'sub', 'subn', 'template']
>>> help(re.match)
Help on function match in module sre:
match(pattern, string, flags=0)
Try to apply the pattern at the start of the string, returning
a match object, or None if no match was found.
>>>
-------------------------------
there also seem to be some well adhered to standards about documentation. I
don't know the details of their system, but the point is that they seem to
be able to generate documentation in much the same way has been *discussed*
in the Tcl community for some time (i.e. a standard format which can then be
used to generate man pages, HTML, PDF, etc).
MISCELLANEOUS
A few other language features that I though were worth mentioning were:
Lambdas (i.e. anonymous functions) - These are occasionally useful and the
syntax is very clean.
Indentation - Python has some rather..umm...interesting ideas about
indentation. Actually, I didn't even look at Python for a long time just
because I thought their requirement of using whitespace as part of the
language syntax was just plain wrong. The point is that while from a
parsing standpoint, making whitespace syntactically significant may seem
like real hassle, I have really grown to appreciate how clean the resulting
code is because it eliminates the need for lots of "{", "}" and ";"s. It
really does grow on you after a while. Of course, it becomes quite
important to have a good auto-indenting editor but that isn't too much of a
problem.
Threading - Python includes native support for threading. I'm not sure what
the current state of threading is *at the Tcl level* (I know that the core
has been thread-safe for a while now).
Exceptions - I find the Python exception system a little odd because
exceptions are really nothing more than strings mostly (I prefer the C++
idea that an exception should be an object...Python can do this but isn't
required). However, I once again would state that something is better than
nothing. I must admit that in Tcl I have been frustrated by the lack of
built-in "try" and "catch" functionality. I've tried to create my own
versions at times, but I always find that clear error reporting/handling is
difficult to implement.
CONCLUSION
OK, so this really seems like a "Python is better than Tcl" sort of post but
believe me when I say that is not what I'm trying to get across here. I'm
just trying to point out some areas where I think Python does a really nice
job. Hopefully this kind of information will spark some ideas among Tcl
developers. If you really want to think of this as a language war, think of
this as "language espionage" (i.e. I have been on patrol and this is what I
saw).
Some of these things are truly idelogical. Tcl is much "looser" than Python
and lets you do all sorts of crazy, wonderful, stupid and goofy things.
Which is cool and powerful. But, from a project management perspective,
this isn't necessarily a good thing. Python seems to be "stricter" and more
standardized.
I decided to post this because there was recently some discussion in the
newsgroup about Python and some people commented that Python was popular but
they didn't base their choice of tools/languages on what was popular. I
agree completely with this sentiment (I'm always championing what I feel may
be better technology even if it isn't popular). However, along with this
attitude comes the responsibility of knowing the facts on both sides of the
argument and making an informed decision. So I guess the point is to
understand that perhaps Python is popular for a reason and not just scoff at
the "Lemmings" who choose to use it.
Anyway, I hope some people find this to be useful information. There are
clearly lots of my own personal opinions here so take it for what it is
worth. I don't have the time to argue with people about these points
although I'll try to respond if people are interested in a legitimate
discussion.
--
Mike
miguel sofer
info.
Miguel Sofer
Cameron Laird
Michael Tiller <mti...@ford.com> wrote:
.
.
.
>Python extension. It took me a little time, but I finally figured out that
>Python comes with a standard module called distutils that handles building
>extensions.
.
.
>BUT, that was just the tip of the iceberg. The same system can build, for
Pythoneers don't think of the purpose of distutils
as to "handle building extensions". In the first
place, it's something like a super-installer--it's
for module *consumers*. Like CPAN, this kind of
standardization led naturally to accessories for
*producers*.
.
.
.
>there also seem to be some well adhered to standards about documentation. I
>don't know the details of their system, but the point is that they seem to
>be able to generate documentation in much the same way has been *discussed*
>in the Tcl community for some time (i.e. a standard format which can then be
>used to generate man pages, HTML, PDF, etc).
tation. It's not quite as pretty as this sketch
hints.
.
.
.
>Lambdas (i.e. anonymous functions) - These are occasionally useful and the
>syntax is very clean.
for one--than they are of lambda. I think they're
funny that way.
.
.
.
>Threading - Python includes native support for threading. I'm not sure what
>the current state of threading is *at the Tcl level* (I know that the core
>has been thread-safe for a while now).
strictly superior to Python's. Let's reserve judg-
ment on this one.
>
>Exceptions - I find the Python exception system a little odd because
>exceptions are really nothing more than strings mostly (I prefer the C++
>idea that an exception should be an object...Python can do this but isn't
>required). However, I once again would state that something is better than
Pyexceptions are more powerful and uniform than
they used to be (pre-2.0, I think). They *are*
objects, now. You might have found old books
which don't make this clear.
.
.
.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
David Gravereaux
>So I thought..."Neat, a special sort of 'make' for Python extensions". I
>told it what files were in my extension (C files, Python files, data files,
>etc) and it took care of building my extension. Very nice! Now,
>"reinventing the [make] wheel" does cause certain problems (it wasn't the
>best at figuring out when things needed to be remade) but it was so simple
>(and standard).
True, the Tcl build system needs some more attention.
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
Jeff Hobbs
> In article <alip9e$k6...@eccws12.dearborn.ford.com>,
> Michael Tiller <mti...@ford.com> wrote:
>>Threading - Python includes native support for threading. I'm not sure what
>>the current state of threading is *at the Tcl level* (I know that the core
>>has been thread-safe for a while now).
>
> Tcl might end up this year having threading which is
> strictly superior to Python's. Let's reserve judg-
> ment on this one.
Correct that to be "already does have", it's just that "common" Tcl builds
don't include it because they have the event loop (something still lacking
painfully from Python). That suffices for most, but you can also build
with threads and the Thread extension to get Tcl-level threading now.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Join us in Sept. for Tcl'2002: http://www.tcl.tk/community/tcl2002/
David N. Welton
> INTRODUCTION
>
> I've used Tcl for quite some time now. I've embedded in a couple of
> simulations tools, I've used it to build graphical user interfaces
> and I've written lots of scripts with it. However, I also try not
> to become too much of a zealot and occasionally look for other
> useful tools to help me out. Recently, I decided to have a serious
> look at Python and there were many interesting things that struck me
> in the comparison.
It's a very well written comparison with some good points - thanks!
> DATA STRUCTURES
I think the base element that's really missing is references.
> So I thought..."Neat, a special sort of 'make' for Python
> extensions". I told it what files were in my extension (C files,
> Python files, data files, etc) and it took care of building my
> extension. Very nice! Now, "reinventing the [make] wheel" does
> cause certain problems (it wasn't the best at figuring out when
> things needed to be remade) but it was so simple (and standard).
For Rivet, we've created a sort of make-like system. 'make' is not
involved with building Rivet, infact. We create our own graph
structure using the graph.tcl package. It might be something to play
with for those who are interested in working with this idea.
--
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/
Wojciech Kocjan
First of all, I read some time ago a nice comparison of Python vs other
languages at python.org. It lacked things that are nicer in Tcl. Maybe
we should put up a Wiki page and write why we prefer Tcl than XXX (ie
Python, Perl, Java).
First of all, I would consider the event system - I can write a program
that does not have to use threads and can handle multiple Tcp
connections, GUI, do some periodic jobs etc. Java, when I last checked,
did not have non-blocking file/socket handling - so you had to assign a
thread to each connection - this causes much trouble when writing a
daemon which would handle maaaany long lasting connections that mostly
just wait.
Also, as some nice people mentioned, Tcl's extension build system is
quite weird and hard to do. Maybe this could indeed be a good idea for
an OS project? I'd rather not reinvent the [make], since it works fine.
Perhaps just a script to create makefiles for Unices, Windows+MinGW and
Windows+vc.
Adding a GUI would also be nice - ie the user could configure flags in a
nice, intuitive way. Something like 'make xconfig' for the Linux kernel,
ponly smaller and suited for Tcl's needs :-)
--
WK (written at Stardate 56693.3)
"Data typing is an illusion. Everything is a sequence of bytes."
-Todd Coram
David N. Welton
> Also, as some nice people mentioned, Tcl's extension build system is
> quite weird and hard to do. Maybe this could indeed be a good idea
> for an OS project? I'd rather not reinvent the [make], since it
> works fine. Perhaps just a script to create makefiles for Unices,
> Windows+MinGW and Windows+vc.
As an additional note, I think that this requires the work being done
for
http://www.tcl.tk/cgi-bin/tct/tip/59.html
http://sourceforge.net/tracker/?group_id=10894&atid=310894&func=detail&aid=507083
to really work well.
Georgios Petasis
news:8765xef...@dedasys.com...
> Wojciech Kocjan <wojc...@n0spam-kocjan.org> writes:
>
> > Also, as some nice people mentioned, Tcl's extension build system is
> > quite weird and hard to do. Maybe this could indeed be a good idea
> > for an OS project? I'd rather not reinvent the [make], since it
> > works fine. Perhaps just a script to create makefiles for Unices,
> > Windows+MinGW and Windows+vc.
>
> As an additional note, I think that this requires the work being done
> for
>
> http://www.tcl.tk/cgi-bin/tct/tip/59.html
>
>
http://sourceforge.net/tracker/?group_id=10894&atid=310894&func=detail&aid=5
07083
>
Actually, I have written a small extension that I use for building simple
extensions that parses the .sh files under unix to find out the needed
info and uses some defaults under windows. Its also on SF
(tBuild). Although at very initial stage, I use it all the time to automate
compilation of extensions that users write in one of my applications...
I have tried only with GCC and Visual C++ 5,6,7 though...
George
Donal K. Fellows
[lots of stuff]
I'll do a quick summary here of the points you raise. Feel free to comment if
you think I've completely missed the target with any of them; my aim is to
coalesce things to make them easier to comment on.
* Python and Tcl are different
* Python's control structures are "simpler" (iterators)
* Python has three main kinds of composite data types (tuples, lists and
dicts) which are all semantically first-class entities. Tcl has two (lists
and arrays) and only lists are first-class.
* The distinction between tuples and lists is confusing.
* Python's packaging system is cool and identified with files.
* Python's object system is no great shakes (especially for C++ refugees) but
at least it is a standard.
* Python has some cool (package) building tools.
* Python's included batteries are nice.
* Python has lambdas.
* Python's indentation scheme is workable.
* Python's got native threads; why isn't Tcl like that by default?
* Python exceptions are cool and useful.
* I like all those points about Python; can we have them in Tcl? Please? :^)
(Would you say that was an accurate-ish summing up?)
I'll respond to these points in a follow-up to this message, so people can
comment on my summing up separately from my response to it.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- I'm curious; where does this statistic come from? Does its home, perchance,
ever see sunlight? -- Jason A Williams <jason+...@compsoc.man.ac.uk>
Donal K. Fellows
> * Python and Tcl are different
Sure they are. For starters, the number of letters in the name is different.
:^D
Whenever you get two groups of smart people tackle very similar problems, you
get answers that, while having recognizable overlap, are nevertheless quite
different. That's life.
> * Python's control structures are "simpler" (iterators)
For people coming from a C/C++/Java heritage, Tcl's [for] command has quite a
nice feel to it (syntax is different, but purpose and capabilities are
comfortingly close.) I tend to use [foreach] a lot though.
> * Python has three main kinds of composite data types (tuples, lists and
> dicts) which are all semantically first-class entities. Tcl has two (lists
> and arrays) and only lists are first-class.
I have some ideas about putting a first-class dictionary value-type into Tcl;
the main downside I can see at the moment is confusion with Tcl arrays (which
are collections of variables, not values, and as such are quite a different sort
of beastie.)
> * The distinction between tuples and lists is confusing.
I quite agree with that. Tuples are conceptually a way of doing structures
without naming the members; IMO their absence from Tcl is a good thing. Better
to either use lists or dictionaries (depending on how you want to look up the
elements.)
> * Python's packaging system is cool and identified with files.
I'm not going to comment on that; I'm one of the great unconverted on this issue
as I tend to just use [source] and [load] directly if I can. ;^)
> * Python's object system is no great shakes (especially for C++ refugees) but
> at least it is a standard.
There are vague plans to add a standard OO system to Tcl, but the last time this
was discussed by the TCT (where everyone was broadly in favour) it was agreed
that doing so in the 8.* release cycle was probably a bad move because it is
such a fundamental change.
> * Python has some cool (package) building tools.
There are some cool ideas floating around here. Maybe now that Macs have a
proper OS underneath, it might be possible to move forward on this matter...
TIP#59 was originally going to include lots of work on this, but it turned out
to have a number of technical aspects that needed more work.
> * Python's included batteries are nice.
That is definitely one of the best points about Python.
> * Python has lambdas.
It's pretty easy to do them in Tcl, you know. The only problem is working out
when you can get rid of the closures created by the lambda command, but that is
a *hard* problem. This matter is deep.
> * Python's indentation scheme is workable.
No comment; I've not written enough python to have anything worthwhile to say.
> * Python's got threads; why isn't Tcl like that by default?
Threads cost you, and many libraries/extensions are not thread safe. And just
to make things more fun, they have more modes of failure too.
> * Python exceptions are cool and useful.
This is one of Tcl's weaker points. We could do with a more unified vision of
error handling in some respects (though the way we tackle some things, like
actual errors in scripts, is not too shabby, given the historic tendency towards
dynamically-generated code.)
> * I like all those points about Python; can we have them in Tcl? Please? :^)
Perhaps you should be surprised about how many of these points are already known
about and the subject of ongoing discussions/plans/thoughts. Often, the reason
they're not being acted on right now is that we were committed to a minor
release, or that there's only 24 hours in a day and we have to use some of those
for non-Tcl things. ;^)
Cameron Laird
Wojciech Kocjan <wojc...@n0spam-kocjan.org> wrote:
.
.
.
>languages at python.org. It lacked things that are nicer in Tcl. Maybe
>we should put up a Wiki page and write why we prefer Tcl than XXX (ie
>Python, Perl, Java).
.
.
<URL: http://wiki.tcl.tk/1324 > and <URL: http://wiki.tcl.tk/1867 >
almost do this.
Michael Tiller
news:3D7DE8A7...@man.ac.uk...
[a quick summary of the points in my original message]
Donal's summary was pretty close but I figured I would tweak a few things
just to be clear:
* Python and Tcl are different in some fundamental ways
* Python's control structures are "simpler" (iterators)
* Python has three main kinds of composite data types (tuples, lists and
dicts) which are all semantically first-class entities. Tcl has two
(lists
and arrays) and only lists are first-class.
* The distinction between tuples and lists is confusing.
* Python's packaging system is simple because it is identified with
files/directories.
* Python's object system is no great shakes (especially for C++ refugees)
but
at least it is a standard.
* Python has some standard (package) building tools.
* Python's included batteries are nice.
* Python has lambdas. (I didn't mean make a bit deal of this, its a minor
point)
* Python's indentation scheme is not as crazy as I first thought.
* Python's got native threads; why isn't Tcl like that by default?
* Python has exceptions, I wish Tcl did
* I like all those points about Python; perhaps Tcl could incorporate some
of these ideas
> (Would you say that was an accurate-ish summing up?)
I would say your original summary was accurate but I just wanted to clarify
my positions on a few things. For example, I didn't say exceptions were
useful in Python (I've never actually used them). I only mentioned that
Python had them and I have sure missed them in Tcl.
--
Mike
Cameron Laird
Donal K. Fellows <donal.k...@man.ac.uk> wrote:
>Michael Tiller wrote:
>[lots of stuff]
>
>I'll do a quick summary here of the points you raise. Feel free to comment if
.
.
> * Python has three main kinds of composite data types (tuples, lists and
> dicts) which are all semantically first-class entities. Tcl has two (lists
> and arrays) and only lists are first-class.
> * The distinction between tuples and lists is confusing.
.
.
I'll pitch in, Donal.
To understand Python, one needs to realize that
Python names also vary along the dimension of
*mutability*. Tuples are immutable lists.
I'm considering picking a fight about whether
Python strings are (also) composite data types.
Here's the point: from a developer's standpoint,
there is special syntax for strings.
In Pythonian terms, the complete list of type
categories is
None
Number
Sequence
Mapping
Callable
Module
Class
Class Instance
File
Internal
Michael Tiller
"Cameron Laird" <cla...@starbase.neosoft.com> wrote in message
news:A9FD1AC408B365B2.C81A983B...@lp.airnews.net...
> In article <alip9e$k6...@eccws12.dearborn.ford.com>,
> Michael Tiller <mti...@ford.com> wrote:
> ...
>
> >Python extension. It took me a little time, but I finally figured out
that
> >Python comes with a standard module called distutils that handles
building
> >extensions.
> ...
>
> >BUT, that was just the tip of the iceberg. The same system can build,
for
> 'Just want to make sure other readers get this.
> Pythoneers don't think of the purpose of distutils
> as to "handle building extensions". In the first
> place, it's something like a super-installer--it's
> for module *consumers*. Like CPAN, this kind of
> standardization led naturally to accessories for
> *producers*.
Fair enough. My comment about it having some quirks for building extensions
was perhaps an unfair criticism if it wasn't designed to do the job of tools
like make. Nevertheless, it can be used to build my extensions *for me* as
well as for others. I still consider this to be a nice feature even if it
is incidental.
> >there also seem to be some well adhered to standards about documentation.
I
> >don't know the details of their system, but the point is that they seem
to
> >be able to generate documentation in much the same way has been
*discussed*
> >in the Tcl community for some time (i.e. a standard format which can then
be
> >used to generate man pages, HTML, PDF, etc).
> There is a fine story to tell about Python documen-
> tation. It's not quite as pretty as this sketch
> hints.
I'm no expert so everything I say about Python should be taken with a grain
of salt. I don't know the story, perhaps you could elaborate?
> >Exceptions - I find the Python exception system a little odd because
> >exceptions are really nothing more than strings mostly (I prefer the C++
> >idea that an exception should be an object...Python can do this but isn't
> >required). However, I once again would state that something is better
than
> This is a bit confusing. Please be aware that
> Pyexceptions are more powerful and uniform than
> they used to be (pre-2.0, I think). They *are*
> objects, now. You might have found old books
> which don't make this clear.
Fair enough. I was reading "Learning Python" by Mark Lutz and I was aware
that it was circa Python 1.5. I tried to "update" myself to 2.2 but I
missed this point about exceptions.
Thanks for the clarifications.
> Cameron Laird <Cam...@Lairds.com>
> Business: http://www.Phaseit.net
> Personal: http://phaseit.net/claird/home.html
--
Mike
John D. Mitchell
[...]
> First of all, I would consider the event system - I can write a program
> that does not have to use threads and can handle multiple Tcp
> connections, GUI, do some periodic jobs etc. Java, when I last checked,
> did not have non-blocking file/socket handling - so you had to assign a
> thread to each connection - this causes much trouble when writing a
> daemon which would handle maaaany long lasting connections that mostly
> just wait.
FYI, Java v1.4 has a new, high-performance I/O package called
"nio" (New/Non-blocking I/O :-). It contains stuff like non-blocking I/O
support, memory-mapped files, etc.
Take care,
John
Cameron Laird
>for
>> 'Just want to make sure other readers get this.
>> Pythoneers don't think of the purpose of distutils
>> as to "handle building extensions". In the first
>> place, it's something like a super-installer--it's
>> for module *consumers*. Like CPAN, this kind of
>> standardization led naturally to accessories for
>> *producers*.
>
>Fair enough. My comment about it having some quirks for building extensions
>was perhaps an unfair criticism if it wasn't designed to do the job of tools
>like make. Nevertheless, it can be used to build my extensions *for me* as
>well as for others. I still consider this to be a nice feature even if it
>is incidental.
.
.
Absolutely. Distutils provides a lot of value. I
sure hope my attempt at clarification doesn't con-
fuse readers in the opposite direction.
Thanks, by the way, for the productive thread you've
launched.
--
Will Duquette
<donal.k...@man.ac.uk> wrote:
>"Donal K. Fellows" summarized what Michael Tiller wrote:
>> * Python's packaging system is cool and identified with files.
>
>I'm not going to comment on that; I'm one of the great unconverted on this issue
>as I tend to just use [source] and [load] directly if I can. ;^)
It's a matter of flexibility. It's nice not to have to worry about
the namespace issues; on the other hand, it's nice to be able to break
a package up into multiple files without multiplying namespaces. I'd
be the first to admit that Tcl's namespace/package system can be
confusing (hence my Guide to Namespaces and Packages) but it works.
>
>> * Python's object system is no great shakes (especially for C++ refugees) but
>> at least it is a standard.
>
>There are vague plans to add a standard OO system to Tcl, but the last time this
>was discussed by the TCT (where everyone was broadly in favour) it was agreed
>that doing so in the 8.* release cycle was probably a bad move because it is
>such a fundamental change.
In the past, the discussions have seemed to go like this:
* We need an 00 system in the core.
* Let's just bless Incr Tcl; lots of people use it.
* But Incr Tcl doesn't do X, Y, Z, and package XYZ does.
And at that point they degenerate into discussions about how to do
objects.
I've recently developed some opinions on that.
As somebody (Donal?) was quoted in this week's Tcl-URL, in Tcl
a command is a command is a command. And in Tcl, an object is
simply a command with subcommands. I think a Tcl-ish OO system
should have these features:
* It should be able to work well with anything that looks like
a Tcl object, regardless of how it was implemented, provided
that the object follows certain rules.
* Object types should be dynamic, i.e., more like Python
than C++. It should be possible to add fields and methods
to an object or type that already exists--if only to make
debugging easier. It's the Tcl way.
* The most prominent set of objects in the Tcl/Tk universe are
the Tk widgets. Any Tcl OO system that won't easily interoperate
with Tk widgets is simply wrong.
* It needs to be possible to create megawidgets using the OO system.
* It needs to support configure/cget for public properties of the
object. This is needed for compatibility with Tk.
Incidentally, the main difference between a normal class and a
megawidget class is that a megawidget class is fundamentally
an "adaptor". In Snit, for example, when you create an instance
of a type Snit creates the new object's command for you. When
you create an instance of a megawidget, you must provide a
widget to Snit in your constructor; Snit then hijacks that widget
command so that it can add its own methods. I'm thinking of
adding "adaptor" as a primary kind of type in Snit, because there
are times when you might want to adapt something other than a
widget.
>> * Python exceptions are cool and useful.
>
>This is one of Tcl's weaker points. We could do with a more unified vision of
>error handling in some respects (though the way we tackle some things, like
>actual errors in scripts, is not too shabby, given the historic tendency towards
>dynamically-generated code.)
Actually, Tcl has excellent exception handling. The "return -code"
command gives you all the flexibility you need to throw real
exceptions, following the Tcl philosophy that everything's
a string. The problem is that there's a bad interface for
catching exceptions. The "catch" command is really too lowlevel;
what's needed is a "try/catch/finally" construct. I've
implemented one, which works very nicely; you can even
handle different exception types in the catch clause. But
there are two problems with it: it's non-standard, so there's no
incentive for package authors to throw meaninful exceptions, and
(being written in pure Tcl) it's really too slow. I wrote an
application that did a fair amount of data munging and used
my try/catch throughout; and after I did some profiling I
replaced it with the standard 'catch' command anywhere
except at the highest levels. Unfortunately it made a
big difference.
But there's no particular reason try/catch/finally couldn't
be coded in C and made a core control structure.
Will Duquette
Chang Li
A deepth observation.
> CONTROL STRUCTURES
>
> One of the things I thought was cleverest about Tcl's design (and I love
> showing this off to people) is how I can create my own control structures
> that look as though they are built in. This is due to Tcl's very clean
> grammar (one rule: command arg arg arg ...) and quoting features ({} vs.
> "").
[...]
Tcl is too flexible in syntax. So you may use it like use the goto statement
in traditional language. A example is {}. Acturally it has many explaination.
When you use {} to include elements there is no evaluation.
case 1:
set a {set x foo}
% set x foo
case 2:
if {1} {set x foo}
% foo
So the meaning of {} is dependent on the definition of the arguments.
And it could be explained as list as well. This confused beginner.
Is it a good displine to avoid use {} in case 1 and list?
>
> DATA STRUCTURES
>
> Tcl has done some amazing things with just lists and associative arrays.
[...]
Tcl is very powerful to create new data structure.
However you need to work on the C level.
>
> PACKAGE STRUCTURE
>
> Now here is where I was very impressed with Python. Having worked with
> tclIndex and pkgIndex.tcl files (and auto_mkindex, etc), I found the Python
[...]
This is a wonderful feature in Python. How could they do it?
I guess there is an auto register and search engine for packages in Python.
Although to copy and write your own pkgIndex.tcl is not difficult,
it is cubesome. Even Java is stupid to depend upon the directory structure.
> OBJECT SYSTEM
>
> Python's object system is OK (i.e. it didn't exactly bowl me over). I think
> the "[incr Tcl]" framework is a much nicer design but that is perhaps
> because I come from a C++ background and so therefore [incr Tcl] is closer
> to what I'm used to.
[...]
Except [Incr Tcl] and XOTcl, I think Tk is an object system.
The problem of Tk is that it can not be expanded on Tcl levle.
>
> EXTENSIONS AND DISTRIBUTION
>
> Another area where I was quite impressed was in the handling of extensions.
> At first, I was quite disoriented because I came at this with a Tcl mindset.
> I had a C++ library that I wanted to call from a Python script. So, I got
> out SWIG and generated the wrapper code. Then came the compile phase. I
> couldn't find any information about how to write a Makefile to build a
> Python extension. It took me a little time, but I finally figured out that
> Python comes with a standard module called distutils that handles building
> extensions.
>
[...]
I doubt that Python is good at the connection to C/C++ in extension.
Tcl is the most nature way to use with C/C++. SWIG may not generate
a good API for using.
[...]
> MISCELLANEOUS
>
> A few other language features that I though were worth mentioning were:
>
> Lambdas (i.e. anonymous functions) - These are occasionally useful and the
> syntax is very clean.
>
Is there a lambda example for real application?
> Exceptions - I find the Python exception system a little odd because
> exceptions are really nothing more than strings mostly (I prefer the C++
> idea that an exception should be an object...Python can do this but isn't
> required). However, I once again would state that something is better than
> nothing. I must admit that in Tcl I have been frustrated by the lack of
> built-in "try" and "catch" functionality. I've tried to create my own
> versions at times, but I always find that clear error reporting/handling is
> difficult to implement.
>
This will be added to Tcl. Tcl may give people the impression that it is not
a reliable language. The simple spelling error can cause runtime error!
There is no type checking.
Chang
Don Porter
>> There are vague plans to add a standard OO system to Tcl, but the last
>> time this was discussed by the TCT (where everyone was broadly in favour)
>> it was agreed that doing so in the 8.* release cycle was probably a bad
>> move because it is such a fundamental change.
> In the past, the discussions have seemed to go like this:
>
> * We need an 00 system in the core.
> * Let's just bless Incr Tcl; lots of people use it.
> * But Incr Tcl doesn't do X, Y, Z, and package XYZ does.
>
> And at that point they degenerate into discussions about how to do
> objects.
No, we're past that at last. TIP 50 was approved. It just lacks anyone
willing/able to do the integration effort.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Cameron Laird
.
[lots of stuff I
can't endorse]
.
.
>Is there a lambda example for real application?
.
.
Tons. Everywhere in Tcl you'd include a script
as an argument, Pythoneers might consider a
lambda.
One of the batteries base Python includes is
Tkinter, a binding of Python to Tk. All Tk
callback thingies are candidates to be lambdas:
b = Button(text="Push me",
command=lambda: sys.stdout.write("Pushed\n"))
Don Porter
> Actually, Tcl has excellent exception handling. The "return -code"
> command gives you all the flexibility you need to throw real
> exceptions, following the Tcl philosophy that everything's
> a string. The problem is that there's a bad interface for
> catching exceptions.
Fixing that is what TIP 90 is about. Once 8.4.0 is released and we
get back into alpha-mode on the HEAD, you'll see activity on this.
Bruce Hartweg
>"Michael Tiller" <mti...@ford.com> wrote in message news:<alip9e$k6...@eccws12.dearborn.ford.com>...
>
>A deepth observation.
>
>
>
>>CONTROL STRUCTURES
>>
>>One of the things I thought was cleverest about Tcl's design (and I love
>>showing this off to people) is how I can create my own control structures
>>that look as though they are built in. This is due to Tcl's very clean
>>grammar (one rule: command arg arg arg ...) and quoting features ({} vs.
>>"").
>>
>>
>[...]
>
>Tcl is too flexible in syntax. So you may use it like use the goto statement
>in traditional language. A example is {}. Acturally it has many explaination.
>When you use {} to include elements there is no evaluation.
>
The syntax is NOT flexible, the language is.
>
>case 1:
>set a {set x foo}
>% set x foo
>
>case 2:
>if {1} {set x foo}
>% foo
>
>So the meaning of {} is dependent on the definition of the arguments.
>And it could be explained as list as well. This confused beginner.
>Is it a good displine to avoid use {} in case 1 and list?
>
>
No, the meaning {} is ALWAYS the same. The Interpreter does NO
substitution. A command
can do anything it wants with it arguments, so some of them might then
evaluate things further.
Your 2 cases above are both a command with 2 arguments - and in both
cases the 2nd argument
is the literal string:
set x foo
The set command handles it's args by assigning the 2nd argument as value
of the variable named
in the first argument.
The If command handles it' args differently - it tests the first arg
and if it evaluates to true then
it executes the 2nd.
Now substitution rules sometime confuse newbies (and not so newbies)
because of the way
commands work with them (or in the case of widgets & bindings WHEN
things happen)
But the syntax is very simple - and as long as you remember that and the
11 rules
( http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm) you are set.
Bruce
Larry Smith
> I think the base element that's really missing is references.
Eh? It has 'em:
set foo "xxx"
upvar 0 foo bar ;# "bar" is a reference to "foo"
puts $bar ;# prints xxx
set bar "yyy"
puts $foo ;# prints yyy
--
.-. .-. .---. .---. .-..-. | Wild Open Source Inc.
| |__ / | \| |-< | |-< > / | "Making the bazaar just a
`----'`-^-'`-'`-'`-'`-' `-' | little more commonplace."
home: www.smith-house.org | work: www.wildopensource.com
Don Porter
> * Python's packaging system is simple because it is identified with
> files/directories.
I'd counter that Python modules are limiting because they're necessarily
tied to files, and to a particular directory structure.
But, you are correct that Tcl has so far failed to supply effective
simple interfaces to its underlying greater power.
And similar to XML vs. HTML, simple beats powerful in attracting
adherents.
The solution for Tcl is to supply simple interfaces built on top of
it's powerful system.
Better support for package authors/installers/users is near the top of
my own to-do list in Tcl development. Look for activity after the
8.4.0 release, and the conference.
Chang Li
> Michael Tiller wrote:
> [lots of stuff]
>
The key point is what we could learn from Python and improve Tcl.
We can learn
* Python's packaging system
* Python's native object system
* Python's batteries
* Python's exception processing
Acturally these are standard features of new generation languages
such as Java and C#. The languages developed from C to C++ to Java.
Tcl is still in the stage of C. For some applications its features
are not enough. For many applications I still think C is the best.
The performance of C code is number one. The combination of Tcl and
C is very powerful. However if we try to design the pure Tcl code
we may feel its limitation as a standalone language. Tcl may fade
away if we only treat it as a wrap (shell) language and refuse to
add new standard language features.
Chang
Don Porter
> Acturally these are standard features of new generation languages
> such as Java and C#. The languages developed from C to C++ to Java.
> Tcl is still in the stage of C. For some applications its features
> are not enough.
You are correct. What you may be missing, and what this thread may
not be emphasizing strongly enough is that the built-in commands of
Tcl are not intended to be a sufficient set for all purposes and all
types of applications. You are supposed to add new commands that serve
you better. You add them by calling on additional packages/extensions
that provide them ( or writing your own if none exist that serve
your needs ).
The underlying problem is not that Tcl is underpowered, but that
too many people fear making use of the additional power available to
them in Tcl packages to accomplish their goals. They confine themselves
to use "only Tcl", and that is indeed too limiting for many things.
There are some legitimate reasons for this (that is, the fears are not
*entirely* irrational), but far fewer than there used to be; and there
should be fewer still as we move forward.
Bryan Oakley
>
> Tcl is too flexible in syntax. So you may use it like use the goto statement
> in traditional language. A example is {}. Acturally it has many explaination.
> When you use {} to include elements there is no evaluation.
>
> case 1:
> set a {set x foo}
> % set x foo
>
> case 2:
> if {1} {set x foo}
> % foo
>
> So the meaning of {} is dependent on the definition of the arguments.
I don't believe that is a correct interpretation. Curly braces *always*
have the same effect, which is to pass their contents literally to the
command. This is immutable, no matter what command is being executed.
It's what makes tcl, tcl.
What changes is how the commands interpret the data they are given.
Learning this single fact generally does more to enlighten new tcl
programmers than any other.
David N. Welton
> "David N. Welton" wrote:
>
> > I think the base element that's really missing is references.
>
> Eh? It has 'em:
>
> set foo "xxx"
> upvar 0 foo bar ;# "bar" is a reference to "foo"
>
> puts $bar ;# prints xxx
> set bar "yyy"
> puts $foo ;# prints yyy
No, it doesn't. Look here for more information:
Jeff Hobbs
>>set foo "xxx"
>>upvar 0 foo bar ;# "bar" is a reference to "foo"
>>
>>puts $bar ;# prints xxx
>>set bar "yyy"
>>puts $foo ;# prints yyy
>
> No, it doesn't. Look here for more information:
>
> http://mini.net/tcl/2933
I certainly hope it *does*, and that appears right:
(tkcon) 49 % set foo xxx
xxx
(tkcon) 50 % upvar 0 foo bar
(tkcon) 51 % puts $bar
xxx
(tkcon) 52 % set bar yyy
yyy
(tkcon) 53 % puts $foo
yyy
Why did you think otherwise on the above reference?
David N. Welton
> In the past, the discussions have seemed to go like this:
>
> * We need an 00 system in the core.
With some people stating that they don't want to see that, although
they would be perfectly happy if the core shipped together with an OO
system.
Roy Terry
Jeff Hobbs wrote:
>
> David N. Welton wrote:
> >>set foo "xxx"
> >>upvar 0 foo bar ;# "bar" is a reference to "foo"
> >>
> >>puts $bar ;# prints xxx
> >>set bar "yyy"
> >>puts $foo ;# prints yyy
> >
> > No, it doesn't. Look here for more information:
> >
> > http://mini.net/tcl/2933
>
> I certainly hope it *does*, and that appears right:
>
> (tkcon) 49 % set foo xxx
> xxx
> (tkcon) 50 % upvar 0 foo bar
> (tkcon) 51 % puts $bar
> xxx
> (tkcon) 52 % set bar yyy
> yyy
> (tkcon) 53 % puts $foo
> yyy
>
> Why did you think otherwise on the above reference?
My (non-theoretical) observation is that upvar works nicely if you're
going
to access at a single calling level (which is about 85% of cases for
me). If
you need to access the "referenced" array at 3 or more calling depths
then
it just becomes cumbersome. Seems to come back to wishing arrays could
be first class objects like lists are.
Roy
David N. Welton
> Actually, I have written a small extension that I use for building
> simple extensions that parses the .sh files under unix to find out
> the needed info and uses some defaults under windows. Its also on SF
> (tBuild). Although at very initial stage, I use it all the time to
> automate compilation of extensions that users write in one of my
> applications... I have tried only with GCC and Visual C++ 5,6,7
> though...
https://sourceforge.net/projects/tbuild/
Nice stuff! We may use this for Rivet. We already do some similar
things, but concentrating it in one well-done file that other people
can collaborate on seems like a good idea.
Better yet, including this in tcllib or, dare I say it, the core would
provide a reasonable interface for people wishing to build stuff
without mucking about trying to get cross-platform configure junk
working.
David Gravereaux
>cross-platform configure junk
hehe... he said `configure junk` hehe.. <in a beavis voice>
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
David N. Welton
> dav...@dedasys.com (David N. Welton) wrote:
>
> >cross-platform configure junk
>
> hehe... he said `configure junk` hehe.. <in a beavis voice>
Tom Tromey has some interesting comments here on build tools. He's
the author of auto*.
http://www.advogato.org/person/tromey/
David N. Welton
Something that would be nice is a way to compile things statically.
We need this for Rivet, if people wish to build something as a
compiled-in part of Apache.
Chang Li
> >
> >case 1:
> >set a {set x foo}
> >% set x foo
> >
> >case 2:
> >if {1} {set x foo}
> >% foo
> >
> >So the meaning of {} is dependent on the definition of the arguments.
Right. Who define the meaning of the arguments?
It backs to the build in C commands. I can implement
a C command that acturally do substitution inside the
{}. The {} inside elements coule be a string, a list,
a group of statements, even a substitutable string.
The multiple face of {} makes Tcl difficult to handle
in some cases.
Is following code a Tcl code?
set x 0
set y 0
property c {orgx $x orgy $y}
%{orgx 0 orgy 0}
The property command is implemented as a C command.
The second argument is a list of pair with name and value.
The value will be substituted or evaluated.
So it is better to explain {} as a group of a set of elements.
Chang
David Gravereaux
>David Gravereaux <davy...@pobox.com> writes:
>
>> dav...@dedasys.com (David N. Welton) wrote:
>>
>> >cross-platform configure junk
>>
>> hehe... he said `configure junk` hehe.. <in a beavis voice>
>
>Tom Tromey has some interesting comments here on build tools. He's
>the author of auto*.
>
>http://www.advogato.org/person/tromey/
Interesting. He's talking about Ant, right?
http://jakarta.apache.org/ant/
There's a make tool in pure Tcl called 'bras'. Which is quite nice from looking
at the docs, but I've never used it. You'd still have a chicken/egg problem
building the core, but would do a good for extensions, assuming a non-classic
mac platform where [exec] is a no-op.
Wojciech Kocjan
Ok. I guess you're right - but it can be easily done:
proc a::x {} {set a(b) c; b::y}
proc b::y {} {c::z}
proc c::z {} {j::a}
proc j::a {} {upvar #1 a a; puts $a(b)}
% a::x
c
So, this code should work - tested with 8.3.4:
proc mkuv {arrayname} {
return [list [expr {[info level]-1}] $arrayname]
}
proc uv {data vn} {
uplevel 1 [list upvar #[lindex $data 0] [lindex $data 1] $vn]
}
proc a::a {} {array set a {b c d e}; b::b [mkuv a]}
proc b::b {d} {c::c $d}
proc c::c {d} {j::j $d}
proc j::j {d} {uv $d vn; parray vn}
% a::a
vn(b) = c
vn(d) = e
Another dirty trick nicely done :-)
This does not change the fact that it wouldn't be necessary if arrays
would be first class objects :-)
--
WK (written at Stardate 56695.4)
"Data typing is an illusion. Everything is a sequence of bytes."
-Todd Coram
Donal K. Fellows
> FYI, Java v1.4 has a new, high-performance I/O package called
> "nio" (New/Non-blocking I/O :-). It contains stuff like non-blocking I/O
> support, memory-mapped files, etc.
Tcl's non-blocking IO is easier to use. :^D (We don't have memory-mapped files
though. Time for someone to suggest a TIP, perhaps extending [binary]?)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- I'm curious; where does this statistic come from? Does its home, perchance,
ever see sunlight? -- Jason A Williams <jason+...@compsoc.man.ac.uk>
Donal K. Fellows
> Michael Tiller <mti...@ford.com> wrote:
>> Lambdas (i.e. anonymous functions) - These are occasionally useful and the
>> syntax is very clean.
>
> Is there a lambda example for real application?
In what language? In languages like Lisp and SML where lambdas have long been
present, they are definitely used in real applications. For example, suppose
you have a list of numbers and you want to apply a simple arithmetic operation
to them, what is the clearest option (using Tcl's syntax here)
# Option 1: with lambdas
set result [map [lambda x {expr {$x*42+327}}] $valueList]
# Option 2: no lambdas, but with map
proc transform x {
expr {$x*42+327}
}
set result [map transform $valueList]
# Option 3: the way you'd currently do it in Tcl
set result {}
foreach x $valueList {
lappend result [expr {$x*42+327}]
}
Which is clearest? (The other advantage of lambdas comes when you start
combining operations together, but that takes longer to build examples. Also
note that when you have such things, you find all sorts of interesting ways to
use them.)
Arjen Markus
>
> "John D. Mitchell" wrote:
> > FYI, Java v1.4 has a new, high-performance I/O package called
> > "nio" (New/Non-blocking I/O :-). It contains stuff like non-blocking I/O
> > support, memory-mapped files, etc.
>
> Tcl's non-blocking IO is easier to use. :^D (We don't have memory-mapped files
> though. Time for someone to suggest a TIP, perhaps extending [binary]?)
>
Would it indeed be necessary to extend [binary]? It seems to me that
with a little imagination, [binary] is already capable of treating a
string as a file.
Perhaps a script example would illustrate how to achieve the effect :-)
Regards,
Arjen
Glenn Jackman
> Is following code a Tcl code?
>
> set x 0
> set y 0
> property c {orgx $x orgy $y}
> %{orgx 0 orgy 0}
Sure:
proc property {name value} {
upvar 1 $name var
set var %{[uplevel 1 [list subst $value]]}
}
--
Glenn Jackman
gle...@ncf.ca
lvi...@yahoo.com
According to Donal K. Fellows <donal.k...@man.ac.uk>:
:> * Python's object system is no great shakes (especially for C++ refugees) but
:> at least it is a standard.
:There are vague plans to add a standard OO system to Tcl, but the last time this
:was discussed by the TCT (where everyone was broadly in favour) it was agreed
:that doing so in the 8.* release cycle was probably a bad move because it is
:such a fundamental change.
I thought the hold up was finding one or more people familar with incr tcl
and who had time enough to refactor it into the needed build structure.
But then, whatever the reason, the approved TIP has sat waiting on a champion
for nearly a year now.
--
Tcl'2002 Sept 16, 2002, Vancouver, BC http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
lvi...@yahoo.com
:
:That is definitely one of the best points about Python.
The same is true for Perl - the general impression is that out of the
box, without any additional modules, one has more functionality.
It has been suggested in the past that it might be useful to sit down
with a list of the Python/Perl/whatever other language functionality,
and the Tcl functionality, and to make up a list of the functionality that is
a) missing and
b) really needed.
I've just not had the time, energy and knowlege to date to do it myself.
Certainly if one is looking for 'merely' more functionality, there is plenty
available in distributions such as ActiveTcl or TclKit/Kitten .
lvi...@yahoo.com
:
:Threads cost you, and many libraries/extensions are not thread safe. And just
:to make things more fun, they have more modes of failure too.
I wonder - in Python, has all the work been done to ensure that all of the
extensions there are thread safe? I mean, one of the things I have heard
in the past with tcl/tk is that Tk-related extensions have a problem related
to threading in that the older underlying X libraries are not thread safe -
seems to me that same thing would be said about Python X related
libraries as well.
Cameron Laird
.
.
.
>The same is true for Perl - the general impression is that out of the
>box, without any additional modules, one has more functionality.
.
.
That's the impression.
Perl relies MUCH more on CPAN (for better and worse).
Perl does NOT include nearly as much additional func-
tionality as Python, although I think this isn't widely
realized yet.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
David N. Welton
> >Tom Tromey has some interesting comments here on build tools. He's
> >the author of auto*.
> >
> >http://www.advogato.org/person/tromey/
>
>
> Interesting. He's talking about Ant, right?
> http://jakarta.apache.org/ant/
Nope, he's talking about a more general solution.
> There's a make tool in pure Tcl called 'bras'. Which is quite nice
> from looking at the docs, but I've never used it. You'd still have
> a chicken/egg problem building the core, but would do a good for
> extensions, assuming a non-classic mac platform where [exec] is a
> no-op.
It would be nice if we could at least confine the crufty stuff to the
core and use Tcl to build Tcl extensions.
Larry Smith
Clever. Weird, but clever.
> This does not change the fact that it wouldn't be necessary if arrays
> would be first class objects :-)
It would be nice if arrays were 1st-class objects,
but it won't change the fact that a reference is a
reference and Tcl _has_ references. They may be
less than perfect, but they are there.
Jeffrey Hobbs
> According to Donal K. Fellows <donal.k...@man.ac.uk>:
> :> * Python's got threads; why isn't Tcl like that by default?
> :
> :Threads cost you, and many libraries/extensions are not thread safe. And just
> :to make things more fun, they have more modes of failure too.
>
> I wonder - in Python, has all the work been done to ensure that all of the
> extensions there are thread safe? I mean, one of the things I have heard
> in the past with tcl/tk is that Tk-related extensions have a problem related
> to threading in that the older underlying X libraries are not thread safe -
> seems to me that same thing would be said about Python X related
> libraries as well.
No, in cases like that you just get huge global locks - not very efficient.
Georgios Petasis
> > from looking at the docs, but I've never used it. You'd still have
> > a chicken/egg problem building the core, but would do a good for
> > extensions, assuming a non-classic mac platform where [exec] is a
> > no-op.
>
> It would be nice if we could at least confine the crufty stuff to the
> core and use Tcl to build Tcl extensions.
Actually, tBuild does not try to achieve the same as make or bras.
Currently it tries to solve the problem: I have these *.c files that
comprise a Tcl extension. With what commands should I compile
them, and not when to execute these commands as in bras.
In tBuild you can say: compile this C/C++ file in order to be
included in a shared library and place the object code in that file.
And then link these object files into the shared library.
tBuild knows what compiler to call, how to invoke it and with what
arguments, it will set the proper tcl include directories, enable stubs
and link with the proper libraries. And it can either execute the commands
or write a makefile/VC project file (not yet completed).
Of course, the main problem is that even in this primitive
state, it does the job I wanted to do, so no updates happen.
As it is not used by others, it isn't enhanced at all :-)
George
Wojciech Kocjan
>>Ok. I guess you're right - but it can be easily done:
> Clever. Weird, but clever.
Hmmm. The problem is you can only send references to higher stack levels :-(
upvar 1 solved over 80% of my problems, this will solve 95%, but there's
still 5% - references & after/bind/event...
I'm wondering about Itcl - it handles local arrays somehow ... Perhaps
better referencing could be done at C level? :-)
>>This does not change the fact that it wouldn't be necessary if arrays
>>would be first class objects :-)
> It would be nice if arrays were 1st-class objects,
> but it won't change the fact that a reference is a
> reference and Tcl _has_ references. They may be
> less than perfect, but they are there.
They are quite hack-friendly, one might say ;-)
--
WK (written at Stardate 56695.8)
Larry Smith
>
> Larry Smith wrote:
> >>Ok. I guess you're right - but it can be easily done:
> >>Another dirty trick nicely done :-)
> > Clever. Weird, but clever.
>
> Hmmm. The problem is you can only send references to higher stack levels :-(
No, upvar 0, as I posted earlier, works just fine on
references within the current stack frame.
Michael Tiller
"Jeffrey Hobbs" <Je...@ActiveState.com> wrote in message
news:3D7F76A3...@ActiveState.com...
> lvi...@yahoo.com wrote:
> > According to Donal K. Fellows <donal.k...@man.ac.uk>:
> > :> * Python's got threads; why isn't Tcl like that by default?
> > :
> > :Threads cost you, and many libraries/extensions are not thread safe.
And just
> > :to make things more fun, they have more modes of failure too.
> >
> > I wonder - in Python, has all the work been done to ensure that all of
the
> > extensions there are thread safe? I mean, one of the things I have
heard
> > in the past with tcl/tk is that Tk-related extensions have a problem
related
> > to threading in that the older underlying X libraries are not thread
safe -
> > seems to me that same thing would be said about Python X related
> > libraries as well.
>
> No, in cases like that you just get huge global locks - not very
efficient.
Hmmm...Does this mean that all the work has been done to ensure that all Tcl
extensions are thread safe? In other words, is Tcl better off somehow than
Python? This isn't a rhetorical question, I really don't know and I'm
curious what the answer is.
--
Mike
Phil Ehrens
>
> Hmmm...Does this mean that all the work has been done to ensure that all Tcl
> extensions are thread safe? In other words, is Tcl better off somehow than
> Python? This isn't a rhetorical question, I really don't know and I'm
> curious what the answer is.
Since it only takes one keystroke to undo all the
thread safe code ever written, how can we even suggest
that there is such a thing? You can build yourself a
prison of mutex locks, and shut yourself up inside it,
and you still wont be thread safe. You just can't ever
know every last thing, every bit of code that's going
to be interacting with your clever little threaded
thingy.
Michael Tiller
"Phil Ehrens" <peh...@nospam.ligo.caltech.edu> wrote in message
news:alof8u$npg$1...@naig.caltech.edu...
So I guess my point is that it wouldn't be fair to say that Python hadn't
done all the work to make extensions safe if it is impossible to do so.
That was my only point.
(Just to be clear, I'm just stating this explicitly since you didn't quote
that section of the thread I was responding to).
--
Mike
David Gravereaux
>Does this mean that all the work has been done to ensure that all Tcl
>extensions are thread safe?
If the extension is "simple", let's not define simple for now, and associates
its internal data to the interpreter by way of the ClientData arg in Tcl
commands created, it is multi-interp safe. As script-level threads in Tcl are
separate interps, too, *voila*, your extension is thread safe, too.
Wasn't that easy?
Global variables in the extension should be addressed and simultaneous entry to
the Tcl_InitProc, too. But as multi-interp safe is almost equal to multi-thread
safe you are whole lot closer.
David N. Welton
> Hmmm...Does this mean that all the work has been done to ensure that
> all Tcl extensions are thread safe? In other words, is Tcl better
> off somehow than Python? This isn't a rhetorical question, I really
> don't know and I'm curious what the answer is.
Worth noting is that the Apache 2.0 server also has this problem, and
by extension, PHP. I assume that Perl has it as well.
David N. Welton
> It would be nice if arrays were 1st-class objects, but it won't
> change the fact that a reference is a reference and Tcl _has_
> references. They may be less than perfect, but they are there.
Are they really? I can't quite put my finger on it, but I don't think
they are, in the same sense of other languages.
I guess the problem is that upvar uses a Var struct, which has to have
a name associated with it (well, it should, if it's not part of a
hashtable, according to the comments). It's not just an Object. Does
that make sense (I'm asking myself too!)?
How would you create a list that contains references to other
variables, without giving names to those other variables?
> (define a (list 1 2))
> (define b (list 3 4))
> (define l1 (list a b))
> l1
((1 2) (3 4))
> (set-car! b 30)
> l1
((1 2) (30 4))
In python:
>>> a = [1, 2]
>>> b = [3, 4]
>>> l1 = [a, b]
>>> l1
[[1, 2], [3, 4]]
>>> b
[3, 4]
>>> b[0] = 5
>>> l1
[[1, 2], [5, 4]]
How do you do that, without knowing a priori whether an element is a
reference to another sublist?
I mean, in Tcl, you could do:
tclsh8.3 [~]set a [list 1 2]
1 2
tclsh8.3 [~]set b [list 3 4]
3 4
tclsh8.3 [~]set l1 [list a b]
but when you go to fiddle with 'l1', you have to know to look up 'a'
and 'b' by their names, right? And you would have to have a name
associated with them, whereas in Python or Scheme or whatever, they
are just lists, with no names attached to them.
The point to this whole thing is not to come up with some clever way
around this. Of course you can find some way to get things done in
Tcl. The point is that this feature is missing from the language.
Chang Li
It is impossible or difficult to let some extensions thread-safe.
For example, to make Expect thread-safe is impossible and unnecessary.
To make pure Tcl code thread-safe is reasonable. Is it reasonable
to make a GUI program thread-safe?
Chang
David N. Welton
> > > There's a make tool in pure Tcl called 'bras'. Which is quite
> > > nice from looking at the docs, but I've never used it. You'd
> > > still have a chicken/egg problem building the core, but would do
> > > a good for extensions, assuming a non-classic mac platform where
> > > [exec] is a no-op.
> > It would be nice if we could at least confine the crufty stuff to
> > the core and use Tcl to build Tcl extensions.
> Actually, tBuild does not try to achieve the same as make or bras.
> Currently it tries to solve the problem: I have these *.c files that
> comprise a Tcl extension. With what commands should I compile them,
> and not when to execute these commands as in bras.
Sure, but adding something like 'aardvark' (my build system for Rivet)
or bras with your extension would be easy. What you have written is
very modular, so it should be easy to use.
Slaven Rezic
> "Michael Tiller" <mti...@ford.com> wrote in message news:<alogpt$n7...@eccws12.dearborn.ford.com>...
>
> It is impossible or difficult to let some extensions thread-safe.
> For example, to make Expect thread-safe is impossible and unnecessary.
> To make pure Tcl code thread-safe is reasonable. Is it reasonable
> to make a GUI program thread-safe?
Yes, for things like progress bars.
Regards,
Slaven
> Chang
>
> > So I guess my point is that it wouldn't be fair to say that Python hadn't
> > done all the work to make extensions safe if it is impossible to do so.
> > That was my only point.
> >
> > (Just to be clear, I'm just stating this explicitly since you didn't quote
> > that section of the thread I was responding to).
--
Slaven Rezic - slaven...@berlin.de
Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net
Donal K. Fellows
> Would it indeed be necessary to extend [binary]? It seems to me that
> with a little imagination, [binary] is already capable of treating a
> string as a file.
Yes, but... Memory mapping is not quite the same thing as loading a binary file
into memory normally, especially in terms of the amount of physical and virtual
memory the OS has to allocate to the process. This makes a difference with very
large files. (They'd be best hanging off [binary], because there's no sensible
way to apply some other encoding to them. And the command has plenty of room
for expansion.)
Donal K. Fellows
> I wonder - in Python, has all the work been done to ensure that all of the
> extensions there are thread safe? I mean, one of the things I have heard
> in the past with tcl/tk is that Tk-related extensions have a problem related
> to threading in that the older underlying X libraries are not thread safe -
> seems to me that same thing would be said about Python X related
> libraries as well.
Depends. If they talk raw X to the server - not going by Xlib - then they can
be as thread-safe as they want to be. If they force all GUI stuff to
synchronize with a single thread (and they might well have done this) then they
can easily be thread-safe in relation to X.
Mind you, I'm not actually sure if they're using real threads or if they are in
some sense "cheating" and doing the multi-threading in their VM as opposed to
using Posix threads (a bit like Java used to do in its early releases.) That
would avoid lots of complex and expensive locks, but at the cost of leaving them
wide open to certain syscalls/libs blocking (one of the main reasons people a
interested in threads.)
Donal K. Fellows
> I thought the hold up was finding one or more people familar with incr tcl
> and who had time enough to refactor it into the needed build structure.
That's not quite the same thing. TIP#50 is about making Itcl have the same sort
of relation to Tcl as Tk does, and not actually modifying Tcl so that it has a
built-in, no extra packages at all, OO system.
> But then, whatever the reason, the approved TIP has sat waiting on a champion
> for nearly a year now.
Yeah. I'm not happy at all about it. But my response is likely to be regarded
as a mixture of gleeful toe-trampling and dino-killing asteroid dropping. :^/
Larry Smith
>
> Larry Smith <la...@wildopensource.com> writes:
>
> > It would be nice if arrays were 1st-class objects, but it won't
> > change the fact that a reference is a reference and Tcl _has_
> > references. They may be less than perfect, but they are there.
>
> Are they really? I can't quite put my finger on it, but I don't think
> they are, in the same sense of other languages.
>
> I guess the problem is that upvar uses a Var struct, which has to have
> a name associated with it (well, it should, if it's not part of a
> hashtable, according to the comments). It's not just an Object. Does
> that make sense (I'm asking myself too!)?
No, it's not an anonymous object. One cannot "new"
an object and refer to it solely via its reference.
> How would you create a list that contains references to other
> variables, without giving names to those other variables?
At the end of the day, you can't. But that does not
mean you don't have references, it merely means that
any new object you create has a name - perhaps an
automatically-generated one - by which it can be
accessed directly as well as by reference. You don't
need to keep track of this name, you know.
I think the real question hinges on your comfort
level with language, not whether or not a particular
feature is present. Tcl has a particular "philosophy"
to it just as Python, Lisp, C and all the rest do.
There are "Tcl-ish" ways to address the world. Often
Tcl can emulate other languages - far more than they
can emulate Tcl, I might add - but the bottom line is,
sometimes you need to do it the Tcl-ish way. By name.
Don Porter
>> The point to this whole thing is not to come up with some clever way
>> around this. Of course you can find some way to get things done in
>> Tcl. The point is that this feature is missing from the language.
> Tcl has a particular "philosophy"
> to it just as Python, Lisp, C and all the rest do.
> There are "Tcl-ish" ways to address the world. Often
> Tcl can emulate other languages - far more than they
> can emulate Tcl, I might add - but the bottom line is,
> sometimes you need to do it the Tcl-ish way.
Seems to me these are just two different ways of expressing the same
thing.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
David N. Welton
> "David N. Welton" wrote:
> >> The point to this whole thing is not to come up with some clever
> >> way around this. Of course you can find some way to get things
> >> done in Tcl. The point is that this feature is missing from the
> >> language.
>
> Larry Smith wrote:
> > Tcl has a particular "philosophy" to it just as Python, Lisp, C
> > and all the rest do. There are "Tcl-ish" ways to address the
> > world. Often Tcl can emulate other languages - far more than they
> > can emulate Tcl, I might add - but the bottom line is, sometimes
> > you need to do it the Tcl-ish way.
I know, and generally it's been good to us. I think it could also be
extended to do certain things without breaking too much with this
philosophy.
> Seems to me these are just two different ways of expressing the same
> thing.
More or less, although part of my point is that certain things might
be easier were we to extend Tcl's functionality. I am not a fan of
'clever' programming to work around missing features, if at all
possible. I like my code to be as straightforward as possible, even
for someone who doesn't know the language and all its nooks and
crannies well.
Jeffrey Hobbs
> "Michael Tiller" <mti...@ford.com> wrote in message news:<alogpt$n7...@eccws12.dearborn.ford.com>...
>
> It is impossible or difficult to let some extensions thread-safe.
> For example, to make Expect thread-safe is impossible and unnecessary.
Expect is one of that very difficult extensions because it touches on so many
intrinsic system calls (dealing with ttys and such). You can make anything
thread-safe with a global lock. However, you can also do things like only
work with expect in one thread and also not worry about it. Or you can do the
locking at the Tcl level, to get around extensions that haven't been made
thread-safe in C. Very flexible.
Jeffrey Hobbs
> "Jeffrey Hobbs" <Je...@ActiveState.com> wrote in message
> news:3D7F76A3...@ActiveState.com...
>
>>lvi...@yahoo.com wrote:
>>
>>>According to Donal K. Fellows <donal.k...@man.ac.uk>:
>>>:> * Python's got threads; why isn't Tcl like that by default?
>>>:
>>>:Threads cost you, and many libraries/extensions are not thread safe.
>>>seems to me that same thing would be said about Python X related
>>>libraries as well.
>>
>>No, in cases like that you just get huge global locks - not very efficient.
>
> Hmmm...Does this mean that all the work has been done to ensure that all Tcl
> extensions are thread safe? In other words, is Tcl better off somehow than
> Python? This isn't a rhetorical question, I really don't know and I'm
> curious what the answer is.
Not C extensions, those you have to make thread-safe, but the method is
well-known and ranges from simple global locks to very fine-grained locking
(if any locking is necessary). However, all code written in pure Tcl is
thread-safe. You can't say the same for python.
Don Porter
>> Seems to me these are just two different ways of expressing the same
>> thing.
> More or less, although part of my point is that certain things might
> be easier were we to extend Tcl's functionality.
Yes, I meant to be agreeing with you. Paraphrasing, you've said,
"Tcl lacks references, and that makes certain styles of programming
difficult in Tcl." Others have countered either 1) "Here are ways
you can half-way fake it, to work around the lack"; or 2) "Ahhh,
you don't need those programming styles anyway. Use other styles."
Ultimately your point remains correct. Doing something about it is
non-trivial, for reasons I think you know.
Chang Li
> Chang Li wrote:
> > So the meaning of {} is dependent on the definition of the arguments.
>
> I don't believe that is a correct interpretation. Curly braces *always*
> have the same effect, which is to pass their contents literally to the
> command. This is immutable, no matter what command is being executed.
> It's what makes tcl, tcl.
This is right, but
"No substitutions are performed on the characters between the braces
except for backslash-newline substitutions described below, nor do
semi-colons, newlines, close brackets, or white space receive any
special interpretation."
Is this still right or exact in the Tcl's syntax definition?
Consider following example:
> set x 0
> set y 0
> property c {orgx $x orgy $y}
> %{orgx 0 orgy 0}
Sure:
proc property {name value} {
upvar 1 $name var
set var %{[uplevel 1 [list subst $value]]}
}
Chang
>
> What changes is how the commands interpret the data they are given.
> Learning this single fact generally does more to enlighten new tcl
> programmers than any other.
Chang Li
> CHA...@neatware.com (Chang Li) writes:
>
> > To make pure Tcl code thread-safe is reasonable. Is it reasonable
> > to make a GUI program thread-safe?
>
> Yes, for things like progress bars.
>
Event message is better solution for progress bars.
No thread needed. It is better to use thread for
backend work. Event is better for frontend work.
In the case that uses thread for GUI we can
do it with a new process. This is a good architecture
for application. My conclusion is that there is no
reason to require all the applications (extensions)
to be thread-safe. So someone may ask Tk for thread-
safe, my question is for what?
Chang
Phil Ehrens
> You can make anything thread-safe with a global lock.
You can also make the most efficient code in the world
grind to a halt that way.
I have pointed strace at a process and watched, awe-struck,
as 20 minutes rolled by with nothing happening but lock
management! Tick-tock goes the context switch...
Mutex locks are the little turds pooped out by the rodent
called threads.
marsd
> Chang Li wrote:
> > Michael Tiller <mti...@ford.com> wrote:
> >> Lambdas (i.e. anonymous functions) - These are occasionally useful and the
> >> syntax is very clean.
> >
> > Is there a lambda example for real application?
>
> In what language? In languages like Lisp and SML where lambdas have long been
> present, they are definitely used in real applications. For example, suppose
> you have a list of numbers and you want to apply a simple arithmetic operation
> to them, what is the clearest option (using Tcl's syntax here)
>
> # Option 1: with lambdas
> set result [map [lambda x {expr {$x*42+327}}] $valueList]
>
> # Option 2: no lambdas, but with map
> proc transform x {
> expr {$x*42+327}
> }
> set result [map transform $valueList]
>
> # Option 3: the way you'd currently do it in Tcl
> set result {}
> foreach x $valueList {
> lappend result [expr {$x*42+327}]
> }
>
> Which is clearest? (The other advantage of lambdas comes when you start
> combining operations together, but that takes longer to build examples. Also
> note that when you have such things, you find all sorts of interesting ways to
> use them.)
>
> Donal.
The last is clearest to intermediate-advanced users coming from
a shell/C background. But due to this thread and the one re: python -vs-
java, I have found that I like python quite a bit.
I think for a large project it has some benefits.
OTOH, tcl is so flexible that you feel constrained in other languages.
Joe English
>Larry Smith writes:
>
>> It would be nice if arrays were 1st-class objects, but it won't
>> change the fact that a reference is a reference and Tcl _has_
>> references. They may be less than perfect, but they are there.
>
>Are they really? I can't quite put my finger on it, but I don't think
>they are, in the same sense of other languages.
I think the difference is that Tcl doesn't have
_anonymous_ references: every mutable object is
accessed by a name or by a handle (the same thing,
really -- a string that identifies the object either
globally or in some context).
The lack of anonymous references to mutable objects is
IMO a feature, not a bug.
--Joe English
David N. Welton
> >> It would be nice if arrays were 1st-class objects, but it won't
> >> change the fact that a reference is a reference and Tcl _has_
> >> references. They may be less than perfect, but they are there.
> >Are they really? I can't quite put my finger on it, but I don't
> >think they are, in the same sense of other languages.
> I think the difference is that Tcl doesn't have _anonymous_
> references: every mutable object is accessed by a name or by a
> handle (the same thing, really -- a string that identifies the
> object either globally or in some context).
Sounds correct.
> The lack of anonymous references to mutable objects is IMO a
> feature, not a bug.
I'll bite - why? It prevents the programmer from expressing some
things cleanly in Tcl.
lvi...@yahoo.com
According to Michael Tiller <mti...@ford.com>:
:So I guess my point is that it wouldn't be fair to say that Python hadn't
:done all the work to make extensions safe if it is impossible to do so.
I agree - but the other side of the coin is that it isn't fair to say
Python has threads and a great toolbox of tools, without mentioning
that not all extensions were thread-safe. And '''that''' is the thought
in my mind when this subthread began.
--
Tcl'2002 Sept 16, 2002, Vancouver, BC http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Glenn Jackman
> tcl is so flexible that you feel constrained in other languages.
--
Glenn Jackman
gle...@ncf.ca
Glenn Jackman
> Bryan Oakley <br...@bitmover.com> wrote in message news:<mZxf9.2395$ed6...@news2.central.cox.net>...
> > have the same effect, which is to pass their contents literally to the
> > command. This is immutable, no matter what command is being executed.
> > It's what makes tcl, tcl.
>
> This is right, but
>
> "No substitutions are performed on the characters between the braces
> except for backslash-newline substitutions described below, nor do
> semi-colons, newlines, close brackets, or white space receive any
> special interpretation."
>
> Is this still right or exact in the Tcl's syntax definition?
You missed a very important factor here in rule 5 of Tcl man page:
If the *first character of a word* is an open brace ... No
substitutions are performed on the characters between the braces ...
(emphasis mine)
However, rule 6 states
If a word *contains* an open bracket then Tcl performs command
substitution.
which means the bracketed word get substituted in
set var %{[info patchlevel]}
because the { char is not the first character of the word.
> Consider following example:
>
> > set x 0
> > set y 0
> > property c {orgx $x orgy $y}
> > %{orgx 0 orgy 0}
>
> proc property {name value} {
> upvar 1 $name var
> set var %{[uplevel 1 [list subst $value]]}
> }
--
Glenn Jackman
gle...@ncf.ca
Kristoffer Lawson
>
> I have some ideas about putting a first-class dictionary value-type into Tcl;
> the main downside I can see at the moment is confusion with Tcl arrays (which
> are collections of variables, not values, and as such are quite a different sort
> of beastie.)
But is there any real benefits to the way arrays work? I sort of like the
syntax (compared to a purely command-based dictionary), and if we could just
pass them as values it would pretty much solve all array problems we have.
Kristoffer Lawson
>>
>>There are vague plans to add a standard OO system to Tcl, but the last time this
>>was discussed by the TCT (where everyone was broadly in favour) it was agreed
>>that doing so in the 8.* release cycle was probably a bad move because it is
>>such a fundamental change.
>
> In the past, the discussions have seemed to go like this:
>
> * We need an 00 system in the core.
> * Let's just bless Incr Tcl; lots of people use it.
> * But Incr Tcl doesn't do X, Y, Z, and package XYZ does.
I thought we all already agreed that ITcl could be included in the standard
distribution, as long as it's not part of the core interpreter itself?
I think that's a fair compromise, and maybe other object systems could be
added at a later point.
Kristoffer Lawson
>
> Perl relies MUCH more on CPAN (for better and worse).
> Perl does NOT include nearly as much additional func-
> tionality as Python, although I think this isn't widely
> realized yet.
And in fact Perl -- the interpreter -- includes less than Tcl too.
But the basic distribution OTOH does include more than Tcl.
Kristoffer Lawson
>
> The underlying problem is not that Tcl is underpowered, but that
> too many people fear making use of the additional power available to
> them in Tcl packages to accomplish their goals. They confine themselves
> to use "only Tcl", and that is indeed too limiting for many things.
I think an important point is that Perl does not seem to suffer from this
same problem (even though the core is even less capable than Tcl's). People
quite readily load extra packages. We need to understand why this happens
with Perl, but not Tcl (probably mostly because the Perl distribution
includes so many libraries).
Joe English
>
>Not C extensions, those you have to make thread-safe, but the method is
>well-known and ranges from simple global locks to very fine-grained locking
>(if any locking is necessary).
And David Graveraux' advice is worth repeating: making extensions
multi-interp safe goes a long way towards making them thread-safe.
I find it easiest to make extensions multi-interp safe and
thread-oblivious: if you avoid global and static variables,
keeping all the extension's internal data in a per-interp
data structure, you can often avoid locking altogether.
--Joe English
Cameron Laird
.
.
I agree that the time is ripe for sociologic enquiry.
I don't feel up to it myself.
One small item--no, *specialized*; it's quite big in
some organizations. There are organizations, perhaps
quite a few, that have FINALLY authorized Tcl for use
in the sense that they've ratified Tcl as not illegal.
It's incredibly difficult, though, to get even tcllib
into such places. There's no collective understanding
of how they can depend on something that they didn't
buy.
This is a serious, serious issue for some people. It's
far easier for them to write their own combobox from
scratch (hold up your hands, all of you who know how
many subtleties that involves), than to get permission
to use what Bryan gives away.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Donal K. Fellows
> The lack of anonymous references to mutable objects is
> IMO a feature, not a bug.
Except for the need to specifically deallocate them (and that slays a lot of
potential uses), I'd agree.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ donal....@man.ac.uk
-- Short attention span since- ooh! Shiny thing on the floor!
-- Chad R. Orzel <orz...@earthlink.net>
Roy Terry
> I have some ideas about putting a first-class dictionary value-type into Tcl;
> the main downside I can see at the moment is confusion with Tcl arrays (which
> are collections of variables, not values, and as such are quite a different sort
> of beastie.)
Would that involve or leverage Fredric Bonnet's work?
http://mini.net/tcl/2176
Slaven Rezic
Maybe because there's CPAN, CPAN.pm and a standard procedure to
install extensions: perl Makefile.PL && make all test install
Regards,
Slaven
--
Slaven Rezic - slaven...@berlin.de
Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net
Larry Smith
This really hits the nail on the head. _It_all_comes_with_
Perl. To management, that makes them all one "thing". With
Tcl you have to get this from here, that from there, some-
thing else from somewhere else...that's scarey. They want
it all in one big "thang". I notice ActiveTcl is getting a
lot of corporate attention now.
Chang Li
> You missed a very important factor here in rule 5 of Tcl man page:
>
> If the *first character of a word* is an open brace ... No
> substitutions are performed on the characters between the braces ...
> (emphasis mine)
>
> However, rule 6 states
> If a word *contains* an open bracket then Tcl performs command
> substitution.
>
> which means the bracketed word get substituted in
> set var %{[info patchlevel]}
Is it $ ??
So ${orgx $x orgy $y} = "orgx $x orgy $y"
that is funny.
Chang
Phil Ehrens
> xx...@freenet.carleton.ca (Glenn Jackman) wrote in message news:<slrnao3qc3...@freenet9.carleton.ca>...
>> You missed a very important factor here in rule 5 of Tcl man page:
>>
>> If the *first character of a word* is an open brace ... No
>> substitutions are performed on the characters between the braces ...
>> (emphasis mine)
>>
>> However, rule 6 states
>> If a word *contains* an open bracket then Tcl performs command
>> substitution.
>>
>> which means the bracketed word get substituted in
>> set var %{[info patchlevel]}
> ^
> Is it $ ??
>
> So ${orgx $x orgy $y} = "orgx $x orgy $y"
>
> that is funny.
no, of course:
${orgx $x orgy $y} = set {orgx $x orgy $y}
but what about:
${or[gx${xorgy}${y}}
I think I fee an obfuscated tcl contest coming on again...
Joe English
>Joe English writes:
>>
>> The lack of anonymous references to mutable objects is IMO a
>> feature, not a bug.
>
>I'll bite - why?
I think it's a natural consequence of "everything is a string",
which is what makes Tcl what it is.
Anonymous mutable objects are fine and dandy -- in Perl, Python,
and Pascal. But they just don't fit in well with Tcl.
>It prevents the programmer from expressing some
>things cleanly in Tcl.
Hm. I guess I've never felt a need for them when writing Tcl.
--Joe English
lvi...@yahoo.com
According to Don Porter <d...@email.nist.gov>:
: Paraphrasing, you've said,
:"Tcl lacks references, and that makes certain styles of programming
:difficult in Tcl." Others have countered either 1) "Here are ways
:you can half-way fake it, to work around the lack"; or 2) "Ahhh,
:you don't need those programming styles anyway. Use other styles."
I thought the discussion had indicated that tcl has named references, but
not anonymous references. I don't think that Tcl has anonymous anythings.
In the past, people have asked about the equivalent of anonymous procs
(aka lamdas). Now David is asking about anonymous lists (and perhaps
arrays).
lvi...@yahoo.com
According to Kristoffer Lawson <se...@gfanrend.fishpool.fi>:
:Cameron Laird <cla...@starbase.neosoft.com> wrote:
:>
:> Perl does NOT include nearly as much additional func-
:> tionality as Python,
:
:And in fact Perl -- the interpreter -- includes less than Tcl too.
:But the basic distribution OTOH does include more than Tcl.
I hope no one takes offense, but without an objective chart, all we have
are individual claims about general comparisons about how much functionality
each of the languages have.
Are we talking about individual 'major' commands, major/minor combos,
or what? How do we quantify amounts of functionality?
lvi...@yahoo.com
According to Cameron Laird <cla...@starbase.neosoft.com>:
: There's no collective understanding
:of how they can depend on something that they didn't
:buy.
:
:This is a serious, serious issue for some people. It's
:far easier for them to write their own combobox from
:scratch (hold up your hands, all of you who know how
:many subtleties that involves), than to get permission
:to use what Bryan gives away.
I know at least one company which requires a legal evaluation of a
software item's End User Licensing Agreement before permitting the software
to be used either on the desktop or in development. If the software has
no explicit licensing agreement, then it cannot be used. If it has a
software licensing that is identical (or as nearly so as some licenses
permit given possible requirement for mentioning the software package itself
in a license), then the amount of review is minimal. If the licensing is
unique - even though the terms are such that the package is 'free to use' -
the software must be evaluated by that company's lawyers first.
Glenn Jackman
> xx...@freenet.carleton.ca (Glenn Jackman) wrote in message news:<slrnao3qc3...@freenet9.carleton.ca>...
> ^
> Is it $ ??
No, it's '%'.
You originally asked for:
> > > > set x 0
> > > > set y 0
> > > > property c {orgx $x orgy $y}
> > > > %{orgx 0 orgy 0}
I assumed that the last line was your desired output from [property].
> > > proc property {name value} {
> > > upvar 1 $name var
> > > set var %{[uplevel 1 [list subst $value]]}
> > > }
The first character of var will be '%'
--
Glenn Jackman
gle...@ncf.ca
Chang Li
Sorry, I made little bit confusion. But your misinterprting
is fruitful. I wrote % as the prompt as usual.
Chang
Kristoffer Lawson
> :
> :And in fact Perl -- the interpreter -- includes less than Tcl too.
> :But the basic distribution OTOH does include more than Tcl.
>
> or what? How do we quantify amounts of functionality?
I was referring to what you probably call major commands. Ie. the base
Perl interpreter doesn't have any network stuff or a lot of the things
you get with the base Tcl interpreter. They all come as separate packages.
OTOH the distribution packages provide more than what you get with Tcl.
tcllib is helping us on the way, but we don't have as much as the Perlers.
Cameron Laird
? Now I'm confused. What "base Perl interpreter" doesn't
include accept() and related "network stuff"?
I might agree with your general conclusion, but we don't
seem to see the same details.