Plans for 8.0 releases

Grant Reaber

unread,

Jan 27, 1997, 3:00:00 AM1/27/97

to

In article <5ce3ot$4...@non.non.net>,
John Ousterhout <ous...@tcl.Eng.Sun.COM> wrote:
>
> We probably won't be able to add any other significant new features
> in this release, and some of the above items may get dropped if we
> run out of time.

Well I'd like to see some clarification of the new object interface. For
instance what is the proper way to do callbacks now? Are we supposed to
be invoking objCmd's all the time (this isn't very well documented)? If
so, is there hope of some kind of varargs interface instead of objc-objv?

Why don't you export objResult into Tcl_Interp? This is obviously more
convenient than Tcl_SetResultObj, as shown by the fact that the Tcl core
commands all refer to objResult directly.

Do you recommend trying to port widgets to the new object system or is
this not worth trying until Tk itself is ported?

By the way, the second alpha release looks great.

Grant

Gerald W. Lester

unread,

Jan 27, 1997, 3:00:00 AM1/27/97

to

John Ousterhout <ous...@tcl.Eng.Sun.COM> wrote in article
<5ce3ot$4...@non.non.net>...
> This article outlines our plans for the rest of the Tcl/Tk 8.0 release
> cycle. All of this is subject to change, of course, but here's how
> things look now.
>...
> 2. However, there are still several new features that we hope to get in
> before the 8.0 releases go final (the alpha designation on the current
> releases indicates that they aren't yet feature-complete). Here's the
> list of new things we hope to include in the final 8.0 releases:
>...
> - Registry support under Windows.

John,

Instead of including this in the core, I would rather see it as a
supported dynamically loaded extension. In other words, the way it is
distributed with SpecTcl 1.0.

John Ousterhout

unread,

Jan 27, 1997, 3:00:00 AM1/27/97

to

In article <5ch08k$s...@anubis.reed.edu>, gre...@reed.edu (Grant Reaber) writes:
|>
|> Why don't you export objResult into Tcl_Interp? This is obviously more
|> convenient than Tcl_SetResultObj, as shown by the fact that the Tcl core
|> commands all refer to objResult directly.

I don't think that the procedural interfaces are much less convenient, and
it's very nice not to have code outside the core mucking with fields in the
interpreter structure; it gives us much more leeway to make changes later.

|> Do you recommend trying to port widgets to the new object system or is
|> this not worth trying until Tk itself is ported?

It's probably simpler to wait. For example, there is going to be a whole
new set of C APIs for managing configuration options, which will take
advantage of the new Tcl_Obj's to do lookups of things like colors. I
think this will make a big difference in performance.

Mike Ponicki

unread,

Jan 28, 1997, 3:00:00 AM1/28/97

to ous...@tcl.eng.sun.com

|Subject: Plans for 8.0 releases
|From: John Ousterhout <ous...@tcl.Eng.Sun.COM>
|Date: 1997/01/25

|This article outlines our plans for the rest of the Tcl/Tk 8.0 release

...
|
|2. However, there are still several new features that we hope to get in

...
|
| - Namespaces (currently under negotiation with Michael
McLennan).

The above excerpt was posted in this newsgroup a few days ago. I need
more info on what the namespace solution is since I am currently working
on a solution of my own. If standard Tcl solves this problem, then I
won't work so hard on my solution and wait for the standard fix. But I
need more information now.

From what I can tell it looks like the goal is to get IncrTcl to be part
of "standard" Tcl. Should I look there for my answers?

Thanks,

Robin Becker

unread,

Jan 28, 1997, 3:00:00 AM1/28/97

to

In article <01bc0c69$8357ccc0$5836...@excalibur.cpu.com>, "Gerald W.
Lester" <gwle...@cpu.com> writes

>John Ousterhout <ous...@tcl.Eng.Sun.COM> wrote in article
><5ce3ot$4...@non.non.net>...

>> This article outlines our plans for the rest of the Tcl/Tk 8.0 release

>> cycle. All of this is subject to change, of course, but here's how
>> things look now.

>>...
>> 2. However, there are still several new features that we hope to get in

>> before the 8.0 releases go final (the alpha designation on the current
>> releases indicates that they aren't yet feature-complete). Here's the
>> list of new things we hope to include in the final 8.0 releases:
>>...
>> - Registry support under Windows.
>
>John,
>
> Instead of including this in the core, I would rather see it as a
>supported dynamically loaded extension. In other words, the way it is
>distributed with SpecTcl 1.0.
>
>

Far better than bunging it into the core; and then what about OLE2 OCX
etc etc which are core for Gate's Empire (phrase from the code), but not
for Tcl/Tk.
--
Robin Becker

Michael D. McCool

unread,

Jan 31, 1997, 3:00:00 AM1/31/97

to

I think the plans for 8.0 are great, but I have a problem with the
way white space is discarded. Basically, Tcl is great for hacking interface
languages, and white-space is sometimes used as a syntactic element.

For instance, I'm working on a functional sublanguage, using Tcl as
an interface shell. I'd like to put my sublanguage in a {} script and
use indenting and linebreaks to disambiguate some situations. This is
particularly handy for functional languages when you often have deeply
nested expressions and don't want to bother with nested paranthesises,
termination markers etc, in the spirit of Tcl. For instance:

func grid num num num num node -> node* {
N M DX DY C ->
func col num node -> node* {
0 _ -> nil
N C -> cons # autocontinuation
node {
C
}.translate 0 DY*N 0 # another autocontinuation
.rotate 45 0 1 0
col N-1 C
}
func row int node -> node* {
0 _ -> nil
N C -> cons
node {
C
}.translate DX*N 0 0
.rotate 32 1 0 0
row N-1 C
}
node (col N (row M C))
}

Unfortunately, if the list parser throws away white space information,
I can't do this. How about if you count the number of spaces before
a word and put it somewhere where syntatic deviants like me can find it?

This wouldn't impact the API much (i.e. it could be done in a way that
makes it backward compatible with the current API), and the count could be
very short. It would also be nice to be able to declare the
number of spaces a tab counts as (while giving a reasonable default),
and mark the positions of newlines.

Another alternative/extension to this would be to modify the list
parser so indentation would signal automatic continuation of commands
EVERYWHERE. This would eliminate all those annoying backslashes. Of course,
it would also break some scripts, but a backward-compatibility switch with the
old behaviour as the default would take care of that.

I have another question: is {B} (a list of one element) a single word
under the new interface, or a list of one element? If I use Tcl lists
as lists in my functional sublanguage, the list-of-one-element
interpretation makes life worth living again :-) In other words, it would
help if the parser preserved this bit of syntatic information in the script,
so rather than using cons and nil I could use Tcl lists and not
have weird things happen.

Michael McCool
--
http://www.cgl.uwaterloo.ca/~mmccool/ mailto:mmc...@cgl.uwaterloo.ca

Heribert Dahms

unread,

Feb 1, 1997, 3:00:00 AM2/1/97

to

In <E4vvD...@undergrad.math.uwaterloo.ca> mmc...@cgl.uwaterloo.ca
(Michael McCool) writes:

: I think the plans for 8.0 are great, but I have a problem with the

: way white space is discarded. Basically, Tcl is great for hacking interface
: languages, and white-space is sometimes used as a syntactic element.
:
: For instance, I'm working on a functional sublanguage, using Tcl as
: an interface shell. I'd like to put my sublanguage in a {} script and
: use indenting and linebreaks to disambiguate some situations. This is
: particularly handy for functional languages when you often have deeply
: nested expressions and don't want to bother with nested paranthesises,
: termination markers etc, in the spirit of Tcl. For instance:
:
: func grid num num num num node -> node* {
: N M DX DY C ->
: func col num node -> node* {

[snipped]
: }
: node (col N (row M C))

: }
:
: Unfortunately, if the list parser throws away white space information,
: I can't do this. How about if you count the number of spaces before
: a word and put it somewhere where syntatic deviants like me can find it?

As was already mentioned several times, do not confuse lists with strings.
Whitespace inside a string should be preserved, so indicate that using "".
I hope you're careful what you do with this string, if it can contain
potentially dangerous $ and [] characters.
Or did I confuse something here?

func grid num num num num node -> node* "
N M DX DY C ->
func col num node -> node* {

[snipped]

}
node (col N (row M C))
"

Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)

Ron A. Zajac

unread,

Feb 1, 1997, 3:00:00 AM2/1/97

to

> Michael McCool writes:
>
> : I think the plans for 8.0 are great, but I have a problem with the

> : way white space is discarded. <SNIP>

Y'know, pre-8.0 lists were so well-implemented that I'd gravitated very
naturally toward treating them as true-to-life types (where I wasn't
daunted by the n/2 indexing time issue). In other words, whitespace
became a non-issue once I actually homed in on lists. I fully expect my
transfer to 8.0 to be seamless in this regard.

In fact, I'm looking forward to expanding my use of lists where they'll
afford a more elegant solution, rather than hacking it out with
associative arrays (under the duress of performance concerns).

--
Ron A. Zajac / NORTEL / 972-684-4887 esn444 / za...@nortel.com
These notions are mine, not NORTEL's!

Donal K. Fellows

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

In article <5cu90k$je9$6...@nz12.rz.uni-karlsruhe.de>,
Heribert Dahms <DA...@ifk20.mach.uni-karlsruhe.de> wrote:

> mmc...@cgl.uwaterloo.ca (Michael McCool) writes:
>> I think the plans for 8.0 are great, but I have a problem with the

>> way white space is discarded. Basically, Tcl is great for hacking
>> interface languages, and white-space is sometimes used as a
>> syntactic element.

[ elided ]

>> Unfortunately, if the list parser throws away white space
>> information, I can't do this. How about if you count the number of
>> spaces before a word and put it somewhere where syntatic deviants
>> like me can find it?
>
> As was already mentioned several times, do not confuse lists with
> strings. Whitespace inside a string should be preserved, so
> indicate that using "".

Pardon?

> I hope you're careful what you do with this string, if it can
> contain potentially dangerous $ and [] characters. Or did I confuse
> something here?

Tcl8 is really quite reasonable here. If you treat a value as a list
(by passing it to one of the list commands, for example) then that
value will get converted to a list, but otherwise it will remain a
string and have all its whitespace preserved. Note that enclosing the
string in double quotes will _not_ change this behaviour (which is
independant of the quoting), so you did confuse something here :^)

The moral of this story is:
Treat things that are conceptually lists as lists, and use list
commands on them. Treat things that are conceptually strings as
strings, and use string commands on them. Using string commands on
lists will give you a performance hit (but will otherwise be OK) and
using list commands on strings is a bad idea, as it can lead to
automagical whitespace translations (as well as the performance hit)

Who knows, this might even lead to a lot of buggy programs getting
fixed (though I would quite like things quoted as strings and used as
lists or commands to be (optionally) reported with a warning (on
stderr or the console), as that style of coding can lead to a lot of
subtle bugs occurring when presented to users...)

Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) fell...@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| do...@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+

Nat Pryce

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

Mike Ponicki <mj...@rsvl.unisys.com> wrote in article <32EE3C...@rsvl.unisys.com>...

> |2. However, there are still several new features that we hope to get in

> ...
> |
> | - Namespaces (currently under negotiation with Michael
> McLennan).
>
> The above excerpt was posted in this newsgroup a few days ago. I need
> more info on what the namespace solution is since I am currently working
> on a solution of my own. If standard Tcl solves this problem, then I
> won't work so hard on my solution and wait for the standard fix. But I
> need more information now.
>
> From what I can tell it looks like the goal is to get IncrTcl to be part
> of "standard" Tcl. Should I look there for my answers?

While we're on the subject of namespaces, can I make an impassioned
plea: please don't adopt the double-colon namespace separator as used
in C++ and [incr Tcl]. Please use the minor/major style as used in
the "string" command and many other parts of Tcl.

There, at the very least I've amused Dr. Ousterhout :-)

Cheers,
Nat.

Bruce Stephens

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

>>>>> "Nat" == Nat Pryce <n...@doc.ic.ac.uk> writes:

> While we're on the subject of namespaces, can I make an impassioned
> plea: please don't adopt the double-colon namespace separator as
> used in C++ and [incr Tcl]. Please use the minor/major style as
> used in the "string" command and many other parts of Tcl.

Does that make sense? It just sounds wrong to me,
somehow---namespaces are a new fundamental feature, and ought to have
a new distinctive syntax. Some things clearly don't need new syntax,
but namespaces (and presumably some kind of object-oriented features,
ultimately) surely ought to have? Perhaps it should use ".", as used
in Tk? (Or perhaps Tk ought to use spaces?)

On the other hand, perhaps it wouldn't be confusing, and perhaps
there's an advantage: people could easily write experimental namespace
commands right in Tcl (and, for that matter, people with old versions
of Tcl could use the Tcl-implementations until they upgraded).
--
Bruce Stephens | email: B.Ste...@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht, The Netherlands

Jeffrey Hobbs

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

Bruce Stephens <step...@math.ruu.nl> wrote:
> "Nat" == Nat Pryce <n...@doc.ic.ac.uk> writes:
>> While we're on the subject of namespaces, can I make an impassioned
>> plea: please don't adopt the double-colon namespace separator as
>> used in C++ and [incr Tcl]. Please use the minor/major style as
>> used in the "string" command and many other parts of Tcl.

>Does that make sense? It just sounds wrong to me,
>somehow---namespaces are a new fundamental feature, and ought to have
>a new distinctive syntax. Some things clearly don't need new syntax,

Ack, no. I agree with Nat. Although I've used and enjoy the features
of [incr Tcl], I prefer the syntax of Tcl. If possible (if it makes no
difference in cost to implement), my vote would be for having this new
functionality maintain a syntax as close to the current Tcl as possible.
Without really thinking it through, it seems like it would be easier to
deal with the parsing, but then again I might be forgetting some key
reason to use ::. I believe it would make it easier for people to learn
if we don't add extra syntax on top of Tcl's basic philosophy.

--
Jeffrey Hobbs office: 541.683.7891
Nomad of the 'Net email: jho...@cs.uoregon.edu
URL: http://www.cs.uoregon.edu/~jhobbs/

Jon Leech

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

In article <01bc11cf$c57e6a30$490ea992@shub-niggurath>,

Nat Pryce <n...@doc.ic.ac.uk> wrote:
>While we're on the subject of namespaces, can I make an impassioned
>plea: please don't adopt the double-colon namespace separator as used
>in C++ and [incr Tcl]. Please use the minor/major style as used in
>the "string" command and many other parts of Tcl.

How would this work for variable access from another scope (e.g. where I
would say ${scope::variable} now)? The approaches I can think of are rather
verbose and ugly.
Jon
__@/

Heribert Dahms

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

In <5d4c3q$5...@m1.cs.man.ac.uk> fell...@cs.man.ac.uk
(Donal K. Fellows) writes:

: In article <5cu90k$je9$6...@nz12.rz.uni-karlsruhe.de>,
: Heribert Dahms <DA...@ifk20.mach.uni-karlsruhe.de> wrote:
: > As was already mentioned several times, do not confuse lists with

: > strings. Whitespace inside a string should be preserved, so
: > indicate that using "".
:
: Pardon?
:
: > I hope you're careful what you do with this string, if it can
: > contain potentially dangerous $ and [] characters. Or did I confuse
: > something here?
:
: Tcl8 is really quite reasonable here. If you treat a value as a list
: (by passing it to one of the list commands, for example) then that
: value will get converted to a list, but otherwise it will remain a
: string and have all its whitespace preserved. Note that enclosing the
: string in double quotes will _not_ change this behaviour (which is
: independant of the quoting), so you did confuse something here :^)

Sorry. Thanks for clarification. I'll try to summarize:

Treat lists as lists and strings as strings by choosing the proper commands.
Enclosing in {} or "" only differs in the usual substitution rules,
but do *not* by itself specify a list or a string.

BTW, does [] treat it's args as a list?

: The moral of this story is:

: Treat things that are conceptually lists as lists, and use list
: commands on them. Treat things that are conceptually strings as
: strings, and use string commands on them. Using string commands on
: lists will give you a performance hit (but will otherwise be OK) and
: using list commands on strings is a bad idea, as it can lead to
: automagical whitespace translations (as well as the performance hit)

Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)

Jeffrey Hobbs

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

In article <5d57d5$n...@watt.cs.unc.edu>, Jon Leech <le...@cs.unc.edu> wrote:
>Nat Pryce <n...@doc.ic.ac.uk> wrote:
>>While we're on the subject of namespaces, can I make an impassioned
>>plea: please don't adopt the double-colon namespace separator as used
>>in C++ and [incr Tcl]. Please use the minor/major style as used in
>>the "string" command and many other parts of Tcl.

> How would this work for variable access from another scope (e.g. where I
>would say ${scope::variable} now)? The approaches I can think of are rather

Actually, considering this will all be compiled, I don't think that a
slightly more verbose solution will make that much of a difference.
To be concise, it could be:
[scope set varName ?value?]
That's not so bad, although I admit the original is a hair nicer.

Nat Pryce

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

Jon Leech <le...@cs.unc.edu> wrote in article
<5d57d5$n...@watt.cs.unc.edu>...
> In article <01bc11cf$c57e6a30$490ea992@shub-niggurath>,

> Nat Pryce <n...@doc.ic.ac.uk> wrote:
> >While we're on the subject of namespaces, can I make an impassioned
> >plea: please don't adopt the double-colon namespace separator as used
> >in C++ and [incr Tcl]. Please use the minor/major style as used in
> >the "string" command and many other parts of Tcl.
>
> How would this work for variable access from another scope (e.g.
where I
> would say ${scope::variable} now)? The approaches I can think of are
rather

> verbose and ugly.

How about something like this...

# Could namespaces be integrated with packages like this?
#
package provide new_pkg 1.2 {
set var1 10
set var2 20

...
}

# Explicit import
#
package import variable new_pkg var1
echo $var1

# Use full name
#
echo [new_pkg set var1]

# Or execute a command in the scope of the package
#
new_pkg {echo $var1}

What do you think?

Cheers,
Nat.

John Ousterhout

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

In article <5d57d5$n...@watt.cs.unc.edu>, le...@cs.unc.edu (Jon Leech) writes:
|> In article <01bc11cf$c57e6a30$490ea992@shub-niggurath>,
|> Nat Pryce <n...@doc.ic.ac.uk> wrote:
|> >While we're on the subject of namespaces, can I make an impassioned
|> >plea: please don't adopt the double-colon namespace separator as used
|> >in C++ and [incr Tcl]. Please use the minor/major style as used in
|> >the "string" command and many other parts of Tcl.
|>
|> How would this work for variable access from another scope (e.g. where I
|> would say ${scope::variable} now)? The approaches I can think of are rather
|> verbose and ugly.

One possibility is [scope get variable] (i.e. have a "get" subcommand for
each namespace command that accesses its variables). This may look verbose,
but it requires only 2 more characters to be typed than the :: form above.

Viktor Dukhovni

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

In <5d825e$k...@engnews2.Eng.Sun.COM> ous...@tcl.eng.sun.com (John Ousterhout) writes:

>One possibility is [scope get variable] (i.e. have a "get" subcommand for
>each namespace command that accesses its variables). This may look verbose,
>but it requires only 2 more characters to be typed than the :: form above.

Why "[scope get variable]" and not "[scope set variable ?value?]"?
Is there some conflict with the standard "set" that is avoided? How does
one set the variable?

BTW. The tk4.2p2.patch.gz seems to have a broken patch for the
"changes" file. tk4.2 was SCCS id 1.133, but the patch is malformed and
starts at 1.134.

Glenn Vanderburg

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

ous...@tcl.eng.sun.com (John Ousterhout) writes:
>
> One possibility is [scope get variable] (i.e. have a "get" subcommand for
> each namespace command that accesses its variables). This may look verbose,
> but it requires only 2 more characters to be typed than the :: form above.

I like that.

I wonder ... here's a question which people who work with [incr Tcl]
might be able to answer. How common is it, in [incr Tcl] code, to
reference a variable within one scope from outside the scope? I know
that it's very common to call procedures using the scope qualifier,
but it seems to me that cross-scope variable references might be much
less common. If that's the case, then the above suggestion looks even
more attractive.

---glv

Jim & Leslie Ingham

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

In article <m3g1zcs...@oblivion.bizworks.com>, Glenn Vanderburg
<g...@vanderburg.org> wrote:

Glenn,

One very common use for cross-scope references is when you want to use a
variable in some scope for the various -variable options of Tk widgets.
You have to pass Tk a fully qualified reference to the variable, so that
out in the event loop, Tk can find it. Thus you need not only setter and
getter operations but a "return my full name" type operation as well (i.e.
either scope::varname, or something else).

This use of cross-scope variable references is very helpful in MegaWidget
development. It allows you to package up your Tcl based megawidget
without having to worry about name conflicts with other Tcl globals.

Jim

Jon Leech

unread,

Feb 4, 1997, 3:00:00 AM2/4/97

to

In article <5d825e$k...@engnews2.Eng.Sun.COM>,

John Ousterhout <ous...@tcl.eng.sun.com> wrote:
>In article <5d57d5$n...@watt.cs.unc.edu>, le...@cs.unc.edu (Jon Leech) writes:
>|> How would this work for variable access from another scope (e.g. where I
>|> would say ${scope::variable} now)? The approaches I can think of are rather
>|> verbose and ugly.
>

>One possibility is [scope get variable] (i.e. have a "get" subcommand for
>each namespace command that accesses its variables). This may look verbose,
>but it requires only 2 more characters to be typed than the :: form above.

Syntax is important; otherwise why have the $name notation at all?

The above suggestion (in fact, any approach in which scoped access is
done in a syntactically distinct fashion from local scope access) appears to
be incompatible with pass-by-name, too.

Jon
__@/

Jan Nijtmans

unread,

Feb 5, 1997, 3:00:00 AM2/5/97

to

John Ousterhout wrote:
> One possibility is [scope get variable] (i.e. have a "get" subcommand for
> each namespace command that accesses its variables). This may look verbose,
> but it requires only 2 more characters to be typed than the :: form above.

Another possibility is to interpret variable names as lists. The last
element is the variable name, while the others form the namespace
path. Not many people use {} or spaces in variable names. And even
one character less to type :-)

for example:
[set {scope variable}]
or (if you prefer lists):
[set [list scope variable]]

The only command to be carefull with is the "foreach" command,
because there the second argument is already interpreted as
a list. But an additional pair of {} or [list ] can solve
that easily.

Jan Nijtmans
NICI (Nijmegen Institute of Cognition and Information)
email: nijt...@nici.kun.nl
url: http://www.cogsci.kun.nl/

Michael J. McLennan

unread,

Feb 5, 1997, 3:00:00 AM2/5/97

to

Jeffrey Hobbs (jho...@cs.uoregon.edu) wrote:

: Bruce Stephens <step...@math.ruu.nl> wrote:
: > "Nat" == Nat Pryce <n...@doc.ic.ac.uk> writes:

: >> While we're on the subject of namespaces, can I make an impassioned

: >> plea: please don't adopt the double-colon namespace separator as
: >> used in C++ and [incr Tcl]. Please use the minor/major style as
: >> used in the "string" command and many other parts of Tcl.

: >Does that make sense? It just sounds wrong to me,

: >somehow---namespaces are a new fundamental feature, and ought to have
: >a new distinctive syntax. Some things clearly don't need new syntax,

: Ack, no. I agree with Nat. Although I've used and enjoy the features
: of [incr Tcl], I prefer the syntax of Tcl. If possible (if it makes no
: difference in cost to implement), my vote would be for having this new
: functionality maintain a syntax as close to the current Tcl as possible.

Having a separator like "::" or "." is an essential part of the new
namespace mechanism. It keeps the command name together as a single
word on the command line, so it can be resolved and its value can
be cached in a single Tcl_Obj. With space-separated words, the
namespace path is spread over a series of arguments, so caching the
name resolution is problematic.

But even if the implementation could be worked out, I think using
space-separated arguments for a namespace path is a bad idea. It turns
your Tcl code into an amorphous mass of gook. For example, if I use
the following command:

foo bar x 0 3

What does this mean? Is "foo" a command that takes "bar x 0 3" as
arguments, or is "foo" a namespace containing the "bar" command?
Maybe "foo" and "bar" are both namespaces that contain the real
command "x", which takes "0 3" as arguments. If you didn't write
the "foo" package, you have no idea how to read this.

With a distinct separator, the relationships between arguments on the
command line becomes much clearer. If I say:

foo::bar::x 0 3

you know immediately that "x" is a command in the namespace "foo::bar"
that takes arguments "0 3".

I think both "." and "::" are good separators. I chose "::" for
[incr Tcl] because it mimics the C++ syntax (so it is well known),
and because "." is already being used for the widget hierarchy. If
we used "." for the separator, then a command like ".foo.bar.x" could
be either a widget, or a command called "x" in the namespace "bar",
in the namespace "foo".

So I am proposing that the new namespace mechanism use "::" as a
separator for namespace qualifiers.

--Michael
...
--------------------------------------------------------- ':'...''. ---
Michael J. McLennan 2C-226 mmcl...@lucent.com '::.''''':;:
Lucent Technologies '::; ;;:
1247 S Cedar Crest Blvd :::,, :;;
Allentown, PA 18103 Lucent Technologies ;:;' ;:;
phone: 610-712-2842 Bell Labs Innovations ;;: .;:
fax: 610-712-2773 :;:, ,:;:
':;;;:;:'

Joel Saunier

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

I agree with Michael.

I don't like very much the "::" notation, but I think we must have a
"single-word" notation, since Tcl cuts instructions in "single-word"
parts. (What about the "->" separator? Humm, take a look at your keyboard :-)

Another proposal was "{scope variable}". I think it breaks the following
code:

set x {scope variable}
eval set $x 10

In article <5davu3$b...@nntpa.cb.lucent.com> m...@mhcnet.lucent.com (Michael J. McLennan) writes:
> With a distinct separator, the relationships between arguments on the
> command line becomes much clearer. If I say:
>
> foo::bar::x 0 3
>
> you know immediately that "x" is a command in the namespace "foo::bar"
> that takes arguments "0 3".
>
> I think both "." and "::" are good separators. I chose "::" for
> [incr Tcl] because it mimics the C++ syntax (so it is well known),
> and because "." is already being used for the widget hierarchy. If
> we used "." for the separator, then a command like ".foo.bar.x" could
> be either a widget, or a command called "x" in the namespace "bar",
> in the namespace "foo".

--
Joel Saunier

Roger Oberholtzer

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

I vote for "::", for the simple reason that iTcl uses it. As I
understand, iTcl will no longer need to be a source modification of Tcl
if namespaces are implemented. In fact, I heard that the Tcl namespace
mechanisim will be the iTcl mechanisim - if legal stuff works out. Thus,
all iTcl can be dynamically loaded into a Tcl with namespace support.
As such, iTcl could be more easily used. Or not. It is
application-specific, NOT Tcl-specific.

If "::" is not used, would iTcl change ALL existing code to the new
syntax? Or would iTcl go one way and the Tcl core some other way - and
the tools built on both have a syntax incompatability? Seems
unneccessary. Let's spend our time on new stuff - not different versions
of the same thing :-)

--

_______________________________________________________________________
=======================================================================
Roger Oberholtzer E-mail: ro...@opq.se
OPQ Systems AB Phone: Int + 46 8 314223
Tomtebogatan 19 Fax: Int + 46 8 302602
113 39 Stockholm
Sweden

"Accuracy is addictive." - FUGRO

Maurice DIAMANTINI

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

In article (Dans l'article) <SAUNIER.97...@simtoul.simulog.fr>,
sau...@simulog.fr (Joel Saunier) wrote (écrivait) :

>I agree with Michael.
>
>I don't like very much the "::" notation, but I think we must have a
>"single-word" notation, since Tcl cuts instructions in "single-word"
>parts. (What about the "->" separator? Humm, take a look at your keyboard :-)
>
>Another proposal was "{scope variable}". I think it breaks the following
>code:
>
> set x {scope variable}
> eval set $x 10
>

This lines breaks also if you had a standard variable name with
space in it (i.e. a varname like a file name on MacOS)

You should use instead:

eval [list set $x 10]

--
Maurice DIAMANTINI - Ecole Nationale Supérieure de Techniques Avancées
di...@ensta.fr - 32 Bd Victor - 75739 PARIS FRANCE
<< branchez-vous sur fr.comp.lang.tcl >>

Jan Nijtmans

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to mmcl...@lucent.com

Michael J. McLennan wrote:
> Having a separator like "::" or "." is an essential part of the new
> namespace mechanism. It keeps the command name together as a single
> word on the command line, so it can be resolved and its value can
> be cached in a single Tcl_Obj. With space-separated words, the
> namespace path is spread over a series of arguments, so caching the
> name resolution is problematic.

That what {} or [list ] can be used for.

> But even if the implementation could be worked out, I think using
> space-separated arguments for a namespace path is a bad idea. It turns
> your Tcl code into an amorphous mass of gook. For example, if I use
> the following command:
>

> foo bar x 0 3
>

> What does this mean? Is "foo" a command that takes "bar x 0 3" as
> arguments, or is "foo" a namespace containing the "bar" command?
> Maybe "foo" and "bar" are both namespaces that contain the real
> command "x", which takes "0 3" as arguments. If you didn't write
> the "foo" package, you have no idea how to read this.

How about:
file delete $filename
or
string range $string $begin $end

What's wrong with interpreting these commands as namespaces
"file" and "string" that have functions "delete" and "range" in
it? It wouldn't make any difference for what these function do.
And it would create a great opportunity to define your own new
options to existing commands if "string" and "file" are
converted to real namespaces:

% namespace string {
proc mycommand {} {return "just a test"}
}
% string mycommand
just a test.

In Itcl there are separate "namespace" and "ensemble" commands, but
I merely see "ensemble" as a subset of "namespace" with a different
syntax. Ensembles cannot have internal variables, but both can have
interal procs.

Jan Nijtmans
NICI (Nijmegen Institute of Cognition and Information)
email: nijt...@nici.kun.nl

url: http://www.cogsci.kun.nl/~nijtmans/

Joel Saunier

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

In article <diam-ya02308000...@ici-paris.ensta.fr> di...@ensta.fr (Maurice DIAMANTINI) writes:
> > set x {scope variable}
> > eval set $x 10
> >
>
> This lines breaks also if you had a standard variable name with
> space in it (i.e. a varname like a file name on MacOS)
>
> You should use instead:
>
> eval [list set $x 10]

Space in varnames is useless (I hope :-;). But in the futur, namespaces and
"scope" notation will be use intensively.

Joel
--
Joel Saunier

Bruce Stephens

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

>>>>> "Michael" == Michael J McLennan <m...@mhcnet.lucent.com> writes:

> Having a separator like "::" or "." is an essential part of the new
> namespace mechanism. It keeps the command name together as a single
> word on the command line, so it can be resolved and its value can be

> cached in a single Tcl_Obj. [...]

> But even if the implementation could be worked out, I think using
> space-separated arguments for a namespace path is a bad idea. It
> turns your Tcl code into an amorphous mass of gook. For example, if
> I use the following command:

> foo bar x 0 3

Yeah, I tend to agree. I can see the analogy with "string foo ..."
and such, but I think they're probably wrong too. I'd hope that
they'd be left for compatibility, of course, but I'd have thought
"string::foo ..." would be more logical. There's clearly a fuzziness,
because I'm not at all sure about widget commands; should I write
".label::cget ..."? (i.e., should commands easily be able/encouraged
to create namespaces? Are namespaces really objects, in the
object-oriented sense?)

Glenn Vanderburg

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

Jan Nijtmans <nijt...@nici.kun.nl> writes:

>
> Michael J. McLennan wrote:
>
> > But even if the implementation could be worked out, I think using
> > space-separated arguments for a namespace path is a bad idea. It turns
> > your Tcl code into an amorphous mass of gook. For example, if I use
> > the following command:
> >
> > foo bar x 0 3

I would still like to find a way to avoid the separator and use the
major/minor notation, but Michael brings up a valid point here. In
evaluating these mechanisms, we need to look at examples that use more
than one level of namespace. So far as I know, there are no
major/minor command suites in Tcl or Tk which use more than one level
of subcommands, but multiple levels are common in [incr Tcl] code.

But I really want to elaborate on one of Jan's comments:

> In Itcl there are separate "namespace" and "ensemble" commands, but
> I merely see "ensemble" as a subset of "namespace" with a different
> syntax. Ensembles cannot have internal variables, but both can have
> interal procs.

I, too, had thought of this, and I think it's a telling disparity.
Tcl needs namespaces, and it also needs the kind of support for
command suites ("ensembles") that [incr Tcl] provides. What it
definitely doesn't need, in my opinion, is two separate, distinct
mechanisms for what are really the same thing.

---glv

Jeffrey Hobbs

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

Vince Darley <vi...@deas.harvard.edu> wrote:
>I think there's enough Itcl code out there, that people use a lot, that
>there will have to be a reasonably good argument for why '->' is somehow
>better than '::' (or whatever else may be proposed). Also a lot of people

Actually, it's for this reason that I would suggest any other notation,
unless the new system is 99% compatible with my current [incr Tcl] stuff.
If it's not compatible, I would like specific semantic differences so I
don't get caught way down the line by some untested code that happened to
have good enough syntax to compile, but not to actually run.

Jeffrey Hobbs

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

Jeffrey Hobbs <jho...@cs.uoregon.edu> wrote:
>Actually, it's for this reason that I would suggest any other notation,
>unless the new system is 99% compatible with my current [incr Tcl] stuff.
>If it's not compatible, I would like specific semantic differences so I

^^^^^^

Ack, I meant "syntactic". Bugger my fingers for typing faster than I can
think... (ah, gone are the days when you could only run at the mouth).

Michael J. McLennan

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

Jan Nijtmans (nijt...@nici.kun.nl) wrote:
: Michael J. McLennan wrote:
: > Having a separator like "::" or "." is an essential part of the new

: > namespace mechanism. It keeps the command name together as a single
: > word on the command line, so it can be resolved and its value can

: > be cached in a single Tcl_Obj. With space-separated words, the

: > namespace path is spread over a series of arguments, so caching the
: > name resolution is problematic.

: That what {} or [list ] can be used for.

Wait a minute. It looks like you have a different idea about how
namespaces should work. The Sun team has suggested that we could
create namespaces with a command like this:

namespace foo {
namespace bar {
proc x {args} {return $args}
}
}

and then access them with a syntax like this:

foo bar x 1 2 3

So each of the namespace qualifiers is a separate word on the command
line. By suggesting {} and [list ], you are implying that the syntax
should be:

{foo bar x} 1 2 3
or
[list foo bar x] 1 2 3

So you have lost the idea that namespaces look like ensembles. Is
this really easier to read than the "::" syntax? Compare it to this:

foo::bar::x 1 2 3

: How about:

: file delete $filename
: or
: string range $string $begin $end

: What's wrong with interpreting these commands as namespaces
: "file" and "string" that have functions "delete" and "range" in
: it? It wouldn't make any difference for what these function do.

: In Itcl there are separate "namespace" and "ensemble" commands, but

: I merely see "ensemble" as a subset of "namespace" with a different
: syntax. Ensembles cannot have internal variables, but both can have
: interal procs.

I used to think that namespaces and ensembles were the same thing.
In fact, I used namespaces to implement ensembles in an early version
of itcl2.0. But the two are fundamentally different, for the following
reasons:

1) Namespaces have variables, ensembles do not.

2) When you enter a namespace, you are activating a new context and
adding a call frame to the call stack. For example, suppose the
usual "info" command were implemented as a namespace. It might
have commands like "exists", "globals", etc. So when you say
"info globals", it means "activate the info namespace, then invoke
its globals command."

But the "globals" command needs to access information from the
calling context. It should report the global variables in the
calling context--not the global variables in the artificial "info"
namespace. So the "globals" command would have to do an "uplevel"
to get at the appropriate information. But what if someone
renamed "info globals" to "info tcl globals" (so they could
override the default implementation)? It would break. In that
case, it would need to look 2 levels up in the call stack.

Ensemble commands like "info globals" are really a single command
with different arguments to control their action.

3) Ensembles report usage errors, namespaces do not. Again, consider
the usual "info" command. When you invoke "info xxx", you get
an error message like:

bad option "xxx": should be args, body, cmdcount, commands,
complete, default, exists, globals, hostname, level, library,
loaded, locals, nameofexecutable, patchlevel, procs, script,
sharedlibextension, tclversion, or vars

If the "info" command were implemented as a namespace, you would
get an error message like:

invalid command name "xxx"

I believe that both namespaces and ensembles are useful, but for
different reasons. So the proposal that I sent to Sun includes support
for both. You can use ensembles to implement things like the "info"
command or the widget access commands, and you can wrap them up in
a namespace, to form a library.

Michael J. McLennan

unread,

Feb 6, 1997, 3:00:00 AM2/6/97

to

Jeffrey Hobbs (jho...@cs.uoregon.edu) wrote:

: Vince Darley <vi...@deas.harvard.edu> wrote:
: >I think there's enough Itcl code out there, that people use a lot, that
: >there will have to be a reasonably good argument for why '->' is somehow
: >better than '::' (or whatever else may be proposed). Also a lot of people

: Actually, it's for this reason that I would suggest any other notation,

: unless the new system is 99% compatible with my current [incr Tcl] stuff.
: If it's not compatible, I would like specific semantic differences so I

: don't get caught way down the line by some untested code that happened to

: have good enough syntax to compile, but not to actually run.

In the proposal that I sent to Sun, the syntax is 100% compatible with
[incr Tcl]. The semantics are 95% compatible. I simplified the name
resolution rules a bit, but it should not affect much of the existing
[incr Tcl] code.

So I think we should pick a separator that is intuitively familiar to
most people. From that standpoint, I still think that "::" is the
best candidate.

Nat Pryce

unread,

Feb 7, 1997, 3:00:00 AM2/7/97

to

Michael J. McLennan <m...@mhcnet.lucent.com> wrote in article
<5davu3$b...@nntpa.cb.lucent.com>...

>
> Having a separator like "::" or "." is an essential part of the new
> namespace mechanism. It keeps the command name together as a single
> word on the command line, so it can be resolved and its value can
> be cached in a single Tcl_Obj. With space-separated words, the
> namespace path is spread over a series of arguments, so caching the
> name resolution is problematic.
>

> I think both "." and "::" are good separators. I chose "::" for
> [incr Tcl] because it mimics the C++ syntax (so it is well known),
> and because "." is already being used for the widget hierarchy. If
> we used "." for the separator, then a command like ".foo.bar.x" could
> be either a widget, or a command called "x" in the namespace "bar",
> in the namespace "foo".
>

> So I am proposing that the new namespace mechanism use "::" as a
> separator for namespace qualifiers.

Ok I can see the sense in having single words separated by some namespace
delimiter. I have a couple of grumbles with "::" though.

Firstly, it's two characters. It doesn't looks too bad in a proportional
font I
admit, but I think a single character would be nice. How about ':' or '@'?

Secondly, it is, as you point out, already well-known from C++. However,
Tcl namespaces will be very different from those of C++ because Tcl itself
is a very different language, mainly in being highly dynamic and
introspective - programs can examine their own state and modify/extend
themselves. C++ is very static and does not support much in the way of
introspection. Therefore I feel that any knowledge that C++ programmers
bring to understanding the "::" notation could be a hindrance rather than
a help. That's just a hunch though and I could be wrong.

Thirdly, if Tcl namespaces are as dynamic as the rest of Tcl, they are
really
objects, encapsulating state and behaviour in a single entity. How will
namespaces relate to other object-like commands in Tcl, such as Tk
widgets etc? And how will existing namespace-like commands, such as
string and info, work in the presence of namespaces?

Cheers,
Nat.

Jan Nijtmans

unread,

Feb 7, 1997, 3:00:00 AM2/7/97

to mmcl...@lucent.com

Michael J. McLennan wrote:
> Wait a minute. It looks like you have a different idea about how
> namespaces should work. The Sun team has suggested that we could
> create namespaces with a command like this:
>
> namespace foo {
> namespace bar {
> proc x {args} {return $args}
> }
> }

Oh, no. I guess I fully agree with the Sun team.

> So each of the namespace qualifiers is a separate word on the command
> line. By suggesting {} and [list ], you are implying that the syntax
> should be:
>
> {foo bar x} 1 2 3
> or
> [list foo bar x] 1 2 3

No, I'm not suggesting that. Images and interpreters always create
a command with the same name. Why not do the same with namespaces.
{} and [list ] should only be used when nessessary, e.g. for
variables.

> 1) Namespaces have variables, ensembles do not.

Indeed, ensembles can be considered a sub-set.

> 2) When you enter a namespace, you are activating a new context and
> adding a call frame to the call stack. For example, suppose the
> usual "info" command were implemented as a namespace. It might
> have commands like "exists", "globals", etc. So when you say
> "info globals", it means "activate the info namespace, then invoke
> its globals command."
>
> But the "globals" command needs to access information from the
> calling context. It should report the global variables in the
> calling context--not the global variables in the artificial "info"
> namespace. So the "globals" command would have to do an "uplevel"
> to get at the appropriate information. But what if someone
> renamed "info globals" to "info tcl globals" (so they could
> override the default implementation)? It would break. In that
> case, it would need to look 2 levels up in the call stack.

I guess that it would be good to have a standard namespace "tcl", which
contains the core commands as well. If you want the core command, use
'tcl info globals' in stead of 'info globals'. Now there are already
protected namespaces, why not implement namespaces in which renaming
is disabled? Renaming is a dangerous practice anyway, and I wouldn't
mind if renaming would be restricted such that commands can only
be renamed within the same namespace.

> 3) Ensembles report usage errors, namespaces do not. Again, consider
> the usual "info" command. When you invoke "info xxx", you get
> an error message like:
>
> bad option "xxx": should be args, body, cmdcount, commands,
> complete, default, exists, globals, hostname, level, library,
> loaded, locals, nameofexecutable, patchlevel, procs, script,
> sharedlibextension, tclversion, or vars
>
> If the "info" command were implemented as a namespace, you would
> get an error message like:
>
> invalid command name "xxx"

Itcl already produces different error-commands than Tcl sometimes. In
this case I would be perfectly satisfied with an error message like:

bad command "xxx" in namespace "tcl info": should be args,
body, cmdcount, commands,complete, default, exists, globals,

hostname, level, library, loaded, locals, nameofexecutable,
patchlevel, procs, script, sharedlibextension, tclversion,
or vars

I guess I hit a hot topic. And that for the difference between '::'
and ' '. Still I think that it would be good to follow the current
tcl syntax as closely as possible.

Michael J. McLennan

unread,

Feb 7, 1997, 3:00:00 AM2/7/97

to

Nat Pryce (n...@doc.ic.ac.uk) wrote:
: Michael J. McLennan <m...@mhcnet.lucent.com> wrote in article
: <5davu3$b...@nntpa.cb.lucent.com>...
: >
: > So I am proposing that the new namespace mechanism use "::" as a
: > separator for namespace qualifiers.

: Ok I can see the sense in having single words separated by some namespace
: delimiter. I have a couple of grumbles with "::" though.

: Firstly, it's two characters. It doesn't looks too bad in a proportional
: font I admit, but I think a single character would be nice. How about
: ':' or '@'? Secondly, it is, as you point out, already well-known from
: C++. However, Tcl namespaces will be very different from those of C++
: because Tcl itself is a very different language, mainly in being highly
: dynamic and introspective - programs can examine their own state and
: modify/extend themselves. C++ is very static and does not support much
: in the way of introspection. Therefore I feel that any knowledge that
: C++ programmers bring to understanding the "::" notation could be a
: hindrance rather than a help. That's just a hunch though and I could
: be wrong.

It's true that C++ and Tcl are different languages, but they have a
lot in common. C++ has procedures, and Tcl has procedures. C++ uses
{}'s for code bodies, and Tcl uses {}'s for code bodies. C++ has commands
like "if", "for", "while", "switch", and Tcl has these same commands.

Actually, I think it was quite clever of John Ousterhout to borrow from
C/C++ and shell when he designed Tcl. It makes it easy for people to
get started with Tcl. So instead of inventing an entirely new syntax
for namespace scoping, I think we should again borrow from C++.

Tcl is more dynamic than C++, but namespaces are used for the same
purpose in both languages. They provide separate scopes for command
and variable names, so you can create libraries that won't interfere
with one another. A name like "foo::bar::x" or "::x" would have
the same meaning in Tcl that it has in C++. So having a "::" operator
in Tcl really makes sense.

: Thirdly, if Tcl namespaces are as dynamic as the rest of Tcl, they are

: really
: objects, encapsulating state and behaviour in a single entity. How will
: namespaces relate to other object-like commands in Tcl, such as Tk
: widgets etc? And how will existing namespace-like commands, such as
: string and info, work in the presence of namespaces?

Its true that namespaces encapsulate variables and commands, so they
have both state and behavior. They can be used to build object systems,
but they are not really "objects" themselves.

Namespaces can contain objects. With an extension like [incr Tcl],
for example, you can create a Toaster named "fred" in one namespace,
and a Toaster named "fred" in another namespace. Each namespace has
its own private "fred" object.

All of the Tk widgets, however, will belong to the global namespace
so you can access them throughout an application. Widgets really
act like global resources for an application. Besides, each widget
must have a unique window name. It doesn't make sense to have two
windows named ".b".

Commands like "string" and "info" are not really namespace-like. They
are ordinary Tcl commands with multiple argument words that control
their actions. I call this kind of command an "ensemble" command.
There will be a separate mechanism for defining and extending ensembles.

Bernd Hentig

unread,

Feb 10, 1997, 3:00:00 AM2/10/97

to

In article <32F998...@opq.se>, Roger Oberholtzer <ro...@opq.se> wrote:
>I vote for "::", for the simple reason that iTcl uses it. As I
>understand, iTcl will no longer need to be a source modification of Tcl
>if namespaces are implemented. In fact, I heard that the Tcl namespace
>mechanisim will be the iTcl mechanisim - if legal stuff works out. Thus,
>all iTcl can be dynamically loaded into a Tcl with namespace support.
>As such, iTcl could be more easily used. Or not. It is
>application-specific, NOT Tcl-specific.
>
>If "::" is not used, would iTcl change ALL existing code to the new
>syntax? Or would iTcl go one way and the Tcl core some other way - and
>the tools built on both have a syntax incompatability? Seems
>unneccessary. Let's spend our time on new stuff - not different versions
>of the same thing :-)
>

This is my opinion, too.
I'm only developing itcl programs for some short time now, but changing the
OO syntax to some obscure scope bracketing will not broaden the user base.
I always thought of tcl as some language easy to learn, but at this time
I really think you're trying to go into the perl direction - unreadable
code for some sysadmins that love things like lisp and .exrc.

So, my vote goes for :: - if an application developer's opinion is worth
anything here.

Andreas Manessinger

unread,

Feb 11, 1997, 3:00:00 AM2/11/97

to

"Nat Pryce" <n...@doc.ic.ac.uk> writes:

> Ok I can see the sense in having single words separated by some namespace
> delimiter. I have a couple of grumbles with "::" though.
>
> Firstly, it's two characters. It doesn't looks too bad in a proportional
> font I
> admit, but I think a single character would be nice. How about ':' or '@'?
>
> Secondly, it is, as you point out, already well-known from C++. However,
> Tcl namespaces will be very different from those of C++ because Tcl itself
> is a very different language, mainly in being highly dynamic and
> introspective - programs can examine their own state and modify/extend
> themselves. C++ is very static and does not support much in the way of
> introspection. Therefore I feel that any knowledge that C++ programmers
> bring to understanding the "::" notation could be a hindrance rather than
> a help. That's just a hunch though and I could be wrong.
>

> Thirdly, if Tcl namespaces are as dynamic as the rest of Tcl, they are
> really
> objects, encapsulating state and behaviour in a single entity. How will
> namespaces relate to other object-like commands in Tcl, such as Tk
> widgets etc? And how will existing namespace-like commands, such as
> string and info, work in the presence of namespaces?

To your first point: Hitting the same key twice doesn't require much
of an effort, at least for me.

Secondly, when I began with Itcl some eight month ago I had solid
knowledge of Tcl, and was quite familiar with C++ and OO methods,
though mostly on a theoretical basis, because I do most of my work in
C. Starting with Itcl was *extremely* easy, because it works almost
like C++, and where there are differences they consist mostly of
simplifications. Class declarations have very similar syntax and very
similar semantics, so reading a design implemented in Itcl is easy for
anybody able to read C++.

Go into a bookshop and look into the shelves. You find hundreds of
books about C++, and almost all new books about OO methods contain
examples in C++. Sorry, but this is reality! I am not to imply that
C++ is the best of all OO languages, but it has all the possibilities
an OO language needs. And so has OO Cobol. And so have many other
languages.

In reality object-orientation is about analysis and design methods,
and not about programming languages. Some methods like Responsibility
Driven Design [Wirfs-Brock et.al., 1990] tend to favour languages
capable of multiple inheritance, so that's something I would like to
have in a language, but besides that it makes no difference,
everything else is in the realms of subjectivity and religion.

Now, if we can draw on the expertise of millions of programmers
familiar with C++, why should that be wrong? Is it really so important
to come up with namespace separators different from those in C++, that
we should pay the price of incompatibility with Itcl?

Michael McLennan has done a very good job in doing for Tcl the same as
Bjarne Stroustrup has done for C. All my old programs that I formerly
ran on `wish' now run on `itkwish', and they do that without any
modification! This allows me to deliver my software with only one
interpreter gernerally used. It makes installation and maintenance
simpler, and if I sometimes need to extend a program, I have a lot
more widgets at hand than I would using `wish'. And this is also the
answer to your third point. We don't need different syntax for already
existing constructs like `string ...', because that would break
existing programs.

Sure, there are those saying hybrid languages are a Bad Thing (TM),
but if we really want a pure OO language then we should not bother
extending Tcl. And if we still do, well, Itcl is probably not the
utterly best implementation of a hybrid approach, but it is very near
:-)

Sure you can use dirty non-OO tricks in C++, sure you can do the same
in Itcl, but believe me, I've tried it, there is nothing that stops
you from writing pure OO programs in either language.

In summary, I *strongly* opt for utmost compatibility with Itcl,
because it already exists, works, has a big user community, and
because it wins Tcl new users from the immense pool of C++ users that
look for a prototyping language. And this last point is probably the
most important: If we fail to win new users and thereby keeping Tcl
alive we may very easily find ourselves programming Visual Basic in a
few years.

--
Andreas Manessinger m...@adv.magwien.gv.at
------------------------------------------------------------------------
"Time is a jet plane, it moves too fast"
Bob Dylan, -You're a big girl now-

Michael Schumacher

unread,

Feb 11, 1997, 3:00:00 AM2/11/97

to

Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote:

: [...] I am not to imply that

: C++ is the best of all OO languages, but it has all the possibilities
: an OO language needs.

I doubt. C++ is a static language, so it's not possible to have
"anonymous objects" at runtime. Objective-C supports this feature nicely.

: Now, if we can draw on the expertise of millions of programmers

: familiar with C++, why should that be wrong?

That somewhat reminds me on countless OS wars. How can an OS be bad if
there are millions using it?

: Michael McLennan has done a very good job in doing for Tcl the same as

: Bjarne Stroustrup has done for C.

Okay, this is the "killer sentence" that forced me to reply. I usually
don't care what programming language folks are using to get their job
done. But C++ is certainly the ugliest, most-bloated language I've
ever came across. iTcl and Java are a lot better in this regard IMNSHO.

mike

Bruce Stephens

unread,

Feb 11, 1997, 3:00:00 AM2/11/97

to

>>>>> "Michael" == Michael Schumacher <mi...@hightec.saarlink.de> writes:

> But C++ is certainly the ugliest, most-bloated language I've ever
> came across. iTcl and Java are a lot better in this regard IMNSHO.

Since they all use the same :: notation (don't they? I sometimes feel
I'm the only human that doesn't know Java, but since it was designed
to look somewhat like C++, presumably it uses ::), I don't see any
conflict.

Andreas Manessinger

unread,

Feb 11, 1997, 3:00:00 AM2/11/97

to

mi...@hightec.saarlink.de (Michael Schumacher) writes:

>
> Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote:
>
> : [...] I am not to imply that
> : C++ is the best of all OO languages, but it has all the possibilities
> : an OO language needs.
>
> I doubt. C++ is a static language, so it's not possible to have
> "anonymous objects" at runtime. Objective-C supports this feature nicely.

Point taken.

> : Now, if we can draw on the expertise of millions of programmers
> : familiar with C++, why should that be wrong?
>
> That somewhat reminds me on countless OS wars. How can an OS be bad if
> there are millions using it?

Nope. What I'm talking about is, that any OO extension to Tcl is
either hybrid, or else a completely different language, incompatible
to Tcl and to any other language as well. Not that such a language
wouldn't be imaginable, not that it may not well be desirable, not
even that it wouldn't make sense to develop it, but it would have to
compete with all other languages around. And sometimes it is not
excellent design that wins, but simply the number of users. Sad but
true.

So if anyone feels the urgent need to produce something different than
what is already established, he probably should also spent some
thoughts on how to tell thousands of users why `::' is ugly as
namespace delimiter, and that this is the reason why they have to
forget what they have learned and what perfectly makes sense to them.

Remember Modula 2? A language so infinitly superior to C, but who uses
it today? Programs then written in Modula 2 are now legacy systems. Is
it really worth making the Tcl programs of today the legacy systems of
tomorrow, only to avoid any slight resemblance to C++?

This may seem hopelessly exaggerated, but what Tcl suffers of today is
it's tendency to split up into different dialects that need different
interpreters. Be assured, I like Itcl, and for me there will have to
be very good reasons before I change to another OO Tcl extension, even
if it is the one "officially" supported by the SUN group. It is a
little bit similar to what were my feelings when Richard Stallman felt
the need to tell us we should stop using Tcl, because the FSF would
produce something better soon. I don't know for sure, but I suspect,
not many Tcl developers have changed to Guile. Am I wrong?

I strongly suspect, many other people share my opinion. After all,
Itcl is quite stable, at least very much more stable than any new
extension could be for many month. And Itcl will always be a moving
target, so anyone implementing an alternative would have to spend a
lot of money to bridge the gap.

So if that holds true, and I really think it does, we have two
scenarios:

1) Itcl does not get SUN's support and is forced to keep on making
core modifications. Then it will probably fade away over the course
of time. But any alternative will have to fight a war for users,
and this will weaken Tcl's overall position.

Why? Simply because the most likely candidate for being supplier of
the alternative OO extension is SUN itself, as they are providing
the basis, the namespace facility. Not using Itcl's modifications
only makes sense if they at least lay the foundations for something
different. But that forces them to partially design this
alternative full-fledged OO extension. From then on it's only a
small step to implementing it. And, voila, we have two teams in
competition, with both their resources bound.

2) SUN and the Itcl crew cooperate. This will take load off the Itcl
developers, because they wont't have to track core modifications
any more. So they could spend their time producing more
megawidgets, better debug tools, etc. And remember, everything done
by them in terms of widgets would automatically be usable for users
of pure Tcl also. They simply would have to use `itkwish' or load
the Itcl package in `wish' to profit from the new widgets.

It would also take load off Dr. Ousterhout's team, and they could
invest the time won into e.g. making the byte compiler faster,
further improve portability, speeding up widgets, implementing more
widgets in the core, providing a truly portable drag'n'drop
facility, etc.

Wouldn't you agree that scenario #2 is more desirable than #1?

> : Michael McLennan has done a very good job in doing for Tcl the same as
> : Bjarne Stroustrup has done for C.
>
> Okay, this is the "killer sentence" that forced me to reply. I usually
> don't care what programming language folks are using to get their job

> done. But C++ is certainly the ugliest, most-bloated language I've

> ever came across. iTcl and Java are a lot better in this regard IMNSHO.

Well, I'd prefer mine being taken humble still :-)

Hmm, ..., have you really got the impression I am of a radically
different opinion? Sure, C++ is ugly, bloated, etc, but it was the
best one could do to C under the premise of strict compatibility. Do
you really think the success of C++, for any good it was, would have
been possible without offering a smooth upgrade path? Probably even
the rise of the object-oriented paradigm would not have taken place
the way it did, without a widely used language, supported especially
on the PC. Because that's where the masses are, that's where they
decide over our fate.

Again, I'm not to imply that I like it that way, but hey, that's how
it is. Welcome to reality.

Hume Smith

unread,

Feb 11, 1997, 3:00:00 AM2/11/97

to

> > But C++ is certainly the ugliest, most-bloated language I've ever
> > came across. iTcl and Java are a lot better in this regard IMNSHO.

> Since they all use the same :: notation I don't see any conflict.

there's more crap to C++ than just that :: thing.

did i ever tell you the story of how it took me two weeks and umpteen
redesigns to reimplement something in real OO style in C++, a year after
i'd done it out of my head in two hours in C? yup. vast improvement.
--
Hume Smith <URL:mailto:hcls...@tallships.istar.ca>
<URL:http://dess.tallships.istar.ca/%7Ehclsmith/>

Nat Pryce

unread,

Feb 13, 1997, 3:00:00 AM2/13/97

to

Michael J. McLennan <m...@mhcnet.lucent.com> wrote in article

> It's true that C++ and Tcl are different languages, but they have a
> lot in common. C++ has procedures, and Tcl has procedures. C++ uses
> {}'s for code bodies, and Tcl uses {}'s for code bodies. C++ has commands
> like "if", "for", "while", "switch", and Tcl has these same commands.

Ok, they have similar syntax, but the underlying principles and
capabilities are quite different and this influences the way one
uses the language. The code I write in Tcl -- dynamic, reflective
and relying on meta-programming features -- is very different from
that which I write in C++ -- statically typed with roles and
interactions defined in terms of abstract interfaces.

> Its true that namespaces encapsulate variables and commands, so they
> have both state and behavior. They can be used to build object systems,
> but they are not really "objects" themselves.
>
> Namespaces can contain objects. With an extension like [incr Tcl],
> for example, you can create a Toaster named "fred" in one namespace,
> and a Toaster named "fred" in another namespace. Each namespace has
> its own private "fred" object.

I fail to see what the difference would be between a Tcl namespace and
an object. Namespaces provide procs which manipulate variables in their
scope and objects provide methods which manipulate their fields. I
think it is a difference of terminology not of semantics. Namespaces
won't be class-based, but I think that for a language like Tcl, a
prototype-based object-system is more convenient and classes can be
defined in terms of prototypical objects if they are needed. There
was a paper presented at OOPSLA'95 by some guys from Apple, based on
experience with the Newton's development environment, which argued
(very persuasively I think), that a prototype-based object-system
is better suited to the development of GUI programs than a class-
based system. I'll dig out the reference if anyone's interested.

Objects can also contain objects in the same way that namespaces can
contain objects. Are you saying that Tcl will not support nested
namespaces? Is there any documentation available describing what
Tcl's namespace mechanism will be like?

<snip>

> Commands like "string" and "info" are not really namespace-like. They
> are ordinary Tcl commands with multiple argument words that control
> their actions. I call this kind of command an "ensemble" command.
> There will be a separate mechanism for defining and extending ensembles.

I disagree here. I think that an "ensemble" command is a form of namespace.
The "string" command is designed that way to avoid polluting the global
namespace with lots of commands to perform different string-processing
operations. This is exactly what namespaces are for.

Cheers,
Nat.

Andreas Manessinger

unread,

Feb 14, 1997, 3:00:00 AM2/14/97

to

"Nat Pryce" <n...@doc.ic.ac.uk> writes:

> Michael J. McLennan <m...@mhcnet.lucent.com> wrote in article
> > It's true that C++ and Tcl are different languages, but they have a
> > lot in common. C++ has procedures, and Tcl has procedures. C++ uses
> > {}'s for code bodies, and Tcl uses {}'s for code bodies. C++ has commands
> > like "if", "for", "while", "switch", and Tcl has these same commands.
>
> Ok, they have similar syntax, but the underlying principles and
> capabilities are quite different and this influences the way one
> uses the language. The code I write in Tcl -- dynamic, reflective
> and relying on meta-programming features -- is very different from
> that which I write in C++ -- statically typed with roles and
> interactions defined in terms of abstract interfaces.

Sure, correct. But that does not mean that, using a C++-like OO
extension like [incr tcl], you can't write dynamic, reflective
programs relying on meta-programming features.

The big PLUS is, that you also can easily take a C++ design from one
of the countless C++ books, and with minimum effort port it to
Itcl. Given that not only C++ books provide their examples in C++, but
also many modern books about OO design do so (Booch, 94), this enables
new users of the language to draw on the collected experience laid
down in literature.

And it is not only the books about design. Having reached a project
phase when languages really begin to matter, the recent books about
design patterns (Gamma, 94; Coplien, 95) are of even more
assistance. You take the C++ classes from there, and simply translate
them to Itcl. For class definitions this can be done almost
mechanically.

Still, using Itcl you can do it either way, all by yourself in any
style you like, or exploiting other folk's C++ patterns. I
certainly prefer having the choice.

> I fail to see what the difference would be between a Tcl namespace and
> an object. Namespaces provide procs which manipulate variables in their
> scope and objects provide methods which manipulate their fields. I
> think it is a difference of terminology not of semantics.

Namespaces, as Michael McLennan uses the term, are bigger entities
(and more costly on implementation side) than objects. Sure, an object
could also be thought of as a "namespace", but in big projects you
will have so many objects that you quickly feel the need for a coarser
means of structuring. So Itcl's namespaces are to be seen on a level
not with objects, but with subsystems. And this certainly assists in
multi-programmer projects. This is nothing that can't be done with
nested classes, but having different terminology is something that has
proven handy. See the literature on OO design. There, classes
correspond more to application domain entities, and subsystems are
loose artifacts of the structuring process during design.

The following is an excerpt from `Jacobson, 92; "Object-Oriented
Software Engineering"', pp 195f in the revised fourth printing:

"When the analysis objects have been identified, the system will
contain a large number of objects. For a medium-sized project,
typically between 30 and 100 objects will be specified. It is seldom
possible to get a clear overview of this number of objects, so the
objects need to be placed in groups. This can be done at one or
several levels depending on the size of the system. Such groups are
called *subsystems*. The system thus consists of a number of
subsystems which can themselves contain subsystems. At the bottom of
such a hierarchy are the analysis objects. Subsystems are thus a way
of structuring the system for further development and maintenance."

Itcl's namespaces are a means for the construction of subsystems.

> ... There

> was a paper presented at OOPSLA'95 by some guys from Apple, based on
> experience with the Newton's development environment, which argued
> (very persuasively I think), that a prototype-based object-system
> is better suited to the development of GUI programs than a class-
> based system. I'll dig out the reference if anyone's interested.

Yes, please :-)

> Objects can also contain objects in the same way that namespaces can
> contain objects. Are you saying that Tcl will not support nested
> namespaces? Is there any documentation available describing what
> Tcl's namespace mechanism will be like?

This is still in flux. I guess this very discussion is part of the
requirements gathering process. But there is a well-written tutorial
on Itcl, containing a discussion of Itcl's concept of namespaces. You
find it on

http://www.tcltk.com/itcl/

In Itcl, classes and namespaces can contain each other to any depth.

> ... I think that an "ensemble" command is a form of namespace.

> The "string" command is designed that way to avoid polluting the global
> namespace with lots of commands to perform different string-processing
> operations. This is exactly what namespaces are for.

See the above comments about namespaces and subsystems.

Frederic BONNET

unread,

Feb 14, 1997, 3:00:00 AM2/14/97

to

Hi folks,

Bruce Stephens wrote:
>
> >>>>> "Michael" == Michael Schumacher <mi...@hightec.saarlink.de> writes:
>

> > But C++ is certainly the ugliest, most-bloated language I've ever
> > came across.

I agree. C++ really sucks, and is close to being unreadable. The fact
that millions of people use it doesn't make its syntax (including the
dreaded ::) more appealing to me. One billion flies can't be wrong:
let's eat shit ;-)
As for me, I prefer Tcl/Smalltalk/ObjectiveC syntax style
(space-separated).

> > iTcl and Java are a lot better in this regard IMNSHO.
>

> Since they all use the same :: notation (don't they? I sometimes feel
> I'm the only human that doesn't know Java, but since it was designed

> to look somewhat like C++, presumably it uses ::), I don't see any
> conflict.

No they fortunately don't, Java uses a IMHO more readable period as a
"namespace" separator. Hopefully, people who designed Java threw away
all this kind of crap from C+ ;-)

And C++ also uses periods. The :: operator is only used to designate
(usually static) class members, whereas the period is used for object
members. Java uses the period for both.
In C++, objects and classes are both namespaces, but use 2 different
notations, so I don't see why Tcl should use the ugliest. Let's use the
period, as other OOL do (Eiffel, Java, VisualBasic, etc...). I think
there are more people using the period notation than the :: operator.

Why can't we use the period as a namespace separator? I understand that
the space is problematic in some case, but the only argument against the
period is that Tk uses it. So what? After all, Tk widgets are commands.
Tk container widgets can also be considered as namespaces, since they
contain subwidgets.

Chosing the period notation is IMHO a great opportunity to introduce
namespaces in Tcl and to turn Tk widgets into namespaces, thus allowing
easy creation of mega-widgets. I do think that Tk widgets are namespaces
since they encapsulate values (config options) and behaviors (widget
subcommands).
Let's consider that namespaces (period separated) and ensembles (space
separated) are 2 distincts things that serve different purposes. Why
can't a Tcl entity be a namespace _and_ an ensemble at the same time?
This is the case for widgets (namespace paradigm for widget hierarchy,
and ensemble paradigm for subcommands). Tk widgets are namespaces,
subwidgets are nested namespaces, widgets options are protected
namespace variables, and widget commands are ensembles.

Let me know what you think of this proposal.

See you, Fred
--
Frederic BONNET fbo...@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Il ne faut jamais remettre au lendemain ce
$env(HOME) without it! | qu'on peut faire le surlendemain" (Oscar WILDE)

Larry W. Virden

unread,

Feb 14, 1997, 3:00:00 AM2/14/97

to

According to Michael Schumacher <mi...@hightec.saarlink.de>:
:That somewhat reminds me on countless OS wars. How can an OS be bad if

:there are millions using it?

How can certain foods be bad for you if there are millions eating them?

The same way anything can happen when there are lots of people doing something
- they are wrong. Period.

I am not saying that is true in the case of C++ - I don't care to argue
over it. I don't use C++ so I don't care if it's a good or bad language.

But just because something is done by a lot of people doesn't make it
automatically right.
--
Larry W. Virden INET: lvi...@cas.org
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.

Nat Pryce

unread,

Feb 14, 1997, 3:00:00 AM2/14/97

to

Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote in article

[on the subject of the double-colon namespace notation]

> The big PLUS is, that you also can easily take a C++ design from one
> of the countless C++ books, and with minimum effort port it to
> Itcl. Given that not only C++ books provide their examples in C++, but
> also many modern books about OO design do so (Booch, 94), this enables
> new users of the language to draw on the collected experience laid
> down in literature.
>
> And it is not only the books about design. Having reached a project
> phase when languages really begin to matter, the recent books about
> design patterns (Gamma, 94; Coplien, 95) are of even more
> assistance. You take the C++ classes from there, and simply translate
> them to Itcl. For class definitions this can be done almost
> mechanically.
>

You have exactly illustrated my main objection to the double-colon
namespace separator: because of the similar syntax ones intuition
tells one that the language is the same. However, a design which is
efficient for C++ is not necessarily efficient in Tcl, because of the
huge differences in the way one uses the two languages.

For example, many of the patterns in the Gamma book are pointless
in Tcl because of the way a Tcl program can create scripts and
then treat them as data, passing them as configuration options to
widgets, binding them to events or passing them as parameters to
procs. This means that patterns such as Factory, Bridge, Adaptor
and many others are not needed. Coplien's idioms are even more
language-specific, as their name implies.

Of course, there are obviously a number of useful Tcl idioms/patterns.
Perhaps we should collect them on the comp.lang.tcl newsgroup...

> > I fail to see what the difference would be between a Tcl namespace and
> > an object. Namespaces provide procs which manipulate variables in their
> > scope and objects provide methods which manipulate their fields. I
> > think it is a difference of terminology not of semantics.
>
> Namespaces, as Michael McLennan uses the term, are bigger entities
> (and more costly on implementation side) than objects. Sure, an object
> could also be thought of as a "namespace", but in big projects you
> will have so many objects that you quickly feel the need for a coarser
> means of structuring. So Itcl's namespaces are to be seen on a level
> not with objects, but with subsystems.

> Itcl's namespaces are a means for the construction of subsystems.

Why is a namespace more costly in implementation? If an object is
a namespace with extra functionality, surely an object is more
costly. I haven't poked through the implementation so I'd appreciate
some enlightenment...

Anyway, with a flexible mechanism for namespaces or objects (or whatever
one wants to call them) it should be possible to use the basic mechanism
to define the concept of namespace, object, class, meta-class, "ensemble
command", and other things that I haven't thought of but other
programmers will. I think that such an approach would be in keeping
with the style of the Tcl language and the way it has been used in
the past.

> > > ... There
> > was a paper presented at OOPSLA'95 by some guys from Apple, based on
> > experience with the Newton's development environment, which argued
> > (very persuasively I think), that a prototype-based object-system
> > is better suited to the development of GUI programs than a class-
> > based system. I'll dig out the reference if anyone's interested.
>
> Yes, please :-)

Here it is. I don't know if it is available on the Web. You'd have
to search Apple's site.

Title: Using a Prototype-based Language for User Interface:
The Newton Project's Experience
Author: Walter R. Smith
Published: In proceedings of the OOPSLA'95,
(Austin TX, USA, October 15-19 1195),
ACM, New York, 1995, pp. 23-35.

Nir Levy

unread,

Feb 16, 1997, 3:00:00 AM2/16/97

to

hi.
Someone once told me:

"Million flys can't be wrong: eat shit !"

Just an after-thought ... :)

Nir.

lw...@cas.org (Larry W. Virden) gracfully told us:
->
->According to Michael Schumacher <mi...@hightec.saarlink.de>:
->:That somewhat reminds me on countless OS wars. How can an OS be bad if
->:there are millions using it?
->
->How can certain foods be bad for you if there are millions eating them?
->
->The same way anything can happen when there are lots of people doing something
->- they are wrong. Period.
->
->I am not saying that is true in the case of C++ - I don't care to argue
->over it. I don't use C++ so I don't care if it's a good or bad language.
->
->But just because something is done by a lot of people doesn't make it
->automatically right.
->--
->Larry W. Virden INET: lvi...@cas.org
-><URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
->Unless explicitly stated to the contrary, nothing in this posting should
->be construed as representing my employer's opinions.

Andreas Manessinger

unread,

Feb 16, 1997, 3:00:00 AM2/16/97

to

"Nat Pryce" <n...@doc.ic.ac.uk> writes:

>
> Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote in article
>
> [on the subject of the double-colon namespace notation]
>

> You have exactly illustrated my main objection to the double-colon
> namespace separator: because of the similar syntax ones intuition
> tells one that the language is the same. However, a design which is
> efficient for C++ is not necessarily efficient in Tcl, because of the
> huge differences in the way one uses the two languages.
>
> For example, many of the patterns in the Gamma book are pointless
> in Tcl because of the way a Tcl program can create scripts and
> then treat them as data, passing them as configuration options to
> widgets, binding them to events or passing them as parameters to
> procs. This means that patterns such as Factory, Bridge, Adaptor
> and many others are not needed. Coplien's idioms are even more
> language-specific, as their name implies.

Sure, some patterns are tied to C++, this is obvious and therefore we
won't use them in, say, an OO extension to Tcl. Others are not. Indeed
most of them are not. They are mainly about hiding implementational
details from a class's users, about isolating subsystems from each
other, and about making parts of a program changable without letting
these changes ripple through the whole program.

Speaking of [Gamma, 94], have a look at the patterns `Composite',
`Facade', `Command', and `Observer', to mention only some of them, and
you will see my point. They are useful in any language, even in non-oo.

With Coplien's book I didn't mean "Advanced C++ Programming Styles and
Idioms", but his recent "Pattern Languages of Program Design", a
colletion of papers presented at the First Annual Conference of
Pattern Languages of Programs (PLoP) in August 1994. There is a second
volume covering the 1995 conference (I think) now.

> Of course, there are obviously a number of useful Tcl idioms/patterns.
> Perhaps we should collect them on the comp.lang.tcl newsgroup...

Fine idea. I'd certainly volunteer to collect them and set up a WWW
page. So go on everybody and post what you have, use `IDIOM' or
`PATTERN' in the subject line, we'll discuss them in the newsgroup,
and again, I could set up a page for the results. This would
definitely be something for the whole community to profit from.

> Why is a namespace more costly in implementation? If an object is
> a namespace with extra functionality, surely an object is more
> costly. I haven't poked through the implementation so I'd appreciate
> some enlightenment...

Itcl's are. This has something to do with protection, I guess. But
Michael McLennan will have a full explanation.

> Anyway, with a flexible mechanism for namespaces or objects (or whatever
> one wants to call them) it should be possible to use the basic mechanism
> to define the concept of namespace, object, class, meta-class, "ensemble
> command", and other things that I haven't thought of but other
> programmers will. I think that such an approach would be in keeping
> with the style of the Tcl language and the way it has been used in
> the past.

Granted. My point was, that the concept of namespaces as used in C++
and Itcl means encapsulation on a higher level as that of
objects. We're talking big projects and especially libraries here.

> Here it is. I don't know if it is available on the Web. You'd have
> to search Apple's site.
>
> Title: Using a Prototype-based Language for User Interface:
> The Newton Project's Experience
> Author: Walter R. Smith
> Published: In proceedings of the OOPSLA'95,
> (Austin TX, USA, October 15-19 1195),
> ACM, New York, 1995, pp. 23-35.

Thanks

Andreas Manessinger

unread,

Feb 16, 1997, 3:00:00 AM2/16/97

to

Frederic BONNET <fbo...@irisa.fr> writes:

> I agree. C++ really sucks, and is close to being unreadable. The fact
> that millions of people use it doesn't make its syntax (including the
> dreaded ::) more appealing to me. One billion flies can't be wrong:
> let's eat shit ;-)
> As for me, I prefer Tcl/Smalltalk/ObjectiveC syntax style
> (space-separated).
>

> ...

>
> No they fortunately don't, Java uses a IMHO more readable period as a
> "namespace" separator. Hopefully, people who designed Java threw away
> all this kind of crap from C+ ;-)

A lot of hate in there, hmm?

> Why can't we use the period as a namespace separator? I understand that
> the space is problematic in some case, but the only argument against the
> period is that Tk uses it. So what? After all, Tk widgets are commands.
> Tk container widgets can also be considered as namespaces, since they
> contain subwidgets.

Sure, they can, but this misses what the concept of namespaces really
is about. They are a means of encapsulating names of variables,
procedures, objects, and classes, to make the implementation of
subsystems easier, especially in the context of library building. This
is encapsulation at a bigger scope.

Of course, you can use `namespace' for anything you like, but that's
the way the word is used throughout the literature, and we'd better
stick to it unless we have a very good reason. Otherwise we'd soon
find us talking about different things without recognizing it :-)

> Let's consider that namespaces (period separated) and ensembles (space
> separated) are 2 distincts things that serve different purposes. Why
> can't a Tcl entity be a namespace _and_ an ensemble at the same time?
> This is the case for widgets (namespace paradigm for widget hierarchy,
> and ensemble paradigm for subcommands). Tk widgets are namespaces,
> subwidgets are nested namespaces, widgets options are protected
> namespace variables, and widget commands are ensembles.
>
> Let me know what you think of this proposal.

I don't like it for the reasons mentioned above. I also don't think
that this is what J.O. meant, when he promised an implementation of
namespaces for Tcl.

Frederic BONNET

unread,

Feb 17, 1997, 3:00:00 AM2/17/97

to

Hi Andreas,

Andreas Manessinger wrote:
> Frederic BONNET <fbo...@irisa.fr> writes:
[C++ bashing deleted ;-)]

>
> A lot of hate in there, hmm?

True. After so many years using C++, I've learnt to hate it as much as I
hate Windows and other bad products I'm obliged to use because everybody
does. If I had the choice I'd get Linux (with Tcl/Tk on it of course ;-)
and Smalltalk/ObjectiveC/whatever.

But anyway...

> > Why can't we use the period as a namespace separator? I understand that
> > the space is problematic in some case, but the only argument against the
> > period is that Tk uses it. So what? After all, Tk widgets are commands.
> > Tk container widgets can also be considered as namespaces, since they
> > contain subwidgets.
>
> Sure, they can, but this misses what the concept of namespaces really
> is about. They are a means of encapsulating names of variables,
> procedures, objects, and classes, to make the implementation of
> subsystems easier, especially in the context of library building. This
> is encapsulation at a bigger scope.

Yep. And Tk megawidgets are an application of namespaces, but namespaces
are of course not restricted to that. I don't think I miss the concept
of namespaces. And I don't see anything contradictory between both
sentences. Because Tk widgets also encapsulates variables, procedures,
etc.

> Of course, you can use `namespace' for anything you like, but that's
> the way the word is used throughout the literature, and we'd better
> stick to it unless we have a very good reason. Otherwise we'd soon
> find us talking about different things without recognizing it :-)

Again, I'm only talking about an _application_ of namespaces. I
understand what namespaces are, something similar to objects in
prototype-based OOLs. Since Tk's philosophy is very close to prototypes,
you see my point.

> > Let's consider that namespaces (period separated) and ensembles (space
> > separated) are 2 distincts things that serve different purposes. Why
> > can't a Tcl entity be a namespace _and_ an ensemble at the same time?
> > This is the case for widgets (namespace paradigm for widget hierarchy,
> > and ensemble paradigm for subcommands). Tk widgets are namespaces,
> > subwidgets are nested namespaces, widgets options are protected
> > namespace variables, and widget commands are ensembles.
>

> I don't like it for the reasons mentioned above. I also don't think
> that this is what J.O. meant, when he promised an implementation of
> namespaces for Tcl.

Well, maybe it's not the best idea I've ever had ;-) But it was only a
suggestion. The important point in my message was about using the
period as a namespace separator. If we choose to use it, then Tk could
(should?) use this new feature (namespaces) in a very powerful way. But
I understand this is not the only (and best) way to use namespaces for
extending and improving Tk.

Just to bring the debate back to namespaces notation (I tried
to sum up many arguments from different people):

Can someone complete/comment this table?

Frederic BONNET

unread,

Feb 17, 1997, 3:00:00 AM2/17/97

to

Hi Michael,

Michael Schumacher wrote:
> C++ is a static language, so it's not possible to have
> "anonymous objects" at runtime. Objective-C supports this feature nicely.

Yes you can, C++ uses temporary objects in many cases. For example:

//----------------------------//
#include <iostream.h>

class Point {
int _x, _y;
public:
Point(int x, int y) : _x(x), _y(y) {};
void print() {cout << _x << "@" << _y << endl;};
};

void DoSomething(Point p) {p.print();};

int main(int, char**) {
DoSomething(Point(0,0));
return 0;
}
//----------------------------//

the result of Point(0,0) is a temporary, anonymous object.

Donal K. Fellows

unread,

Feb 17, 1997, 3:00:00 AM2/17/97

to

In article <x0bu9no...@imrryr.adv.magwien.gv.at>,

Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote:
> "Nat Pryce" <n...@doc.ic.ac.uk> writes:
>> Michael J. McLennan <m...@mhcnet.lucent.com> wrote in article
>>> It's true that C++ and Tcl are different languages, but they have a
>>> lot in common. C++ has procedures, and Tcl has procedures. C++ uses
>>> {}'s for code bodies, and Tcl uses {}'s for code bodies. C++ has commands
>>> like "if", "for", "while", "switch", and Tcl has these same commands.
>>
>> Ok, they have similar syntax, but the underlying principles and
>> capabilities are quite different and this influences the way one
>> uses the language. The code I write in Tcl -- dynamic, reflective
>> and relying on meta-programming features -- is very different from
>> that which I write in C++ -- statically typed with roles and
>> interactions defined in terms of abstract interfaces.
>
> Sure, correct. But that does not mean that, using a C++-like OO
> extension like [incr tcl], you can't write dynamic, reflective
> programs relying on meta-programming features.
>
> The big PLUS is, that you also can easily take a C++ design from one
> of the countless C++ books, and with minimum effort port it to
> Itcl. Given that not only C++ books provide their examples in C++, but
> also many modern books about OO design do so (Booch, 94), this enables
> new users of the language to draw on the collected experience laid
> down in literature.

[ ... ]

> Still, using Itcl you can do it either way, all by yourself in any
> style you like, or exploiting other folk's C++ patterns. I
> certainly prefer having the choice.

Just because one extension uses a particular syntax does not mean that
that particular syntax should be in the core. Indeed, there are
powerful reasons for _not_ putting that syntax in the core, since it
can otherwise lead to subtle semantic bugs which you would have to be
a Tcl wizard to hunt down in any reasonable amount of time. Better to
have something that is explicitly different which then is less likely
to clash in unexpected ways. (I have the `scars' to prove this... :^)

_Syntactic_ compatability is no real good unless you have _semantic_
compatability, something that is not always sensible (and this is one
of those non-sensible cases IMHO)

>> I fail to see what the difference would be between a Tcl namespace and
>> an object. Namespaces provide procs which manipulate variables in their
>> scope and objects provide methods which manipulate their fields. I
>> think it is a difference of terminology not of semantics.
>
> Namespaces, as Michael McLennan uses the term, are bigger entities
> (and more costly on implementation side) than objects. Sure, an object
> could also be thought of as a "namespace", but in big projects you
> will have so many objects that you quickly feel the need for a coarser
> means of structuring. So Itcl's namespaces are to be seen on a level
> not with objects, but with subsystems. And this certainly assists in
> multi-programmer projects. This is nothing that can't be done with
> nested classes, but having different terminology is something that has
> proven handy. See the literature on OO design. There, classes
> correspond more to application domain entities, and subsystems are
> loose artifacts of the structuring process during design.

There you go again - using a particular implementation to mould your
ideas of what a different implementation should be. This is wrong
unless you can demonstrate that the problem is common to both, and I
don't think that this is the case here.

If the implementation of namespaces was much cheaper than MM's current
version, would it be right to use [incr tcl]'s or Itcl's current
partitioning of the OO paradigm?

Oh, and if you want a more restrictive interface in core Tcl, then
you'll have to argue very hard to get it, as it is likely to make life
much harder for extension writers. I much prefer having something
basic from which more sophisticated things can be built, and a way of
having a namespace as a first-class object* would do just that, with
objects and classes as conventions over that.

Donal.

* Note that I'm using object in a different sense here, as in
first-class objects are things that I can store in ordinary
variables. In Tcl7.6, only strings are first-class objects.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) fell...@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| do...@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+

Andreas Manessinger

unread,

Feb 17, 1997, 3:00:00 AM2/17/97

to

First for all novices to this thread:

This is still about whether using `::' or something else as namespace
delimiter. As a user of [incr tcl] I argued that when we get
namespaces in the core, they should be implemented like Itcl's, just to
keep them compatible. And concerning Itcl, I said that it's similarity
to C++ makes it very easy to take object-oriented patterns from books
like [Gamma, 94; "Design Patterns"], and to almost mechanically
transfer them to Itcl. My impression is, that this helps many new
users learning the language. After all, C++ is by far the most used OO
programming language (though many of you guys seem to prefer to deny
it's object-orientedness and probably it's being a programming
language as well :-)

fell...@cs.man.ac.uk (Donal K. Fellows) writes:

> Just because one extension uses a particular syntax does not mean that
> that particular syntax should be in the core. Indeed, there are
> powerful reasons for _not_ putting that syntax in the core, since it
> can otherwise lead to subtle semantic bugs which you would have to be
> a Tcl wizard to hunt down in any reasonable amount of time. Better to
> have something that is explicitly different which then is less likely
> to clash in unexpected ways. (I have the `scars' to prove this... :^)

OK, give me an example, please. Itcl *has* the syntax, I use it quite
often, and am very pleased with it's ease of use and it's
clarity. Probably one could object to it's speed, but I fail to see
where it's conceptual problems are.

But, back to the quote above, why should it make a difference if we
have `::' as namespace delimiter or `.', `:', `@',
`_NAMESPACE_DELIMITER_', or whatever you like? Sure, it should be
something short, and it should be something that normally isn't used
in identifiers.

I admit I *have* seen `::' as part of procedure names in some people's
sources. But is there anything that you'd consider safe?

Tcl as it stands can use everything as name of a variable or a
procedure. Say we have ` ' as namespace delimiter. Then how do we
handle something like:

bash % tclsh
% set "x x" 1
1
% echo ${x x}
1
% proc "s s" {} {
puts [info level 0]
}
% "s s"
{s s}
%

This is perfectly possible in Tcl. Of course we could argue that
nobody will use names containing spaces. But do we know? And probably
these names would have been synthesized from user input. Use ' ' as
namespace delimiter, and a program like the one above probably breaks
with subtle semantic bugs which you would have to be a Tcl wizard to

hunt down in any reasonable amount of time.

So, please show me your scars and tell me: What are your powerful
reasons for _not_ putting the `::' syntax into the core?

> _Syntactic_ compatability is no real good unless you have _semantic_
> compatability, something that is not always sensible (and this is one
> of those non-sensible cases IMHO)

Tell me more about YHO, I can't see the point.

> > Namespaces, as Michael McLennan uses the term, are bigger entities
> > (and more costly on implementation side) than objects. Sure, an object
> > could also be thought of as a "namespace", but in big projects you
> > will have so many objects that you quickly feel the need for a coarser
> > means of structuring. So Itcl's namespaces are to be seen on a level
> > not with objects, but with subsystems. And this certainly assists in
> > multi-programmer projects. This is nothing that can't be done with
> > nested classes, but having different terminology is something that has
> > proven handy. See the literature on OO design. There, classes
> > correspond more to application domain entities, and subsystems are
> > loose artifacts of the structuring process during design.
>
> There you go again - using a particular implementation to mould your
> ideas of what a different implementation should be. This is wrong
> unless you can demonstrate that the problem is common to both, and I
> don't think that this is the case here.

No, I don't take Itcl's namespaces as model for my concept of
namespaces. I simply argue that namespaces as implemented in Itcl are
very close to what is generally understood under the term
"namespace". They are a means of partitioning the space of
user-defined names in a program, thereby allowing the easier
implementation of libraries and subsystems. If you prefer that, use
"module" or "package" for what in Itcl and C++ is called a
namespace. Do you think JO meant something different when he promised
us namespaces in the core?

> If the implementation of namespaces was much cheaper than MM's current
> version, would it be right to use [incr tcl]'s or Itcl's current
> partitioning of the OO paradigm?

What do you mean by "would it be right"? Would it be wrong? I can't
imagine that the efficiency of an implementation depends on the token
being used, as long as it is short enough. Or do you mean semantics?
If yes, what would be your proposal for the semantics of namespaces in
Tcl?

> Oh, and if you want a more restrictive interface in core Tcl, then
> you'll have to argue very hard to get it, as it is likely to make life
> much harder for extension writers. I much prefer having something
> basic from which more sophisticated things can be built, and a way of
> having a namespace as a first-class object* would do just that, with
> objects and classes as conventions over that.

More restrictive than what? Please clarify your concepts. Obviously
you compare Itcl's implementation of namespaces, but to what? Have I
missed something?

Are Itcl's namespaces what you call "restrictive"? And why exactly are
they likely to make life much harder for extension writers? Tell me
more about that.

...

Hmm, there is so much emotion in this discussion! Probably we all
should calm down :-)

Believe me, I don't really care about how namespaces are implemented
in Tcl, as long as they enable Itcl to become a "normal" loadable
extension, i.e. without having to patch the core. That's all.

If this is possible with a namespace facility that presents itself
differently to Tcl and Itcl, then only users of Tcl loose the ability
to change to `itkwish' and have all of Itcl's megawidgets at hand. I
can live with that, and obviously you too can.

If the SUN group decides against providing Itcl what it needs from the
core, then this would make Itcl fade away in the long term, because
other people (probably SUN itself) would come up with a different OO
extension that would be easier to install and maintain. But this would
take a long while, and in the meantime we would have to live with an
enormous waste of manpower.

Do you think the question of `::' vs. `.' (or whatever you prefer)
is really worth it?

Don't forget, compared to e.g. Visual Basic, Tcl is an orchid
language, and the more we endulge in particularism, the more Tcl
itself is endangered. But this again is the old UNIX desease, we split
our powers, and soon we find ourselves writing programs for something
like Windows NT.

A somewhat tired

Jan Nijtmans

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Andreas Manessinger wrote:
> Tcl as it stands can use everything as name of a variable or a
> procedure. Say we have ` ' as namespace delimiter. Then how do we
> handle something like:
>
> bash % tclsh
> % set "x x" 1
> 1
> % echo ${x x}
> 1
> % proc "s s" {} {
> puts [info level 0]
> }
> % "s s"
> {s s}
> %

how about:

bash % tclsh
% set "{x x}" 1
1

% echo [set {{x x}}]

1
% proc "s s" {} {
puts [info level 0]
}
% {s s}
{s s}
%

So, if you want to use spaces in names, just use {} to make
sure that it is a proper list element. B.T.W. The above code
runs in Tcl 7.x as well :-). The proc command should not
be changed in syntax because we can always define procs in
another namespace by using the "namespace" command.
We already have seen the problem of using "::", when TIX was
forced to change the syntax to use ":" as delemiter. With spaces
this is much less likely to happen.

It would be nicer for the second line to read:
echo ${{x x}}
only that doesn't work in tcl7.x because the first '}' is
parsed as the end of the variable name.

It cannot be prevented that existing code breaks, no matter
whether the choice will be made for "::", "." or " ". Still
my vote would be to use the space.

Jan Nijtmans
NICI (Nijmegen Institute of Congnition and Information)

Michael Schumacher

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Frederic BONNET <fbo...@irisa.fr> wrote:

: Michael Schumacher wrote:
: > C++ is a static language, so it's not possible to have
: > "anonymous objects" at runtime. Objective-C supports this feature nicely.

: Yes you can, C++ uses temporary objects in many cases. For example:

[del]

Nay, that's not what I meant, but it's off topic here in clt to explain the
difference between ObjC's runtime system and C++'s lack thereof. ;-) It's
basically that "Smalltalk vs. Simula" thing. Just one point: ObjC's runtime
environment is based on strings and hash tables, such that objects/classes
and methods can be looked up at runtime. Sounds familiar? That's because this
is pretty much the same mechanism Tcl uses to look up procs/builtin-commands.
And for the best part, ObjC invokes methods using the "[...]" construct,
which is darn similar to Tcl's command substitution.

Here are my opinions on Tcl and namespaces:

- Tcl certainly needs a way to represent namespaces, as more and
more folks try to write even complex applications exclusively in
Tcl/Tk (plus maybe some well-known extensions); while doable,
this is pretty painful and error-prone (there's not even a
warning message if you redefine a global variable or proc/command,
and there's not even a point in issueing a warning in these cases
as they're perfectly legal). Another good reason for having
namespaces is the huge amount of code written in Tcl, which
sooner or later leads to what is called "namespace pollution"

- Tcl's new namespaces should not break existing Tcl applications,
but it's okay IMHO to break non-standard Tcl code; e.g., nobody
complained that Tcl's "clock" command wasn't 100% compatible with
TclX's "convertclock"/"fmtclock", or that Tk's "grid" is a bit
different from BLT's "table", or that Tcl's "socket" command didn't
match the TclX/DP/RPC counterparts a.s.o.; the big point is that
when something makes its way into the Tcl core, it's going to be
standard and is likely to be maintained for a very long time

- iTcl's syntactical rules (derived from C++) break vanilla Tcl:
proc hey::buddy { args } {
puts $args
}
hey::buddy can you diggit?

- Tcl's syntax and runtime behaviour comes pretty close to that of
Smalltalk/ObjC, so why not following that direction? I like John's
proposal of introducing an "access method", as it's unlikely to
break existing code and nevertheless offers full access to
namespaces while being fully compatible with Tcl's current syntax
and semantics

I'm convinced that John and his team will - as always - come up with a
clever solution the majority of Tcl users can happily live with.

mike

Andreas Manessinger

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

mi...@hightec.saarlink.de (Michael Schumacher) writes:

> - iTcl's syntactical rules (derived from C++) break vanilla Tcl:
> proc hey::buddy { args } {
> puts $args
> }
> hey::buddy can you diggit?

This may seem naive, but: why?

bash % itclsh2.2
% proc hey::buddy { args } {
puts $args
}
% hey::buddy can you diggit?
can you diggit?
% exit

bash % tclsh7.6
% proc hey::buddy { args } {
puts $args
}
% hey::buddy can you diggit?
can you diggit?
% exit
bash %

Where is the difference? Or do you think there should be one? Sorry,
but this slightly confuses me.

Michael Schumacher

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote:
: mi...@hightec.saarlink.de (Michael Schumacher) writes:

: > - iTcl's syntactical rules (derived from C++) break vanilla Tcl:
: > proc hey::buddy { args } {
: > puts $args
: > }
: > hey::buddy can you diggit?

: This may seem naive, but: why?

If Tcl would introduce "::" as a namespace separator, would the above
procedure still continue to work as it does now? That's a question we
can't answer until we know how the new mechanism is supposed to work.

mike

Andreas Manessinger

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Hmm, now I find myself following up to my own article :-)

> Jan Nijtmans <nijt...@nici.kun.nl> writes:
>
> > We already have seen the problem of using "::", when TIX was
> > forced to change the syntax to use ":" as delemiter. With spaces
> > this is much less likely to happen.
>

> I admit I seem to have missed that. Why did they have to do the
> change? I would have thought it was, to be compatible with Itcl.

Just as I thought it. This is from `Tix4.1.0/docs/Changes.html':

Incompatibility: All the "::" qualifiers in Tix class methods
have been replaced by ":", so that the Tix classes can be
loaded into Itcl without patching Itcl. If you have written
your own Tix classes, you need to modify the source files to
use the ":" qualifier instead.

So Tix changed for the benefits of compatibility with Itcl, and if
Itcl would have used spaces, then Tix would have changed to that. But
this leaves the "::" delimiter untainted, doesn't it?

Frederic BONNET

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Hi Michael,

Michael Schumacher wrote:
>
> Frederic BONNET <fbo...@irisa.fr> wrote:
[...]

> > C++ uses temporary objects in many cases. For example:
> [del]
>
> Nay, that's not what I meant, but it's off topic here in clt to explain the
> difference between ObjC's runtime system and C++'s lack thereof. ;-) It's
> basically that "Smalltalk vs. Simula" thing. Just one point: ObjC's runtime
> environment is based on strings and hash tables, such that objects/classes
> and methods can be looked up at runtime. Sounds familiar? That's because this
> is pretty much the same mechanism Tcl uses to look up procs/builtin-commands.
> And for the best part, ObjC invokes methods using the "[...]" construct,
> which is darn similar to Tcl's command substitution.

Ok, I see your point now.

> Here are my opinions on Tcl and namespaces:
>
> - Tcl certainly needs a way to represent namespaces, as more and
> more folks try to write even complex applications exclusively in
> Tcl/Tk (plus maybe some well-known extensions); while doable,

[...]

I think everybody agrees on that point.

>
> - Tcl's new namespaces should not break existing Tcl applications,
> but it's okay IMHO to break non-standard Tcl code; e.g., nobody
> complained that Tcl's "clock" command wasn't 100% compatible with
> TclX's "convertclock"/"fmtclock", or that Tk's "grid" is a bit
> different from BLT's "table", or that Tcl's "socket" command didn't
> match the TclX/DP/RPC counterparts a.s.o.; the big point is that
> when something makes its way into the Tcl core, it's going to be
> standard and is likely to be maintained for a very long time

I totally agree. And since Itcl is a nonstandard extension, then we shouldn't
feel compelled to use its namespace notation, whatever it is.

> - iTcl's syntactical rules (derived from C++) break vanilla Tcl:
> proc hey::buddy { args } {
> puts $args
> }
> hey::buddy can you diggit?

I don't really see your point here (it works in both Tcl and Itcl), but I guess
you mean that the new namespace notation is likely to break existing code?
Anyway, it's likely to occur whatever the notation is.

> - Tcl's syntax and runtime behaviour comes pretty close to that of
> Smalltalk/ObjC, so why not following that direction? I like John's
> proposal of introducing an "access method", as it's unlikely to

YES! YES! ;-)

I love Smalltalk, so I second your point.
Once, I wrote a Tcl-only extension called SmallTcl (never released, only for
my personal use) that provided an object model similar to Smalltalk/ObjectiveC.
It was built on top of the "unknown" mechanism. I never completed it because it
was darn slow and writing the libraries was too much work (I only wrote the basic
classes + some collections). Anyway the syntax was elegant (like Smalltalk).
(FYI, MIT's OTcl provides similar features, but is a C extension). My work would
certainly have been made easier if I've had namespaces.

> break existing code and nevertheless offers full access to
> namespaces while being fully compatible with Tcl's current syntax
> and semantics
>
> I'm convinced that John and his team will - as always - come up with a
> clever solution the majority of Tcl users can happily live with.

I hope so. For now, I see several possibilities:

- keeping itcl :: notation :-Z
The simplest (and IMHO ugliest) solution, but likely to break some code
(many megawidget extensions, and J.L Fontaine's stooop/scwoop) since
many people use :: in plain Tcl (it's a widely used convention)
- using a period separator. Very close to many OOLs (Java, Eiffel...) but
likely to conflict with Tk, but I think it could provide a powerful megawidget
mechanism
- Smalltalk-like space-separated syntax. Very close to Tcl philosophy, but
variable designation can be problematic. Using an accessor
(eg <namespace> set <variable> ?value?) is very elegant but only solves
part of the problem (Tcl uses pass-by-name convention, and spaces are
ill-treated in many cases such as "eval set $varname"). But after all, we
already use the space for interpreters notation. And most code (including mine)
already handle spaces in names. Since it's a bit useless to put spaces in
names in current versions of Tcl, I don't think it'll break a lot of code.

The easiest solution would be to keep the :: notation since it's widely
used but many people (including me) think it's ugly.

About space:
M. McLennan said that using space would lead to ambiguity. Here is a little
quote:
>
> foo bar x 0 3
>
> What does this mean? Is "foo" a command that takes "bar x 0 3" as
> arguments, or is "foo" a namespace containing the "bar" command?
> Maybe "foo" and "bar" are both namespaces that contain the real
> command "x", which takes "0 3" as arguments. If you didn't write
> the "foo" package, you have no idea how to read this.

It's true, unless namespaces are considered as commands (this is not
the case for now). If namespaces are commands, there's no ambiguity.
After all, many Tcl dynamic constuctions are commands (Tk widgets,
images, interpreters...) so why shouldn't namespaces be considered
as commands, too?
In the above example, foo is a command in the current namespace. If
foo is a regular command, it is called with args "bar x 0 3". If foo is a
namespace, then we look further for a bar command within, and so on.

About variable designation: I like the <namespace> set <variable> ?value?
but in order to pass variables by name, we also have to designate them as
space-separated lists, eg:

n1 n2 n3 set x 1
set {n1 n2 n3 x} 1

both commands set the variable x to 1 in the namespace n3 child of n2 child of n1.
The only objection is about spaces in var names but I think a lot of code
handles that correctly. To pass the variable x by value, we use {n1 n2 n3 x}.
To designate namespaces relatively to the global level, we can mimic the
interp syntax, that is, put a {} as the first namespace name. This is equivalent
to putting :: at the beginning of the variable/command using itcl notation.

I personally prefer the space separator notation (Smalltalk's bad influence ;-)
but the period is fine, too (maybe more problematic). I dislike the :: notation.
But all 3 solutions have positive and negative points, so it's not a trivial
question.

Andreas Manessinger

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Jan Nijtmans <nijt...@nici.kun.nl> writes:

> We already have seen the problem of using "::", when TIX was
> forced to change the syntax to use ":" as delemiter. With spaces
> this is much less likely to happen.

I admit I seem to have missed that. Why did they have to do the
change? I would have thought it was, to be compatible with Itcl.

--

mus...@mecasw.com

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote:

[lots of snip....]

>A somewhat tired

>--
>Andreas Manessinger m...@adv.magwien.gv.at
>------------------------------------------------------------------------
>"Time is a jet plane, it moves too fast"
> Bob Dylan, -You're a big girl now-

Thank you Andreas, for a clear and well put message in this rather
subjectively treated question.

tgds
td

Heribert Dahms

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

In <3309E9...@irisa.fr> fbo...@irisa.fr (Frederic Bonnet) writes:

: And since Itcl is a nonstandard extension, then we shouldn't

: feel compelled to use its namespace notation, whatever it is.

Then what's a standard extension, please?
BLT obviously not, or the Sun team had tried it with the newer releases
and noted that they broke bgexec, so they could have either fixed Tcl/Tk
or suggested a patch for BLT, at least for unix. Maybe they tried, but
had no time...

: But all 3 solutions have positive and negative points, so it's not a
: trivial question.

Anybody thinks it would be possible to enable namespaces package-wise with
a different separator string, not disturbing others?
Inside BLT there could be "namespace blt _" so that blt_barchart would work
again, and you might also use "namespace foo ::" and "namespace string { }".

Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)

Steve Simmons

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Avoiding such-and-such an operator because it's similar to a language
someone doesn't like is silly. `::' should not be rejected because
people don't like how C++ works. The change should be something which,
as much as possible, doesn't break current code either in the tcl core
or in the more popular extensions. IMHO this is a much stronger
arguement against `::'. It also argues against using simple white space.

That said, I don't care what the operator is. Use `entry@namespace', or
`entry@@namespace' if it's too hard to distinguish between the intent of
`@' and it's current use in bitmap/xy markers.

Bryan Oakley

unread,

Feb 18, 1997, 3:00:00 AM2/18/97

to

Andreas Manessinger wrote:
>
> Hmm, now I find myself following up to my own article :-)
>

> > Jan Nijtmans <nijt...@nici.kun.nl> writes:
> >
> > > We already have seen the problem of using "::", when TIX was
> > > forced to change the syntax to use ":" as delemiter. With spaces
> > > this is much less likely to happen.
> >
> > I admit I seem to have missed that. Why did they have to do the
> > change? I would have thought it was, to be compatible with Itcl.
>

> Just as I thought it. This is from `Tix4.1.0/docs/Changes.html':
>
> Incompatibility: All the "::" qualifiers in Tix class methods
> have been replaced by ":", so that the Tix classes can be
> loaded into Itcl without patching Itcl. If you have written
> your own Tix classes, you need to modify the source files to
> use the ":" qualifier instead.
>
> So Tix changed for the benefits of compatibility with Itcl, and if
> Itcl would have used spaces, then Tix would have changed to that. But
> this leaves the "::" delimiter untainted, doesn't it?

I think your interpretation is slightly incorrect. He didn't remove the
:: to be compatible with itcl, per se. He removed the ::'s so that he
wouldn't be *in*compatible with itcl. You see, itcl used :: and tix used
:: in two different ways. The way I understand it, itcl would return a
list of objects by searching the namespace for names with a :: in it (or
something like that...). Of course, this would return tix method names
too, which itcl couldn't grok.

So, to avoid this annoyance, tix removed the :: so as not to clash with
itcl. It was not because itcl used single colons but because tix's use
of double colons clashed with itcl. If itcl had used spaces there
wouldn't have been a need for tix to change.

--
Bryan Oakley mailto:oak...@healthcare.com
Software Engineer http://www1.clearlight.com/~oakley/
Healthcare Communications, Inc. http://www.healthcare.com/

Michael Schumacher

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

Steve Simmons <s...@iti.org> wrote:
: Avoiding such-and-such an operator because it's similar to a language

: someone doesn't like is silly. `::' should not be rejected because
: people don't like how C++ works. The change should be something which,
: as much as possible, doesn't break current code either in the tcl core
: or in the more popular extensions. IMHO this is a much stronger
: arguement against `::'. It also argues against using simple white space.

Yes, Yes, Yes, Yes and No. :-)

The argument against using "::" is not that some folks dislike C++, but
that it would break Tcl's syntax (just as would do ".", "@" or whatever),
*if* namespaces were implemented simply using a separator. The alternative
approach is using whitespace *plus an access method*, i.e. something like
"[access foo bar]". This is backward compatible with Tcl's syntax (i.e.,
the parser needs no changes) and with Tcl's semantics. Way better IMHO.

mike

Nir Levy

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

mi...@hightec.saarlink.de (Michael Schumacher) gracfully told us:

I remember that a while back in this thread someone said that "::" is not good
because it uses two characters. I wonder what he would of said about "[access foo bar]"

Just a thought :~)
Nir.

Andreas Manessinger

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

Bryan Oakley <oak...@healthcare.com> writes:

> So, to avoid this annoyance, tix removed the :: so as not to clash with
> itcl. It was not because itcl used single colons but because tix's use
> of double colons clashed with itcl. If itcl had used spaces there
> wouldn't have been a need for tix to change.

Correct, here my fingers were much faster than my brain :-)

Donal K. Fellows

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

In article <330834...@irisa.fr>, Frederic BONNET <fbo...@irisa.fr> wrote:
[ Loads elided - I'm sure some important context has been lost... :^) ]

> Just to bring the debate back to namespaces notation (I tried
> to sum up many arguments from different people):
>
> =========+==========================+===========================
> Notation | Pros | Cons
> =========+==========================+===========================
> :: |already used in [incr Tcl]|ugly ;-)
> | |why 2 chars?
> |close to C++ |too close to C++

Also too close to to [incr Tcl] unless the semantics match very
closely indeed. I suspect that [incr Tcl]'s semantics are not really
what we would want to actually have, especially since they are built
round the concept that creating a namespace (or class) is an expensive
operation and thus objects should be built differently.

Conflicts with Tk would be the killer here. I _really_ don't want to
have to rewrite all my Tk apps if at all possible; there's quite a lot
of them... :^)

> ---------+--------------------------+---------------------------
> -> |? |why 2 chars?
> | |look at your keyboard ;-)

Well, _I_ like this. It gives me the feeling that we are going into
something.

I could (mostly) live with space as the separator (and will everyone
please note that there is a difference between "foo bar spong" and
"{foo bar} spong" so the ensemble argument is not particularly
pressing) especially as the times when you are accessing variables
that are not in your current (or ancestor) namespaces should be
flagged in BIG letters, and I don't think that commands like foreach
ought to use iterators outside the current namespace anyway.

I understand the desire of some people for compatability with C++, but
I feel that if that could be provided by a (loadable) extension, given
that there were namespaces of a kind in the core, then that would
probably be a better way to go. Myself, I'd like to have cheap
namespaces which could either be named or "anonymous" (i.e. with a
program-generated unique name), and where I can specify in each
namespace the level of access-control (open, no external creation
and/or deletion of names, no external access at all to names (or
subsets of them)) as this would then provide a scheme on which things
like ensembles, McLennan's namespaces, classes and objects can all be
built (as well as things I haven't thought of). The notation issue
doesn't particularly bother me though, as long as it doesn't interact
subtlely and horribly with other current schemes.

Hmm. Other notations could include a single colon, or backtick, or
vertical bar, or any number of other things. I quite like single
colon (surrounded by non-colons, so [incr Tcl] will not clash) now I
come to think of it...

Donal.

Larry W. Virden

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

According to Andreas Manessinger <m...@imrryr.adv.magwien.gv.at>:

:Jan Nijtmans <nijt...@nici.kun.nl> writes:
:
:> We already have seen the problem of using "::", when TIX was
:> forced to change the syntax to use ":" as delemiter. With spaces
:> this is much less likely to happen.
:
:I admit I seem to have missed that. Why did they have to do the
:change? I would have thought it was, to be compatible with Itcl.

To become compatible with itcl, an extension or program cannot use :: in
their variable names. The older Tcl-only Tix was using :: as a naming
convention to simulate, in it's own way, a name space. However,
it was done in a way that didn't work with itcl, so things had to be
renamed, causing users of Tix great grief.

If* there are other publically available extensions which do this, their
community of users will be impacted by the move to begin using this
notation for another purpose. Likewise, any where within a user's environment
that they might have used :: for their own naming purposes will have
to be identified and modified.

However, the same is true for any other notation. It's just more likely,
because of the similarity to the C++ notation, that folk are already using
:: in variable names.

I myself am in favor of treating name spaces as functions...
--

Larry W. Virden INET: lvi...@cas.org

<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."

Unless explicitly stated to the contrary, nothing in this posting should

John Goodsen

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

Why can't Sun and Lucent synchronize development to co-release
compatible Tcl8.0 and Itcl3.0 in which the namespaces are migrated
to the Tcl core, thereby preserving all existing itcl programs
and keeping a clean migration path of namespaces into Tcl ?

--
John Goodsen Saguaro Software, Inc. / RADSoft Labs Division
jgoo...@radsoft.com User Centered Object-Oriented Design
Specialists
http://www.radsoft.com Object-Oriented S/W Architecture, Process,
Methods
Software Engineering Tools and Training

John Ousterhout

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

I hate to intrude on such a vigorous discussion, but we've now made our
decision on the naming mechanism for namespaces. We're going to use
:: as in incr tcl. I don't think any of us here at Sun is particularly
wild about this choice, but there isn't an alternative that is
significantly better, and in the absence of a clearly superior alternative
we might as well stick with what people are used to.

John Ousterhout

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

In article <330B2C...@radsoft.com>, John Goodsen <jgoo...@radsoft.com> writes:
|> Why can't Sun and Lucent synchronize development to co-release
|> compatible Tcl8.0 and Itcl3.0 in which the namespaces are migrated
|> to the Tcl core, thereby preserving all existing itcl programs
|> and keeping a clean migration path of namespaces into Tcl ?

Actually, this is what we're doing. Michael McLennan is "in the loop"
for the design and implementation of official Tcl namespace support.

John Ousterhout

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

In article <330B3C...@irisa.fr>, Frederic BONNET <fbo...@irisa.fr> writes:
|> But will namespaces be Tcl commands? I hope so, since it will allow
|> more powerful use of this new feature.

Probably not. The Tcl command approach isn't sufficient by itself
(e.g. it won't create a namespace that doesn't already exist and it
doesn't eliminate the need for :: separators) and I don't think it
adds any functionality that isn't already available through some other
mechanism. Thus, in order to minimize the additional functionality
we'll probably leave this feature out. Of course, you can always
create Tcl procedures for each namespace to emulate this functionality.

Michael Schumacher

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

Nir Levy <ni...@shaked.co.il> wrote:

: I remember that a while back in this thread someone said that "::" is not

: good because it uses two characters. I wonder what he would of said about
: "[access foo bar]"

I guess my example (or better: the name "access") wasn't chosen very well.
If there is a constructor for namespaces, e.g. a command named "namespace",
then you can create a namespace "foo" containing variable "bar" using:

namespace -create foo bar

Then, in order to access "bar" lateron, one could say

set val [foo bar]

You'll notice, that "[foo bar]" takes just one more char than "foo::bar",
but it conforms to Tcl's current rules. Clearly, my "implementation" of
namespaces needs some, um, polishing. I hope you get the picture, though.

mike

Jon Leech

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

In article <5eeuo2$i...@csa21s4m.cas.org>,

Larry W. Virden <lvi...@cas.org> wrote:
>If* there are other publically available extensions which do this, their

Someone at Neosoft could grep the archives pretty easily...

>community of users will be impacted by the move to begin using this
>notation for another purpose. Likewise, any where within a user's environment
>that they might have used :: for their own naming purposes will have
>to be identified and modified.

I'm not sure that's always or even mostly true. If I have Tcl code with
variables and procs with :: in their names, many things will still work in
itcl. info won't list the variables/procs not in the root namespace, true.

The argument can be inverted, too. If Sun implements a core namespace
mechanism that doesn't support the existing itcl notation, or at least allow
adding the existing notation without rewriting the core or taking large
performance hits, then it's the *itcl* users that will be impacted. I
suspect that's a large group, at this point.

Jon
__@/

Frederic BONNET

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

Heribert Dahms wrote:
> In <3309E9...@irisa.fr> fbo...@irisa.fr (Frederic Bonnet) writes:

> : And since Itcl is a nonstandard extension, then we shouldn't

> : feel compelled to use its namespace notation, whatever it is.
>

> Then what's a standard extension, please?

Oops I mean nonstandard Tcl code (referring to Michael's sentence)...

> Anybody thinks it would be possible to enable namespaces package-wise with
> a different separator string, not disturbing others?
> Inside BLT there could be "namespace blt _" so that blt_barchart would work
> again, and you might also use "namespace foo ::" and "namespace string { }".

It sounds interesting, but parsing is going to become a big mess ;-)
Anyway, it will solve the problem since anybody could use any convention,
but I don't think it's feasable.

Frederic BONNET

unread,

Feb 19, 1997, 3:00:00 AM2/19/97

to

Hi John,

Ok, I accept this decision. The strongest argument in favor of the ::
was that M. McLennan's code already used it, so it's a gain of time,
and probably a good compromise.

But will namespaces be Tcl commands? I hope so, since it will allow

more powerful use of this new feature. I think several people agree
on that point (M. Schumacher?).

John Ellson

unread,

Feb 20, 1997, 3:00:00 AM2/20/97

to

In article <3309E9...@irisa.fr>, Frederic BONNET <fbo...@irisa.fr> wrote:
>Michael Schumacher wrote:

> - keeping itcl :: notation

> - using a period separator.

> - Smalltalk-like space-separated syntax

>The easiest solution would be to keep the :: notation since it's widely
>used but many people (including me) think it's ugly.

>I personally prefer the space separator notation (Smalltalk's bad influence ;-)

>but the period is fine, too (maybe more problematic). I dislike
>the :: notation. But all 3 solutions have positive and negative points,
>so it's not a trivial question.
>
>See you, Fred

I'm uncomfortable with the space-separator suggestion because,
even though Tcl can handle it, the code loses human readability and
is likely to be error prone.

Personally I'd prefer to see a single character separator so that names could
be split easily into a list. I suppose "::" would be OK if a
built-in function could be added to split strings on compound
separators, that might be a generally useful function anyway.

OTOH, wouldn't it be possible to use a single ":" as a
separator *and* not break any itcl code? "foo::bar" would just
split into the three element name: {foo {} bar}
As long as the new namespace facilties can handle null as a valid
name, all names in existing itcl code should be no problem.

Also, it would be trivial for the interpreter to recognise any command
token with leading ":" as a name space accessor.

John Ellson
Lucent Technologies

Andreas Saremba

unread,

Feb 20, 1997, 3:00:00 AM2/20/97

to

John Ousterhout wrote:
>...

> We're going to use :: as in incr tcl. I don't think any of us here at > Sun is particularly wild about this choice, but there isn't
> an alternative that is significantly better, and in the absence of a
> clearly superior alternative
> we might as well stick with what people are used to.

<sighOfRelief> Thank you! </sighOfRelief>

--
************************************************
* Andreas Saremba (andreas...@bln.sni.de)*
* Tel. +49-30-38624423 *
* Siemens Nixdorf (SNI) Office Solutions *
* Nonnendammallee 101, D-13629 Berlin *
************************************************

Volker Hetzer

unread,

Feb 20, 1997, 3:00:00 AM2/20/97

to

Michael Schumacher wrote:
>
> Nir Levy <ni...@shaked.co.il> wrote:
>
> : I remember that a while back in this thread someone said that "::" is not
> : good because it uses two characters. I wonder what he would of said about
> : "[access foo bar]"
>
> I guess my example (or better: the name "access") wasn't chosen very well.
> If there is a constructor for namespaces, e.g. a command named "namespace",
> then you can create a namespace "foo" containing variable "bar" using:
>
> namespace -create foo bar
>
> Then, in order to access "bar" lateron, one could say
>
> set val [foo bar]

Big problem: is foo a procedure or a namespace?
I like set val [namespace foo bar] better.
Or what about:

with {<list of namespaces or mappings such as:>
{itcl} {tix}
{fooSpace barIdentifier bar2Identifier}
{std stderr} } \
{ commands }

as an additional syntax?

Volker

Michael Schumacher

unread,

Feb 20, 1997, 3:00:00 AM2/20/97

to

John Ousterhout <ous...@tcl.eng.sun.com> wrote:
: In article <330B3C...@irisa.fr>, Frederic BONNET <fbo...@irisa.fr> writes:
: |> But will namespaces be Tcl commands? I hope so, since it will allow

: |> more powerful use of this new feature.

: Probably not.

In this case I'd suggest making the namespace feature a compile-time option,
so that legacy code (which would break otherwise) continues to work with
newer versions of Tcl. It would also have the additional benefit of
minimizing Tcl's memory footprint in case of -DTCL_GENERIC_ONLY (yes, there
are still people out there who use Tcl for glueing their apps).

mike

PS: Is there a way to inform us about how the new mechanism will look
like, or is the design still "in the works"?

John Ousterhout

unread,

Feb 20, 1997, 3:00:00 AM2/20/97

to

In article <8564400...@htc01.hightec.saarlink.de>, mi...@hightec.saarlink.de (Michael Schumacher) writes:
|>
|> PS: Is there a way to inform us about how the new mechanism will look
|> like, or is the design still "in the works"?

It's still very much in the works. It's likely to look a lot like the
incr tcl namespace mechanism, but I think there's a good chance we'll
end up subsetting it a bit.

Maurice DIAMANTINI

unread,

Feb 21, 1997, 3:00:00 AM2/21/97

to

In article (Dans l'article) <8564400...@htc01.hightec.saarlink.de>,
mi...@hightec.saarlink.de (Michael Schumacher) wrote (écrivait) :

>John Ousterhout <ous...@tcl.eng.sun.com> wrote:
>: In article <330B3C...@irisa.fr>, Frederic BONNET <fbo...@irisa.fr>
writes:
>: |> But will namespaces be Tcl commands? I hope so, since it will allow
>: |> more powerful use of this new feature.
>
>: Probably not.

What a pity, I'd like to write TCL script with a namespace feature
without any "tcl_distrib" foreign extension.

I think the tcl distrib SHOULD provide a mean to do this as
a (several?) TCL command.

This standard "micro namespace" feature could be a standard extension
callable be some thing like :

load tcl_namespace.8.0.so

or:

package require namespace

>In this case I'd suggest making the namespace feature a compile-time option,
>so that legacy code (which would break otherwise) continues to work with
>newer versions of Tcl. It would also have the additional benefit of
>minimizing Tcl's memory footprint in case of -DTCL_GENERIC_ONLY (yes, there
>are still people out there who use Tcl for glueing their apps).

NO compile time option!
One never know if a foreign site has ou not this flag true!!

If a give someone a tcl script which need namespaces, I'd prefer
require it by the package require feature.

so (if I understand the use of the future namespac feature?)
I want do :

either
package require namespace
if my script contains only the standard tcl distrib namespace feature

either
package require itcl
if my script need the full namespace feature provided by iwish

--
Maurice DIAMANTINI - Ecole Nationale Supérieure de Techniques Avancées
di...@ensta.fr - 32 Bd Victor - 75739 PARIS FRANCE
<< branchez-vous sur fr.comp.lang.tcl >>

Mike Tiller

unread,

Feb 21, 1997, 3:00:00 AM2/21/97

to

ous...@tcl.eng.sun.com (John Ousterhout) writes:

> In article <330B2C...@radsoft.com>, John Goodsen writes:
> |> Why can't Sun and Lucent synchronize development to co-release
> |> compatible Tcl8.0 and Itcl3.0 in which the namespaces are migrated
> |> to the Tcl core, thereby preserving all existing itcl programs
> |> and keeping a clean migration path of namespaces into Tcl ?
>
> Actually, this is what we're doing. Michael McLennan is "in the loop"
> for the design and implementation of official Tcl namespace support.

This reminds me. Do you guys have any plans for picking up Tix or
some of its technology? I think Tix is an awesome package and I'd
really like to see something like Tix be maintained in the future by
somebody (Sun?). Something that had the really impressive graphics of
Tix along with the object system of Itcl would be a great addition to
the Tcl community. Just a thought.

I know my company would even be willing to pay for something like Tix
or even just support in general. I just wanted to voice my
encouragement if you decide to go that way.

--
Mike

Heribert Dahms

unread,

Feb 21, 1997, 3:00:00 AM2/21/97

to

In <diam-ya02308000...@ici-paris.ensta.fr> di...@ensta.fr
(maurice Diamantini) writes:

: In article (Dans l'article) <8564400...@htc01.hightec.saarlink.de>,

: mi...@hightec.saarlink.de (Michael Schumacher) wrote (écrivait):

: >In this case I'd suggest making the namespace feature a compile-time option,

: >so that legacy code (which would break otherwise) continues to work with
: >newer versions of Tcl. It would also have the additional benefit of
: >minimizing Tcl's memory footprint in case of -DTCL_GENERIC_ONLY (yes, there
: >are still people out there who use Tcl for glueing their apps).
:
: NO compile time option!
: One never know if a foreign site has ou not this flag true!!

YES for the compile time option!
Read above again: Mike is talking about a really minimal embedded system,
but you mean running arbitrary Tcl scripts on an unknown foreign site!
People having such small beasts usally know what they can run on them 8-)

Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)

Russ Fellows

unread,

Feb 21, 1997, 3:00:00 AM2/21/97

to Michael J. McLennan

Michael and John:

I have followed this discussion/controversy for some time. In my
opinion, working on medium to large projects, Tcl is useless
without Itcl. Don't get me wrong, Tcl is great, but it cannot
handle programming "real" applications without some help. One
of the best things about Itcl is namespaces. It is not confusing
at all, and any real programmer at all familiar with modern
OO programming techniques can master it in about two minutes.

Therefore I STRONGLY urge that Tcl incorporate Itcl's namespace
convention. The Sun proposal is weak, and only solves part of
the problem. The small reduction in complexity claimed is
not worth the features lost.

I imagine that I like many others would just hack Tcl to do things
the "right" way if the Itcl namespace convention is not used. One
more incentive is that there are probably millions of lines of code
already developed with the Itcl namespace extensions being heavily
utilized. To date, there are no lines of code written to the new
proposal (other than some beta users).

Sincerely,

----------------------------------------------------------------------------
Russell D. Fellows (rfellows@intellistor)

Larry W. Virden

unread,

Feb 21, 1997, 3:00:00 AM2/21/97

to

It would really be a shame if the name spaces from incr tcl were
so much a subset that itcl still required core source code modifications
before it ended up being usable.

For instance, I have heard a lot of discussion about name spaces
(variable encapsulation?). However, what about private variables?
This is something that has been regularly requested from users, and
itcl provides.

Larry W. Virden

unread,

Feb 23, 1997, 3:00:00 AM2/23/97

to

According to Heribert Dahms <DA...@ifk20.mach.uni-karlsruhe.de>:
:In <diam-ya02308000...@ici-paris.ensta.fr> di...@ensta.fr

: (maurice Diamantini) writes:
:
:: In article (Dans l'article) <8564400...@htc01.hightec.saarlink.de>,
:: mi...@hightec.saarlink.de (Michael Schumacher) wrote (écrivait):
:
:: >In this case I'd suggest making the namespace feature a compile-time option,
:: >so that legacy code (which would break otherwise) continues to work with
:: >newer versions of Tcl. It would also have the additional benefit of
:: >minimizing Tcl's memory footprint in case of -DTCL_GENERIC_ONLY (yes, there
:: >are still people out there who use Tcl for glueing their apps).
::
:: NO compile time option!
:: One never know if a foreign site has ou not this flag true!!
:
:YES for the compile time option!

I vote yes for the compile time option, _but_ with something that the
smaller version has for a script to detect that support isn't present.

Frederic BONNET

unread,

Feb 24, 1997, 3:00:00 AM2/24/97

to

Hi all,

Mike Tiller wrote:
> [...] Something that had the really impressive graphics of

> Tix along with the object system of Itcl would be a great addition to
> the Tcl community. Just a thought.

And native look&feel would be great, too. I'd like to use comboboxes
and tabbed windows on all platforms (esp. Windows).

Donal K. Fellows

unread,

Feb 24, 1997, 3:00:00 AM2/24/97

to

In article <5efan8$g...@engnews2.Eng.Sun.COM>,

John Ousterhout <ous...@tcl.eng.sun.com> wrote:
> I hate to intrude on such a vigorous discussion, but we've now made

> our decision on the naming mechanism for namespaces. We're going to

> use :: as in incr tcl. I don't think any of us here at Sun is
> particularly wild about this choice, but there isn't an alternative
> that is significantly better, and in the absence of a clearly
> superior alternative we might as well stick with what people are
> used to.

OK. So what exactly will namespaces affect? Variables definitely
ought to be on the list, but if there are access commands, I don't see
the need to add procedures as well...

Can you create cheap "anonymous" namespaces (ie. like you can create
"anonymous" images, with names that I just stuff into variables
instead of having to generate uniquely when I write the script) so I
could use them as a basis for objects? More verbose forms of syntax
are mostly not a problem, given that generally you want to access the
current namespace, and the compiler will clean up (most of) the
inefficiencies. I don't want to have to build qualified variable
names with format...

I would hope that the restrictions on Itcl's namespaces due to the
form of their implementation do not mean that a superior mechanism
gets rejected (should such a mechanism be available). This is of
particular concern to me as Itcl's design decisions were made without
the compiler in mind (in particular, why should namespaces be
expensive? Surely a cheap namespace semantics can be found that takes
advantage of the compiler and the fact that it is very intimate with
the rest of the core...)

I also don't like the double colon notation, but that's probably due
to too many bad experiences with C++ being stupid and not doing what I
want. That's what comes of learning OOPLs with the Modula's first...

Overall judgement is reserved until I see what the new scheme can do.

Heribert Dahms

unread,

Feb 24, 1997, 3:00:00 AM2/24/97

to

In <5epdc6$2...@csa21s4m.cas.org> lw...@cas.org (Larry W. Virden) writes:

: I vote yes for the compile time option, _but_ with something that the

: smaller version has for a script to detect that support isn't present.

I guess you get one for free with:
info commands namespace

Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)

Bryan Oakley

unread,

Feb 25, 1997, 3:00:00 AM2/25/97

to

Russ Fellows wrote:
>
> Michael and John:
>
> I have followed this discussion/controversy for some time. In my
> opinion, working on medium to large projects, Tcl is useless
> without Itcl. Don't get me wrong, Tcl is great, but it cannot
> handle programming "real" applications without some help.

Wow. I have to disagree strongly with this statement. I've never used
itcl, though I maintain a tcl code base of a couple hundred thousand
lines. It is part of a commercial application which is the best of it's
class and does extremely well in the marketplace. So, it obviously _can_
handle "real" applications without the help of itcl.

--
Bryan Oakley mailto:oak...@healthcare.com
Software Engineer http://www1.clearlight.com/~oakley/
Healthcare Communications, Inc. http://www.healthcare.com/

Jeffrey Hobbs

unread,

Feb 25, 1997, 3:00:00 AM2/25/97

to

Bryan Oakley <oak...@healthcare.com> wrote:

>Russ Fellows wrote:
>> I have followed this discussion/controversy for some time. In my
>> opinion, working on medium to large projects, Tcl is useless
>> without Itcl. Don't get me wrong, Tcl is great, but it cannot
>> handle programming "real" applications without some help.

>Wow. I have to disagree strongly with this statement. I've never used
>itcl, though I maintain a tcl code base of a couple hundred thousand

I'm with Bryan on this one. I've written over 10K lines of iTcl for one app
alone, but gads more raw Tcl for numerous other applications. I would sort
of equate the relationship of Tcl=>incrTcl as c=>C++ (of course). C doesn't
lack the ability to be programmed in VL apps, it just requires a certain
discipline in programming, and the same is true for Tcl. However, there is
one difference: while I would welcome incrTcl heartily, C++ is a bad hack of
OO design.

The trick is to find good programmers....

--
Jeffrey Hobbs jho...@cs.uoregon.edu,@or.cadix.com
Software Engineer, Oregon R&D office: 541.683.7891
CADIX International, Inc. fax: 541.683.8325
URL: http://www.cs.uoregon.edu/~jhobbs/

Nat Pryce

unread,

Mar 5, 1997, 3:00:00 AM3/5/97

to

Andreas Manessinger <m...@imrryr.adv.magwien.gv.at> wrote in article
<x0914on...@imrryr.adv.magwien.gv.at>...
> "Nat Pryce" <n...@doc.ic.ac.uk> writes:
> >
> > Of course, there are obviously a number of useful Tcl idioms/patterns.
> > Perhaps we should collect them on the comp.lang.tcl newsgroup...
>
> Fine idea. I'd certainly volunteer to collect them and set up a WWW
> page. So go on everybody and post what you have, use `IDIOM' or
> `PATTERN' in the subject line, we'll discuss them in the newsgroup,
> and again, I could set up a page for the results. This would
> definitely be something for the whole community to profit from.

Ok, I've taken up the challenge and created a Tcl Programming Idioms web
page and three idioms.

The URL is:

http://www-dse.doc.ic.ac.uk/~np2/patterns/tcl/index.html

I think that a pattern-language of proven design techniques will be
useful for the whole Tcl community. It will help new programmers
come up to speed with the language and give experienced programmers
a common jargon in which to discuss Tcl programming issues.

To achieve this, it must be a joint effort, so please comment on the
idioms documented by posting articles to comp.lang.tcl with the subject
line starting with IDIOM. I'd appreciate comments on what I have written
so far, including comments on:

- New idioms
- Examples of existing uses each idiom
- Consequences, both positive and negative, of using each idiom
- Other patterns and idioms related to each idiom
- Comments on the organisation and style of the documents

[[Send Tcl/Tk announcements to tcl-an...@mitchell.org
Send administrivia to tcl-announ...@mitchell.org
Announcements archived at http://www.xpi.com/tcl/comp.lang.tcl.announce/
The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]]