The array and matrix definitions given in the FSL utilities source,

fsl-util.x
or
fsl_util.x.

The arrays are quite nice for their flexibility in making arrays out of
any type of data, and are useful in many instances. However, the source
definitions are slow on non-optimizing Forth systems.

I believe the design of the arrays and matrices traces back to Julian
Noble's, "Scientific Forth." A 1-D array is named with a trailing left
brace "{" while 2-D matrices have a trailing double left brace, "{{".
This allows a convenient notation

a{ I } \ resolves to address of array element I
m{{ J I }} \ resolves to address of matrix element at row J, col I

The indices are 0-origin, so the first element of the array named a{ is
stored at address

a{ 0 }

and the top left element of the matrix named m{{ is stored at address

m{{ 0 0 }}

Creation of fixed size arrays and matrices is performed with the parsing
words

ARRAY
MATRIX

and the size of each element is one of the arguments on the stack, so,
typically, we can write

36 FLOAT ARRAY a{ \ create array named "a{" with 36 elements of size
FLOAT (a constant, usually 8 bytes)

120 48 INTEGER MATRIX m{{ \ create matrix named "m{{" with 120 rows and
48 columns of size INTEGER (a cell size in bytes)

There are provisions for creating dynamically allocated arrays as well.

The operators "}" and "}}" resolve the adress of the indexed element of
the specified array, and this is where the inefficiency lies. I've been
tempted to make "}" and "}}" machine code primitives for these words to
increase their speed in kForth. It seems unlikely though that the words
"}" and "}}" would be generally adopted as common use words, so I have
not made them built-in words.

To give you an idea of the efficiency hit from using these words versus
custom arrays of fixed size elements, I tested numerically intensive
code using a custom matrix of double precision floats, with index and
fetch, and index and store words:
]]F@
]]F!
The code and definitions for the two words above are found in the
program, pde1.4th, at the link provided.

Next, I created a version of pde1.4th which used FSL matrices and no
extra optimizations, with the notation described earlier e.g. for a
floating point matrix,

m{{ J I }} F@ and m{{ J I }} F!

Some typical execution times with the custom matrix fetch and store
words versus the typical FSL matrix word usage are,

Custom matrices: 9656 ms
FSL matrices: 20474 ms

The above timings use kForth-64 to time the word SOLVE for the
RECTangular boundary value problem, with a specified tolerance of 1E-16.

kforth32 has similar timings (kforth32-fast performs much faster).

Some optimization is clearly needed on the FSL array and matrix definitions.

The FSL definitions of ARRAY and MATRIX in kForth may be found in its
fsl-util.4th file at the link given below.

--
Krishna Myneni

Links to code mentioned above:

https://github.com/mynenik/kForth-64/blob/master/forth-src/pde1.4th

https://github.com/mynenik/kForth-64/blob/master/forth-src/fsl/fsl-util.4th

Interesting, but the performance gain is not surprising
if you use matrix-adapted primitives.

Just for comparison:
I use different internal representations for vectors and
matrices. Vectors are simple fp-number fields. Matrices
in the heap are fat data and have a header for dimension,
numeric type and reference count. Matrices can only be
referenced via matrix-values (or matrix-stack elements).

The compiler automatically generates the correct and
therefore performant type-dependent code for
<indices> } -> matrix element
<indices> }^ -> address of the element
<indices> }! -> write matrix element

This is of course not FSL syntax, but more readable IMO.
There are also slices, but that is not the topic here.

On 12/14/23 06:44, minforth wrote:
> Interesting, but the performance gain is not surprising
> if you use matrix-adapted primitives.
>
> Just for comparison:
> I use different internal representations for vectors and
> matrices. Vectors are simple fp-number fields. Matrices
> in the heap are fat data and have a header for dimension,
> numeric type and reference count. Matrices can only be
> referenced via matrix-values (or matrix-stack elements).
>
How do you implement vectors of different types other than fp-numbers?
Do you use a full-blown matrix then?

> The compiler automatically generates the correct and
> therefore performant type-dependent code for

In the FSL, this can be done for statically alloted arrays and matrices,
when the "}" and "}}" words can determine the element size (+number of
columns for a matrix) at compile-time, by making them IMMEDIATE words.

I don't see how the element-size-specific reference can be done for
dynamic arrays and matrices at compile-time, when the element size and
number of columns are not known.

Another drawback would be having to make "}" and "}}" state-dependent
words (on single-xt systems).

> <indices> } -> matrix element
> <indices> }^ -> address of the element
> <indices> }!  -> write matrix element
>
> This is of course not FSL syntax, but more readable IMO.
> There are also slices, but that is not the topic here.

I prefer the symmetry of the FSL syntax. If you used }@ it would be more
symmetric but you might not like the added visual noise. Again, it would
not be possible for }@ to compile an element-size-specific reference on
dynamically declared matrices.

--
Krishna

On 12/14/23 09:51, Krishna Myneni wrote:
> On 12/14/23 06:44, minforth wrote:
....
>> The compiler automatically generates the correct and
>> therefore performant type-dependent code for
>
> In the FSL, this can be done for statically alloted arrays and matrices,
> when the "}" and "}}" words can determine the element size (+number of
> columns for a matrix) at compile-time, by making them IMMEDIATE words.
>
> I don't see how the element-size-specific reference can be done for
> dynamic arrays and matrices at compile-time, when the element size and
> number of columns are not known.
>

Correction: For FSL dynamic arrays and matrices the element size is
known at compile time. For FSL dynamic matrices the number of columns is
not known at compile time, so it would always have to retrieved at run-time.

--
Krishna

The details of the implementation would go too far here. Essentially,
my matrices are objects with methods for reading and writing cells
(and slices). There is a matrix stack with pointers to a pre-allocated
pool of empty matrix objects in the heap at the start of the programme.
Other frequently used global matrix values are also predefined.
This allows a lot of early-binding during compilation.

In Forth jargon, the matrices do not have single cell execution tokens,
but structs that carry type information (and other states). It is
therefore not a standard Forth. Available primitive data types are
integers, float24, float32, float64 (and compound types with companion bits).

As visual syntax example an older PLU factorisation (today primitive):

: MPLU ( m: m -- m: l p u ) PLU factorization
?square mrows meye mswap mrows dup mzeros mswap ( p l u ) mrows
FOR n n mcpivot v0~ IF -408 throw THEN
dup n = IF drop ELSE mrot dup n mrswap mrot dup n mrswap mrot n mrswap THEN
m[ n n ] 1. m'[ n n ]! mrows n 1+
?DO m[ i n ]^ dup v@ fover f/ fdup i n mrmulsub 0. v! m'[ i n ]!
LOOP fdrop
NEXT ;

(M[ means the top, M'[ the second matrix matrix on the matrix stack, and
as you can see, floats have been assumed here)

minforth wrote:

> The details of the implementation would go too far here. Essentially,
> my matrices are objects with methods for reading and writing cells
> (and slices). There is a matrix stack with pointers to a pre-allocated
> pool of empty matrix objects in the heap at the start of the programme.
> Other frequently used global matrix values are also predefined.
> This allows a lot of early-binding during compilation.

This is also the approach I have chosen for iForth. However, there I have
no need for a matrix stack (the parameter stack is perfectly well
suited to handle the matrix/array struct pointers).
I also have a pool of "local" matrix objects. It is possible to write
words for e.g. matrix inversion that work independent of type (byte,
word, cell, sfloat, dfloat, float, xfloat, ddouble, complex, arbitrary
precision ...)

I kept the FSL notation A{{ }} B{ } but there are new words to
access the struct fields: A{{ DIMS , B{ DADDR C{{ DSIZE etc..

-marcel

mhx wrote:

> minforth wrote:

>> The details of the implementation would go too far here. Essentially,
>> my matrices are objects with methods for reading and writing cells
>> (and slices). There is a matrix stack with pointers to a pre-allocated
>> pool of empty matrix objects in the heap at the start of the programme.
>> Other frequently used global matrix values are also predefined.
>> This allows a lot of early-binding during compilation.

> This is also the approach I have chosen for iForth. However, there I have
> no need for a matrix stack (the parameter stack is perfectly well
> suited to handle the matrix/array struct pointers).

Yes, that works. The mstack is also there for historical reasons, because
matrix pointers used to be fat pointers. With the introduction of copy-on-write,
this was no longer suitable. In addition, the normal integer and fp data stacks
are full enough with other things, so the mstack is also useful for clearer code.

minforth wrote:
[..]
> In addition, the normal integer and fp data stacks
> are full enough with other things, so the mstack is also useful for clearer code.

It probably comes as no surprise that I find locals to be a perfect solution
for that.

-marcel

On 12/13/23 18:38, Krishna Myneni wrote:
....
> The operators "}" and "}}" resolve the adress of the indexed element of
> the specified array, and this is where the inefficiency lies. I've been
> tempted to make "}" and "}}" machine code primitives for these words to
> increase their speed in kForth. It seems unlikely though that the words
> "}" and "}}" would be generally adopted as common use words, so I have
> not made them built-in words.
>

I think the best approach forward for me, in kForth, is to include
efficient primitives in Forth system,

FSL_ARRAY_EL_REF ( a_arr nidx -- )
FSL_MATRIX_EL_REF ( a_mat nidx midx -- )

Then, in fsl-util.4th, "}" and "}}" may be declared to be synonyms for
these primitives, or something else if the user prefers a different
implementation of arrays and matrices.

--
Krishna

On 15/12/2023 10:28 pm, mhx wrote:
> minforth wrote:
> [..]
>> In addition, the normal integer and fp data stacks
>> are full enough with other things, so the mstack is also useful for clearer code.
>
> It probably comes as no surprise that I find locals to be a perfect solution
> for that.

Nor the only one. But as Jeff Fox explains:

"Forth is about words. Words have names. The choice of the names of the words
in Forth is certainly one of the most important things. And given that humans
have limited minds there should be a focus on what words are important. That's
why it was considered important in the design of Forth to put emphasis on not
having to name every temporary storage location. It has a name. It is a called
a stack. The point being here that you don't have to name items on a stack.
If you think you want to name the temporary items on the stack you are missing
the most important design features of the language."

https://groups.google.com/g/comp.lang.forth/c/ef7xV5y6ddg/m/wGI0Q4D69GMJ

One of the few things in Google's c.l.f. archive actually worth bookmarking ...
though it wouldn't be needed were it uppermost in every forther's thinking.

dxf <dxforth@gmail.com> writes:
>But as Jeff Fox explains:
>
>"Forth is about words. Words have names. The choice of the names of the words
> in Forth is certainly one of the most important things. And given that humans
> have limited minds there should be a focus on what words are important. That's
> why it was considered important in the design of Forth to put emphasis on not
> having to name every temporary storage location. It has a name. It is a called
> a stack. The point being here that you don't have to name items on a stack.
> If you think you want to name the temporary items on the stack you are missing
> the most important design features of the language."

I don't see how the last sentence follows from the stuff he wrote
before.

And Chuck Moore and others who do not use locals do not practice what
Jeff Fox preached. They just use VARIABLEs instead of locals.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <2023Dec16.084551@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>I don't see how the last sentence follows from the stuff he wrote
>before.
>
>And Chuck Moore and others who do not use locals do not practice what
>Jeff Fox preached. They just use VARIABLEs instead of locals.

If I want named local storage I use VARIABLE's. There is a
reentrant and a information hiding aspect to LOCAL's.
I forego the reentrant aspect and attain information hiding if needed
with other means with VARIABLE's or whatever other data structure.

It is not a good to duplicate VARIABLE's with LOCAL's
DVARIABLE's with DLOCAL's FVARIABLE's with DLOCAL's etc.
Parsing with TO is an abuse of the powers of Forth.

Agree to disagree. Should be in the FAQ.

>- anton

Albert van der Horst
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

none wrote:

> It is not a good to duplicate VARIABLE's with LOCAL's
> DVARIABLE's with DLOCAL's FVARIABLE's with DLOCAL's etc.

I don't understand why it should be a discussion. Even if
Forth didn't have a LOCAL concept, users could add it.

[ BTW, it's not just classical re-entrancy. If a word is
used from more than one location in a bigger program,
its variables have to be duplicated. Where do you
put the copies? ]

> Parsing with TO is an abuse of the powers of Forth.

Are we preachers or engineers?

-marcel

In article <cbdb4357523903a4fbdf42e68ac9690e@news.novabbs.com>,
mhx <mhx@iae.nl> wrote:
>none wrote:
<SNIP>
>[ BTW, it's not just classical re-entrancy. If a word is
> used from more than one location in a bigger program,
> its variables have to be duplicated. Where do you
> put the copies? ]
They are local variables, so they don't need duplicates.
You're entrenched in LOCAl such that you don't understand
any more what local variables as a concept are.

>
>-marcel
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

albert@cherry.(none) (albert) writes:
> DVARIABLE's with DLOCAL's FVARIABLE's with DLOCAL's etc.
> Parsing with TO is an abuse of the powers of Forth.

Whatever problems might result from TO are completely separate from
whatever problems might result from locals.

On 16/12/2023 6:45 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> But as Jeff Fox explains:
>>
>> "Forth is about words. Words have names. The choice of the names of the words
>> in Forth is certainly one of the most important things. And given that humans
>> have limited minds there should be a focus on what words are important. That's
>> why it was considered important in the design of Forth to put emphasis on not
>> having to name every temporary storage location. It has a name. It is a called
>> a stack. The point being here that you don't have to name items on a stack.
>> If you think you want to name the temporary items on the stack you are missing
>> the most important design features of the language."
>
> I don't see how the last sentence follows from the stuff he wrote
> before.

I saw it as a summation.

> And Chuck Moore and others who do not use locals do not practice what
> Jeff Fox preached. They just use VARIABLEs instead of locals.

If I use VARIABLEs as locals it is admission I was beaten. I try to keep
that to a minimum :)

dxf <dxforth@gmail.com> writes:
> If I use VARIABLEs as locals it is admission I was beaten. I try to keep
> that to a minimum :)

I can't think of Forth as a HLL if users are supposed to do what amounts
to pipeline scheduling and register allocation in their head, planning
out the stack juggling and so on.

On 17/12/2023 6:41 pm, Paul Rubin wrote:
> dxf <dxforth@gmail.com> writes:
>> If I use VARIABLEs as locals it is admission I was beaten. I try to keep
>> that to a minimum :)
>
> I can't think of Forth as a HLL if users are supposed to do what amounts
> to pipeline scheduling and register allocation in their head, planning
> out the stack juggling and so on.

I can't think of using Forth over an HLL - unless I believe I can do better
and have the means. Otherwise I'm just coding C in RPN and who needs that.

On 12/15/23 08:55, Krishna Myneni wrote:
> On 12/13/23 18:38, Krishna Myneni wrote:
> ...
>> The operators "}" and "}}" resolve the adress of the indexed element
>> of the specified array, and this is where the inefficiency lies. I've
>> been tempted to make "}" and "}}" machine code primitives for these
>> words to increase their speed in kForth. It seems unlikely though that
>> the words "}" and "}}" would be generally adopted as common use words,
>> so I have not made them built-in words.
>>
>
> I think the best approach forward for me, in kForth, is to include
> efficient primitives in Forth system,
>
> FSL_ARRAY_EL_REF    ( a_arr nidx -- )
> FSL_MATRIX_EL_REF   ( a_mat nidx midx -- )
>
....

I'm implementing "}}" as an intrinsic word in kForth, for use with FSL
matrices. In order to test new implementations and benchmark them
against different versions including the original source code version
from the kForth fsl-util.4th file, I wrote a benchmark program which
also performs elementary tests on "}}". The existing source code version
of "}}" for FSL-style, row-ordered matrices, is

: }} ( addr i j -- addr[i][j] )
>R >R
DUP [ 2 CELLS ] LITERAL - 2@ \ &a[0][0] size m
R> * R> + * + ;

In addition to the automated tests on the implementation of "}}", the
benchmark program generates a random 256x256 floating point matrix and
can perform a specified number of fetches from random row and column
locations -- a typical number would be 1,000,000 random accesses from
the matrix.

--- example use ---
include bench-fsl-matrix

FSL-UTIL V1.3c 11 Sep 2021 EFC, KM

TESTING }}

Filling 256x256 floating point matrix with random values ...
Benchmark: "ms@ 1000000 random-matrix-access ms@ swap - ." ok
ok

ms@ 1000000 random-matrix-access ms@ swap - .
454 ok
--- end of example ---

The testing and benchmark program is given below.

--- start of program ---
\ bench-fsl-matrix.4th
\ \ Benchmark the implementation of }}
\ \ Krishna Myneni, 2023-12-17

include ans-words
include random
include ttester
include fsl/fsl-util

\ Basic tests on }}
4 constant NROWS
16 constant NCOLS
NROWS NCOLS float matrix b{{
cr
TESTING }}
t{ b{{ b{{ 0 0 }} = -> true }t
t{ b{{ float+ b{{ 0 1 }} = -> true }t
t{ b{{ NCOLS floats + b{{ 1 0 }} = -> true }t
t{ b{{ NROWS NCOLS * 1- floats + b{{ NROWS 1- NCOLS 1- }} = -> true }t

\ Benchmarking matrix is 256x256
256 constant NROWS
NROWS constant NCOLS
NROWS NCOLS float matrix m{{

ms@ seed ! \ seed random number gen

: gen-random-float ( F: -- r)
random2p s>f
random2p 7 and negate s>f
falog f* ;

: fill-matrix ( -- )
NROWS 0 DO
NCOLS 0 DO
gen-random-float m{{ J I }} f!
LOOP
LOOP ;

\ Generate random row and column numbers
: random-row-col ( -- urow ucol )
random2p 255 and \ row
random2p 255 and \ col
;

: random-matrix-access ( -- )
0 ?DO m{{ random-row-col }} drop LOOP ;

cr
cr .( Filling 256x256 floating point matrix with random values ... )
fill-matrix
cr .( Benchmark: "ms@ 1000000 random-matrix-access ms@ swap - ." )

--- end of program --

--
Krishna Myneni

On 16/12/2023 6:45 pm, Anton Ertl wrote:
> ...
> And Chuck Moore and others who do not use locals do not practice what
> Jeff Fox preached. They just use VARIABLEs instead of locals.

Moore has said:

"Don't use local variables [...] It's bad. It's wrong."

<https://www.ultratechnology.com/1xforth.htm>

If he's merely using VARIABLEs where locals would otherwise be used that's
worth investigating. Unfortunately I'm not aware of any substantive code
by Moore in the public domain to test the proposition.

As one of the "others who do not use locals" I offer the following sample.
Readers may decide whether such use of VARIABLEs and VALUEs amounts to locals
in the usual meaning of the word. ISTM the more factored the code, the more
difficult it is to apply the term 'local'.

variable #DIGIT \ #digits entered

: /FIELD ( n -- 0 )
drop #digit @ begin dup while
<bs> emit space <bs> emit 1-
repeat decimal #digit off ;

: .VIS ( c -- )
dup visible? if emit 1 #digit +! end drop ;

: ?$ ( n c -- n' c' )
[char] $ of /field hex [char] $ .vis key then ;

: +DIGIT ( u c -- u' err )
base @ >digit if swap base @ * + dup 255 u> end
drop true ;

: BUILD# ( c -- n c2 ) \ CR or BL exits
decimal #digit off
0 swap begin dup bl <> over <cr> <> and while
?$ upcase dup .vis +digit if beep /field then key
repeat decimal ;

: GET# ( -- n ) key build# drop ;

variable LEN 0 value MAXCHR

: ROOM? ( -- f ) len @ maxchr < ;

: +CHR ( c -- ) ibuf len @ + c! 1 len +! ;

: DO-NUM ( c -- ) \ CR or BL BL exits
begin room? while
build# swap #digit @ if +chr else drop then
<cr> = if end space key bl of <cr> then
repeat drop ;

: DO-ASC ( c -- )
begin dup <cr> - room? and while
dup .chr +chr key
repeat drop ;

: DIGIT? ( c -- f )
dup [char] $ = swap [char] 0 [char] 9 between or ;

: GET$ ( maxlen -- adr len )
to maxchr len off
key dup digit? if do-num else do-asc then
ibuf len @ ;

On 12/17/23 15:00, Krishna Myneni wrote:
....
>
> : random-matrix-access ( -- )
>     0 ?DO  m{{ random-row-col }} drop LOOP ;
>
....
This doesn't measure what I thought it was measuring. The benchmarking
of RANDOM-MATRIX-ACCESS measures the efficiency of RANDOM-ROW-COL rather
than measuring the efficiency of "}}". Using fixed row and column
numbers as indices gives a more accurate benchmark of "}}" which
computes the address of the specified element.

-- KM

On 12/15/23 08:55, Krishna Myneni wrote:
> On 12/13/23 18:38, Krishna Myneni wrote:
> ...
>> The operators "}" and "}}" resolve the adress of the indexed element
>> of the specified array, and this is where the inefficiency lies. I've
>> been tempted to make "}" and "}}" machine code primitives for these
>> words to increase their speed in kForth. ...
>
> I think the best approach forward for me, in kForth, is to include
> efficient primitives in Forth system,
>
....
Experimenting with an assembly language implementation of "}}" I find
that the following code in kforth64's vm64.s gives me a factor of 2x
speedup over the Forth source code for double-precision fp matrices.
This factor of 2 increase should not depend on the size of the matrix
element e.g., it should hold even if each matrix element was a
quad-precision floating point number (16 bytes) or a larger data
structure -- I still have to test this speedup under such conditions.

--
KM

L_fsl_mat_addr:
LDSP
INC_DSP
mov (%rbx), %rcx # rcx = j (column index)
INC_DSP
STSP
mov (%rbx), %rdx # rdx = i (row index)
mov WSIZE(%rbx), %rax # adress of first element
sub $2*WSIZE, %rax # rax = a - 2 cells
mov %rax, %rdi
mov (%rax), %rax # rax = ncols
imulq %rdx # rax = i*ncols
add %rax, %rcx # rcx = i*ncols + j
mov %rdi, %rax
add $WSIZE, %rax
mov (%rax), %rax # rax = size
imulq %rcx # rax = size*(i*ncols + j)
add %rax, WSIZE(%rbx) # TOS = a + rax
INC2_DTSP
xor %rax, %rax
NEXT

vs

: }} ( addr i j -- addr[i][j] )
>R >R
DUP [ 2 CELLS ] LITERAL - 2@ \ &a[0][0] size m
R> * R> + * + ;

In the experimental kforth64, the code L_fsl_mat_addr maps to the
built-in word, "}}".

Looks good for existing FSL code. it might even be faster if you
introduced type-specific and thus shorter address computations
like }}F }}SF }}I and }F }SF }I.

On 12/18/23 03:35, minforth wrote:
> Looks good for existing FSL code. it might even be faster if you
> introduced type-specific and thus shorter address computations
> like }}F }}SF }}I and }F }SF }I.

Yes, I expect I might gain an additional 2x speedup for type-specific
versions. But, I want }} to do the size-specific compilation,
eventually. To do that properly, I want to go to a dual-xt system and
avoid explicit STATE-dependence (which has other benefits we've
discussed in the past). That's a bigger project for later.

--
Krishna

In article <ulo1bt$351qd$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>On 16/12/2023 6:45 pm, Anton Ertl wrote:
>> ...
>> And Chuck Moore and others who do not use locals do not practice what
>> Jeff Fox preached. They just use VARIABLEs instead of locals.
>
>Moore has said:
>
>"Don't use local variables [...] It's bad. It's wrong."
>
><https://www.ultratechnology.com/1xforth.htm>
>
>If he's merely using VARIABLEs where locals would otherwise be used that's
>worth investigating. Unfortunately I'm not aware of any substantive code
>by Moore in the public domain to test the proposition.
>
>As one of the "others who do not use locals" I offer the following sample.
>Readers may decide whether such use of VARIABLEs and VALUEs amounts to locals
>in the usual meaning of the word. ISTM the more factored the code, the more
>difficult it is to apply the term 'local'.
>
>variable #DIGIT \ #digits entered
>
>: /FIELD ( n -- 0 )
> drop #digit @ begin dup while
> <bs> emit space <bs> emit 1-
> repeat decimal #digit off ;
>
>: .VIS ( c -- )
> dup visible? if emit 1 #digit +! end drop ;
>
>: ?$ ( n c -- n' c' )
> [char] $ of /field hex [char] $ .vis key then ;
>
>: +DIGIT ( u c -- u' err )
> base @ >digit if swap base @ * + dup 255 u> end
> drop true ;
>
>: BUILD# ( c -- n c2 ) \ CR or BL exits
> decimal #digit off
> 0 swap begin dup bl <> over <cr> <> and while
> ?$ upcase dup .vis +digit if beep /field then key
> repeat decimal ;
>
>: GET# ( -- n ) key build# drop ;
>
>variable LEN 0 value MAXCHR
>
>: ROOM? ( -- f ) len @ maxchr < ;
>
>: +CHR ( c -- ) ibuf len @ + c! 1 len +! ;
>
>: DO-NUM ( c -- ) \ CR or BL BL exits
> begin room? while
> build# swap #digit @ if +chr else drop then
> <cr> = if end space key bl of <cr> then
> repeat drop ;
>
>: DO-ASC ( c -- )
> begin dup <cr> - room? and while
> dup .chr +chr key
> repeat drop ;
>
>: DIGIT? ( c -- f )
> dup [char] $ = swap [char] 0 [char] 9 between or ;
>
>: GET$ ( maxlen -- adr len )
> to maxchr len off
> key dup digit? if do-num else do-asc then
> ibuf len @ ;
>

An excellent example.

Another excellent example is the <# # #> wordset.
They are superbly factored, by virtue of the "global"
HLD a (user) variable. It is actually more of a
"package-local" variable. Who are in the habit
of using LOCAL's as a first resort, are blocked to think
in this direction.
In the 2500 lines of the manx package (plays musical score
simultaneously on midi keyboard and mechanical instruments) you see
no LOCAL and merely half a dozen VARIABLE or VALUE.
Some of this are hard (or impossible) to replace by LOCAL,
e.g. SHIFTER and TICKS-PER-SECOND. They are set by
a calibration word in the initialisation, then are needed all
over the place, mostly by words that need not address them directly.
They convert the system dependant tick rate to real time.

Then you have the assembler/disassembler ciasdis.
This implements a "blackboard design pattern" for a
kind of state machine.
It is hard to imagine that some one scribbles something on a blackboard,
and then no one is ever to read it.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -