Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #132390
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: value-flavoured structures |
| Date | 2024-10-05 15:52 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2024Oct5.175249@mips.complang.tuwien.ac.at> (permalink) |
| References | (8 earlier) <vdo4q8$4h5p$1@dont-email.me> <2024Oct4.135221@mips.complang.tuwien.ac.at> <vdp0tf$80bg$1@dont-email.me> <2024Oct4.200414@mips.complang.tuwien.ac.at> <vdr6k8$m1ue$1@dont-email.me> |
Ruvim <ruvim.pinka@gmail.com> writes:
>On 2024-10-04 22:04, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2024-10-04 15:52, Anton Ertl wrote:
>>>> It can be defined: Gforth has SET-TO
>> ...
>>> I wonder why a kind of "TO" is not used to set this field/property, and
>>> *maybe* a kind of "ACTION-OF" to get this property.
>>
>> Interesting idea. Maybe in some future version.
Thinking some more about it, better not:
SET-TO SET-OPTIMIZER etc. all work on the latest definition. The
methods that they set work on an NT or XT passed on the stack. The
usual behaviour of defer-flavoured words is that the context is the
same. If you have
defer d
' foo is d
action-of d
That's always the same global D. For a defer-flavoured field,
likewise:
0
value: vf
defer: df
constant mystruct
create foo mystruct allot
1 foo to vf
' . foo is df
foo vf .
2 foo df
So having TO TO instead of SET-TO would disobey this principle.
For COMPILE, there is the additional problem that it is a deferred
word, so when you do "IS COMPILE," you change the behaviour for all
uses of "COMPILE,", not just of the latest definition. The actual
method of each definition is called OPT-COMPILE,.
>What advantages do you see in *using* the to-based setters?
Over using SET-... words?
1) It's a popular and convenient mechanism.
2) I can find out the setter from looking at the central word:
``vf .hm
\ output:
opt: $7F43EB229B98
to: $7F43EB229BE0
extra: $7F43EB229B60
>int: noop
>comp: default-name>comp
>string: named>string
>link: named>link ok
Ok, $7F43EB229BE0 is not very informative, but I can still make use of
that:
$7F43EB229BE0 xt-locate
struct-val.fs:88
...
cell ' aligned ' @ !a-table wrap+value: value: ( u1 "name" -- u2 ) \ gforth-experimental
...
>> The lack of flexibility of standard TO has not deterred them from
>> using that.
>
>This statement contains the logical fallacy "Survivorship bias" [1].
>
>There are different use cases. In some use cases the discussed
>flexibility is not needed, in other — it is needed.
That's a very Forthy way of looking at it. The usual argument for
getters and setters is that that flexibility might be needed in the
future, so you don't use a mechanism like variables or values that
does not provide this flexibility, in order to avoid having to change
all the places where the variable or value is used, and only have to
change the place where the getter and setter is defined. In this
scenario value-flavoured words must not be used unless the flexibility
for TO is provided (i.e., they must not be used in standard Forth).
But yes, there are probably not many people with that mindset in the
Forth community. Forth-94 seems to have had some of that, though,
with words like GET-CURRENT and SET-CURRENT instead of a (user)
variable CURRENT that had existing practice at the time. I wish they
had defined GET-BASE and SET-BASE instead of BASE.
>For example, it could be a defining word "val" that is used as "val x"
>and creates the getter "x" and the setter "set-x".
>
>Such a word "val" can be defined like this:
>
> [undefined] name> [if]
> : name> ( nt -- xt )
> name>interpret dup if exit then
> drop [: -14 throw ;]
> ;
> [then]
>
> : val ( "name" -- )
> create 0 , [: does> @ ;] execute
> 0. <# latest-name name>string holds s" set-" holds #>
> ['] : execute-parsing
> latest-name name> >body lit,
> postpone ! postpone ;
> ;
>
> \ Re "latest-name" see [2]
>
> \ test
> t{ val x -> }t
> t{ x -> 0 }t
> t{ 3 set-x -> }t
> t{ x -> 3 }t
>
>
> \ Let's redefine the setter "set-x"
> : set-x ( u -- )
> dup 10 u> abort" too big value for x"
> set-x
> ;
>
> t{ 4 set-x x -> 4 }t
> t{ 11 ' set-x catch 2drop x -> 4 }t
>
>
>Could you show how to implement that in Gforth when the to-based setter
>"to x" is used?
: to-x ( u xt -- )
>r dup 10 u> abort" too big value for x" r> >body ! ;
to-table: x-table to-x
' >body x-table to-class: x-to
0 value x
' x-to set-to
4 to x x . \ prints "4"
11 to x
The last line produces the following error:
*the terminal*:13:7: error: too big value for x
11 to >>>x<<<
>NB: the solution must not change the original "x", it must redefine "x".
>The difference is that the new definition *can* be in a different word
>list, in which case both definitions (old and new) can be used depending
>on the context.
Let's see. To make it easier to see what is going on I use a
different name for the redefined word.
0 value y
synonym z y
' x-to set-to
4 to y
z . \ prints 4
11 to y
z . \ prints 11
11 to z \ aborts with "error: too big value for x"
For a bounds-checking TO I find this requirement strange, however.
>>> This shows that some people don't like the to-based approach.
>>
>> Does it? Are they using getters and setters instead? No.
>
>How do you know this?
I see many more postings with TO than with setters and getters.
- 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
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
"Back & Forth" is back! Hans Bezemer <the.beez.speaks@gmail.com> - 2024-08-10 12:57 +0200
Re: "Back & Forth" is back! dxf <dxforth@gmail.com> - 2024-08-11 13:35 +1000
Re: "Back & Forth" is back! Hans Bezemer <the.beez.speaks@gmail.com> - 2024-08-11 14:46 +0200
Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-08-30 09:04 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-08-30 20:32 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] BuzzMcCool <buzz_mccool@yahoo.com> - 2024-08-30 23:00 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-09-02 09:03 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-03 11:23 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-09-02 22:53 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-03 17:27 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-11 11:20 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-11 09:49 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-11 14:41 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-12 14:01 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-08-31 11:05 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] BuzzMcCool <buzz_mccool@yahoo.com> - 2024-08-30 22:59 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-05 17:18 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-05 17:37 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-05 17:42 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-09-06 14:03 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-07 14:40 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-10 04:26 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-10 23:19 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-11 12:03 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-11 14:32 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-11 23:51 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-12 18:21 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-12 09:08 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-12 10:11 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-12 10:31 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-12 10:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-13 09:37 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-13 07:56 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-13 19:47 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-13 03:38 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Jan Coombs <jan4comp.lang.forth@murray-microft.co.uk> - 2024-09-13 13:07 +0100
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-13 17:59 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 01:12 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-14 01:56 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 21:56 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-14 09:10 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-15 15:17 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 09:52 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 12:46 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:14 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-13 13:07 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-13 18:07 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 12:48 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-14 05:47 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-14 06:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 18:40 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-15 15:04 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-15 16:16 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-15 21:35 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 14:45 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-16 12:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-16 14:37 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 17:37 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 18:58 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 19:26 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-17 06:53 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 17:29 +0000
value-flavoured structures (was: Avoid treating the stack as an array) Ruvim <ruvim.pinka@gmail.com> - 2024-09-27 12:15 +0400
Re: value-flavoured structures minforth@gmx.net (minforth) - 2024-09-27 08:51 +0000
Re: value-flavoured structures mhx@iae.nl (mhx) - 2024-09-27 09:38 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-09-27 16:27 +0400
Re: value-flavoured structures minforth@gmx.net (minforth) - 2024-09-27 12:46 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-09-27 23:28 +0400
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-27 19:13 -0700
Re: value-flavoured structures dxf <dxforth@gmail.com> - 2024-09-28 14:19 +1000
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-27 22:38 -0700
Re: value-flavoured structures albert@spenarnc.xs4all.nl - 2024-09-28 13:21 +0200
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-28 10:52 -0700
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-28 11:06 -0700
Re: value-flavoured structures dxf <dxforth@gmail.com> - 2024-09-28 14:04 +1000
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 16:32 +0000
Re: value-flavoured structures dxf <dxforth@gmail.com> - 2024-10-04 13:00 +1000
Re: value-flavoured structures albert@spenarnc.xs4all.nl - 2024-10-04 23:27 +0200
Re: value-flavoured structures (was: Avoid treating the stack as an array) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 15:58 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-10-04 11:17 +0400
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 11:52 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-10-04 19:17 +0400
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 18:04 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-10-05 15:06 +0400
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-05 15:52 +0000
value-flavoured properties of a word (was: value-flavoured structures) Ruvim <ruvim.pinka@gmail.com> - 2024-10-06 17:12 +0400
value-flavoured approach (was: value-flavoured structures) Ruvim <ruvim.pinka@gmail.com> - 2024-10-06 20:04 +0400
value-flavoured approach in API (was: value-flavoured structures) Ruvim <ruvim.pinka@gmail.com> - 2024-10-06 20:58 +0400
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-14 12:32 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 14:52 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-14 15:08 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 17:13 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 17:43 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 17:41 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-14 18:54 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 19:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-15 06:17 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-15 07:30 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-15 07:35 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:42 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-15 18:14 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-15 08:58 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-15 09:58 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (ahmed) - 2024-09-15 12:06 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-16 09:13 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 10:13 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-16 10:36 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 22:47 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-16 13:21 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 13:33 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-16 12:16 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 19:55 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 21:43 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-17 10:47 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-17 09:12 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-17 08:43 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-17 07:24 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 09:56 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 14:11 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 23:32 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-16 08:48 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 20:01 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:20 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-15 15:28 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:53 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-12 08:55 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 12:39 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 16:26 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-17 12:18 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-18 13:08 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-17 22:39 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-18 17:30 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-18 13:10 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-19 14:14 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-28 13:49 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-28 22:36 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-29 14:22 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-29 11:44 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-30 16:13 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-29 14:40 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-29 16:53 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-29 11:33 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-11 11:02 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-11 13:29 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-12 00:10 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-08 14:56 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-08 16:09 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-09 17:15 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-09 21:16 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-10 12:21 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-10 12:10 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-08 16:27 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-09 17:34 +0000
csiph-web