23,118
社区成员
发帖
与我相关
我的任务
分享选择Tcl/Tk语言的十大理由---转载自Tcl/Tk中文网
选择Tcl/Tk语言的十大理由
---------------------------------------
转载自Tcl/Tk中文网
http://tcltk.126.com
介绍Tcl/Tk语言的基本知识，汇集大量关于
Tcl/Tk的中文原创文章，英文翻译文档，开
设有Tcl/Tk中文网论坛。
---------------------------------------
人们使用Tcl/Tk的原因各不相同的，不过总的来说可以归纳为几类。下面所列的就是当前人们选择Tcl/Tk的10个最主要的原因。
1. 开发应用程序的周期短
人们使用Tcl/Tk 最主要的原因是Tcl/Tk使他们的工作能够更快的完成。许多情况下，用Tcl编写的应用程序比用其他语言编写的应用程序运行速度快5-10倍。这在那些包含图形用户界面，字符串操作，积分操作的程序中表现得尤为突出。而且用Tcl编写的应用程序稍加修改就能适应变化的需求。
2. 适于开发图形用户界面
Tcl与Tk工具箱相互配合提供了一整套创建图形用户界面的非常简单而又十分强大的工具。比如Tk的Canvas构件，不但可以十分方便的创建图形显示而且还提供诸如bindings和tags之类功能强大的部件。Text构件则可以提供复杂的超文本功能。在过去，只有Tcl提供了在UNIX下创建图形用户界面的完美的解决方案，这使得它拥有了一大批早期的追随者。如今Tcl可以在Windows，Macintoshi平台上提供同样出色的功能。
3．能够开发跨平台的应用程序
Tcl可以在Windows,Macintosh和几乎所有能想到的UNIX平台下运行，这使它成为开发跨平台应用程序的绝佳工具。举例来说，同样的Tcl脚本可以在UNIX，Windows和Macintosh上显示一个图形用户界面，这个图形用户界面在不同的平台上具有不同的外观，使不同平台上的用户在使用上没有障碍。由于Tcl可运行于所有的主流平台，所以它为那些类似于服务器采用UNIX，桌面采用Windows这样的混合环境提供了卓越的管理和整合工具。
4． 可以方便的扩展应用程序
如果你想创建一个能让用户自行修改和扩充的，功能强大的应用程序，那么你需要在这个应用程序中包含进一个解释性的脚本语言。Tcl/Tk能非常好的实现这个目的。Tcl解释器设计的初衷就是要能够嵌入到各种应用程序中。你可以很容易的将Tcl整合到一个应用程序中。Tcl解释器与应用程序能够很自然的融合在一起，看起来就好像Tcl是专门为编写这个应用程序而设计的语言。
5．具有弹性的整合功能
使用Tcl可以很方便的将已有的部件与应用程序整合起来，使他们能更有效的工作。例如，可以将Tcl用作特殊用途的硬件和协议的控制语言，为陈旧的应用程序添加图形用户接口或网络接口，或者将以前用C/C++编写的代码与新的Java应用程序整合起来，这使Tcl成为网络管理和工业自动化领域的强大工具。
6．为企业应用提供解决方案
随着Tcl8.1的发布，Tcl成为适合于开发大型服务程序和开发用于执行关键任务的企业级应用程序的首选（也是唯一可选）的脚本语言。脚本语言的优势，如快速的开发周期，弹性升级，易于整合，是众所周知的，但是在Tcl8.1之前，还没有一种能够满足企业应用程序需求的脚本语言，这些需求包括对国际化，线性安全，跨平台性，出色的图形用户接口，可嵌入性，因特网访问，数据访问之类的支持。Tcl8.1加入了对国际化的支持和线性安全，使Tcl成为不仅具有脚本语言的所有优势还能满足企业需求的首选脚本语言。
7．易于调试
Tcl是用于实现硬件自动化和软件测试的理想语言并且可能会成为这方面的主导语言。使用Tcl你可以很容易的连接到测试硬件或是一个应用程序的内部API接口，执行测试功能，检查结果，报告错误。Tcl的解释执行使测试环境能够迅速的建立起来，并且能够将测试结果以脚本文件的形式保存以用于以后的测试。如果你正在测试一个软件应用程序，Tcl可以使你直接连接到应用程序的底层API中，这样可以使测试更准确、更全面。
8．易于学习
Tcl是一种非常简单易学的语言，有经验的程序员可以在几天甚至几小时内就可以学会并能开始着手编写应用程序。普通的程序员也能很快的学会Tcl。通常由有经验的程序员编写一些基本的功能，更多普通的程序员应用这些功能来创建自己的应用程序。
9．易于编写网络应用程序
Tcl比任何平台都更易于使用网络设备，编写服务器端和客户端应用程序，只需几行代码，几分钟内就可以创建出来。另外，Tcl还可以很方便的为陈旧的应用程序加入网络接口。
10．庞大的Tcl网络社区
使用Tcl的另一个原因是它具有一个庞大的用户开发者社区，你随时都可以在Tcl网络社区中与别人交换代码、扩展包以及应用程序，还可以得到技术支持。
11．附加一点，Tcl是免费的！
Tcl可以从Tcl Developer Xchang网站上免费的得到，你可以对其代码进行修改以满足自己的需要或者将它用于商业用途。
---------------------------------------
转载自Tcl/Tk中文网
http://tcltk.126.com
介绍Tcl/Tk语言的基本知识，汇集大量关于
Tcl/Tk的中文原创文章，英文翻译文档，开
设有Tcl/Tk中文网论坛。
---------------------------------------
人们使用Tcl/Tk的原因各不相同的，不过总的来说可以归纳为几类。下面所列的就是当前人们选择Tcl/Tk的10个最主要的原因。
1. 开发应用程序的周期短
人们使用Tcl/Tk 最主要的原因是Tcl/Tk使他们的工作能够更快的完成。许多情况下，用Tcl编写的应用程序比用其他语言编写的应用程序运行速度快5-10倍。这在那些包含图形用户界面，字符串操作，积分操作的程序中表现得尤为突出。而且用Tcl编写的应用程序稍加修改就能适应变化的需求。
2. 适于开发图形用户界面
Tcl与Tk工具箱相互配合提供了一整套创建图形用户界面的非常简单而又十分强大的工具。比如Tk的Canvas构件，不但可以十分方便的创建图形显示而且还提供诸如bindings和tags之类功能强大的部件。Text构件则可以提供复杂的超文本功能。在过去，只有Tcl提供了在UNIX下创建图形用户界面的完美的解决方案，这使得它拥有了一大批早期的追随者。如今Tcl可以在Windows，Macintoshi平台上提供同样出色的功能。
3．能够开发跨平台的应用程序
Tcl可以在Windows,Macintosh和几乎所有能想到的UNIX平台下运行，这使它成为开发跨平台应用程序的绝佳工具。举例来说，同样的Tcl脚本可以在UNIX，Windows和Macintosh上显示一个图形用户界面，这个图形用户界面在不同的平台上具有不同的外观，使不同平台上的用户在使用上没有障碍。由于Tcl可运行于所有的主流平台，所以它为那些类似于服务器采用UNIX，桌面采用Windows这样的混合环境提供了卓越的管理和整合工具。
4． 可以方便的扩展应用程序
如果你想创建一个能让用户自行修改和扩充的，功能强大的应用程序，那么你需要在这个应用程序中包含进一个解释性的脚本语言。Tcl/Tk能非常好的实现这个目的。Tcl解释器设计的初衷就是要能够嵌入到各种应用程序中。你可以很容易的将Tcl整合到一个应用程序中。Tcl解释器与应用程序能够很自然的融合在一起，看起来就好像Tcl是专门为编写这个应用程序而设计的语言。
5．具有弹性的整合功能
使用Tcl可以很方便的将已有的部件与应用程序整合起来，使他们能更有效的工作。例如，可以将Tcl用作特殊用途的硬件和协议的控制语言，为陈旧的应用程序添加图形用户接口或网络接口，或者将以前用C/C++编写的代码与新的Java应用程序整合起来，这使Tcl成为网络管理和工业自动化领域的强大工具。
6．为企业应用提供解决方案
随着Tcl8.1的发布，Tcl成为适合于开发大型服务程序和开发用于执行关键任务的企业级应用程序的首选（也是唯一可选）的脚本语言。脚本语言的优势，如快速的开发周期，弹性升级，易于整合，是众所周知的，但是在Tcl8.1之前，还没有一种能够满足企业应用程序需求的脚本语言，这些需求包括对国际化，线性安全，跨平台性，出色的图形用户接口，可嵌入性，因特网访问，数据访问之类的支持。Tcl8.1加入了对国际化的支持和线性安全，使Tcl成为不仅具有脚本语言的所有优势还能满足企业需求的首选脚本语言。
7．易于调试
Tcl是用于实现硬件自动化和软件测试的理想语言并且可能会成为这方面的主导语言。使用Tcl你可以很容易的连接到测试硬件或是一个应用程序的内部API接口，执行测试功能，检查结果，报告错误。Tcl的解释执行使测试环境能够迅速的建立起来，并且能够将测试结果以脚本文件的形式保存以用于以后的测试。如果你正在测试一个软件应用程序，Tcl可以使你直接连接到应用程序的底层API中，这样可以使测试更准确、更全面。
8．易于学习
Tcl是一种非常简单易学的语言，有经验的程序员可以在几天甚至几小时内就可以学会并能开始着手编写应用程序。普通的程序员也能很快的学会Tcl。通常由有经验的程序员编写一些基本的功能，更多普通的程序员应用这些功能来创建自己的应用程序。
9．易于编写网络应用程序
Tcl比任何平台都更易于使用网络设备，编写服务器端和客户端应用程序，只需几行代码，几分钟内就可以创建出来。另外，Tcl还可以很方便的为陈旧的应用程序加入网络接口。
10．庞大的Tcl网络社区
使用Tcl的另一个原因是它具有一个庞大的用户开发者社区，你随时都可以在Tcl网络社区中与别人交换代码、扩展包以及应用程序，还可以得到技术支持。
11．附加一点，Tcl是免费的！
Tcl可以从Tcl Developer Xchang网站上免费的得到，你可以对其代码进行修改以满足自己的需要或者将它用于商业用途。
...全文
请发表友善的回复…
发表回复
tishineq 2004-02-17
- 打赏
- 举报
up
mmxxt 2003-09-10
- 打赏
- 举报
up
mmxxt 2003-09-09
- 打赏
- 举报
up
Nvram 2003-09-05
- 打赏
- 举报
关于哪种语言好的争论似乎从没停息，公说公理，婆说婆理。
大家可以在google上搜索"TCL War"，这是RMS和TCL的作者的
争论，还有Larry Wall（Perl语言的作者）这样的大师一起参
与，很有意思，呵呵。
大家可以在google上搜索"TCL War"，这是RMS和TCL的作者的
争论，还有Larry Wall（Perl语言的作者）这样的大师一起参
与，很有意思，呵呵。
Nvram 2003-09-05
- 打赏
- 举报
我上面转帖的文章只代表RMS的观点，不代表我个人的观点。我要说的是，我不反对TCL。确实，在我现在所在的公司和曾经所在的公司，TCL语言被广泛用在测试自动化方面，并取得了很好的效果。但是虽然我不反对TCL，但我也不怎么喜欢它。RMS更喜欢类Lisp语言，他在文中提到了Scheme。我曾经研究过这种语言，它确实非常好。Scheme是从Lisp中派生出来的，语法形式跟Lisp很象，但比Lisp简单得多。它最值得一提的特点就是能够用最简单的语法形式表达非常复杂的算法。Scheme语言被作为模型语言在国外大学广泛用在计算机程序设计语言的教学。然而实际使用的并不是很广泛，最值得一提的是Gimp。Gimp是GNU的图形处理工具，使用Guile作为Scheme嵌入式解释器。其实应用扩展语言有很多种，可以分为两大类，一种是将通用编程语言作为应用扩展语言，如Lisp、Scheme、Perl、Python。还有专门设计的应用扩展语言，如TCL、JavaScript、Lua、C-Lang等。前者功能强大，后者的能力有限。但前者学习比较困难，后者容易上手。Lisp是很早发明的语言，只比Fortran晚一点点，由人工智能领域的先驱约翰麦卡西发明，当时麦卡西在MIT的AI实验室，RMS也在，所以RMS对Lisp情有独忠。Lisp作为应用扩展语言除了在Emacs里使用外，另外值得一提的就是AutoCAD。无论是Emacs或AutoCAD，它们都比较难学，但是学会了就会发现，它们都是“万能”应用程序。
mmxxt 2003-09-05
- 打赏
- 举报
Tcl简介
Tcl是一种非常简单的编程语言，如果你以前曾经学过编程，那么你只要学习几个小时就可以编写出一些有趣的Tcl程序。本文将对Tcl的功能做一个大概的介绍。一般来说，读完本文之后，你就可以开始独立的编写一些简单的Tcl脚本了；不过，要想获得更全面的认识，我们建议你还是去参考几本目前已经出版的Tcl书籍。
基本语法
Tcl脚本由一些被换行符或是分号分开的命令所组成。命令都有相同的基本格式，如下面的例子所示：
expr 20 + 10
该命令计算20加10的和，并返回结果30。你可以把这个例子以及本文中的所有其它的例子键入到tclsh这样的Tcl应用程序中来验证它们；在一个命令结束后，tclsh将打印出它的结果。
每个Tcl命令都含有一个或多个被空格分开的单词，在这个例子中有4个单词：expr,20,+,和10。第一个单词是一个命令名，其余的单词是这个命令的参数。所有的Tcl命令都含有一些单词，但不同的命令对他们的参数有不同的处理方式。expr命令把它的所有参数看作是一个算术表达式，计算表达式的结果，并以字符串的形式返回结果。在expr命令中，单词之间的分隔不是很重要：同样的命令你可以写成这种形式：
expr 20+10
不过，对大部分的命令来说，单词的结构是很重要的。每个单词都会用于不同的目的。所有的Tcl命令都返回结果。如果一个命令产生了没有意义的结果，那么它将返回一个空字符串作为它的结果。
变量
Tcl允许你在变量中保存数值，并且可以在后续的命令中使用这些数值。set命令用于对变量进行读写操作。比如，下面的命令对变量x赋值为32。
set x 32
这个命令返回变量的新值。你可以让set只带一个参数来读出变量的数值：
set x
你不需要在Tcl中声明变量：变量在第一次set的时候被自动创建。Tcl变量没有类型：任何值可以赋给任何变量。
要想在一个命令中使用变量的值，可以采用变量替代，如下例所示：
expr $x*3
当一个字符$出现在一个命令中的时候，Tcl把跟在它后面的字母和数字看作是一个变量名并且将其替换成变量的值。在这个例子中，expr命令接收到的实际参数将是32*3（假设变量x在前面的例子中被set过）。你可以在任何命令的任何单词中使用变量替代，甚至对一个单词多次使用：
set cmd expr
set x 11
$cmd $x*$x
命令替代
你也可以在一个命令的参数中使用另一个命令的结果。这被称之为命令替代：
set a 44
set b [expr $a*4]
当中括号出现在一个命令中的时候，Tcl把中括号之间的所有语句看作是一组Tcl命令。Tcl对这组命令进行解释，并用结果替代中括号之间的文字。上面的例子中，第二个set命令的第二个参数将为176。
双引号和大括号
双引号允许你指定包含空格的单词。我们看下面的这个例子：
set x 24
set y 18
set z "$x + $y is [expr $x + $y]"
在这三个命令都被解释后，变量z的值将是24+18 is 42。双引号之间的所有语句作为一个单词传给set命令。此处需要注意几点（a）引号之间的命令和变量替代仍起作用，（b）引号自身不会被传给命令。如果没有引号的话，set命令会得到6个参数，这将引起错误。
花括号对单词提供另外一种组合信息的方式。它与双引号的不同之处在于：花括号内的替代不起作用：
set z {$x + $y is [expr $x +$y]}
这个命令把变量z赋值为 " $x + $y is [expr $x +$y]"。
控制结构
Tcl提供一整套控制结构包括条件，循环和过程。Tcl的控制结构只是一些将Tcl脚本作为参数的命令。下面的示例创建了一个叫做power的Tcl的过程，实现对一个数求它的n次方：
proc power {base p}{
set result 1
while {$p >0}{
set result [expr $result * $base]
set p [expr $p- 1]
}
return $result
}
这个脚本由一个简单的命令proc所组成，这个proc命令有3个参数：过程名，参数名列表和过程体。过程体是一个Tcl脚本。需要注意的是，第一行末尾的花括号和最后一行花括号之间的语句都被逐字逐句的作为一个参数传给proc。proc命令创建了一个新的叫做power的具有两个参数的Tcl命令。你可以这样来调用power：
power 2 6
power 1.15 5
当power被调用的时候，过程体就被解释了。当过程体执行的时候，它可以变量的形式进入它的参数中：base获得第一个参数，p获得第二个参数。
power过程体中包含3个Tcl命令：set,while和return。while命令完成了这个过程中的大部分工作。它有两个参数，一个表达式（$p>0）和一个Tcl脚本写的主体。while命令使用与C语言相似的规则来解释它的表达式参数。如果结果是真（非零），那么它将把函数体作为脚本来执行。他不断的重复这个过程，直到最后表达式的值变为假（零）。在这个例子中，while命令的函数体将result的值与base相乘，然后减少p的值。当p的值减到零的时候，结果就包含了需要的base的n次方值。return命令的作用是退出过程，同时将变量result的值作为过程的结果返回。
命令是如何运作的？
正如你所见到的，Tcl中所有有趣的功能都是靠命令来描述的。声明是命令，表达式由可执行命令来解释，控制结构是命令，过程也是命令。
Tcl命令由3种方式来创建。一组命令由Tcl解释器自身来提供。这些命令称之为内建命令，他们包括到现在为止你已经看到的命令和更多其他的命令（见下面）。内建命令出现在所有的Tcl应用程序中。
第二组命令使用Tcl扩展机制来创建。Tcl提供许多API接口，允许你用C或C++编写一个命令过程来创建一个新的命令。然后你可以通过Tcl解释器来通知Tcl过程实现的命令名，来注册命令过程。以后只要那个特定的名称被当作Tcl命令来使用，Tcl就会调用你的命令过程来执行这个命令。其实内建命令也是使用同样的扩展机制来执行的，只不过它们的命令过程是Tcl库中的一部分。
当Tcl用于嵌入到一个应用程序中的时候，应用程序使用扩展机制把它的主要功能和Tcl结合起来，这样一来那些可用的Tcl命令就因程序的不同而不同。还有大量的扩展包可以和Tcl应用程序组合起来使用。Tk是最著名的扩展之一，它提供了许多强大的创建图形用户界面的工具。而其他的扩展则提供了面向对象的编程，数据库访问，更多的图形功能，及其他的一些特性。用Tcl来创建完整的应用程序的优势之一是它可以很方便的进行扩展，从而可以组合进新的功能或与其它的资源进行通信。
第三组命令是一些由proc命令创建的过程。比如上面创建的power命令。通常，扩展用于较低层的功能，用C语言实现比较方便；而过程用于较高层的功能，用Tcl实现比较方便。
其它的功能
Tcl除了前面的例子中所使用的命令外，还有许多其它的命令，这里举例给出一些内建的Tcl命令所具有的功能：
☆ 更多的控制结构，如if,for,foreach和switch
☆ 字符串操作，包括一个强大的规则表达式匹配工具。不定长字符串可以像数字一样被传递和操作
☆ I/O 输入输出包括磁盘，网络通信通道，和类似串口的设备中的文件。Tcl为在Internet上进行通信提供了非常方便的工具
☆ 文件管理：Tcl提供许多命令来操作文件名，读写文件属性，复制文件，删除文件，创建目录，等等
☆ 分支过程的实现：你可以使用exec命令来运行其他程序，并且可以在它们的运行过程中和它们进行通信
☆ Lists Tcl使创建数值的集合变得很容易，并且可以用许多方式来对它们进行操作
☆ 数组 你可以创建有成对的名称数值组成的结构化数值，同时可以使用不定长字符串来定义这些名称和数值
☆ 可以对时间和日期进行操作
☆ Events允许等待一定的事件发生后再触发Tcl脚本，比如一段时间的延迟或是网络通信中输入的数据变为有效
Tcl是一种非常简单的编程语言，如果你以前曾经学过编程，那么你只要学习几个小时就可以编写出一些有趣的Tcl程序。本文将对Tcl的功能做一个大概的介绍。一般来说，读完本文之后，你就可以开始独立的编写一些简单的Tcl脚本了；不过，要想获得更全面的认识，我们建议你还是去参考几本目前已经出版的Tcl书籍。
基本语法
Tcl脚本由一些被换行符或是分号分开的命令所组成。命令都有相同的基本格式，如下面的例子所示：
expr 20 + 10
该命令计算20加10的和，并返回结果30。你可以把这个例子以及本文中的所有其它的例子键入到tclsh这样的Tcl应用程序中来验证它们；在一个命令结束后，tclsh将打印出它的结果。
每个Tcl命令都含有一个或多个被空格分开的单词，在这个例子中有4个单词：expr,20,+,和10。第一个单词是一个命令名，其余的单词是这个命令的参数。所有的Tcl命令都含有一些单词，但不同的命令对他们的参数有不同的处理方式。expr命令把它的所有参数看作是一个算术表达式，计算表达式的结果，并以字符串的形式返回结果。在expr命令中，单词之间的分隔不是很重要：同样的命令你可以写成这种形式：
expr 20+10
不过，对大部分的命令来说，单词的结构是很重要的。每个单词都会用于不同的目的。所有的Tcl命令都返回结果。如果一个命令产生了没有意义的结果，那么它将返回一个空字符串作为它的结果。
变量
Tcl允许你在变量中保存数值，并且可以在后续的命令中使用这些数值。set命令用于对变量进行读写操作。比如，下面的命令对变量x赋值为32。
set x 32
这个命令返回变量的新值。你可以让set只带一个参数来读出变量的数值：
set x
你不需要在Tcl中声明变量：变量在第一次set的时候被自动创建。Tcl变量没有类型：任何值可以赋给任何变量。
要想在一个命令中使用变量的值，可以采用变量替代，如下例所示：
expr $x*3
当一个字符$出现在一个命令中的时候，Tcl把跟在它后面的字母和数字看作是一个变量名并且将其替换成变量的值。在这个例子中，expr命令接收到的实际参数将是32*3（假设变量x在前面的例子中被set过）。你可以在任何命令的任何单词中使用变量替代，甚至对一个单词多次使用：
set cmd expr
set x 11
$cmd $x*$x
命令替代
你也可以在一个命令的参数中使用另一个命令的结果。这被称之为命令替代：
set a 44
set b [expr $a*4]
当中括号出现在一个命令中的时候，Tcl把中括号之间的所有语句看作是一组Tcl命令。Tcl对这组命令进行解释，并用结果替代中括号之间的文字。上面的例子中，第二个set命令的第二个参数将为176。
双引号和大括号
双引号允许你指定包含空格的单词。我们看下面的这个例子：
set x 24
set y 18
set z "$x + $y is [expr $x + $y]"
在这三个命令都被解释后，变量z的值将是24+18 is 42。双引号之间的所有语句作为一个单词传给set命令。此处需要注意几点（a）引号之间的命令和变量替代仍起作用，（b）引号自身不会被传给命令。如果没有引号的话，set命令会得到6个参数，这将引起错误。
花括号对单词提供另外一种组合信息的方式。它与双引号的不同之处在于：花括号内的替代不起作用：
set z {$x + $y is [expr $x +$y]}
这个命令把变量z赋值为 " $x + $y is [expr $x +$y]"。
控制结构
Tcl提供一整套控制结构包括条件，循环和过程。Tcl的控制结构只是一些将Tcl脚本作为参数的命令。下面的示例创建了一个叫做power的Tcl的过程，实现对一个数求它的n次方：
proc power {base p}{
set result 1
while {$p >0}{
set result [expr $result * $base]
set p [expr $p- 1]
}
return $result
}
这个脚本由一个简单的命令proc所组成，这个proc命令有3个参数：过程名，参数名列表和过程体。过程体是一个Tcl脚本。需要注意的是，第一行末尾的花括号和最后一行花括号之间的语句都被逐字逐句的作为一个参数传给proc。proc命令创建了一个新的叫做power的具有两个参数的Tcl命令。你可以这样来调用power：
power 2 6
power 1.15 5
当power被调用的时候，过程体就被解释了。当过程体执行的时候，它可以变量的形式进入它的参数中：base获得第一个参数，p获得第二个参数。
power过程体中包含3个Tcl命令：set,while和return。while命令完成了这个过程中的大部分工作。它有两个参数，一个表达式（$p>0）和一个Tcl脚本写的主体。while命令使用与C语言相似的规则来解释它的表达式参数。如果结果是真（非零），那么它将把函数体作为脚本来执行。他不断的重复这个过程，直到最后表达式的值变为假（零）。在这个例子中，while命令的函数体将result的值与base相乘，然后减少p的值。当p的值减到零的时候，结果就包含了需要的base的n次方值。return命令的作用是退出过程，同时将变量result的值作为过程的结果返回。
命令是如何运作的？
正如你所见到的，Tcl中所有有趣的功能都是靠命令来描述的。声明是命令，表达式由可执行命令来解释，控制结构是命令，过程也是命令。
Tcl命令由3种方式来创建。一组命令由Tcl解释器自身来提供。这些命令称之为内建命令，他们包括到现在为止你已经看到的命令和更多其他的命令（见下面）。内建命令出现在所有的Tcl应用程序中。
第二组命令使用Tcl扩展机制来创建。Tcl提供许多API接口，允许你用C或C++编写一个命令过程来创建一个新的命令。然后你可以通过Tcl解释器来通知Tcl过程实现的命令名，来注册命令过程。以后只要那个特定的名称被当作Tcl命令来使用，Tcl就会调用你的命令过程来执行这个命令。其实内建命令也是使用同样的扩展机制来执行的，只不过它们的命令过程是Tcl库中的一部分。
当Tcl用于嵌入到一个应用程序中的时候，应用程序使用扩展机制把它的主要功能和Tcl结合起来，这样一来那些可用的Tcl命令就因程序的不同而不同。还有大量的扩展包可以和Tcl应用程序组合起来使用。Tk是最著名的扩展之一，它提供了许多强大的创建图形用户界面的工具。而其他的扩展则提供了面向对象的编程，数据库访问，更多的图形功能，及其他的一些特性。用Tcl来创建完整的应用程序的优势之一是它可以很方便的进行扩展，从而可以组合进新的功能或与其它的资源进行通信。
第三组命令是一些由proc命令创建的过程。比如上面创建的power命令。通常，扩展用于较低层的功能，用C语言实现比较方便；而过程用于较高层的功能，用Tcl实现比较方便。
其它的功能
Tcl除了前面的例子中所使用的命令外，还有许多其它的命令，这里举例给出一些内建的Tcl命令所具有的功能：
☆ 更多的控制结构，如if,for,foreach和switch
☆ 字符串操作，包括一个强大的规则表达式匹配工具。不定长字符串可以像数字一样被传递和操作
☆ I/O 输入输出包括磁盘，网络通信通道，和类似串口的设备中的文件。Tcl为在Internet上进行通信提供了非常方便的工具
☆ 文件管理：Tcl提供许多命令来操作文件名，读写文件属性，复制文件，删除文件，创建目录，等等
☆ 分支过程的实现：你可以使用exec命令来运行其他程序，并且可以在它们的运行过程中和它们进行通信
☆ Lists Tcl使创建数值的集合变得很容易，并且可以用许多方式来对它们进行操作
☆ 数组 你可以创建有成对的名称数值组成的结构化数值，同时可以使用不定长字符串来定义这些名称和数值
☆ 可以对时间和日期进行操作
☆ Events允许等待一定的事件发生后再触发Tcl脚本，比如一段时间的延迟或是网络通信中输入的数据变为有效
bjay 2003-09-05
- 打赏
- 举报
了解一下。
andersky 2003-09-04
- 打赏
- 举报
没有接触过，以前只是听说过
看来要学习了解一下
看来要学习了解一下
mmxxt 2003-09-04
- 打赏
- 举报
UP
Nvram 2003-09-03
- 打赏
- 举报
================ 第2部分 ===============
The GNU extension language plan
Here is the plan for achieving the design goals stated above.
* Step 1. The base language should be modified Scheme, with these features:
** Case-sensitive symbol names.
** No distinction between #f and (), for the sake of supporting Lisp
as well as Scheme.
** Convenient fast exception handling, and catch and throw.
** Extra slots in a symbol, to better support
translating other Lisp dialects into Scheme.
** Multiple obarrays.
** Flexible string manipulation functions.
** Access to all or most of the Unix system calls.
** Convenient facilities for forking pipelines,
making redirections, and so on.
** Two interfaces for call-outs to C code.
One allows the C code to work on arbitrary Scheme data.
The other passes strings only, and is compatible with Tcl
C callouts provided the C function does not try to call
the Tcl interpreter.
** Cheap built-in dynamic variables (as well as Scheme's lexical variables).
** Support for forwarding a dynamic variable's value
into a C variable.
** A way for applications to define additional Scheme data types
for application-specific purposes.
** A place in a function to record an interactive argument reading spec.
** An optional reader feature to convert nil to #f and t to #t,
for the sake of supporting Lisp as well as Scheme.
** An interface to the library version of expect.
** Backtrace and debugging facilities.
All of these things are either straightforward or have already been
done in Scheme systems; the task is to put them together. We are
going to start with SCM, add some of these features to it, and write
the rest in Scheme, using existing implementations where possible.
* Step 2. Other languages should be implemented on top of Scheme.
** Rush is a cleaned-up version of the Tcl language, which runs far
faster than Tcl itself, by means of translation into Scheme. Some
kludgy but necessary Tcl constructs don't work in Rush, and Tcl
aficionadoes may be unhappy about this; but Rush provides cleaner ways
to get the same results, so users who write extensions should like it
better. Developers looking for an extension language are likely to
prefer Rush to Tcl if they are not already attached to Tcl.
Here are a couple of examples supplied by Adam Sah:
*** To pass an array argument without copying it, in Tcl you must use
upvar or make the array a global variable. In Rush, you can simply
declare the argument "pass by reference".
*** To extract values from a list and pass them as separate arguments
to a function, in Tcl you must construct a function call expression
using that list, and then evaluate it. This can cause trouble if the
other arguments contain text that includes any special Tcl syntax. In
Rush, the apply function handles this simply and reliably.
*** Rush eliminates the need for the "expr" command by allowing infix
mathematical expressions and statements. For example, the Tcl
computation `"set a [expr $b*$c]' can be written as `a = b*c' in
Rush. (The Tcl syntax works also.)
Some references:
[SBD94] Adam Sah, Jon Blow and Brian Dennis. "An Introduction to the Rush
Language." Proc. Tcl'94 Workshop. June, 1994.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-tcl94.*
[SB94] Adam Sah and Jon Blow. "A New Architecture for the Implementation of
Scripting Languages." Proc. USENIX Symp. on Very High Level Languages.
October, 1994. to appear.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-vhll94.*
** It appears that Emacs Lisp can be implemented efficiently by
translation into modified Scheme (the modifications are important).
** Python appears suitable for such an implementation, as far as I can
tell from a quick look. By "suitable" I mean that mostly the same
language could be implemented--minor changes in semantics would be ok.
(It would be useful for someone to check this carefully.)
** A C-like language syntax can certainly be implemented this way.
* Distribution conditions.
We will permit use of the modified Scheme interpreter in proprietary
programs, so as to compete effectively with alternative extensibility
packages.
Translators from other languages to modified Scheme will not be part
of any application; each individual user will decide when to use one
of these. Therefore, there is no special reason not to use the GPL as
the distribution terms for translators. So we will encourage
developers of translators to use the GPL as distribution terms.
Conclusion
Until today, users have not been able to choose which extension
language to use. They have always been compelled to use whichever
language is supposed by the tool they wish to extend. And that has
meant many different languages for different tools.
Adopting Tcl as the universal scripting language offers the
possibility of eliminating the incompatibility--users would be able to
extend everything with just one language. But they wouldn't be able
to choose which language. They would be compelled to use Tcl and
nothing else.
By making modified Scheme the universal extension language, we can
give users a choice of which language to write extensions in. We can
implement other languages, including modified Tcl (Rush), a Python
variant, and a C-like language, through translation into Scheme, so
that each user can choose the language to use. Even users who choose
modified Tcl will benefit from this decision--they will be happy with
the speedup they get from an implementation that translates into
Scheme.
Only Scheme, or something close to Scheme, can serve this purpose.
Tcl won't do the job. You can't implement Scheme or Python or Emacs
Lisp with reasonable performance on top of Tcl. But modified Scheme
can support them all, and many others.
The universal extension language should be modified Scheme.
Request for Volunteers
If you understand Scheme implementation well, and you want to
contribute a substantial amount of time to this project, please send
mail to Tom Lord, lord@gnu.ai.mit.edu.
If you expect to have time later but don't have time now, please send
mail when you do have time to work. Participation in a small way is
probably not useful until after the package is released.
The GNU extension language plan
Here is the plan for achieving the design goals stated above.
* Step 1. The base language should be modified Scheme, with these features:
** Case-sensitive symbol names.
** No distinction between #f and (), for the sake of supporting Lisp
as well as Scheme.
** Convenient fast exception handling, and catch and throw.
** Extra slots in a symbol, to better support
translating other Lisp dialects into Scheme.
** Multiple obarrays.
** Flexible string manipulation functions.
** Access to all or most of the Unix system calls.
** Convenient facilities for forking pipelines,
making redirections, and so on.
** Two interfaces for call-outs to C code.
One allows the C code to work on arbitrary Scheme data.
The other passes strings only, and is compatible with Tcl
C callouts provided the C function does not try to call
the Tcl interpreter.
** Cheap built-in dynamic variables (as well as Scheme's lexical variables).
** Support for forwarding a dynamic variable's value
into a C variable.
** A way for applications to define additional Scheme data types
for application-specific purposes.
** A place in a function to record an interactive argument reading spec.
** An optional reader feature to convert nil to #f and t to #t,
for the sake of supporting Lisp as well as Scheme.
** An interface to the library version of expect.
** Backtrace and debugging facilities.
All of these things are either straightforward or have already been
done in Scheme systems; the task is to put them together. We are
going to start with SCM, add some of these features to it, and write
the rest in Scheme, using existing implementations where possible.
* Step 2. Other languages should be implemented on top of Scheme.
** Rush is a cleaned-up version of the Tcl language, which runs far
faster than Tcl itself, by means of translation into Scheme. Some
kludgy but necessary Tcl constructs don't work in Rush, and Tcl
aficionadoes may be unhappy about this; but Rush provides cleaner ways
to get the same results, so users who write extensions should like it
better. Developers looking for an extension language are likely to
prefer Rush to Tcl if they are not already attached to Tcl.
Here are a couple of examples supplied by Adam Sah:
*** To pass an array argument without copying it, in Tcl you must use
upvar or make the array a global variable. In Rush, you can simply
declare the argument "pass by reference".
*** To extract values from a list and pass them as separate arguments
to a function, in Tcl you must construct a function call expression
using that list, and then evaluate it. This can cause trouble if the
other arguments contain text that includes any special Tcl syntax. In
Rush, the apply function handles this simply and reliably.
*** Rush eliminates the need for the "expr" command by allowing infix
mathematical expressions and statements. For example, the Tcl
computation `"set a [expr $b*$c]' can be written as `a = b*c' in
Rush. (The Tcl syntax works also.)
Some references:
[SBD94] Adam Sah, Jon Blow and Brian Dennis. "An Introduction to the Rush
Language." Proc. Tcl'94 Workshop. June, 1994.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-tcl94.*
[SB94] Adam Sah and Jon Blow. "A New Architecture for the Implementation of
Scripting Languages." Proc. USENIX Symp. on Very High Level Languages.
October, 1994. to appear.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-vhll94.*
** It appears that Emacs Lisp can be implemented efficiently by
translation into modified Scheme (the modifications are important).
** Python appears suitable for such an implementation, as far as I can
tell from a quick look. By "suitable" I mean that mostly the same
language could be implemented--minor changes in semantics would be ok.
(It would be useful for someone to check this carefully.)
** A C-like language syntax can certainly be implemented this way.
* Distribution conditions.
We will permit use of the modified Scheme interpreter in proprietary
programs, so as to compete effectively with alternative extensibility
packages.
Translators from other languages to modified Scheme will not be part
of any application; each individual user will decide when to use one
of these. Therefore, there is no special reason not to use the GPL as
the distribution terms for translators. So we will encourage
developers of translators to use the GPL as distribution terms.
Conclusion
Until today, users have not been able to choose which extension
language to use. They have always been compelled to use whichever
language is supposed by the tool they wish to extend. And that has
meant many different languages for different tools.
Adopting Tcl as the universal scripting language offers the
possibility of eliminating the incompatibility--users would be able to
extend everything with just one language. But they wouldn't be able
to choose which language. They would be compelled to use Tcl and
nothing else.
By making modified Scheme the universal extension language, we can
give users a choice of which language to write extensions in. We can
implement other languages, including modified Tcl (Rush), a Python
variant, and a C-like language, through translation into Scheme, so
that each user can choose the language to use. Even users who choose
modified Tcl will benefit from this decision--they will be happy with
the speedup they get from an implementation that translates into
Scheme.
Only Scheme, or something close to Scheme, can serve this purpose.
Tcl won't do the job. You can't implement Scheme or Python or Emacs
Lisp with reasonable performance on top of Tcl. But modified Scheme
can support them all, and many others.
The universal extension language should be modified Scheme.
Request for Volunteers
If you understand Scheme implementation well, and you want to
contribute a substantial amount of time to this project, please send
mail to Tom Lord, lord@gnu.ai.mit.edu.
If you expect to have time later but don't have time now, please send
mail when you do have time to work. Participation in a small way is
probably not useful until after the package is released.
Nvram 2003-09-03
- 打赏
- 举报
但是，那应该用什么替代TCL呢？
再转贴：GNU扩展语言计划
作者： Richard Stallman
================== 第1部分 =================
GNU Extension Language Plans
Tom Lord (lord@gnu.ai.mit.edu)
Wed, 19 Oct 94 00:20:18 -0400
GNU Extension Language Plans
Richard Stallman, GNU Project
[Please redistribute widely]
Many software packages need an extension language to make it easier
for users to add to and modify the package.
In a previous message I explained why Tcl is inadequate as an
extension language, and stated some design goals for the extension
language for the GNU system, but I did not choose a specific
alternative.
At the time, I had not come to a conclusion about what to do. I knew
what sort of place I wanted to go, but not precisely where or how to
get there.
Since then, I've learned a lot more about the topic. I've read about
scsh, Rush and Python, and talked with people working on using Scheme
as an extension and scripting language. Now I have formulated a
specific plan for providing extensibility in the GNU system.
Who chooses which language?
Ousterhour, the author of Tcl, responded to my previous message by
citing a "Law" that users choose the language they prefer, and
suggested that we each implement our favorite languages, then sit back
and watch as the users make them succeed or fail.
Unfortunately, extension languages are the one case where users
*cannot* choose the language they use. They have to use the language
supported by the application or tool they want to extend. For
example, if you wanted to extend PDP-10 Emacs, you had to use TECO.
If you want to extend GNU Emacs, you have to use Lisp.
When users simply want "to write a program to do X or Y," they can use
any language the system supports. There's no reason for system
designers to try to decide which language is best. We can instead
provide as many languages as possible, to give each user the widest
possible choice. In the GNU system, I would like to support every
language people want to use--provided someone will implement them.
With the methods generally used today, we cannot easily provide many
languages for extending any particular utility or application package.
Supporting an extension language means a lot of work for the developer
of the package. Supporting two languages is twice as much work,
supposing the two fit together at all. In practice, the developer has
to choose a language--and then all users of the package are stuck with
that one. For example, when I wrote GNU Emacs, I had to decide which
language to support. I had no way to let the users decide.
When a developer chooses Tcl, that has two consequences for the
users of the package:
* They can use Tcl if they wish. That's fine with me.
* They can't use any other language. That I consider a problem.
Sometimes developers choose a language because they like it. But not
always. Sun recently announced a campaign to "make Tcl the universal
scripting language." This is a campaign to convince all the
developers who *don't* prefer Tcl that they really have no choice.
The idea is that each one of us will believe that Sun will inevitably
convince everyone else to use Tcl, and each of us will feel compelled
to follow where we believe the rest are going.
That campaign is what led me to decide that I needed to speak to the
community about the issue. By announcing on the net that GNU software
packages won't use Tcl, I hope to show programmers that not everyone
is going to jump on the Tcl bandwagon--so they don't have to feel
compelled to do so. If developers choose to support Tcl, it should be
because they want to, not because Sun convinces them they have no
choice.
Design goals for GNU
When you write a program, or when you modify a GNU program, I think
you should be the one who decides what to implement. I can't tell you
what language to support, and I wouldn't want to try.
But I am the leader of one particular project, the GNU project. So I
make the decision about which packages to include in the GNU operating
system, and which design goals to aim for in developing the GNU
system.
These are the design goals I've decided on concerning extension
languages in the GNU system:
* As far as possible, all GNU packages should support the same
extension languages, so that a user can learn one language (any one of
those we support) and use it in any package--including Emacs.
* The languages we support should not be limited to special, weak
"scripting languages". They should be designed to be good for writing
large programs as well as small ones.
My judgement is that Tcl can't satisfy this goal. (Ousterhout seems
to agree that Tcl doesn't serve this goal. He thinks that doesn't
constitute a problem--I think it does.) That's why I've decided not
to use Tcl as the main system-wide extension language of the GNU
system.
* It is important to support a Lisp-like language, because they
provide certain special kinds of power, such as representing programs
as data in a structured way that can be decoded without parsing.
** It is desirable to support Scheme, because it is simple and clean.
** It is desirable to support Emacs Lisp, for compatibility with Emacs
and the code already written for Emacs.
* It is important to support a more usual programming language syntax
for users who find Lisp syntax too strange.
* It would be good to support Tcl as well, if that is easy to do.
再转贴：GNU扩展语言计划
作者： Richard Stallman
================== 第1部分 =================
GNU Extension Language Plans
Tom Lord (lord@gnu.ai.mit.edu)
Wed, 19 Oct 94 00:20:18 -0400
GNU Extension Language Plans
Richard Stallman, GNU Project
[Please redistribute widely]
Many software packages need an extension language to make it easier
for users to add to and modify the package.
In a previous message I explained why Tcl is inadequate as an
extension language, and stated some design goals for the extension
language for the GNU system, but I did not choose a specific
alternative.
At the time, I had not come to a conclusion about what to do. I knew
what sort of place I wanted to go, but not precisely where or how to
get there.
Since then, I've learned a lot more about the topic. I've read about
scsh, Rush and Python, and talked with people working on using Scheme
as an extension and scripting language. Now I have formulated a
specific plan for providing extensibility in the GNU system.
Who chooses which language?
Ousterhour, the author of Tcl, responded to my previous message by
citing a "Law" that users choose the language they prefer, and
suggested that we each implement our favorite languages, then sit back
and watch as the users make them succeed or fail.
Unfortunately, extension languages are the one case where users
*cannot* choose the language they use. They have to use the language
supported by the application or tool they want to extend. For
example, if you wanted to extend PDP-10 Emacs, you had to use TECO.
If you want to extend GNU Emacs, you have to use Lisp.
When users simply want "to write a program to do X or Y," they can use
any language the system supports. There's no reason for system
designers to try to decide which language is best. We can instead
provide as many languages as possible, to give each user the widest
possible choice. In the GNU system, I would like to support every
language people want to use--provided someone will implement them.
With the methods generally used today, we cannot easily provide many
languages for extending any particular utility or application package.
Supporting an extension language means a lot of work for the developer
of the package. Supporting two languages is twice as much work,
supposing the two fit together at all. In practice, the developer has
to choose a language--and then all users of the package are stuck with
that one. For example, when I wrote GNU Emacs, I had to decide which
language to support. I had no way to let the users decide.
When a developer chooses Tcl, that has two consequences for the
users of the package:
* They can use Tcl if they wish. That's fine with me.
* They can't use any other language. That I consider a problem.
Sometimes developers choose a language because they like it. But not
always. Sun recently announced a campaign to "make Tcl the universal
scripting language." This is a campaign to convince all the
developers who *don't* prefer Tcl that they really have no choice.
The idea is that each one of us will believe that Sun will inevitably
convince everyone else to use Tcl, and each of us will feel compelled
to follow where we believe the rest are going.
That campaign is what led me to decide that I needed to speak to the
community about the issue. By announcing on the net that GNU software
packages won't use Tcl, I hope to show programmers that not everyone
is going to jump on the Tcl bandwagon--so they don't have to feel
compelled to do so. If developers choose to support Tcl, it should be
because they want to, not because Sun convinces them they have no
choice.
Design goals for GNU
When you write a program, or when you modify a GNU program, I think
you should be the one who decides what to implement. I can't tell you
what language to support, and I wouldn't want to try.
But I am the leader of one particular project, the GNU project. So I
make the decision about which packages to include in the GNU operating
system, and which design goals to aim for in developing the GNU
system.
These are the design goals I've decided on concerning extension
languages in the GNU system:
* As far as possible, all GNU packages should support the same
extension languages, so that a user can learn one language (any one of
those we support) and use it in any package--including Emacs.
* The languages we support should not be limited to special, weak
"scripting languages". They should be designed to be good for writing
large programs as well as small ones.
My judgement is that Tcl can't satisfy this goal. (Ousterhout seems
to agree that Tcl doesn't serve this goal. He thinks that doesn't
constitute a problem--I think it does.) That's why I've decided not
to use Tcl as the main system-wide extension language of the GNU
system.
* It is important to support a Lisp-like language, because they
provide certain special kinds of power, such as representing programs
as data in a structured way that can be decoded without parsing.
** It is desirable to support Scheme, because it is simple and clean.
** It is desirable to support Emacs Lisp, for compatibility with Emacs
and the code already written for Emacs.
* It is important to support a more usual programming language syntax
for users who find Lisp syntax too strange.
* It would be good to support Tcl as well, if that is easy to do.
Nvram 2003-09-03
- 打赏
- 举报
转贴：为什么不应该使用TCL
作者：Richard Stallman
==================== 全文 ====================
Why you should not use Tcl
Richard Stallman (rms@gnu.ai.mit.edu)
Fri, 23 Sep 94 19:14:52 -0400
Why you should not use Tcl
Richard Stallman, GNU Project
As interest builds in extensible application programs and tools, and
some programmers are tempted to use Tcl, we should not forget the
lessons learned from the first widely used extensible text
editor--Emacs.
The principal lesson of Emacs is that a language for extensions should
not be a mere "extension language". It should be a real programming
language, designed for writing and maintaining substantial programs.
Because people will want to do that!
Extensions are often large, complex programs in their own right, and
the people who write them deserve the same facilities that other
programmers rely on.
The first Emacs used a string-processing language, TECO, which was
inadequate. We made it serve, but it kept getting in our way. It
made maintenance harder, and it made extensions harder to write.
Later Emacs implementations have used more powerful languages because
implementors learned from the problems of the first one.
Another lesson from Emacs is that the way to make sure an extension
facility is really flexible is to use it to write a large portion of
the ordinary released system. If you try to do that with Tcl, you
will encounter its limitations.
Tcl was not designed to be a serious programming language. It was
designed to be a "scripting language", on the assumption that a
"scripting language" need not try to be a real programming language.
So Tcl doesn't have the capabilities of one. It lacks arrays; it
lacks structures from which you can make linked lists. It fakes
having numbers, which works, but has to be slow. Tcl is ok for
writing small programs, but when you push it beyond that, it becomes
insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
For these reasons, the GNU project is not going to use Tcl in GNU
software. Instead we want to provide two languages, similar in
semantics but with different syntaxes. One will be Lisp-like, and one
will have a more traditional algebraic syntax. Both will provide
useful data types such as structures and arrays. The former will
provide a simple syntax that hackers like; the latter will offer
non-hackers a syntax that they are more comfortable with.
Some people plan to use Tcl because they want to use Tk. Thankfully,
it is possible to use Tk without Tcl. A Scheme interpreter called STk
is already available. Please, if you want to use Tk, use it with STk,
not with Tcl. One place to get STk is from
ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
作者：Richard Stallman
==================== 全文 ====================
Why you should not use Tcl
Richard Stallman (rms@gnu.ai.mit.edu)
Fri, 23 Sep 94 19:14:52 -0400
Why you should not use Tcl
Richard Stallman, GNU Project
As interest builds in extensible application programs and tools, and
some programmers are tempted to use Tcl, we should not forget the
lessons learned from the first widely used extensible text
editor--Emacs.
The principal lesson of Emacs is that a language for extensions should
not be a mere "extension language". It should be a real programming
language, designed for writing and maintaining substantial programs.
Because people will want to do that!
Extensions are often large, complex programs in their own right, and
the people who write them deserve the same facilities that other
programmers rely on.
The first Emacs used a string-processing language, TECO, which was
inadequate. We made it serve, but it kept getting in our way. It
made maintenance harder, and it made extensions harder to write.
Later Emacs implementations have used more powerful languages because
implementors learned from the problems of the first one.
Another lesson from Emacs is that the way to make sure an extension
facility is really flexible is to use it to write a large portion of
the ordinary released system. If you try to do that with Tcl, you
will encounter its limitations.
Tcl was not designed to be a serious programming language. It was
designed to be a "scripting language", on the assumption that a
"scripting language" need not try to be a real programming language.
So Tcl doesn't have the capabilities of one. It lacks arrays; it
lacks structures from which you can make linked lists. It fakes
having numbers, which works, but has to be slow. Tcl is ok for
writing small programs, but when you push it beyond that, it becomes
insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
For these reasons, the GNU project is not going to use Tcl in GNU
software. Instead we want to provide two languages, similar in
semantics but with different syntaxes. One will be Lisp-like, and one
will have a more traditional algebraic syntax. Both will provide
useful data types such as structures and arrays. The former will
provide a simple syntax that hackers like; the latter will offer
non-hackers a syntax that they are more comfortable with.
Some people plan to use Tcl because they want to use Tk. Thankfully,
it is possible to use Tk without Tcl. A Scheme interpreter called STk
is already available. Please, if you want to use Tk, use it with STk,
not with Tcl. One place to get STk is from
ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
mmxxt 2003-09-03
- 打赏
- 举报
up
mmxxt 2003-08-30
- 打赏
- 举报
你是不是没设置好啊
rogueking 2003-08-29
- 打赏
- 举报
tcltk在windows下每个程序都有个dos框，非常不爽，所以不用！
mmxxt 2003-08-27
- 打赏
- 举报
up
mmxxt 2003-08-24
- 打赏
- 举报
up
bit7 2003-08-23
- 打赏
- 举报
up
mmxxt 2003-08-20
- 打赏
- 举报
tcltk在windows下对中文的支持已经有了很大的改进
现在的最新版本是 ActiveTcl 8.4.4
现在的最新版本是 ActiveTcl 8.4.4
whoonline 2003-08-19
- 打赏
- 举报
但我用的是Python的Tkinter,感觉Tcl/Tk对中文支持太差,而且在windows下不太稳定.
加载更多回复（3）
