发信人: ajax@phoenix (ajax), 信区: programming 发信站: 交大资工凤凰城信息站 (Sat Apr  2 08:59:46 1994) ==> 在 TwoO@nctu_csie_bbs (O-O) 的文章中提到: >> 太依赖 stack operation, 缺乏自然; > 其实 Forth 的 word 相当于 C 里的 function，可见 Forth 的高度模块化。 > 各模块间要有一致的传递界面，最理想的是什么？  答案是 Stack。  在一般 > 的模块化语言中，大多也都是用 stack 来传递参数，传回值有些虽不用 stack > ，但却因而有传回值个数的问题。 > 在做运算时直接以 item in stack 做为 operand 有什么好处呢？  在硬件上 > 可以少掉 operand 的 encode/decode，在软件上由于不用在 compile(/link) > 时去计算 operand 的地址，速度变得很快，也因而使 design->coding->test > 这个发展循环变得非常快，并使得 interactive develop 容易达成。 > PS. 在 C 中要测试刚写好的 function 正不正确有多麻烦，大家应该都印象 >     深刻。  如果等到程序全写完时才测试，结果就不用我说了。     其实用 stack传参数最大的好处是很容易做到 reentrance, 因此 Forth很容易加上 round robin 的 multi-tasking 功能, 但是 stack的处理可能得留心些, 一不小心就留下一堆垃圾或 underflow.     interactive develop 的环境实在太棒了, 尤其是在搞 embedded system 时,不用为了测每一个 I/O写一个 assembler程序, 但我告诉别人, 总是会嫌再学一种语言麻烦, 奈何! >> 缺乏标准。 > 缺乏标准是由于 Forth 太有延伸性，你甚至可以将其改写成前置式或中置式。 > 这种强烈的自由度当然造成没有标准，使得各 Forth 系统的共通性大减。  有 > 鉴于此，Forth 还是有一些刻意定出来的标准（如 F83）。  但是〞标准就像 > 两面的刃〞，其中的拿捏非常难，不也有人将〞标准〞称为〞必要的罪恶〞吗？       ANSI 标准最近出笼了. ============================================================================== 发信人: william (C++/ASM/Win Master), 信区: 'programming' 发信站: 交大资科_BBS (Apr  2 15:18:30 1994) ==>[Author]: TwoO@nctu_csie_bbs (O-O) on board 'programming' >> 太依赖 stack operation, 缺乏自然; > 其实 Forth 的 word 相当于 C 里的 function，可见 Forth 的高度模块化。 > 各模块间要有一致的传递界面，最理想的是什么？  答案是 Stack。  在一般 > 的模块化语言中，大多也都是用 stack 来传递参数，传回值有些虽不用 stack > ，但却因而有传回值个数的问题。 在 PC 上, 有些 compiler (如 Watcom C, BC+ 3.1 以后) 就提供“缓存器传参数”以提高效率。而许多 RISC 更是如此。 所以我质疑的是: Forth 在“原始程序”层次就极度仰赖 stack operations,不知这样是否自然? 这是以programmer 的角度来看的; Forth 在 implementation上, 是否也真的高度仰赖 stack? 会不会降低效率? 还是说 Forth私底下会自动像 compiler 一样, 为个别的机器做个别的最佳化处理? 这是以低阶角度来看的。 > 在做运算时直接以 item in stack 做为 operand 有什么好处呢？  在硬件上 > 可以少掉 operand 的 encode/decode，在软件上由于不用在 compile(/link) > 时去计算 operand 的地址，速度变得很快，也因而使 design->coding->test > 这个发展循环变得非常快，并使得 interactive develop 容易达成。 如果我们用的是 Forth hardware 或 firmware, 就像 Lisp machine 那样的embedded, 我不怀疑它的效率。但如果是在传统的机器上, 所有你提到的那些operand 的部份都是 CPU自己处理, 不劳最后的执行档费心 (当然, compiler 会累些, 但以现在的技术而言, 这也不会“太”费事) , 所以执行档可以近乎该机器的全速执行。而如果语言不利用这些现成的资源, 而硬要自己处理, 造出一个 runtime virtual machine, 是否会产生 overhead? 当然, Forth 的 interactive 环境的确是一流的, 无其它语言能比。 >> 太依赖 RPN, 违反自小受教育以来的习惯; >> Conditional syntax 违反吾人习用的口语。 > 习惯靠左开车的人对靠右开感到不适应。  这还只是习惯的问题，两着间并无 > 好坏之分。  但若因为习惯而错过了更好的东西，那就不值得了。 的确。不过高阶的语言不就是希望语言适应人, 而非人去适应语言? 我知道 Forth的语法也可改成 infix等等, 但不知道这会不会影响 runtime 效率? >> 未和最新的 PLs 趋势连接。 > 最新的趋势？ 看起来怎么好像是〞最新流行春装〞？  依我自己的看法，现在 > 最新的语言不如 Forth 的地方还多着呢。 有人以 Forth做出 OO, 我知道, 台北的 BBS有。但还是和 C++ Eiffel 等等相去甚多。 近代程序型语言多要求 static scope, 但 Forth? 其它的地方待我想想... >> 语言和系统几乎为一体 (定义语言即定义系统) , 是一 overhead。 > Forth 系统本身就是用 Forth 定义出来的，而你的应用程序也是用 Forth 定义 > 出来的，通通都是 Forth。  就因为如此，Forth 才能和软硬件系统配合得那么 > 好，那么有延伸性。  由于 Forth 的 code generation 很快（前面说过了）， > 这个 overhead 变得很小。  如果你善用〞词典〞，那就几乎看不到 overhead > 。  用 Borland C++ 时有不喜欢的地方，你有试过改它的 IDE 吗？  在 LIB > 中加个 function 方不方便呢？ Forth 在 develop 上的成就无庸置疑。但如同我前面所提的, 我质疑的是final runtime。 > 另外，要把在 68K 上的 Forth 移到 x86 上怎么做？  把 Meta-File 里的东西 > （都是些 Forth 里最基本的东西）用机器码重新定义一次，然后再 Meta-Compile > 一下，就好了(对，就好了）。 > 有这么大的自由，却只多了那么一点小到〞可能〞看不到的 overhead，不值得吗？ 软件生命周期不能只考虑发展阶段呀!

评论