3
在Gforth中輸入'a'
時,字符的ASCII編號(將通過使用key
字並按a將放入堆棧的編號相同)被放入堆棧。使用Gforth獲取ASCII代碼
這不起作用,例如與' '
(空間)。相反:
' ' ok
.s <1> 34384939008 ok
數量「應該」是32如何解釋這種現象?除了手動將相應於' '
(空格)的ASCII碼放在堆棧上之外,還可以做些什麼呢?
在Gforth中輸入'a'
時,字符的ASCII編號(將通過使用key
字並按a將放入堆棧的編號相同)被放入堆棧。使用Gforth獲取ASCII代碼
這不起作用,例如與' '
(空間)。相反:
' ' ok
.s <1> 34384939008 ok
數量「應該」是32如何解釋這種現象?除了手動將相應於' '
(空格)的ASCII碼放在堆棧上之外,還可以做些什麼呢?
這個'a'
語法對於Forth來說是相當新的。它是作爲擴展名添加到傳統語法之上的,它將所有內容解析爲以空格分隔的令牌。所以'a'
是一個原子標記,然後被解析爲一個字符文字。
現在,' '
不是原子標記,因爲它包含空格字符。相反,它被解析爲兩個'
令牌。它實際上是完全有效的Forth代碼,因爲'
是一個Forth單詞(叫做「tick」)。在你的例子中,第一個滴答作用在第二個。結果34384939008
是'
的xt。
怎麼辦?獲取字符的ASCII碼的傳統詞是CHAR
或[CHAR]
。第一個在解釋模式下工作,第二個在編譯模式下工作。 但是它們不適用於空格字符的特定情況,因爲再次,所有空格都被解析掉。
但是,還有另一個字推動ASCII代碼空間字符:BL
。
哈哈,滴答不是一個深奧的詞......尷尬;-)我剛從FORTH開始,錯過了。 –
只是一個問題:在運行時和編譯模式下,有兩個不同版本的'char'和'[char]'可能是什麼原因? –
在解釋的代碼中,只有'CHAR'是有意義的。 但是'CHAR'和'[CHAR]'在編譯代碼中很有用。 '[CHAR]'在編譯時工作,所以它解析程序中的下一個單詞。 'CHAR'在運行時工作,所以它不能在程序文本上運行,而是在稍後輸入流。這可以在例如直接的話。 –