The Standard Forth text interpreter recognizes words in the search
order (rec-nt
), integer numbers (rec-num
), and floating
point numbers (rec-float
). By default Gforth also recognizes
syntaxes for
"mystring"
, with rec-string
0e+1ei
, with rec-complex
->myvalue
,
with rec-to
`dup
, with rec-tick
``mysynonym
, with rec-dtick
<myarray+8>
, with
rec-body
${HOME}
, with rec-env
myvoc1:myvoc2:myword
, with rec-scope
float?1.
, , with rec-meta
You can use locate
(see Locating source code definitions) to
determine which recognizer recognizes a piece of source code. E.g.:
defer mydefer locate ->mydefer
will show that rec-to
recognizes ->mydefer
. However, if
the recognizer recognizes a dictionary word (e.g., the scope
recognizer), locate will show that word.
You can see which recognizers are used and the order of recognizers with
Print the current recognizer order, with the first-searched
recognizer leftmost (unlike .order). The inverted ~
is
displayed instead of rec-
, which is the common prefix
of all recognizers.
Recognizers are typically designed to avoid matching the same strings
as other recognizers. E.g., rec-env
(the environment variable
recognizer) requires braces to avoid a conflict with the number
recognizer for input strings like $ADD
. There are a few
exceptions to this policy, however:
However, they tend not to start with 0
(and if they do, they
contain special characters), so if your base is hex
, it is a
good practice to let your numbers start with 0
.
In the code bases we have looked at, starting words with '
(quote aka tick) is much more common than starting them with `
(backquote aka backtick), so the recognizers for the xt and the nt use
`
to reduce the number of conflicts.
rec-num
and the floating-point
recognizer rec-float
recognize, e.g., 1.
. Because
rec-num
is (by default) first, 1.
is recognized as a
double-cell integer. If you change the recognizer order to use
rec-float
first, 1.
is recognized as a floating-point
number, but loading code written in Standard Forth may behave in a
non-standard way.
In any case, it’s a good practice to avoid that conflict in your own
code as follows: Always write double-cell integers with a number
prefix, e.g., #1.
; and always write floating-point numbers with
an e
, e.g., 1e
.
->
. You can
avoid a conflict by using to myvalue
or to?->myvalue
(the latter works with postpone
).