发信人: 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，不值得吗？

软件生命周期不能只考虑发展阶段呀!

评论