Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135148 > unrolled thread

Back to the Forth Virus

Back to article view | Back to comp.lang.forth

Contents

  Back to the Forth Virus clv2020 <clv2020@vodafonemail.de> - 2026-06-08 13:40 +0200
    Re: Back to the Forth Virus Jan Coombs <jan4etsept@murray-microft.co.uk> - 2026-06-08 13:16 +0100
    Re: Back to the Forth Virus Ruvim <ruvim.pinka@gmail.com> - 2026-06-08 12:23 +0000
      Re: Back to the Forth Virus Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-08 13:56 +0100
        Re: Back to the Forth Virus anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 15:40 +0000
          Re: Back to the Forth Virus Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-08 19:26 +0100
            Re: Back to the Forth Virus anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 20:06 +0000
          GForth reproducible builds (was Re: Back to the Forth Virus) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 14:40 -0300
    Re: Back to the Forth Virus minforth <minforth@gmx.net> - 2026-06-09 01:01 +0200
      Re: Back to the Forth Virus clv2020 <clv2020@vodafonemail.de> - 2026-06-10 13:13 +0200
        Re: Back to the Forth Virus minforth <minforth@gmx.net> - 2026-06-11 10:01 +0200
          Re: Back to the Forth Virus anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-11 17:28 +0000
            Naming issues in create-does (was: Back to the Forth Virus) Ruvim <ruvim.pinka@gmail.com> - 2026-06-12 17:23 +0000
              Re: Naming issues in create-does (was: Back to the Forth Virus) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-12 17:52 +0000
                Re: Naming issues in create-does (was: Back to the Forth Virus) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-12 18:22 +0000
                  Re: Naming issues in create-does dxf <dxforth@gmail.com> - 2026-06-13 13:14 +1000
                    Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-13 06:33 +0000
                      Re: Naming issues in create-does dxf <dxforth@gmail.com> - 2026-06-13 22:20 +1000
                        Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-13 15:55 +0000
                          Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-15 13:08 +0000
                          Re: Naming issues in create-does Hans Bezemer <the.beez.speaks@gmail.com> - 2026-07-23 19:58 +0200
                    Defining words in more than one step (was: Naming issues in create-does) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 06:46 +0000
                      Re: Defining words in more than one step dxf <dxforth@gmail.com> - 2026-06-14 12:29 +1000
                Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-12 19:59 +0000
                  Re: Naming issues in create-does anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 10:25 +0000
                    Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-13 15:30 +0000
                      Re: Naming issues in create-does anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 17:30 +0000
                Re: Naming issues in create-does (was: Back to the Forth Virus) peter <peter.noreply@tin.it> - 2026-06-13 20:21 +0200
    Re: Back to the Forth Virus dxf <dxforth@gmail.com> - 2026-06-09 12:14 +1000
      Re: Back to the Forth Virus "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-06-10 18:54 +0100
        Re: Back to the Forth Virus dxf <dxforth@gmail.com> - 2026-06-11 16:32 +1000
          Re: Back to the Forth Virus "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-06-11 14:20 +0100
    Re: Back to the Forth Virus Stephen Pelc <stephen@vfxforth.com> - 2026-06-09 10:22 +0000
      Re: Back to the Forth Virus clv2020 <clv2020@vodafonemail.de> - 2026-06-10 15:55 +0200
    Re: Back to the Forth Virus albert@SPENARNC.XS4ALL.NL - 2026-07-24 13:35 +0200

Page 2 of 2 — ← Prev page 1 [2]

#135249 — Re: Naming issues in create-does

On 13-06-2026 17:55, Ruvim wrote:
> On 2026-06-13 12:20, dxf wrote:
>> On 13/06/2026 4:33 pm, Ruvim wrote:
>>> On 2026-06-13 03:14, dxf wrote:
>>>> On 13/06/2026 4:22 am, Anton Ertl wrote:
>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>> Overall, SET-DOES> is unambiguous and good enough.
>>>>>
>>>>> But while we are at it, according to Andrew Haley early Forth had USE
>>>>> with the same functionality as SET-DOES>.
>>>>
>>>> I don't recall that one.  AFAIK the original definer was in the form:
>>>>
>>>>     : ... CONSTANT ;: ... ;
>>>>
>>>> Presumably 2CONSTANT VARIABLE etc could also be used.  Hard to find 
>>>> actual
>>>> examples as vintage code is scarce.
>>>>
>>>> In addition to CREATE DOES> F83 had:
>>>>
>>>>     : CONSTANT   (S n -- )
>>>>        CREATE ,   ;USES DOCONSTANT ,
>>>>
>>>> a move closer to the xt variants.
>>>>
>>>> DX-Forth implemented BUILD to support its compilation model.  I saw no
>>>> reason to persist with the 'CREATE then patch' concept.
>>>>
>>>>     : CONSTANT ['] @ BUILD , ;
>>>
>>>
>>> BTW, do you consider `immediate` to be a from of patching as well?
>>
>> IMMEDIATE alters a flag in the word's header that informs the compiler
>> how the word should be treated.  Nothing is actually replaced.

> In some implementations, the run-time semantics of `does>` only stores
> an xt at an address. For example, this is how my portable create-does
> implementation [1] works.
> 
> [1] <https://gist.github.com/ruv/4b957889b59480cb19a440d00346b0ae>


Oh, how wildly different 4tH works. First, you cannot use when defining 
a new datatype, cause apart from defining arrays of various length, you 
cannot define new data types.

You can only add DOES> to either a cell or a character (array) -- and 
only if that symbol returns either a literal or a variable. And it 
should represent a (cell or string (array)) pointer. E.g. you can add a 
DOES> to a string or array, but not a VALUE (because it returns a value, 
not a pointer).

What a DOES> does is create a *NEW* definition with the *name* of the 
original variable or and compiles the pointer before adding the rest of 
the code.

For this reason, this Gforth lines in 
https://rosettacode.org/wiki/15_puzzle_game#Forth can be compiled by 4tH 
unchanged:

create valid? ' up-valid? , ' left-valid? , ' right-valid? , ' 
down-valid? , does> ith execute ;
create step -4 , -1 , 1 , 4 , does> ith ;

Also the application of VALIOD

Hans Bezemer

> -- 
> Ruvim
> 

[toc] | [prev] | [next] | [standalone]

#135175 — Defining words in more than one step (was: Naming issues in create-does)

dxf <dxforth@gmail.com> writes:

>On 13/06/2026 4:22 am, Anton Ertl wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> But while we are at it, according to Andrew Haley early Forth had USE
>> with the same functionality as SET-DOES>.

Actually, he wrote in <KZadnaZ99qHVrl7LnZ2dnUU7-S2dnZ2d@supernews.com>:

| That's not wildly different from polyFORTH II, which had USE:
| 
|     CREATE FOO  ... blah ...   <address> USE
| 
| USE takes the address of some runtime code and patches it into the
| code field of the most recent definition.  I think that syntax is a
| little more pleasant than your above.

So it's probably like Gforth's SET-EXECUTE (which takes a machine-code
address), not like Gforth's SET-DOES> (which takes an xt).  And
polyForthII is not that early.

>I don't recall that one.  AFAIK the original definer was in the form:
>
>  : ... CONSTANT ;: ... ;

Interestingly, Elizabeth Rather writes in
<LY2dnf9BXvXOmQTKnZ2dnUU7-XHNnZ2d@supernews.com>:

|> Elizabeth D. Rather wrote:
|>> Historical note: ;: was Chuck's original name for the structure which
|>> for many years now has been CREATE DOES> (by separating the creation
|>> from the instance behaviors you get more flexibility).
|..
|I don't really remember the details, but as I recall it didn't have the 
|separate CREATE step,

But it still might be as you write.

>DX-Forth implemented BUILD to support its compilation model.  I saw no
>reason to persist with the 'CREATE then patch' concept.
>
>  : CONSTANT ['] @ BUILD , ;

That's nice.  In my EuroForth 2015 paper
<http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/ertl.pdf>
I suggested the word DOES-CREATE and gave the example

: const ( n "name" -- )
    [’] @ does-create , ;

In <2016Feb16.173433@mips.complang.tuwien.ac.at> I followed up on that
by remarking that DOES> is not the only word that changes an existing
word.  Ruvim mentioned IMMEDIATE, but Gforth also has SET-OPTIMIZER,
SET-TO and other words of this kind.  So in the spirit of
DOES-CREATE/BUILD, I suggested that we might move to specifying the
modifications first, and producing the word only afterwards, and gave

: constant ( n "name" -- )
  \ you must not change the body of "name"
  ['] @ next-does>
  [: >body @ postpone literal ;] next-optimizer
  create , ;

as example.  I fleshed this out more in
<2016Jul28.111700@mips.complang.tuwien.ac.at>:

|However, that's not the only issue in this context; we also have other
|words that change existing words, in particular, IMMEDIATE; among
|non-standard words, we have e.g., COMPILE-ONLY and SET-OPTIMIZER/OPT:.
|
|Doing all of that in one step is not very practical.  We could have a
|word with one parameter for each of these options that creates a word
|with these options in one step, maybe something like:
|
|new-word ( flag1 flag2 xt1 xt2 xt3 xt4 "name" -- )
|\ flag1 specifies immediacy
|\ flag2 specifies compile-only
|\ xt1 specifies interpretation/execution semantics
|\ xt2 specifies compilation semantics
|\ xt3 specifies what to do when COMPILE,ing the xt of "name" (for optimization)
|\ xt4 specifies TO "name" semantics
|
|But, apart from the sheer uglyness, that would require standardizing
|all these features, and leaving no room for non-standard features.  So
|I lean more towards recording the things for the next definition in a
|RAM buffer, and then the next defining word puts all these features in
|the newly-defined word (in flash, in one step), and wipe the (RAM)
|slate clean for the next word to be defined; i.e. for an immediate
|word, it would be something like:
|
|next-immediate : bar ... ;
|
|For the DOES>-using foo example above it would be:
|
|: foo
|  [: code2 ;] next-does create code1 ;
|
|For an optimizing 2DUP it would be
|
|:noname drop postpone over postpone over ; next-optimizer
|: 2dup over over ;
|
|And then one could combine several of these setup words.  E.g., for
|defining <http://forth-standard.org/standard/facility/PlusFIELD>:
|
|: +field ( n1 n2 "name" -- n3 )
|  [: @ + ;] next-does
|  [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
|  create over , + ;

and in <2016Jul28.165423@mips.complang.tuwien.ac.at>:

|"HAA" <someone@microsoft.com> writes:
|>You could do
|>
|>: foo  ['] xt2 <does-create code1 ;
|>
|>For basic systems xt2 is what you expect but for systems requiring
|>multiple xt's and/or other info, xt2 can be a system-specific struct
|>containing all the information foo needs to create child words.
|
|Yes, having an explicit word-descriptor structure, with a default
|content (or content coming from an existing word), rather than an
|implicit next-word-descriptor structure is also a possibility.
|
|E.g., for the implicit example from my posting
|
|: +field ( n1 n2 "name" -- n3 )
|  [: @ + ;] next-does
|  [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
|  create over , + ;
|
|an explicit-descriptor variant might look like this:
|
|word-descriptor field-desc
|:noname @ + ; field-desc word-does!
|:noname >body @ ?dup if postpone literal postpone + then ; 
|field-desc word-optimizer!
|
|: +field ( n1 n2 "name" -- n3 )
|  field-desc word-create over , + ;

IIRC neither of these ideas found much interest, even among the
compile-to-flash people, so I did not pursue them further and instead
we continued to work with the create-then-patch approach.

With the new Gforth header, the create-then-patch approach means that
we have to duplicate the header-method structure when patching; to
save memory, we deduplicate this structure when the next word is
started.  But this duplication and deduplication costs time (also
code, but we cannot get rid of that), so for frequent users like
CONSTANT and FIELD, we introduced another creation word, somewhat in
the spirit of WORD-CREATE above, but inspired by implementation
issues:

|'create-from' ( nt "name" -  ) gforth-1.0
|   Create a word name that behaves like nt, but with an empty body.  nt
|must be the nt of a named word.  The resulting header is not yet
|'reveal'ed; use 'reveal' to reveal it or 'latest' to get its xt.
|Creating a word with 'create-from' without using any 'set-' words is
|faster than if you create a word using 'set-' words, 'immediate', or
|'does>'.  You can use 'noname' with 'create-from'.

The usual way to use it is to define a prototype for a kind of word,
and then use the prototype with CREATE-FROM.  E.g., the CONSTANT above
could be defined as:

create constant-prototype
['] @ set-does>
[: >body @ postpone literal ;] set-optimizer

: constant ( n "name" -- )
  ['] constant-prototype create-from , reveal ;

Now Gforth uses CREATE-FROM extensively for all the common defining
words.  I guess that not that much deduplication happens in Gforth
these days.

It probably would be good enough to just have a one-bit reference
counter (1: one reference; 0: >1 references) in the header-methods
structure, and SET-* words, DOES> and IMMEDIATE duplicate if there is
more than one reference, and there is no deduplication.  We would have
additional header-methods structures for words defined with IMMEDIATE
and with DOES>, but for Gforth that would probably be less than 1000
cells of memory, which for the kind of systems that Gforth runs on
does not justify the code and the time expended on deduplication.  Of
course, now that we have the deduplication code, the cost is mainly
the time, which is acceptable given that most words are created with
CREATE-FROM and do not need deduplication.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#135182 — Re: Defining words in more than one step

On 13/06/2026 4:46 pm, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
> 
>> On 13/06/2026 4:22 am, Anton Ertl wrote:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> But while we are at it, according to Andrew Haley early Forth had USE
>>> with the same functionality as SET-DOES>.
> 
> Actually, he wrote in <KZadnaZ99qHVrl7LnZ2dnUU7-S2dnZ2d@supernews.com>:
> 
> | That's not wildly different from polyFORTH II, which had USE:
> | 
> |     CREATE FOO  ... blah ...   <address> USE
> | 
> | USE takes the address of some runtime code and patches it into the
> | code field of the most recent definition.  I think that syntax is a
> | little more pleasant than your above.
> 
> So it's probably like Gforth's SET-EXECUTE (which takes a machine-code
> address), not like Gforth's SET-DOES> (which takes an xt).  And
> polyForthII is not that early.

I looked into it, and yes, pF has USE.  But it may be of limited use.
It's not documented in the manual (polyFORTH ISD-4 dated 1986).  I only
noticed it from a disassembly.  The only info/usage I was able to glean
being:

  : USE ( A -- )  LAST @ @ CFA ! ;

  : (;CODE)  R> USE ;

  CREATE (PEXPECT) WAIT USE

  : CODE  CREATE HERE USE ASSEMBLER ;

[toc] | [prev] | [next] | [standalone]

#135172 — Re: Naming issues in create-does

On 2026-06-12 17:52, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2026-06-11 17:28, Anton Ertl wrote:
>>> minforth <minforth@gmx.net> writes:
>>>> : FCONSTANT  \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
>>>>      create f, ['] f@ _<does ;
>>>
>>> The word that you call _<does is called SET-DOES> in Gforth
>>
>> In the name `does>`,  the symbol `>` means that the following code up to
>> ';' is a part of the semantics of the recent child of `create` (not the
>> containing definition).
>>
>> In the name "set-does>" the symbol ">" is misleading.
> 
> Yes.  But given that Forth and Gforth continues to have DOES>,
> SET-DOES> makes it clear to which word it is related.  And I also find
> it easier to remember that the spelling of DOES> does not differ
> between DOES> and SET-DOES>.


In my view, it is more important (than same spelling) for special 
symbols in names to convey a specific meaning.



> 
>> The name '_<does' is also strange.
> 
> Given the explanation for the ">" in DOES>, <DOES points in the
> direction where the xt should be pushed on the stack.  

However, the names of other words that take an xt from the stack do not 
begin with "<".


> It's not clear to me why minforth prepended a "_".
> 
>> Why not simply choose the name `set-does`?
> 
> Different spelling of the "DOES>" part.
> 
>> Or, even better, `set-latest-doer` ?
> 
> Even more different.  Gforth contains a number of words that change
> the latest word, and they all start with SET-, not with SET-LATEST-

> (one might see it as a problem that there are words that do not change
> the latest word and that have also names starting with SET-).

Yes, this is an inconsistency in naming.

> And the
> spelling of DOES> is even more different.  Plus, we (at least in
> Gforth source code, maybe also elsewhere) call run-time routines like
> DOCOL DOCON DOVAR and DODOES doers, so I would expect that
> SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.

I see.  In that case, since Gforth already has `DODOES` (rather than 
`DODOES>`), the name `SET-DOES` seems more appropriate.


> 
> Overall, SET-DOES> is unambiguous and good enough.
> 
> - anton


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135176 — Re: Naming issues in create-does

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2026-06-12 17:52, Anton Ertl wrote:
>> And the
>> spelling of DOES> is even more different.  Plus, we (at least in
>> Gforth source code, maybe also elsewhere) call run-time routines like
>> DOCOL DOCON DOVAR and DODOES doers, so I would expect that
>> SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
>
>I see.  In that case, since Gforth already has `DODOES` (rather than 
>`DODOES>`), the name `SET-DOES` seems more appropriate.

There is no Forth word DODOES in Gforth.  Howerver, there are the
following documented (i.e., supported) words that contain "DOES", with
the line numbers where they occur in the source code of the manual.

 9061: does>
 9103: set-does>
 9620: const-does>
18986: dodoes:
18998: >does-code
19003: does-code!

An early occurence indicates that the word is more foundational and
more generally useful, while a late occurence indicates a word that
may be useful in specific places.

The documentation for the latter three words is:

'dodoes:' ( - addr  ) gforth-0.6 "dodoes-colon"
   The code address of a 'DOES>'-defined word.

'>does-code' ( xt1 - xt2  ) gforth-0.2 "to-does-code"
   If xt1 is the execution token of a child of a 'set-does>'-defined
word, xt2 is the xt passed to 'set-does>', i.e, the xt of the word that
is executed when executing xt1 (but first the body address of xt1 is
pushed).  If xt1 does not belong to a 'set-does>'-defined word, xt2 is
0.

'does-code!' ( xt2 xt1 -  ) gforth-0.2 "does-code-store"
   Change xt1 to be a 'xt2 set-does>'-defined word.

So if we would rename, then we would probably introduce DODOES>:,
>DOES>-CODE and DOES>-CODE! and declare the other words obsolete.
Maybe we will, but for now there is no desire to go there.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#135178 — Re: Naming issues in create-does

On 2026-06-13 10:25, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2026-06-12 17:52, Anton Ertl wrote:
>>> And the
>>> spelling of DOES> is even more different.  Plus, we (at least in
>>> Gforth source code, maybe also elsewhere) call run-time routines like
>>> DOCOL DOCON DOVAR and DODOES doers, so I would expect that
>>> SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
>>
>> I see.  In that case, since Gforth already has `DODOES` (rather than
>> `DODOES>`), the name `SET-DOES` seems more appropriate.
> 
> There is no Forth word DODOES in Gforth.  Howerver, there are the
> following documented (i.e., supported) words that contain "DOES", with
> the line numbers where they occur in the source code of the manual.
> 
>   9061: does>
>   9103: set-does>
>   9620: const-does>
> 18986: dodoes:
> 18998: >does-code
> 19003: does-code!
> 
> An early occurence indicates that the word is more foundational and
> more generally useful, while a late occurence indicates a word that
> may be useful in specific places.
> 
> The documentation for the latter three words is:
> 
> 'dodoes:' ( - addr  ) gforth-0.6 "dodoes-colon"
>     The code address of a 'DOES>'-defined word.

What does the colon at the end mean?
I would hide that word in the attic and not show it to anyone ;-)


> 
> '>does-code' ( xt1 - xt2  ) gforth-0.2 "to-does-code"
>     If xt1 is the execution token of a child of a 'set-does>'-defined
> word, xt2 is the xt passed to 'set-does>', i.e, the xt of the word that
> is executed when executing xt1 (but first the body address of xt1 is
> pushed).  If xt1 does not belong to a 'set-does>'-defined word, xt2 is
> 0.
> 
> 'does-code!' ( xt2 xt1 -  ) gforth-0.2 "does-code-store"
>     Change xt1 to be a 'xt2 set-does>'-defined word.
> 
> So if we would rename, then we would probably introduce DODOES>:,
> >DOES>-CODE and DOES>-CODE! and declare the other words obsolete.
> Maybe we will, but for now there is no desire to go there.


The names `defer@` and `defer` follow a well known naming convention and 
look far better than `>does>code` (although I don't like the "defer" 
part in them).


One option that I consider is to introduce an artificial noun, such as 
"codedoes", and use it in names as follows:

   codedoes! ( xt2 xt1 -- )
   codedoes@ ( xt1 -- xt2|0 )
   set-codedoes ( xt2 -- )
   set-latest-codedoes ( xt2 -- )


--
Ruvim

[toc] | [prev] | [next] | [standalone]

#135180 — Re: Naming issues in create-does

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2026-06-13 10:25, Anton Ertl wrote:
>> The documentation for the latter three words is:
>> 
>> 'dodoes:' ( - addr  ) gforth-0.6 "dodoes-colon"
>>     The code address of a 'DOES>'-defined word.
>
>What does the colon at the end mean?

DODOES:, DOCOL: etc. are native code addresses (the only native-code
addresses around at the time when these words were introduced).  You
would put them in a code field.

>I would hide that word in the attic and not show it to anyone ;-)

You can decide that for your system.

These words are there, because of the original goal that Gforth should
be a model implementation of Forth.  And given that it was
indirect-threaded or direct-threaded in the beginning, the code
addresses used in the code field were exposed.  The difference between
indirect and direct threading was hidden behind words like
CODE-ADDRESS!.

These days, we have slightly higher-level words like SET-EXECUTE that
take code addresses like DOCOL:.  SET-EXECUTE ensures that COMPILE,
behaves in line with the new interpretation/execution semantics,
unlike when you use CODE-ADDRESS!.  But we still need the code
addresses.

We rarely need DODOES:, because we have SET-DOES>, which implicitly
sets the code address to DODOES:.  The most relevant use of DODOES:
probebly is when checking if a word has the code address DODOES:.

Or, even higher-level, you define a new word from a prototype with
CREATE-FROM, without needing to set the code address or anything else
explicitly.

- 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 2025 proceedings: http://www.euroforth.org/ef25/papers/

[toc] | [prev] | [next] | [standalone]

#135181 — Re: Naming issues in create-does (was: Back to the Forth Virus)

On Fri, 12 Jun 2026 17:52:46 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Ruvim <ruvim.pinka@gmail.com> writes:
> >On 2026-06-11 17:28, Anton Ertl wrote:
> >> minforth <minforth@gmx.net> writes:
> >>> : FCONSTANT  \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
> >>>     create f, ['] f@ _<does ;
> >> 
> >> The word that you call _<does is called SET-DOES> in Gforth
> >
> >In the name `does>`,  the symbol `>` means that the following code up to 
> >';' is a part of the semantics of the recent child of `create` (not the 
> >containing definition).
> >
> >In the name "set-does>" the symbol ">" is misleading.
> 
> Yes.  But given that Forth and Gforth continues to have DOES>,
> SET-DOES> makes it clear to which word it is related.  And I also find
> it easier to remember that the spelling of DOES> does not differ
> between DOES> and SET-DOES>.
> 
> >The name '_<does' is also strange.
> 
> Given the explanation for the ">" in DOES>, <DOES points in the
> direction where the xt should be pushed on the stack.  It's not clear
> to me why minforth prepended a "_".
> 
> >Why not simply choose the name `set-does`?
> 
> Different spelling of the "DOES>" part.
> 
> >Or, even better, `set-latest-doer` ?
> 
> Even more different.  Gforth contains a number of words that change
> the latest word, and they all start with SET-, not with SET-LATEST-
> (one might see it as a problem that there are words that do not change
> the latest word and that have also names starting with SET-).  And the
> spelling of DOES> is even more different.  Plus, we (at least in
> Gforth source code, maybe also elsewhere) call run-time routines like
> DOCOL DOCON DOVAR and DODOES doers, so I would expect that
> SET-LATEST-DOER does what SET-EXECUTE does, not what SET-DOES> does.
> 
> Overall, SET-DOES> is unambiguous and good enough.

In LXF64 I have SET-DOES>. It came out as a part of DOES> and I took 
the name from GFORTH. I like the name!

IN LXF64 SET-DOES> rewrites the last definition and compiles the xt.
If the xt point to a macro it will be inlined. This means that 
SET-DOES> not only works with CREATE but all definitions that start
with a literal. Like constant, variable, value, defer, and any
colon definition that starts with a literal!

The DOES> part of a definition is compiled as a separate :noname word
Also that can be a macro!

BR
Peter

 
> - anton

[toc] | [prev] | [next] | [standalone]

#135157

On 8/06/2026 9:40 pm, clv2020 wrote:
> Hello,
> 
> some years passed and now I would be interested to try Forth again.
> 
> First question: Which Forth is used nowadays for PCs under Windows11? I tried Win32Forth, ciForth and the old volksForth in an Oracle VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for the moment). What would you recommend?
> 
> The second question: All Forth systems I tried showed critical virus warnings from Google Chrome or Microsoft defender. Even an old volksForth vf38141.arc - no modern archive utiliy could read this format - was captured by Chrome. Win32Forth seems to be kidnapped on about each start by the Defender. I'm not very amused to turn all IT security off to use Forth. Is there a chance to solve this issue?
> 

Provided you've downloaded forth from an original source there should be no actual
virus and any offending files can be tagged as safe.  Win32Forth in particular is
often mentioned as triggering antivirus.  Most of the Win forths you mention are
sitting on my Win10 desktop.  I wouldn't worry about them being 'big' as most follow
the Forth Standard which is enough for writing some apps and reacquainting with
forth.

As for Volksforth and DOS-based forth, you'll need DOSBOX.  I prefer the official
DOSBOX after trying various forks.  Any ARCs can be handled from there.  I use the
DOS utility 'AC - The Archive Converter v3.11' which bulk converts ARC to ZIP.  If
16-bit DOS forth still interests, there is DX-Forth which tries to be modern and
is still maintained.  It's also 'small' producing turnkeys as small as 6 KB :)

HTH

[toc] | [prev] | [next] | [standalone]

#135162

On Tue, 9 Jun 2026 12:14:07 +1000
dxf <dxforth@gmail.com> wrote:

[]
> 16-bit DOS forth still interests, there is DX-Forth which tries to be modern and
> is still maintained.  It's also 'small' producing turnkeys as small as 6 KB :)
> 
Feh; a 2k forth should be easy - it's 1k I'm trying for. (the trick is to
use hash values for keywords).

-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#135165

On 11/06/2026 3:54 am, Kerr-Mudd, John wrote:
> On Tue, 9 Jun 2026 12:14:07 +1000
> dxf <dxforth@gmail.com> wrote:
> 
> []
>> 16-bit DOS forth still interests, there is DX-Forth which tries to be modern and
>> is still maintained.  It's also 'small' producing turnkeys as small as 6 KB :)
>>
> Feh; a 2k forth should be easy - it's 1k I'm trying for. (the trick is to
> use hash values for keywords).

SwiftX uses a recursive procedure to strip unused definitions from an initial
compile.  Such things were beyond by goal/ability which was to replicate
something akin to Turbo-Pascal - a runtime kernel and a compiler that can be
jettisoned.

So what's in your 2K (or 1K) forth and the goal in general?

[toc] | [prev] | [next] | [standalone]

#135167

On Thu, 11 Jun 2026 16:32:44 +1000
dxf <dxforth@gmail.com> wrote:

> On 11/06/2026 3:54 am, Kerr-Mudd, John wrote:
> > On Tue, 9 Jun 2026 12:14:07 +1000
> > dxf <dxforth@gmail.com> wrote:
> > 
> > []
> >> 16-bit DOS forth still interests, there is DX-Forth which tries to be modern and
> >> is still maintained.  It's also 'small' producing turnkeys as small as 6 KB :)
> >>
> > Feh; a 2k forth should be easy - it's 1k I'm trying for. (the trick is to
> > use hash values for keywords).
> 
> SwiftX uses a recursive procedure to strip unused definitions from an initial
> compile.  Such things were beyond by goal/ability which was to replicate
> something akin to Turbo-Pascal - a runtime kernel and a compiler that can be
> jettisoned.
> 
> So what's in your 2K (or 1K) forth and the goal in general?
> 
I admit it's early days, and I'm probably being quite naive about it, but
I've cribbed an asm source (Jones forth) and hacked that down and tried to
implement a hashing scheme rather than 'wasting' space for keywords - I
guess that means 'see' will not be available.

I'm targetting a 8086 chip running DOS with int 21h for IO.
maybe change IO once/if I get something working. 
64k max size prog +interpreter.

2 regs as TOS & TOS-1, further items on the sp stack, so 
PICK is pop TOS_1
SWAP is xchg TOS,TOS_1.


-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#135158

On 8 Jun 2026 at 13:40:16 CEST, "clv2020" <clv2020@vodafonemail.de> wrote:

> Hello,
> 
> some years passed and now I would be interested to try Forth again.
> 
> First question: Which Forth is used nowadays for PCs under Windows11? I
> tried Win32Forth, ciForth and the old volksForth in an Oracle
> VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for
> the moment). What would you recommend?

What do you mean by "too big"

> The second question: All Forth systems I tried showed critical virus
> warnings from Google Chrome or Microsoft defender. Even an old
> volksForth vf38141.arc - no modern archive utiliy could read this format
> - was captured by Chrome. Win32Forth seems to be kidnapped on about each
> start by the Defender. I'm not very amused to turn all IT security off
> to use Forth. Is there a chance to solve this issue?

Without code signing, nearly all Windows Forths will be caught by Defender at
some stage. However, adding relevant sections to the executable with something
like ResHacker reduces the issues greatly. The reason for all this is that
Forth
usually requires a main section to have read, write and execute permissions.
Such a section is often treated as a virus.

Stephen

-- 
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974
http://www.vfxforth.com/downloads/VfxCommunity/
  free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#135161

Am 09.06.2026 um 12:22 schrieb Stephen Pelc:
>> ...  (gForth, bigForth, VFX, Swiftforth are too big for me for
>> the moment). ...
> 
> What do you mean by "too big"

For the moment my little brain tries to understand the traditional 
indirect-threading. Optimized native code might come later for me.

>> The second question: All Forth systems I tried showed critical virus
>> warnings from Google Chrome or Microsoft defender. Even an old
>> volksForth vf38141.arc - no modern archive utiliy could read this format
>> - was captured by Chrome. Win32Forth seems to be kidnapped on about each
>> start by the Defender. I'm not very amused to turn all IT security off
>> to use Forth. Is there a chance to solve this issue?
> 
> Without code signing, nearly all Windows Forths will be caught by Defender at
> some stage. However, adding relevant sections to the executable with something
> like ResHacker reduces the issues greatly. The reason for all this is that
> Forth
> usually requires a main section to have read, write and execute permissions.
> Such a section is often treated as a virus.
> 
> Stephen
> 

I'm not really involved in Resources and ResHack. Virustotal backs your 
opinion. For Win32Forth the only real hint showed:

Contained Resources
SHA-256	File Type	Type	Language	Entropy	Chi2

88479a7c699e9aaa67141fba8271a4eac894467e4268795907e82364e386172f	unknown 
RT_ICON	NEUTRAL	3.16	34436.72
61e4d7114d33c4d5320da94000d1816511ec5e511c0b9b71a3a215375888b0cc	unknown 
RT_ICON	NEUTRAL	2.86	19575.13
b10e28a32eddb2ab20a46ceae59d9c0786911eb20f0c8dd2a28421f226ea2b8b	ICO 
RT_GROUP_ICON	NEUTRAL	2.37	2345.29
b987ff8b14f04477e603e5cb00b2ac25c3b91afee3e929c84c44fd884717c883	unknown 
RT_MANIFEST	NEUTRAL	5.18	5109.05

I have no idea, if this indicates a problem. For me it sounds not critical.

And the other Forths catched by Defender seem too old for resources and 
memory permissions issues.

Claus
-- 
Ich bin nicht die Signatur. Ich putze hier nur.

[toc] | [prev] | [next] | [standalone]

#135252

clv2020 <clv2020@vodafonemail.de> wrote:
> Hello,
>
> some years passed and now I would be interested to try Forth again.
>
> First question: Which Forth is used nowadays for PCs under Windows11? I
> tried Win32Forth, ciForth and the old volksForth in an Oracle
> VirtualBox. (gForth, bigForth, VFX, Swiftforth are too big for me for
> the moment). What would you recommend?
>
> The second question: All Forth systems I tried showed critical virus
> warnings from Google Chrome or Microsoft defender. Even an old
> volksForth vf38141.arc - no modern archive utiliy could read this format
> - was captured by Chrome. Win32Forth seems to be kidnapped on about each
> start by the Defender. I'm not very amused to turn all IT security off
> to use Forth. Is there a chance to solve this issue?

This worked for ciforth. Complains to the virus producer, refer to the
source that is producing the code. They will add an exception.
(It is a myth that virus scanners make computing more secure. Never used
one. Moreover they will not reveal the reason why a program is deemed suspect.)

Groetjes Albert.

--
The glass is half empty. There is no such thing as a free world.
This is the first day of the end of your life.
If you can't beat them, ... too bad.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web