* remove old notes
** lambda calculus in cicada
   1. 我發現cicada讓我對lambda-cal的理解產生了變化
      也就是在用函數複合語義來實現lambda-cal的過程中
      因爲表達方式的變化
      而讓我看到了我以前沒有認識到的東西
      比如lambda-term的嵌套
      在cicada中也能形成lambda-term的嵌套
      只不過所使用的語法元素更多了
      也許這讓表達變得繁瑣了
      也許這讓表達變得清晰了
   2. 以函數複合語義爲基礎的表達是否適合用來實現digrap ???
      我必須探索一下可能性
      要知道在沒有副作用的λ-cal中每一次計算都是rewrite
      而每次rewriting都是由λ-application引起的
      但是在cicada中現在對λ-cal的實現方式卻很不一樣
      在cicada中需要:
      1) 準備參數
      2) 製作lambda-body
         即 λ-abstraction
      3) apply
         即 λ-application
      每一次計算是由對lambda-body中的一個元素的executing引起的
      是這樣的嗎??
      如何理解cicada中lambda的行爲呢??
   3. 其實如果我只使用<lambda>這個數據結構的話
      那麼語義又可以迴歸簡樸
   4. 當設計了λ的語法
      然後過了Y的測試之後
      我就給Dan寫郵件
   5. 我明白了λ-cal的那種單純性在於之以λ-term爲數據結構
      甚至在scheme中這種單純性也不復存在
      所以cicada沒有什麼好慚愧的
   6. cicada在一個lambda-body中保存一段基於棧的計算
      這種性質其實是非常好的
      試想其他基於λ-cal的語言
      在想要引入有別於λ-term的數據結構的時候的困難就知道了
** about design
   - 關於語法設計
     我已經擁有的是一種計算模型
     而這種計算模型以什麼樣的方式[語法]被表現出來都是沒有關係的
     當然應該設計出精簡而易讀而易於處理的語法
   - 語義的設計
     language-kernelisation as math-formalisation as factoring
   - 關於標準化
     create a standard approach to common problems
     like concurrency, threads and os calling
     爲了讓跟多的人接受這個語言
     這些工作是必要的
     但是也許我根本就不想讓很多人都接受這個語言
   - 關於對底層操作的保護
     有人認爲作爲一個程序員
     你在什麼抽象層級工作 你就理解這一層次的基礎結構就好
     但是我不這麼認爲
     我必須在每一層次都打開通向更低層次的通道
     當擁有統一的調用和通信接口時
     一段代碼可以用不同的語言寫成
     用一些標記語言就可以把代碼塊解析出來
     因爲這些不同的mode只不過是不同的編譯器或解釋器而已
   - 關於類型系統與面向對象
     1) 類型系統的產生在於:
        你發現你在寫一個函數的時候經常先去設計這個函數的類型
        先把這個函數的參數與返回值的類型寫出來作爲註釋
        然後你想 何不把這種東西加入到編譯器中呢?
        這樣編譯器就會更高效
        同時報錯系統何以實現地更加完善
     2) 如果類似的去猜想面向對象的產生的話 那麼就是:
        你發現每次你實現數據類型的時候
        你都先去設計這個數據類型的接口
        你把它們寫成註釋
        然後你想 何不把這些東西加到編譯器中呢?
        於是以後你就同時定義數據類型與接口
        程序的模塊化更強了
        + 節約了命名空間 程序也更好讀了
     可見一個是以函數爲中心 一個是以數據結構爲中心
     去掉堂皇的部分之後發現這兩個都是好主意
     但是衝突在於
     爲了讓機器來處理
     就要限制了設計數據結構和接口的方式
add note on math / 重要筆記
add note