Atast 和 Dynamic dispatch

=== 2008/08/07 ===

使用 Atlast 的一個問題是名稱的衝突。比如停止 motion 和停止 interpreter都用 stop 時，stop有多種意義。而 Atlast 極簡的解譯器無法瞭解，只能依賴 dynamic dispatch 。這不是 Atlast 獨有的問題，是所有 dynamic typed language 都有的問題。

我只能選擇接受。

Sqlite3

=== 2008/07/29 ===

研讀了一下有關 Sqlite3 的網頁，以下是我學到的：

被宣告為 INTEGER PRIMARY KEY 的欄位會使得 statemement 每次被執行時，自動增加那欄位的值。同時 Sqlite3 會為這一欄位建立 index 。這很適合用於 id ，比如我程式中的 move_poid，就不必每次都要設定 move_poid 了。

Sqlite3 使用 manifest typing, 其型別是和每個 Cell 而非每個 Column 結合的。

如果某一欄位在 WHERE 中被使用，建議為此欄位建立 index ，以加快 SELECT 的處理速度。但注意使用 INDEX 會使得 INSERT, UPDATE 及 DELETE 的處理速度變慢。

使用 transaction 以增加處理速度。

Sqlite3 支援使用者定義的 function !!

Forth and Eiffel, lua, prototype

=== 2008/07/08 ===

其實，Forth 不必使用 prototype 的概念來實現物件。
如果所有的 Forth 物件都來自 Eiffel，則可以使用 factory.

variable x
geometry_factory.new_circle x !
x.radius
x geometry_factory.recycle_circle
x 是一個很簡單的 forth 變數。
而 geometry_factory.new_circle 會建立一個圓，把 object id 放在 forth 的資料堆疊上。
不必使用物件堆疊。執行 x.radius 時，會將 x 當成一物件 id ，在 Eiffel 側找到那個物件，找到那物件的 feature radius 並執行。geometry_factory.recycle_circle 會回收 x 指向的物件。

在 Forth 側，不提供物件導向。只提供 x.y 這樣的語法。和 Lua 比較，Lua 也沒有物件導向。只有 table 而已。

如果要對在堆疊頂的物件進行操作，可以用 top.radius 。
一個問題是：這樣的方法，執行速度會很差，因為不論是 x.radius 或是 top.radius ，都必須在執行階段去查詢和物件結合的 prototype ，才知道 radius 做的是什麼事。

解決的方法是想法子在編譯時就決定 x 的型別。所以可以考慮修正如下：

variable x
geometry_factory.new_circle x !
x circle.radius
x geometry_factory.recycle_circle

這樣，程式師必須清楚知道 x 的型別。這方法類似 gtk 的作法。

Forth and prototype

=== 2008/07/07 ===

思索如何在 forth 中引進物件。引進的方式必須和 eiffel 有很好的配合，又必須適合 dynamic language。一種方法是在 forth 使用 prototype，類似 Javascript 。

我希望觀念儘量和 Eiffel 接近。Forth 可以使用 Eiffel 的物件做為 prototype，再增加自己的資料。

此外，允許使用 x.y 的呼叫方式。此一方式必須符合 Eiffel 的各種規則。如果要對物件堆疊上的物件做處理，必須先給物件一個名字。以下是嘗試：

reference circle
create-circle
circle object!
circle.radius .

reference box
create-box
box object!
box.width .

reference circular-box
prototype circle
prototype box

嗯，似乎不容易以 prototype 方式建造這 circular-box 物件。
因此，解決的方法似乎還必須給予 reference 型別如下：

reference circular-box \ 無型別的 reference
prototype circle \ 具型別 circle
prototype box \ 具型別 box
create-method make-circular-box
origin3d 1.0 make-circle origin3d 1.0 1.0 1.0 make-box ;

create circular-box.make-circular-box

circle-box.radius .
circle-box.width .

如此建造出來的物件沒有 eiffel merge features 的能力。但似乎可用了。

在實現上，不急著做 prototype 。可以先做 x.y 這樣的呼叫。由 Eiffel 建立物件的 prototype。

FORTH是好的起點，不必把起點當終點

=== 2008/07/01 ===

以下這篇文章是回覆符式協會內討論時我寫的：

我前些時候也考慮使用 lua ，最後我使用 forth 於我目前的計劃中，有以下幾種原因：

1. lua 使用圾垃收集，但是在 realtime 時不能做垃圾收集。我很難在 realtime 時關掉 lua 的圾垃收集。

2. 我使用的高階物件導向語言（編譯式的) 本身就有垃圾收集，lua 又有自己的一套。這兩套要協同運作會讓我頭疼。

3. 我已經很熟 forth ，可以完全掌握我要它走的方向。但是 lua 的方向不是我能掌握的，聽說過去常常發生程式界面改變造成不相容的問題。

4. 速度。比較起來，forth還是比其他的 scripting language 速度快。

因此我在尋找了幾年後最終還是回到 forth 。這之間我考慮用過 lisp, python, scheme, ruby, lua。本來根本不想用 forth ，最後還是回到 forth ，只因上列幾點。最後確定自己的選擇是正確的。很可惜沒在三年前做下這一個選擇。

Forth 不是萬靈丹，但是有時就是沒得選，只有它合用。

Forth 和其他語言尤其是 c 語言的相容性不足，的確限制它在接受的程度。但是光改變這個並不能讓它被更多人接受。FICL 已經做過這樣的嘗試了。不必去煩惱如何讓forth被更多人接受，不如換個想法，想想如何讓 forth 對自己更有用。這種自私的想法很可能才是最適合 forth 的玩家。因為，每一個人都有能力寫出自己的 forth 。

現在的我完全放棄 forth 會被很多人接受的想法。也放棄了會有某個人長期維護我使用的 forth 的想法。以 retroforth 為例，在 10.0 版之前有過一兩年未曾維護的時期。因此，必須抱著「使用 forth 於產品開發時，要能自己完全維護」這樣的心態來選擇
forth 。這是我目前選擇 ATLAST 的原因。因為我知道我可以做到自我維護這點。雖然它比較舊，不合 ANS 的標準。同樣的，我覺得 FICL 也很不賴。它沒再維護，不如說它已經實現了作者的期望了。

架構在我目前選擇的 ATLAST 上，我加上了物件堆疊以和其他物件導向編譯式語言溝通。但我不要物件導向的 forth，那條路我十八年前走過，沒有必要，不是 forth 擅長的。未來我還想做的就是為 forth 加上一件非後位運算的外衣。比如，讓它的文法看來和 lua 一樣，當 forth 只是一個 virtual machine，最後，我很可能為了追求更高的速度將這個 virtual machine 以 LLVM 改寫。你可以說，那就不是 forth 了。但只要產品成功，最後它是不是 forth 並不重要。

所以，forth 對我來說就是一個可以變化的語言。只要我放棄有人會維護它的想法自己擔起維護它的責任，它可以隨我產品的需求一直改變。它很簡單，是一個很好的起點，雖然不一是終點。由於有很多種不同的 forth ，我可以選擇一個適合我的起點，不斷改進它。

另一篇文章中提到 labview、plc 有關 forth 的構想。我相信若現實中真的感受到那需求， 在這個領域，forth 很可能個好選擇。我不開發韌體。也不懂 labview。但是我想 mcusir 是想使用 labview 的簇來實現 forth 的 virtual machine，也就是實現 forth 的 internal interpreter。那麼，可以參考
http://www.ece.cmu.edu/~koopman/stack_computers/index.html 這本書。或是選擇一個最簡單的 forth ，這兒大家都懂的，比如 eforth ，自行揣摩 internal interpreter 的設計，改寫成 labview 的語言。

LLVM很可能可用於我的產品

=== 2008/06/22 ===

經研究，LLVM在現階段很可能已可用於我的產品。有文件指出 llvm-gcc 編出的程式速度比 gcc -O3 快 35%。
請見：llvm 2.2 vs gcc 4.2
此外，因為 llvm 有 apple 這樣的大公司支援，讓人更覺安心。

ATLAST 和 FICL

=== 2008/06/22 ===

之前從我產品的觀點比較了 ATLAST 和其他 scripting language 的優劣。那些優點並不是 ATLAST 獨有，大多數的 FORTH 都有那樣的特點。

在此我想比較 ATLAST 和另一個類似的 FORTH ：FICL。

我喜歡 ATLAST 的原因：

1. 原始程式只有一個檔案。讓我覺得它十分簡單容易理解。
2. 因為它是 John Walker 的作品。
3. 它為 Public Domain，代表我可以為所欲為。
4. 在字串上直接用 c 的字串，因此使用 c 的能更易學會。
5. 沒有雙精度和單精度整數的區別。概念簡單。

但是 FICL 有很多優點：

1. 是完整的 ANS FORTH。
2. 允許多個 vm 。
3. 使用 switching threaded 架構，若我要，容易改以 Eiffel 實現。
4. Reentrant。
5. 浮點有自己的堆疊。因此不會如 ATLAST 般使用 .s 時無法區分浮點和整數。
6. 浮點有自己的堆疊，所以，若以後要以 Eiffel 實現會容易些。也不會有堆疊上浮點數 alignment 不良造成效率差的問題。

認真考慮後，我覺得 ATLAST 比較合乎我的需求：更接近 C 的概念，更容易為 C 語言的使用都接受。

The implementation of LUA 5.0

=== 2008/06/18 ===

The implementation of LUA 5.0 這篇文章提及了 LUA 5.0 內部虛擬引擎的設計。以下記述我的閱讀重點。

為了 portability，LUA 5.0 使用 switch threading，不用 direct threading。

LUA 5.0 使用 hand-written scanner and hand-written recursive decent parser, 好處是 smaller, more efficient, more portable, fully reentrant, better error messages.

LUA 5.0 使用 tagged-union 來表示 values，因此，在 32-bit machine 使用 64-bit double 的情況下，每個 value 都佔 12 bytes。

LUA 5.0 的 table 有一個 array part 及一個 hash part。

因為 LUA 動態管理 table ，而 table 又是 LUA 核心的資料結構。這使得 LUA 不適用於 real time system。

SVN 優於 GIT 之處

=== 2008/06/13 ===

讀到一篇名為「Programmer Insecurity」的文章。
裡面提及中央集權式的管控軟體（SVN）優於分散管制的管控軟體（GIT）之處。
分散管制的，各程式師有自己的 repository，以致於程式常久久才得以整合一次。
另有一篇文章「The risks of distributed version control」也值得參考。

ATLAST and EDP

=== 2008/06/12 ===

Howard Thomson 將推出 EDP，an IDE for Eiffel。IDE 想必需要個 scripting language。起心動念想將自己改過的 ATLAST 和其整合。比較使用 ATLAST 和使用其他 scripting languages 如下：

1. ATLAST 簡單，容易理解。
2. ATLAST 沒有自己的 type system，容易和 Eiffel 本身的 typing system 結合。
3. ATLAST 沒有自己的 object oriented 架構。可修改使用 Eiffel 的 object oriented 架構。我已為 ATLAST 增加了 object stack，使用 Eiffel 的 object。
4. ATLAST 沒有自己的 GC ，可採用 Eiffel 本身的 GC。
5. ATLAST 建立 FORTH 的基礎上，因此可以用各種 FORTH 最佳化的技巧來最佳化 ATLAST。
6. ATLAST 的核心小，未來可將 ATLAST 以 Eiffel 改寫。或使用 LLVM。
7. 單純將 ATLAST 視為 VM，可為 ATLAST 添加類似 Eiffel 的語法。

Dynamic typed scripting languages：
1. 自有一套 type system，和 Eiffel 會有衝突。
2. 自有一套 object oriented 架構，和 Eiffel 的架構會有衝突。
3. 自有一套 GC ，和 Eiffel 的 GC 會有衝突。
4. 自有一群開發者，不可能將以 Eiffel 改寫。

LLVM and Stacker

=== 2008/06/10 ===

花了整晚的時間瞭解 LLVM 及 Stacker。考慮它是否可用於自己的計劃：運用 LLVM 實現 native code ATLAST.

Why SparkForth?

SparkForth結合了兩個對我的生活有意義的字：Spark 是工具機切割工件時的火星。Forth則是我的電腦母語。