* note about compiler-semantic [1st version]
  1. use hash-table in assembly to implement
     better compiler-semantic
  2. 在编译的时候
     当在函数体中遇到
     未定义的词的时候
     把它们记录在一个数组中
  3. 然后当定义一个新的函数的时候
     搜索这个数组看有没有比配的词
     这时 在函数体中这些词 已经能够用这个新定义的词来定义了
  4. 但是注意
     这不适用于 语法关键词
     也就是说在使用一个语法关键词之前还是必须
     先定义 这个语法关键词
     这种差异很不好 但是没有办法
  5. 并且这里需要 做更多的错误处理
     比如:
     1) 当新定义了一个语法关键词
        而在 数组中搜索到了相同的词
        这个时候就需要报错
  6. 在传统的编译过程中通过 multi-pass
     可以以正确的方式实现 上面的东西
  7. about incremetal compiler
     这一点让我明白了
     我所使用的技术不能被称为是 渐进编译
     而只是一个 语言的用户接口而已
  8. 我说过编译语义的特点
     就是 当它需要处理源代码的时候
     所有的源代码 它都能够看见
     而解释器在每一时刻仅能看见局部的源代码
  9. 在语言的用户接口中
     要想以正确的方式实现 编译语义
     就必须完整地保存 以最原始的字符串形式呈现的源代码
     而不能用我在上面所指出的策略了
  10. 那么保存所有源代码的策略可行吗?
      难点在于 内存的动态分配
      可以说没有 GC 的时候
      几乎是不可能以正确的方式实现这个一特性的
  11. 我说过
      在编译语义下
      我可以直接把 GC 融合进语言的核心部分之内
      这在于我看到了 fasm 中用汇编代码实现的 cicada 的函数的性质
      因为 fasm 的 multi-pass
      所以这些函数在代码中的位置是无所谓的
      但是应该以什么方式在 cicada 的解释器中实现这一性质呢 ?
      我想 fasm 是这样实现内存分配的
      即 把整个源代码 (或信息充分的中间代码) 保存在一个 buffer 中
      在生成目标代码的时候 参照这个 buffer 中 所保存的信息
      在生成目标代码之后 释放这个 buffer 就行了
  12. 但是 这种策略在 cicada 中可行吗 ?
      首先 我有一个解释器的外表
      即代码是一段一段输入的
      例如 如果我 用下面这个策略 会出现什么困难吗? :
      1) 先去检查函数定义
         如果其中有未定义的 词
         就把这个一段源代码保存到 一个 buffer 中
         ><
         + 这是不行的
           因为 如果不先定义一个 词头 到 字典中的话
           就没法解决相互调用的的问题
  13. 当允许嵌套的时候
      一个函数体的 中的一部分
      可能会被用来定义 这个函数体中其他部分 所需要的 词
      比如 引发 我对 "ok" 的依赖 的就是这种情况
      这时 第二种策略就可能失效了
      第一种还是可行的
      + >< 保存源代码的策略是不合理的
        除非 要求 特殊处理 相互调用的情形
  14. 如果 每个语法关键词 所能编译到函数体内的东西
      都一定比 把其后的 词看作 函数时所编译进 函数体的多
      那么每次 遇到语法关键词 的时候
      + >< 也不行
        因为语法关键词 所使用的是 字符串
        而在定义好一个语法关键词的时候
        之前出现的需要用到这个语法关键词的函数体的字符串已经消失了
        + >< 除非我有 GC
          如果我把 GC 转移到汇编代码中
          那无异于 把所有的代码都用汇编写了
  15. scheme 好像也没有处理好这一情况
      语法关键词 必须 定义在 使用前
      语法关键词 会对表达式进行预处理
      在使用一个语法关键词之前 定义这个 语法关键词 是必须的
  16. 我就用最开始的方式来实现 我所希望编译语义了
      因为 古典 的 Forth 中
      不允许相互调用的函数 这种编译语义 很易于理解
      但是 当需要 写相互递归的函数的时候很不方便
      而 最开始的实现策略其实已经能够解决这个问题了
      也就是说 在使用一个语法关键词之前
      我要求用户必须定义这个语法关键词
      其合理性在于
      没有相互调用的语法关键词
      + >< 有吗 ?
        在 scheme 中 语法关键词 可以是递归的
      + 在 scheme 中 定义 一个 语法关键词 之前也可以使用它
        因为 scheme 中 用 list of symbol 来保存 源代码
      不合理性在于
      这里的实现方式 并不入 scheme 好
      因为 在 scheme 中 虽然 语法关键词 不能递归调用
      但是其顺序却可以是无关的
      + scheme 的优越性 其实可以被 cicada 超越
        只要 我有了基本的编译语义之后
        能够使用 GC 来重新定义编译器了 就行了
        那个时候 不管是 用 symbol 还是 用 string 来表达 代码
        我都不用关心 内存分配的问题了