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 1 of 2  [1] 2  Next page →

#135148 — Back to the Forth Virus

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?

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

[toc] | [next] | [standalone]

#135149

Bernd recently (2026-05-31 20:16) wrote 
"That's the reason why I stopped maintaining the Win version.  It turned 
out that WSL was getting better at running native Linux Gforth than Cygwin 
was running Gforth compiled from source, so it became a waste of time."

If I understand corectly, your answer is gForth for linux running under 
Windows Subsystem for Linux (WSL)

Jan Coombs
--- 


On Mon, 8 Jun 2026 13:40:16 +0200
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?
> 

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

#135150

On 2026-06-08 11:40, clv2020 wrote:
> 
> 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?

A small and modern Forth system that I like: Post4
<https://codeberg.org/SirWumpus/post4>

However, at the moment, this system is not convenient enough when it 
comes to error reporting.


I would like to recommend SP-Forth/4 (which I currently maintain), but 
at the moment, you need to manually rename "SPF.eng.ERR" to "SPF.ERR" in 
the "lib/" directory to make the system output error messages in 
English. This will be fixed in the next release. To obtain the bleeding 
edge executable, you need download sources and run "src/compile.bat". 
Ask me if you have any problem.
<http://github.com/rufig/spf>


> 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?
> 

A reliable way is to build the executable file by yourself.

Gforth can be build and used under WSL on Windows from a tarball; see 
the instruction at:
<https://gforth.org/#:~:text=Build%20from%20Tarball>

Aside from a number of dependencies and the lengthy build process, 
Gforth is quite user-friendly.


--
Ruvim

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

#135151

[Multipart message — attachments visible in raw view] — view raw

Ruvim <ruvim.pinka@gmail.com> writes:

> On 2026-06-08 11:40, clv2020 wrote:
>> 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?

[...]

> A reliable way is to build the executable file by yourself.
>
> Gforth can be build and used under WSL on Windows from a tarball; see
> the instruction at:
> <https://gforth.org/#:~:text=Build%20from%20Tarball>
>
> Aside from a number of dependencies and the lengthy build process,
> Gforth is quite user-friendly.

Just to inform, that I was unsuccessful with building GForth on a GNU
operating system.  Besides the build error, the public PGP key they used
to sign the tarball is nowhere to be found.  So I had to blind-trust,
then got a build error.

If a build error also happens in windows, I wouldn't be surprised.

Cheers for Freedom,

-- 
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

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

#135153

Daniel Cerqueira <dan.list@lispclub.com> writes:
>Just to inform, that I was unsuccessful with building GForth on a GNU
>operating system.  Besides the build error,

Please provide details, possibly by email (less work for me to forward
it to Bernd).

>the public PGP key they used
>to sign the tarball is nowhere to be found.  So I had to blind-trust,

Try <https://savannah.gnu.org/people/viewgpg.php?user_id=9629>.  With
that I get

[a4:/tmp:110662] gpg --verify gforth.tar.xz.sig
gpg: assuming signed data in 'gforth.tar.xz'
gpg: Signature made Wed 13 May 2026 04:48:59 PM CEST
gpg:                using RSA key 449D4D0EA3D0470627C018EBF72D9493932DA067
gpg: Good signature from "Bernd Paysan <bernd.paysan@gmx.de>" [unknown]
[...]
gpg: Signature notation: manu=2,2.5+1.12,2,2
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

So you may still distrust it.  OTOH, you get the snapshot from
<https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/>, which is
secured with https, and the signature comes from
<https://savannah.gnu.org/>, also secured with https, so an attack
scenario that subverts all that is interesting.  The easiest way
probably would be to break into Bernd Paysan's computer where he
builds and signs Gforth, but then a trusted signature does not help.

- 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]

#135154

[Multipart message — attachments visible in raw view] — view raw

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Daniel Cerqueira <dan.list@lispclub.com> writes:
>>Just to inform, that I was unsuccessful with building GForth on a GNU
>>operating system.  Besides the build error,
>
> Please provide details, possibly by email (less work for me to forward
> it to Bernd).



>>the public PGP key they used
>>to sign the tarball is nowhere to be found.  So I had to blind-trust,
>
> Try <https://savannah.gnu.org/people/viewgpg.php?user_id=9629>.  With
> that I get
>
> [a4:/tmp:110662] gpg --verify gforth.tar.xz.sig
> gpg: assuming signed data in 'gforth.tar.xz'
> gpg: Signature made Wed 13 May 2026 04:48:59 PM CEST
> gpg:                using RSA key 449D4D0EA3D0470627C018EBF72D9493932DA067
> gpg: Good signature from "Bernd Paysan <bernd.paysan@gmx.de>" [unknown]
> [...]
> gpg: Signature notation: manu=2,2.5+1.12,2,2
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.

[...]

Thank you.  That does it :-) .

What should I do when I want to find out people's keys on Savannah ?


-- 
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

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

#135155

Daniel Cerqueira <dan.list@lispclub.com> writes:
>What should I do when I want to find out people's keys on Savannah ?

What I did was to look at Gforth's page, where Bernd Paysan is listed,
and then I clicked on his name, and then on "Download GPG Key".

Another way is to put the name in the search field, select "People"
from the area to search in, and then click on search, and finally on
"Download GPG Key".

- 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]

#135532 — GForth reproducible builds (was Re: Back to the Forth Virus)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> you get the snapshot from
> <https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/>, which is
> secured with https, and the signature comes from
> <https://savannah.gnu.org/>, also secured with https, so an attack
> scenario that subverts all that is interesting.  The easiest way
> probably would be to break into Bernd Paysan's computer where he
> builds and signs Gforth, but then a trusted signature does not help.

Generally speaking, so-called “reproducible builds” are a potential
solution to this problem — they do not prevent back doors from being
introduced into the source code, but if there is no back door in the
source code, they will detect any attempt to introduce back doors into
the executable code, because builds on different machines will not match
byte-for-byte.  (Unless all of the build machines have been subverted by
the same attacker.)

Debian is currently succeeding in building GForth 0.7.3 reproducibly:
<https://reproduce.debian.net/amd64/forky.html#gforth>

Kragen

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

#135156

Am 08.06.2026 um 13:40 schrieb clv2020:
> 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?
> 

You already mentioned some of the actively maintained Forths e.g. with
company backup. And most Forthers (not that there are many) use their
own private Forth systems. You restricted yourself to Win11 desktop
systems, but you'll find more widespread usage for embedded systems
e.g. with ESP32Forth or Mecrisp Stellaris.

For experimentation in a Win11 text console you might find MinForth
interesting:
https://sourceforge.net/projects/minforth/files/

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

#135160

Am 09.06.2026 um 01:01 schrieb minforth:

> For experimentation in a Win11 text console you might find MinForth
> interesting:
> https://sourceforge.net/projects/minforth/files/

I just tried minforth. An interesting method to reduce the forth system 
to small application. The transpiler of course does not know about words 
with Create does> I wrote by myself. Are there more drawbacks?

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

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

#135166

Am 10.06.2026 um 13:13 schrieb clv2020:
> Am 09.06.2026 um 01:01 schrieb minforth:
> 
>> For experimentation in a Win11 text console you might find MinForth
>> interesting:
>> https://sourceforge.net/projects/minforth/files/
> 
> I just tried minforth. An interesting method to reduce the forth system 
> to small application. The transpiler of course does not know about words 
> with Create does> I wrote by myself. Are there more drawbacks?
> 

The transpiler offers a workaround in the form of
... create ['] <does-code> _<does ...
for instance as in

: FCONSTANT  \ ( f 'name' -- |r -- f) 12.6.1.1492 fp-number constant
    create f, ['] f@ _<does ;

Although it can go far in some cases, the transpiler is not really meant
to translate Forth _applications_. The obvious drawback is that while
compiling, it cannot execute already compiled words. Compiletime-
execution is simply not possible with standard C. Zig seems to promise
more, but I have not yet looked into it.

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

#135168

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
<https://net2o.de/gforth/CREATE_002e_002eDOES_003e-details.html#index-set_002ddoes_003e-_0028-xt-_002d_002d-_0029-gforth>

- 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]

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

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.

The name '_<does' is also strange.

Why not simply choose the name `set-does`?
Or, even better, `set-latest-doer` ?



set-latest-doer ( xt2 -- )
Obtain the execution token xt1 of the latest definition.
Replace the execution semantics identified by xt1 with the following: 
Place the data filed address associated with xt1 on the stack and 
execute xt2.
An ambiguous condition exists if no data filed address is associated 
with xt1.


If you can set a doer for any child of `create` (not only the latest 
one), a possible factor is as follows.

doer! ( xt2 xt1 -- )
Replace the execution semantics identified by xt1 with the following: 
Place the data filed address associated with xt1 on the stack and 
execute xt2.
An ambiguous condition exists if no data filed address is associated 
with xt1.


The latest definition: the definition that was placed into the 
compilation word list most recently among the definitions available in 
the compilation word list.


--
Ruvim

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

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

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.

- 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]

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

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>.

Unfortunatley, Gforth contains a word USE with a different meaning:

  'use' ( "file" -  ) gforth-0.2
     Open file as the current blocks file.

- 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]

#135173 — Re: Naming issues in create-does

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 , ;

> 
> Unfortunatley, Gforth contains a word USE with a different meaning:
> 
>   'use' ( "file" -  ) gforth-0.2
>      Open file as the current blocks file.
> 
> - anton

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

#135174 — Re: Naming issues in create-does

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?

As for `does>`, I also prefer to pass an xt and avoid patching. However, 
for the sake of backward compatibility and support for legacy programs, 
we have to retain `does>` as well.

I would like to introduce a basic factor of your `BUILD` that accept an 
xt and return other xt.

How to call such a word?

XXX ( xt1 -- xt2 )
Create a nameless definition with the execution token xt2.
If the data-space pointer is not aligned, reserve enough data space to 
align it. The new data-space pointer defines the data field associated 
with xt2. No data space is allocated in the data field. The execution 
semantics identified by xt2 are as follows: Place the data filed address 
associated with xt2 on the stack and execute xt1.



--
Ruvim

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

#135177 — Re: Naming issues in create-does

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.

> As for `does>`, I also prefer to pass an xt and avoid patching. However, for the sake of backward compatibility and support for legacy programs, we have to retain `does>` as well.

That was my conclusion too.  That said, there's little reason for me to
actually use DOES> .

> 
> I would like to introduce a basic factor of your `BUILD` that accept an xt and return other xt.
> 
> How to call such a word?
> 
> XXX ( xt1 -- xt2 )
> Create a nameless definition with the execution token xt2.
> If the data-space pointer is not aligned, reserve enough data space to align it. The new data-space pointer defines the data field associated with xt2. No data space is allocated in the data field. The execution semantics identified by xt2 are as follows: Place the data filed address associated with xt2 on the stack and execute xt1.

When you say it's a factor, do you mean xt1 is passed to BUILD in which case
XXX is transparent?

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

#135179 — Re: Naming issues in create-does

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>


>> As for `does>`, I also prefer to pass an xt and avoid patching.
>> However, for the sake of backward compatibility and support for legacy
>> programs, we have to retain `does>` as well.
> 
> That was my conclusion too.  That said, there's little reason for me to
> actually use DOES> .
> 
>>
>> I would like to introduce a basic factor of your `BUILD` that accept an xt and return other xt.
>>
>> How to call such a word?
>>
>> XXX ( xt1 -- xt2 )
>> Create a nameless definition with the execution token xt2.
>> If the data-space pointer is not aligned, reserve enough data space to 
>> align it. The new data-space pointer defines the data field associated 
>> with xt2. No data space is allocated in the data field. The execution 
>> semantics identified by xt2 are as follows: Place the data filed address 
>> associated with xt2 on the stack and execute xt1.>
> When you say it's a factor, do you mean xt1 is passed to BUILD in which case
> XXX is transparent?
> 

I mean that BUILD can be defined using XXX as follows:

    : BUILD ( xt1 "<spaces>name" -- )
      XXX ( xt2 ) PARSE-NAME ENLIST
    ;

Where the word ENLIST places a new word to the compilation word list.

ENLIST ( xt1 sd.name -- )
Place a named definition into the compilation word list; the
definition's name matches the character string sd.name, and the
definition's execution semantics are equivalent to the execution
semantics identified by xt1.


One of the issues I currently see is that, for `>body` to work
correctly, `enlist` must guarantee either the identity of the execution
token:

   t{ :noname ;  dup s" foo" enlist -> ' foo }t

or, at least, the identity of the data field (and other associated
properties):

   t{ create bar  ' bar >body  ' bar s" foo" enlist -> ' foo >body }t



--
Ruvim

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

#135184 — Re: Naming issues in create-does

On 2026-06-13 15: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:
[...]
>>>> DX-Forth implemented BUILD to support its compilation model.  I saw no
>>>> reason to persist with the 'CREATE then patch' concept.
>>>>
>>>>     : CONSTANT ['] @ BUILD , ;
[...]
>>>
>>> I would like to introduce a basic factor of your `BUILD` that accept 
>>> an xt and return other xt.
>>>
>>> How to call such a word?
>>>
>>> XXX ( xt1 -- xt2 )
>>> Create a nameless definition with the execution token xt2.
>>> If the data-space pointer is not aligned, reserve enough data space 
>>> to align it. The new data-space pointer defines the data field 
>>> associated with xt2. No data space is allocated in the data field. 
>>> The execution semantics identified by xt2 are as follows: Place the 
>>> data filed address associated with xt2 on the stack and execute xt1.

A possible name:

   BIND-DATAFIELD ( xt1 -- xt2 )
   \ A more narrow type specification:
   \ ( xt1[ any1 addr.data-field -- any2 ] -- xt2[ any1 -- any2 ] )

Rationale. In some popular languages, the verb "bind" is used in the 
name of a method/function that creates a partially applied function. In 
our case, we bind a function to a data filed, and also allow to use 
`>body` to obtain the data field address from the xt2. That is why the 
part "datafield" is present in the name.


>>
>> When you say it's a factor, do you mean xt1 is passed to BUILD in 
>> which case XXX is transparent?
>>
> 
> I mean that BUILD can be defined using XXX as follows:
> 
>     : BUILD ( xt1 "<spaces>name" -- )
>       XXX ( xt2 ) PARSE-NAME ENLIST
>     ;

A problem with this approach is that `enlist` reserves (allocates) a 
data space range withing the data field associated with xt2.

Thus, neither `create` nor `build` can be defined using such XXX.

Some other words can. For example:

   : alias ( xt "<space>name" -- ) parse-name enlist ;

   : constant ( x "<spaces>name" -- )
     ['] @ bind-datafiled >r  ,  r> alias
   ;




> 
> Where the word ENLIST places a new word to the compilation word list.
> 
> ENLIST ( xt1 sd.name -- )
> Place a named definition into the compilation word list; the
> definition's name matches the character string sd.name, and the
> definition's execution semantics are equivalent to the execution
> semantics identified by xt1.
> 
> 
> One of the issues I currently see is that, for `>body` to work
> correctly, `enlist` must guarantee either the identity of the execution
> token:
> 
>    t{ :noname ;  dup s" foo" enlist -> ' foo }t
> 
> or, at least, the identity of the data field (and other associated
> properties):
> 
>    t{ create bar  ' bar >body  ' bar s" foo" enlist -> ' foo >body }t
> 

--
Ruvim

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web