I wonder if the following code is (partially) ANS compatible, and
if it is easy to understand what it does, especially the word MAIN3.
Can it be written in a completely standard way?

What I need is a word that is passed parameters that define an index
into an array that is not allotted yet. So neither the index nor the
base address
can be pre-computed. When the word executes (after much more code which
finally sets up the data), it should access the array to fetch a byte at
the indexed position.
The way I've set it up, the user of the program edits a file to allocate
the data and define a function that does the fetching.

If your Forth lacks >S S> S , leave them away or replace with >R R> R@

FORTH> MAIN3
one, two, three = 1 2 3 \ 1 2 3
result = 123
MAIN3 compiled a noname $013454C0 ok
FORTH> $013454C0 idis
$013454C0 : [trashed]
$013454CA movzx rbx, $01345086 byte-offset
$013454D1 push rbx
$013454D2 ;
FORTH> $01345086 c@ . 123 ok

-marcel
---
\ in THIS file
CREATE myinsert
," ] CR DUP . R@ . S . one . two . three . one two * three * DUP TO
result ["
: MAIN0 ( -- )
1 2 3 0 LOCALS| result three two one |
4 >S 5 >R 6
[ myinsert COUNT EVALUATE ] ( compile time, locals accessible )
CR ." myinsert compiled `one two * three * DUP TO result` "
CR ." stack = " . ." \ 6"
CR ." R> = " R> . ." \ 5"
CR ." S> = " S> . ." \ 4"
CR ." one, two, three = " one . two . three . ." \ 1 2 3"
CR ." MAIN0 does `one two * three *` = " 0DEC.R
." , result = " result . ;

\ in file inside1.frt
\ ] CR DUP . R@ . S . one . two . three . one two * three * DUP TO
result [
: MAIN1 ( -- )
1 2 3 0 LOCALS| result three two one |
4 >S 5 >R 6
[ S" inside1.frt" INCLUDED ] ( at compile time, locals accessible )
CR ." inside1.frt compiled `one two * three * DUP TO result` "
CR ." stack = " . ." \ 6"
CR ." R> = " R> . ." \ 5"

[email protected] (mhx) writes:

I wonder if the following code is (partially) ANS compatible, and
if it is easy to understand what it does, especially the word MAIN3.

There is no definition of MAIN3 in what you posted, only a use, so no.

What I need is a word that is passed parameters that define an index
into an array that is not allotted yet. So neither the index nor the
base address
can be pre-computed.
When the word executes (after much more code which
finally sets up the data), it should access the array to fetch a byte at
the indexed position.

From this description, what's wrong with

: array-c@ ( c-addr uindex -- c ) + c@ ;

? But I expect that I missed something about your requirements.

In general, if you want a program to be easily understandable, avoid
iForthisms (especially where standard alternatives are
straightforwardly available. Avoiding LOCALS| is also a good idea.
It's unintuitive and therefore harder-to-understand order of locals
was the reason why {: was standardized.

- 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 2024: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I don't think I quite understand what you're trying to achieve.
But what happens if there are errors in the process?
Leftover garbage on the s-stack?

At least in my system(s), INCLUDED is implemented with an
internal CATCH/THROW mechanism, which clears all important
stacks (and some internal stuff) on error.

As for ANS compatibility: who cares, as long as your code
is well documented.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Dec 2024 10:12:13 +0000, minforth wrote:

I don't think I quite understand what you're trying to achieve.
But what happens if there are errors in the process?
Leftover garbage on the s-stack?

In iForth the S-stack is a first class citizen. It might also work
to make this stack cyclical.

At least in my system(s), INCLUDED is implemented with an
internal CATCH/THROW mechanism, which clears all important
stacks (and some internal stuff) on error.

I would sure hope so :-)

As for ANS compatibility: who cares, as long as your code
is well documented.

I was more interested in WHY it would not be compatible.
In (old) SwiftForth the problem is that >R and R> don't work while
INCLUDEing. In (very old) gForth the problem is compiler
security. The [ >S ] is supposed to move the expected address
left by :NONAME away to expose the arguments on the data
stack. In gForth the data stack is polluted with security stuff.

Was there a problem in minforth?

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)