Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Time is an illusion perpetrated by the manufacturers of space.


devel / comp.lang.forth / Re: IS vs. DEFER! (was: Naming for parsing words)

SubjectAuthor
* Naming for parsing wordsRuvim
+* Re: Naming for parsing wordsS Jack
|`* Re: Naming for parsing wordsRuvim
| +* Re: Naming for parsing wordsAnton Ertl
| |+* Re: Naming for parsing wordsHans Bezemer
| ||`* Simplicity and the text interpreter (was: Naming for parsing words)Anton Ertl
| || `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Hans Bezemer
| ||  `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Anton Ertl
| ||   `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Hans Bezemer
| ||    `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Anton Ertl
| ||     +- Re: Simplicity and the text interpreter (was: Naming for parsing words)Hans Bezemer
| ||     `* Re: Simplicity and the text interpreterPaul Rubin
| ||      `- Re: Simplicity and the text interpreterHans Bezemer
| |+* Format to quoting a word (was: Naming for parsing words)Ruvim
| ||+* Re: Format to quoting a word (was: Naming for parsing words)Anton Ertl
| |||+* Re: Format to quoting a word (was: Naming for parsing words)Marcel Hendrix
| ||||+- Re: Format to quoting a word (was: Naming for parsing words)Anton Ertl
| ||||`* Re: Format to quoting a word (was: Naming for parsing words)none
| |||| `- Re: Format to quoting a word (was: Naming for parsing words)Anton Ertl
| |||`* Recognizers precedence (was: Format to quoting a word)Ruvim
| ||| +* Re: Recognizers precedence (was: Format to quoting a word)none
| ||| |`- Re: Recognizers precedence (was: Format to quoting a word)dxforth
| ||| `- Re: Recognizers precedence (was: Format to quoting a word)Ruvim
| ||`- Re: Format to quoting a word (was: Naming for parsing words)none
| |+- Re: Naming for parsing wordsRuvim
| |`* Re: Naming for parsing wordsRuvim
| | `* Re: Naming for parsing wordsnone
| |  `* Re: Naming for parsing wordsdxforth
| |   +* Re: Naming for parsing wordsHans Bezemer
| |   |`* Re: Naming for parsing wordsRuvim
| |   | `* Re: Naming for parsing wordsHans Bezemer
| |   |  `* Re: Naming for parsing wordsRuvim
| |   |   +* Re: Naming for parsing wordsdxforth
| |   |   |`* Re: Naming for parsing wordsRuvim
| |   |   | +- Re: Naming for parsing wordsdxforth
| |   |   | `* Re: Naming for parsing wordsS Jack
| |   |   |  `* Re: Naming for parsing wordsminf...@arcor.de
| |   |   |   `* Re: Naming for parsing wordsS Jack
| |   |   |    `* Re: Naming for parsing wordsS Jack
| |   |   |     `- Re: Naming for parsing wordsS Jack
| |   |   +- Re: Naming for parsing wordsnone
| |   |   `- Re: Naming for parsing wordsHans Bezemer
| |   `* Re: Naming for parsing wordsRuvim
| |    `* Re: Naming for parsing wordsRuvim
| |     `- Re: Naming for parsing wordsnone
| +* Re: Naming for parsing wordsS Jack
| |`* Re: Naming for parsing wordsRuvim
| | +- Re: Naming for parsing wordsS Jack
| | `- Re: Naming for parsing wordsnone
| +* Re: Naming for parsing wordsdxforth
| |`* Re: Naming for parsing wordsRuvim
| | `* Re: Naming for parsing wordsP Falth
| |  `* Re: Naming for parsing wordsRuvim
| |   +* Re: Naming for parsing wordsHans Bezemer
| |   |`* Re: Naming for parsing wordsStephen Pelc
| |   | `- Re: Naming for parsing wordsMarcel Hendrix
| |   `* Re: Naming for parsing wordsP Falth
| |    `* Re: Naming for parsing wordsRuvim
| |     `* Re: Naming for parsing wordsP Falth
| |      +* Re: Naming for parsing wordsRuvim
| |      |+* Re: Naming for parsing wordsAnton Ertl
| |      ||+- Re: Naming for parsing wordsminf...@arcor.de
| |      ||`- Re: Naming for parsing wordsRuvim
| |      |`* Re: Naming for parsing wordsStephen Pelc
| |      | `* Re: Naming for parsing wordsS Jack
| |      |  +* Re: Naming for parsing wordsS Jack
| |      |  |`* Re: Naming for parsing wordsStephen Pelc
| |      |  | `- Re: Naming for parsing wordsAnton Ertl
| |      |  +* Re: Naming for parsing wordsRuvim
| |      |  |+* Re: Naming for parsing wordsHans Bezemer
| |      |  ||+* Re: Naming for parsing wordsdxforth
| |      |  |||`* Re: Naming for parsing wordsHans Bezemer
| |      |  ||| `- Re: Naming for parsing wordsdxforth
| |      |  ||`- Re: Naming for parsing wordsnone
| |      |  |`- Re: Naming for parsing wordsS Jack
| |      |  `- Re: Naming for parsing wordsStephen Pelc
| |      `- Re: Naming for parsing wordsS Jack
| +* Re: Naming for parsing wordsnone
| |`- Re: Naming for parsing wordsRuvim
| `* Re: Naming for parsing wordsHans Bezemer
|  `* Re: Naming for parsing wordsnone
|   +- Re: Naming for parsing wordsAnton Ertl
|   `* Re: Naming for parsing wordsHans Bezemer
|    `* IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|     `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|      `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|       `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|        `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|         `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|          `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|           `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|            `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             +* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             |`* Re: IS vs. DEFER! (was: Naming for parsing words)Marcel Hendrix
|             | `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             |  `- memory dependencies (was: IS vs. DEFER! (was: Naming for parsing words))Anton Ertl
|             +* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|             |+* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             ||`- Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|             |`* Re: IS vs. DEFER! (was: Naming for parsing words)Hans Bezemer
|             | `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|             `* Re: IS vs. DEFER! (was: Naming for parsing words)P Falth
+* Re: Naming for parsing wordsnone
+* Re: Naming for parsing wordsdxforth
+- Re: Naming for parsing wordsS Jack
`- Re: Naming for parsing wordsRuvim

Pages:12345
Re: IS vs. DEFER! (was: Naming for parsing words)

<t6esq5$4eq$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17969&group=comp.lang.forth#17969

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Mon, 23 May 2022 12:50:45 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6esq5$4eq$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="4570"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Mon, 23 May 2022 02:50 UTC

On 22/05/2022 17:16, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 21/05/2022 20:26, Anton Ertl wrote:
>>> ...
>>> Concerning VALUEs, GForth does not allow ADDR for them, so you have to
>>> use IS to change them. And that's good, because it means that @ and !
>>> don't access the value.
>>
>>So assembler routines can't access VALUEs ?
>
> If they know where to find them, they can. The value might be in a
> register, however; it also might be in a register in some parts of the
> code, and in memory in other parts.

The choice whether a VALUE or a VARIABLE is used should have nothing to do
with whether one is using high-level or assembler. In making the former
harder to use, one is saying VALUEs for forth and VARIABLEs for assembler.

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May23.074038@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17970&group=comp.lang.forth#17970

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Mon, 23 May 2022 05:40:38 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 22
Message-ID: <2022May23.074038@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com> <nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="91a43f25bdbd950c7ec1ec8001f40ef0";
logging-data="12020"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+uWm4LtFOs3PDzvNYyceY4"
Cancel-Lock: sha1:fG1qXp+A9EIL10tQU0sXUH1ELss=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 23 May 2022 05:40 UTC

dxforth <dxforth@gmail.com> writes:
>On 22/05/2022 17:16, Anton Ertl wrote:
>>>So assembler routines can't access VALUEs ?
>>
>> If they know where to find them, they can. The value might be in a
>> register, however; it also might be in a register in some parts of the
>> code, and in memory in other parts.
>
>The choice whether a VALUE or a VARIABLE is used should have nothing to do
>with whether one is using high-level or assembler.

If you feel this way, you as a system designer can devise the
interface between Forth and assembly language accordingly; or as a
user of a third-party Forth system, you can choose a Forth system that
satisfies your requirement.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6fjuf$1u1s$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17973&group=comp.lang.forth#17973

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Mon, 23 May 2022 19:25:34 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6fjuf$1u1s$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="63548"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Mon, 23 May 2022 09:25 UTC

On 23/05/2022 15:40, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 22/05/2022 17:16, Anton Ertl wrote:
>>>>So assembler routines can't access VALUEs ?
>>>
>>> If they know where to find them, they can. The value might be in a
>>> register, however; it also might be in a register in some parts of the
>>> code, and in memory in other parts.
>>
>>The choice whether a VALUE or a VARIABLE is used should have nothing to do
>>with whether one is using high-level or assembler.
>
> If you feel this way, you as a system designer can devise the
> interface between Forth and assembly language accordingly; or as a
> user of a third-party Forth system, you can choose a Forth system that
> satisfies your requirement.

Gforth seems to be the 'odd man out' here. A user may well ask why has
it made access to VALUEs so difficult.

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May23.132321@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17978&group=comp.lang.forth#17978

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Mon, 23 May 2022 11:23:21 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 29
Message-ID: <2022May23.132321@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com> <nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="91a43f25bdbd950c7ec1ec8001f40ef0";
logging-data="10151"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19S/y+y7OuaFwosQlGRMc3S"
Cancel-Lock: sha1:XkLZcKF/AWaamz/lslnSdETatpI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 23 May 2022 11:23 UTC

dxforth <dxforth@gmail.com> writes:
>Gforth seems to be the 'odd man out' here. A user may well ask why has
>it made access to VALUEs so difficult.

Difficult? Let's phrase the question in a less loaded way:

Q: Why does Gforth not support ADDR on value-flavoured words?

A: E.g., because without ADDR a future version of Gforth can keep the
value V in a register in the loop

?do ... v ... @ ... to v ... loop

wheras with ADDR V that's not generally possible, and those cases that
are possible require a lot of compiler complexity.

Q: But I want to port code that uses ADDR V to Gforth?

A: Either define V as a VARUE (like a VALUE, but supports ADDR), or
just prepend the code with

: VALUE VARUE ;

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6hbmd$55d$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17983&group=comp.lang.forth#17983

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Tue, 24 May 2022 11:16:59 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6hbmd$55d$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me> <t62vui$1mi$1@dont-email.me>
<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="5293"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Tue, 24 May 2022 01:16 UTC

On 23/05/2022 21:23, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>Gforth seems to be the 'odd man out' here. A user may well ask why has
>>it made access to VALUEs so difficult.
>
> Difficult? Let's phrase the question in a less loaded way:
>
> Q: Why does Gforth not support ADDR on value-flavoured words?
>
> A: E.g., because without ADDR a future version of Gforth can keep the
> value V in a register in the loop
>
> ?do ... v ... @ ... to v ... loop
>
> wheras with ADDR V that's not generally possible, and those cases that
> are possible require a lot of compiler complexity.

Keeping things in registers usually refers to constants or locals.
My understanding of VALUEs is that they're read far more often than
written and, as such, your use above would appear to be something of
an anomaly. FWIW I don't expect ADDR to be used much either - which
isn't to say I can do without it. I definitely want to be able to
access VALUEs via assembler. To me that's more important than
'keeping it in a register'.

>
> Q: But I want to port code that uses ADDR V to Gforth?
>
> A: Either define V as a VARUE (like a VALUE, but supports ADDR), or
> just prepend the code with
>
> : VALUE VARUE ;

I have a hard enough time justifying VALUEs and VARIABLEs.

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May24.124822@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17984&group=comp.lang.forth#17984

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Tue, 24 May 2022 10:48:22 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 62
Message-ID: <2022May24.124822@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com> <nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="16593"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cLPGhg2T7z+bcvOvfBPlz"
Cancel-Lock: sha1:pa+HGEdy1bQk6i52fNvscwhnHH8=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 10:48 UTC

dxforth <dxforth@gmail.com> writes:
>On 23/05/2022 21:23, Anton Ertl wrote:
>> Q: Why does Gforth not support ADDR on value-flavoured words?
>>
>> A: E.g., because without ADDR a future version of Gforth can keep the
>> value V in a register in the loop
>>
>> ?do ... v ... @ ... to v ... loop
>>
>> wheras with ADDR V that's not generally possible, and those cases that
>> are possible require a lot of compiler complexity.
>
>Keeping things in registers usually refers to constants or locals.

Sure, if you support ADDR, you cannot keep values in registers in many
situations (and the remaining situations are probably so few that you
just keep them in memory all the time).

But there are also those who advocate not using locals, and to use
variables or values instead. Aren't you one of them? Anyway, for
those usages, among others, it would be beneficial to keep values in
registers.

>My understanding of VALUEs is that they're read far more often than
>written and, as such, your use above would appear to be something of
>an anomaly.

Possibly. When a value is both read and written in a loop, allocating
it in a register is particularly beneficial. Here's an example:

: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;

[/tmp:130361] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo1 bye"
[/tmp:130362] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo2 bye"

On a Skylake this produces:

cycles instructions
1012951207 4010090522 foo1
5060982449 6010156213 foo2

So allocating x in a register (what lxf does for stack items) is 5
times faster than allocating it in memory (what lxf does for values).

>FWIW I don't expect ADDR to be used much either

Exactly. But the possible future use of ADDR on a value means that it
always has to be kept in memory. So if you support ADDR on a value,
you have to pay for it even if you don't use it (on that value, or at
all).

And that's why Gforth does not support ADDR on values. If you want to
use ADDR on a word, you can define this particular word with VARUE.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May24.181134@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17985&group=comp.lang.forth#17985

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Tue, 24 May 2022 16:11:34 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 134
Message-ID: <2022May24.181134@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="30661"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zV6afaz2FXpi7rGm8uhMR"
Cancel-Lock: sha1:hdE/RJNAUeFIuJ6go4Snj987KrI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 16:11 UTC

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>When a value is both read and written in a loop, allocating
>it in a register is particularly beneficial. Here's an example:
>
>: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
>0 value x
>: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
>
>[/tmp:130361] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo1 bye"
>[/tmp:130362] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo2 bye"
>
>On a Skylake this produces:
>
> cycles instructions
> 1012951207 4010090522 foo1
> 5060982449 6010156213 foo2
>
>So allocating x in a register (what lxf does for stack items) is 5
>times faster than allocating it in memory (what lxf does for values).

Sorry for the confusion, I used both lxf and vfxlin 4.72 for this,
with similar results.

And just to show that it's not as bad for read-only or write-only
memory accesses:

: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
0 value y
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
: foo3 to y 0 begin y over u> while 1+ repeat drop ;
: foo4 0 begin 2dup u> while 1+ dup to y repeat 2drop ;

cycles instructions vfxlin 4.72
1012848419 4009410376 foo1 registers
5060035003 6010211435 foo2 read+write
1900018814 4009598660 foo3 read-only
1012666250 5009454583 foo4 write-only

Here are the inner loops:

foo1 foo2 foo3 foo4
CMP EBX, [EBP] CMP EBX, [080A3440] CMP EBX, [080A3444] CMP EBX, [EBP]
JNB 080C0ACC JBE 080C0B7B JNB 080C0BBF JNB 080C0C12
INC EBX MOV EDX, [080A3440] INC EBX INC EBX
JMP 080C0AC0 INC EDX JMP 080C0BB0 MOV [080A3444], EBX
MOV [080A3440], EDX JMP 080C0C00
JMP 080C0B60

Interestingly, foo1 and foo4 read one stack item from memory (likewise
for lxf).

For lxf:

cycles instructions vfxlin 4.72
1002385171 4000942415 foo1 registers
5137955357 7001690803 foo2 read+write
1002416848 5000977891 foo3 read-only
2002758293 5001179157 foo4 write-only

foo1 foo2 foo3 foo4
cmp [ebp], ebx mov eax, [08389CF8] mov eax, [08389CFC] cmp [ebp], ebx
jbe "0804FBFB" cmp ebx, eax cmp eax, ebx jbe "0804FC80"
inc ebx jbe "0804FC3A" jbe "0804FC5C" inc ebx
jmp "0804FBEF" mov eax, [08389CF8] inc ebx mov [08389CFC], ebx
inc eax jmp "0804FC4C" jmp "0804FC6E"
mov [08389CF8], eax
jmp "0804FC20"

Interestingly, on lxf FOO3 is faster and FOO4 slower than on vfxlin,
even though FOO4 has the same code as on VFX; maybe a code alignment
issue. Anyway, you can see that the variant with memory read+write is
a lot slower than the other variants.

- anton

(

>
>>FWIW I don't expect ADDR to be used much either
>
>Exactly. But the possible future use of ADDR on a value means that it
>always has to be kept in memory. So if you support ADDR on a value,
>you have to pay for it even if you don't use it (on that value, or at
>all).
>
>And that's why Gforth does not support ADDR on values. If you want to
>use ADDR on a word, you can define this particular word with VARUE.
>
>- 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: http://www.forth200x.org/forth200x.html
> EuroForth 2021: https://euro.theforth.net/2021

--
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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<2eabea8f-b829-4bc2-93e3-0d7cba662accn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17987&group=comp.lang.forth#17987

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:6214:20ec:b0:461:dc16:163d with SMTP id 12-20020a05621420ec00b00461dc16163dmr22956063qvk.40.1653424603270;
Tue, 24 May 2022 13:36:43 -0700 (PDT)
X-Received: by 2002:a05:620a:3184:b0:6a5:8e2e:766d with SMTP id
bi4-20020a05620a318400b006a58e2e766dmr218760qkb.482.1653424603082; Tue, 24
May 2022 13:36:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 24 May 2022 13:36:42 -0700 (PDT)
In-Reply-To: <2022May24.181134@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:1c05:2f14:600:b551:72a3:dd5f:1be6;
posting-account=-JQ2RQoAAAB6B5tcBTSdvOqrD1HpT_Rk
NNTP-Posting-Host: 2001:1c05:2f14:600:b551:72a3:dd5f:1be6
References: <t60i6r$7m0$1@dont-email.me> <nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at>
<t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at>
<t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at>
<t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at>
<t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at> <2022May24.181134@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2eabea8f-b829-4bc2-93e3-0d7cba662accn@googlegroups.com>
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
From: mhx...@iae.nl (Marcel Hendrix)
Injection-Date: Tue, 24 May 2022 20:36:43 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 4588
 by: Marcel Hendrix - Tue, 24 May 2022 20:36 UTC

On Tuesday, May 24, 2022 at 6:53:55 PM UTC+2, Anton Ertl wrote:
[..]
> And just to show that it's not as bad for read-only or write-only
> memory accesses:
> : foo1 0 begin 2dup u> while 1+ repeat 2drop ;
> 0 value x
> 0 value y
> : foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
> : foo3 to y 0 begin y over u> while 1+ repeat drop ;
> : foo4 0 begin 2dup u> while 1+ dup to y repeat 2drop ;
>
> cycles instructions vfxlin 4.72
> 1012848419 4009410376 foo1 registers
> 5060035003 6010211435 foo2 read+write
> 1900018814 4009598660 foo3 read-only
> 1012666250 5009454583 foo4 write-only

Hmm, weird. On iForth it is permutated:

FORTH> #1000000000 TO #times TEST
foo1 0.212 seconds elapsed.
foo2 0.221 seconds elapsed.
foo3 0.213 seconds elapsed.
foo4 0.425 seconds elapsed. ok

FORTH> ' foo1 idis ' foo2 idis ' foo3 idis ' foo4 idis
$0133D880 : foo1
$0133D88A xor rbx, rbx
$0133D88D mov rax, rax
$0133D890 pop rdi
$0133D891 cmp rbx, rdi
$0133D894 push rdi
$0133D895 jae $0133D8A3 offset NEAR
$0133D89B lea rbx, [rbx 1 +] qword
$0133D89F jmp $0133D890 offset SHORT
$0133D8A1 push rbx
$0133D8A2 pop rbx
$0133D8A3 pop rdi
$0133D8A4 ;
$01340940 : foo2
$0134094A mov $01340500 qword-offset, 0 d#
$01340955 pop rbx
$01340956 nop
$01340957 nop
$01340958 mov rax, $01340500 qword-offset
$0134095F cmp rax, rbx
$01340962 jae $0134097E offset NEAR
$01340968 mov rax, $01340500 qword-offset
$0134096F lea rcx, [rax 1 +] qword
$01340973 mov $01340500 qword-offset, rcx
$0134097A jmp $01340958 offset SHORT
$0134097C push rbx
$0134097D pop rbx
$0134097E ;
$01340A00 : foo3
$01340A0A pop rbx
$01340A0B mov $01340520 qword-offset, rbx
$01340A12 xor rbx, rbx
$01340A15 mov rax, rax
$01340A18 mov rax, $01340520 qword-offset
$01340A1F cmp rbx, rax
$01340A22 jae $01340A30 offset NEAR
$01340A28 lea rbx, [rbx 1 +] qword
$01340A2C jmp $01340A18 offset SHORT
$01340A2E push rbx
$01340A2F pop rbx
$01340A30 ;
$01340A80 : foo4
$01340A8A xor rbx, rbx
$01340A8D mov rax, rax
$01340A90 pop rdi
$01340A91 cmp rbx, rdi
$01340A94 push rdi
$01340A95 jae $01340AAE offset NEAR
$01340A9B lea rcx, [rbx 1 +] qword
$01340A9F mov $01340520 qword-offset, rcx
$01340AA6 lea rbx, [rbx 1 +] qword
$01340AAA jmp $01340A90 offset SHORT
$01340AAC push rbx
$01340AAD pop rbx
$01340AAE pop rdi
$01340AAF ;

The stack variable ( rdi ) is causing the slowdown.

-marcel

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6jv1t$1hhd$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17988&group=comp.lang.forth#17988

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Wed, 25 May 2022 10:59:40 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6jv1t$1hhd$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="50733"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Wed, 25 May 2022 00:59 UTC

On 24/05/2022 20:48, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> ...
>>Keeping things in registers usually refers to constants or locals.
>
> Sure, if you support ADDR, you cannot keep values in registers in many
> situations (and the remaining situations are probably so few that you
> just keep them in memory all the time).
>
> But there are also those who advocate not using locals, and to use
> variables or values instead. Aren't you one of them? Anyway, for
> those usages, among others, it would be beneficial to keep values in
> registers.
>
>>My understanding of VALUEs is that they're read far more often than
>>written and, as such, your use above would appear to be something of
>>an anomaly.
>
> Possibly. When a value is both read and written in a loop, allocating
> it in a register is particularly beneficial. Here's an example:
>
> : foo1 0 begin 2dup u> while 1+ repeat 2drop ;
> 0 value x
> : foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;

That's where I would use a VARIABLE - which optimizing compilers can
can keep in a register if they wish. The example code I previously
posted has one VALUE referenced once and two VARIABLEs each referenced
twice. If I were going to prioritize anything for register use, it
would be VARIABLEs as they're used more often.

VALUEs in forth were conceived as self-fetching VARIABLEs. Which was
fine until one had to write to them. They're in CORE-EXT because they
didn't replace anything nor add anything. Syntactic sugar with pros
and cons is how I view them. I'll use them - but not when VARIABLEs
are the better choice.

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May25.064418@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17990&group=comp.lang.forth#17990

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Wed, 25 May 2022 04:44:18 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 53
Message-ID: <2022May25.064418@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at> <2022May24.181134@mips.complang.tuwien.ac.at> <2eabea8f-b829-4bc2-93e3-0d7cba662accn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="f80a06ed755d02b2287695ac37136878";
logging-data="19307"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19UWqRa59WaMqEqbiyFDJuU"
Cancel-Lock: sha1:RuVewWcuFT6poifSedv2E7JvEJU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 25 May 2022 04:44 UTC

Marcel Hendrix <mhx@iae.nl> writes:
>On Tuesday, May 24, 2022 at 6:53:55 PM UTC+2, Anton Ertl wrote:
>[..]
>> And just to show that it's not as bad for read-only or write-only
>> memory accesses:
>> : foo1 0 begin 2dup u> while 1+ repeat 2drop ;
>> 0 value x
>> 0 value y
>> : foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
>> : foo3 to y 0 begin y over u> while 1+ repeat drop ;
>> : foo4 0 begin 2dup u> while 1+ dup to y repeat 2drop ;
>>
>> cycles instructions vfxlin 4.72
>> 1012848419 4009410376 foo1 registers
>> 5060035003 6010211435 foo2 read+write
>> 1900018814 4009598660 foo3 read-only
>> 1012666250 5009454583 foo4 write-only
>
>Hmm, weird. On iForth it is permutated:
>
>FORTH> #1000000000 TO #times TEST
>foo1 0.212 seconds elapsed.
>foo2 0.221 seconds elapsed.
>foo3 0.213 seconds elapsed.
>foo4 0.425 seconds elapsed. ok

So that's ~1/1/1/2 cycles per iteration if your CPU runs slightly
below 5GHz. My guess is that's because you are running it on a Zen3
CPU, where the hardware has special optimizations for avoiding the
memory dependence latency we see on the Skylake.

Here's the cycles/iteration that I see on more recent CPUs than the
Skylake (using lxf):

foo1 foo2 foo3 foo4
1 8 1 1 Zen2 (Ryzen 3900X)
1 1 1 1 Zen3 (Ryzen 5800X)
1 1.8 1 1 Rocket Lake (Xeon W1370P)

So Rocket Lake obviously optimizes this case, too, but apparently
there is some residue.

At some point, CPUs will optimize so well that Python will run as fast
as well-written assembly language. Of course, by then software
developers will have switched to a language that's 100 times slower
even on that hardware:-).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May25.070559@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17991&group=comp.lang.forth#17991

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Wed, 25 May 2022 05:05:59 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 58
Message-ID: <2022May25.070559@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="f80a06ed755d02b2287695ac37136878";
logging-data="31299"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19zyYt61Icp3kGrq0I4TNV6"
Cancel-Lock: sha1:eSeflXLYyNzcEGFosg9CNn75wOY=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 25 May 2022 05:05 UTC

dxforth <dxforth@gmail.com> writes:
>On 24/05/2022 20:48, Anton Ertl wrote:
>> : foo1 0 begin 2dup u> while 1+ repeat 2drop ;
>> 0 value x
>> : foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
>
>That's where I would use a VARIABLE

I certainly used to think that variables are the Forth way, and that
one should use values only for almost-constants that are not changed
in compiled code. But values (without ADDR) have a nice property, as
discussed in this thread.

>which optimizing compilers can
>can keep in a register if they wish.

Forget it. This optimization is as hard for variables as for varues.
It is easy for values. A Forth meme is that you should not burden the
compiler with jobs that the programmer can perform. And as it
happens, values make the compiler's job easier than varues or
variables, so if you want this optimization, use values!

Another way to satisfy the meme is to fetch the variable at the start,
keep it in, e.g., a local in the word, and store it back im the end.
E.g.,

variable xx
: foo2a 0 {: x :} begin dup x u> while x 1+ to x repeat drop x xx ! ;
\ or
: foo2b 0 begin {: x :} dup x u> while x 1+ repeat xx ! drop ;

>The example code I previously
>posted has one VALUE referenced once and two VARIABLEs each referenced
>twice. If I were going to prioritize anything for register use, it
>would be VARIABLEs as they're used more often.

And then you find that you have to prove that nothing else stores to
or fetches from the address between the accesses to the variable.
Hundreds of papers have been written about this problem (alias
analysis); it takes a lot of work (both compiler writer time and
compile time) to perform alias analysis, and it still only partially
solves the problem. As mentioned above, IMO that's not the Forth way.

We already have some Forth ways:

1) Use values.

2) Keep the value of the variable explicitly in locals, the return
stack, or the data stack in the code fragment where you want to give
the compiler the opportunity to keep it in a register.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6kl3a$902$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17994&group=comp.lang.forth#17994

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Wed, 25 May 2022 17:15:54 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6kl3a$902$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
<2022May25.070559@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="9218"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Wed, 25 May 2022 07:15 UTC

On 25/05/2022 15:05, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 24/05/2022 20:48, Anton Ertl wrote:
>>> : foo1 0 begin 2dup u> while 1+ repeat 2drop ;
>>> 0 value x
>>> : foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
>>
>>That's where I would use a VARIABLE
>
> I certainly used to think that variables are the Forth way, and that
> one should use values only for almost-constants that are not changed
> in compiled code.

Does that make a VARUE an 'almost-variable' :) How many languages
do you know have "almost constants"? Sorry, a VALUE is a variable.

> But values (without ADDR) have a nice property, as
> discussed in this thread.

Good luck in the real world.

>
>>which optimizing compilers can
>>can keep in a register if they wish.
>
> Forget it. This optimization is as hard for variables as for varues.
> It is easy for values. A Forth meme is that you should not burden the
> compiler with jobs that the programmer can perform. And as it
> happens, values make the compiler's job easier than varues or
> variables, so if you want this optimization, use values!

A better meme is don't break common practice - especially when one
is promoting portability between systems, standards and the like.

Re: Simplicity and the text interpreter

<94e6e5cf-b2d3-4894-a9e1-bf0b0f057f5en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18002&group=comp.lang.forth#18002

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:2886:b0:699:bab7:ae78 with SMTP id j6-20020a05620a288600b00699bab7ae78mr20712852qkp.618.1653491066857;
Wed, 25 May 2022 08:04:26 -0700 (PDT)
X-Received: by 2002:ac8:5f12:0:b0:2f9:3af4:c6b4 with SMTP id
x18-20020ac85f12000000b002f93af4c6b4mr10037951qta.150.1653491066667; Wed, 25
May 2022 08:04:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 25 May 2022 08:04:26 -0700 (PDT)
In-Reply-To: <871qwlwc6o.fsf@nightsong.com>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at>
<fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com> <2022May20.165835@mips.complang.tuwien.ac.at>
<42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com> <2022May21.194316@mips.complang.tuwien.ac.at>
<0c04229d-21f0-47ac-af3a-393388c4e767n@googlegroups.com> <2022May22.101658@mips.complang.tuwien.ac.at>
<871qwlwc6o.fsf@nightsong.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <94e6e5cf-b2d3-4894-a9e1-bf0b0f057f5en@googlegroups.com>
Subject: Re: Simplicity and the text interpreter
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Wed, 25 May 2022 15:04:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6574
 by: Hans Bezemer - Wed, 25 May 2022 15:04 UTC

On Sunday, May 22, 2022 at 10:21:37 PM UTC+2, Paul Rubin wrote:
The advantage of being Dutch is that lots more of his work is available to you.
Dijkstra didn't believe the myth that "the language will save you" - that's a
recurring theme in his work:

"For example, to the desperate manager, it is a startlingly comforting thought
that the programming language in use is the source of all his misery. The wretch
clings to the dream of the programming language, in which programming is so
easy that everything will work itself out. The new programming languages ​​as
panacea are sold in the quack stall like fresh bread from the baker. Notorious in
this regard is the IBM ad in Datamation, 1968, in which a radiant Susie Meyer
—in colors!— declares that the conversion to PL/I was the end of all her programming
troubles. Unfortunately, history does not record what poor Susie Meyer looked like a
few years later, but one can guess, because the miracle cure did not work, of course.
Anyone who reads the propaganda literature for Ada—the programming language
promoted by the US Department of Defense—must see that the world has changed
little in 14 years".

And:

"Once the feeling among mathematicians that computers are not worth bothering
with, then it acts as a so-called "self-fulfilling prophecy": if the intellectually best
equipped ignore the subject, the territory is occupied by second- and third-rate
people and after a while it is even more difficult for the really clever boy to
imagine that there is a task in front of him (..) By discussing the essentially
mathematical nature of the entire usability problem with a large-scale campaign,
programming as something that anyone can learn in a three-week course, in short,
by declaring so obstinately that the gold of the promised mountains is massive that
enough people believe it. In the years that followed, the profession of programmer
was recruited completely uncritically. Here in this country MULO (Highschool)
was more than enough, but in other countries it was no better. The result can be
imagined: of the half-million professional programmers the world now counts,
the majority is one of incompetence that defies description. But here's an
explanation for the tough life of the software crisis: an incompetent half-million
labor army isn't replaced overnight".

Hans Bezemer

Original:

Voor de wanhopige manager is het bijvoorbeeld een ontstellend geruststellende gedachte,
dat de gebezigde programmeertaal de bron van al zijn ellende is. De stakker klampt zich
vast aan de droom van de programmeertaal, waarin programmeren zo makkelijk is, dat het
allemaal vanzelf goedkomt. De nieuwe programmeertalen als panacee gaan in de
kwakzalverskraam over de toonbank als verse broodjes bij de bakker. In dit verband berucht
is de IBM-advertentie in Datamation, 1968, waarin een stralende Susie Meyer —in kleuren!—
verklaart, dat de bekering tot PL/I het einde van al haar programmeerproblemen was. Hoe de
arme Susie Meyer er een paar jaar later uitzag, vermeldt de historie helaas niet, maar het laat
zich raden, want het wondermiddel heeft natuurlijk niet gewerkt. Wie de propagandaliteratuur
voor Ada —de programmeertaal, die door het Amerikaanse ministerie van defensie wordt
gepousseerd— leest, moet constateren, dat de wereld in 14 jaar weinig is veranderd.

Overheerst bij wiskundigen eenmaal het gevoel dat computers niet de moeite waard
zijn om je mee bezig te houden, dan werkt dat vervolgens als een z.g.
"self-fulfilling prophecy": als de intellectueel het best geequipeerden het vak links laten
liggen, wordt het gebied bezet door tweede- en derderangs mensen en na enige tijd kan
de echt knappe jongen zich nog moeilijker voorstellen dat daar een taak voor hem ligt (..)
Door met een groots opgezette campagne het wezenlijk wiskundige karakter van de hele
gebruiksproblematiek onder tafel te praten, programmeren voor te stellen als iets dat
iedereen in een drieweekse cursus kan leren, kortom door zo hardnekking te verklaren
dat het goud der beloofde bergen massief is, dat genoeg mensen het geloven. In de jaren
die daar op volgden is er voor het vak van programmeur volledig kritiekloos geronseld.
Hier in den lande was MULO ruimschoots genoeg, maar in andere landen was het geen
haar beter. Het resultaat laat zich denken: van de half-millioen professionele programmeurs,
die de wereld inmiddels telt is het merendeel van een incompetentie die elke beschrijving tart.
Maar hier ligt wel een verklaring van het taaie leven van de software crisis: een incompetent
arbeidsleger van een half millioen ververs je niet een-twee-drie.

memory dependencies (was: IS vs. DEFER! (was: Naming for parsing words))

<2022May25.150906@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18004&group=comp.lang.forth#18004

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: memory dependencies (was: IS vs. DEFER! (was: Naming for parsing words))
Date: Wed, 25 May 2022 13:09:06 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 53
Message-ID: <2022May25.150906@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at> <2022May24.181134@mips.complang.tuwien.ac.at> <2eabea8f-b829-4bc2-93e3-0d7cba662accn@googlegroups.com> <2022May25.064418@mips.complang.tuwien.ac.at>
Injection-Info: reader02.eternal-september.org; posting-host="f80a06ed755d02b2287695ac37136878";
logging-data="6352"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Pk2A6cmMRUCquK9b1v5E9"
Cancel-Lock: sha1:MhWIoVqaAiPjjS1hsAbUajMUv3U=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 25 May 2022 13:09 UTC

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>My guess is that's because you are running it on a Zen3
>CPU, where the hardware has special optimizations for avoiding the
>memory dependence latency we see on the Skylake.
>
>Here's the cycles/iteration that I see on more recent CPUs than the
>Skylake (using lxf):
>
>foo1 foo2 foo3 foo4
>1 8 1 1 Zen2 (Ryzen 3900X)
>1 1 1 1 Zen3 (Ryzen 5800X)
>1 1.8 1 1 Rocket Lake (Xeon W1370P)
>
>So Rocket Lake obviously optimizes this case, too, but apparently
>there is some residue.

Of course, the question is how well this works in other cases. A
major difference between gforth and gforth-fast is that gforth keeps
the TOS in memory and gforth-fast keeps it in a register. And if we
disable the additional optimizations of gforth-fast with
"--ss-number=0 --ss-states=0", that's even more so. In particular, a
lot of the performance difference on CPUs without this optimization is
due to this difference. So on CPUs with this optimization the
performance difference should be much smaller. Let's see whether that
works out. I do

for i in gforth-fast gforth; do LC_NUMERIC=en_US perf stat -e cycles -e instructions -e branches $i --ss-number=0 --ss-states=0 ../gforth/onebench.fs; done

on six different CPUs; the numbers are cycles, except for the first
line.

gforth-fast gforth
3,460,908,004 4,737,564,166 instructions (all)
2,269,234,025 4,104,828,209 Goldmont (2016 efficiency)
1,714,076,717 3,495,857,543 Sandy Bridge (2011)
1,584,890,277 3,419,614,950 Zen (2017)
1,342,756,453 2,706,876,924 Zen2 (2019)
1,110,655,337 2,424,136,035 Zen3 (2020)
1,189,653,919 2,106,179,585 Rocket Lake (2021)

So, gforth-fast --ss-number=0 --ss-states=0 gets roughly a factor of 2
throughout the bank. The memory dependence optimization does not
appear to benefit gforth more than gforth-fast. It's unclear to me
whether that is because it is not that effective for gforth, or there
are also important memory dependencies in gforth-fast for which it
helps (but I don't know of the latter).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18006&group=comp.lang.forth#18006

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:1a29:b0:2f9:32e4:52e with SMTP id f41-20020a05622a1a2900b002f932e4052emr15217212qtb.689.1653510218543;
Wed, 25 May 2022 13:23:38 -0700 (PDT)
X-Received: by 2002:a05:620a:3184:b0:6a5:8e2e:766d with SMTP id
bi4-20020a05620a318400b006a58e2e766dmr3903347qkb.482.1653510218374; Wed, 25
May 2022 13:23:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 25 May 2022 13:23:38 -0700 (PDT)
In-Reply-To: <t6jv1t$1hhd$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Wed, 25 May 2022 20:23:38 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3008
 by: Hans Bezemer - Wed, 25 May 2022 20:23 UTC

On Wednesday, May 25, 2022 at 2:59:47 AM UTC+2, dxforth wrote:
> That's where I would use a VARIABLE - which optimizing compilers can
> can keep in a register if they wish. The example code I previously
> posted has one VALUE referenced once and two VARIABLEs each referenced
> twice. If I were going to prioritize anything for register use, it
> would be VARIABLEs as they're used more often.
>
> VALUEs in forth were conceived as self-fetching VARIABLEs. Which was
> fine until one had to write to them. They're in CORE-EXT because they
> didn't replace anything nor add anything. Syntactic sugar with pros
> and cons is how I view them. I'll use them - but not when VARIABLEs
> are the better choice.

As far as 4tH is concerned - I started out like you. Sure, it's in the extended
core and people tend to use them in programs, so it's handy if you add them
to the vocabulary. But its use largely overlaps VARIABLE. Not supporting
LOCALS helps too ;-)

Nowadays the difference (in 4tH) has blurred even further, since the optimizer
changes VARIABLEs to VALUEs when the address of the variable is known
at compile time. +TO changes VALUEs to VARIABLEs so it won't take up another
token and +! can simply be used.

And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
like VARIABLE in Forth-79.

HB

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6n36g$1fge$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18008&group=comp.lang.forth#18008

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Thu, 26 May 2022 15:28:48 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6n36g$1fge$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="48654"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Thu, 26 May 2022 05:28 UTC

On 26/05/2022 06:23, Hans Bezemer wrote:
> ...
> And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
> like VARIABLE in Forth-79.

Given VALUEs will change (else one would use CONSTANT) it might have been
better to omit the initial value. Or would that have made VALUEs too much
like VARIABLEs ? In the app below every VALUE was defined with a dummy.

\ Program constants
0 value #TERMS \ number of terminals in DTA file
0 value TERM \ working terminal#
$95 constant TLEN \ length of each term definition
$100 constant CHUNK \ in-file chunk to get
20 constant ISIZ \ size input buffer / terminal name
200 constant TMAX \ max #terminals

\ Storage areas allocated at run-time
here value IN-BASE ( -- a ) \ in-file
here value DTA-BASE ( -- a ) \ dta-file
here value TBUF ( -- a ) \ temp terminal buffer
here value SBUF ( -- a ) \ swap/work buffer
here value IBUF ( -- a ) \ console input
here value XBUF ( -- a ) \ terminal index

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May26.081224@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18009&group=comp.lang.forth#18009

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Thu, 26 May 2022 06:12:24 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 61
Message-ID: <2022May26.081224@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org> <049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com> <t6n36g$1fge$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="aa851ce9bdb8ec799e3855bf657f3d3d";
logging-data="16168"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX193+M8aFQRyjleLJdZ81QDZ"
Cancel-Lock: sha1:CaHOWF3sQ/EPUGrCSpIU/gvMCZo=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 26 May 2022 06:12 UTC

dxforth <dxforth@gmail.com> writes:
>On 26/05/2022 06:23, Hans Bezemer wrote:
>> ...
>> And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
>> like VARIABLE in Forth-79.

From Forth-79:
|VARIABLE 227
| A defining word executed in the form:
| VARIABLE <name>
| to create a dictionary entry for <name> and allot two bytes
| for storage in the parameter field. The application must
| initialize the stored value.

In fig-Forth VARIABLE took the initial value from the stack. I miss
it every time I use VARIABLE.

>Given VALUEs will change (else one would use CONSTANT) it might have been
>better to omit the initial value.

No. You need to initialize a variable (or value) before reading its
value. So the way to ensure this is to initialize it right after
definition:

variable where-index -1 where-index !

This is much more cumbersome than fig-Forth's

-1 variable where-index

At least they got it right for VALUE.

>In the app below every VALUE was defined with a dummy.

A defined dummy helps avoid Heisenbugs, and can help find bugs.

>\ Program constants
>0 value #TERMS \ number of terminals in DTA file

You have more than 0 terminals at the start?

>\ Storage areas allocated at run-time
>here value IN-BASE ( -- a ) \ in-file
>here value DTA-BASE ( -- a ) \ dta-file
>here value TBUF ( -- a ) \ temp terminal buffer
>here value SBUF ( -- a ) \ swap/work buffer
>here value IBUF ( -- a ) \ console input
>here value XBUF ( -- a ) \ terminal index

I work on systems where accessing memory near 0 produces an exception,
so initializing addresses as 0 helps find bugs quickly where the
allocation has not happened before the first read. Without
initialization, the bug might go unnoticed for longer, making it
harder to find.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6nf29$5cp$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18011&group=comp.lang.forth#18011

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Thu, 26 May 2022 18:51:21 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6nf29$5cp$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
<t6n36g$1fge$1@gioia.aioe.org> <2022May26.081224@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="5529"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Thu, 26 May 2022 08:51 UTC

On 26/05/2022 16:12, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 26/05/2022 06:23, Hans Bezemer wrote:
>>> ...
>>> And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
>>> like VARIABLE in Forth-79.
>
> From Forth-79:
> |VARIABLE 227
> | A defining word executed in the form:
> | VARIABLE <name>
> | to create a dictionary entry for <name> and allot two bytes
> | for storage in the parameter field. The application must
> | initialize the stored value.
>
> In fig-Forth VARIABLE took the initial value from the stack. I miss
> it every time I use VARIABLE.
>
>>Given VALUEs will change (else one would use CONSTANT) it might have been
>>better to omit the initial value.
>
> No. You need to initialize a variable (or value) before reading its
> value. So the way to ensure this is to initialize it right after
> definition:

I do that in a function (e.g. INIT ) so that when a program is re-run
VALUEs and anything else that requires predictable initial values will
be correctly set. Defining x VALUE FOO is misleading as it suggests
FOO will be x whenever the program is run. It's such assumptions that
lead to your Heisenbugs.

>
> variable where-index -1 where-index !
>
> This is much more cumbersome than fig-Forth's
>
> -1 variable where-index
>
> At least they got it right for VALUE.
>
>>In the app below every VALUE was defined with a dummy.
>
> A defined dummy helps avoid Heisenbugs, and can help find bugs.

Or not. I recently ported an old program which presumed VARIABLE
initialized to zero. It helped that my VARIABLE initialized to a
random value else I might still be looking for the bug.

>
>>\ Program constants
>>0 value #TERMS \ number of terminals in DTA file
>
> You have more than 0 terminals at the start?
>
>>\ Storage areas allocated at run-time
>>here value IN-BASE ( -- a ) \ in-file
>>here value DTA-BASE ( -- a ) \ dta-file
>>here value TBUF ( -- a ) \ temp terminal buffer
>>here value SBUF ( -- a ) \ swap/work buffer
>>here value IBUF ( -- a ) \ console input
>>here value XBUF ( -- a ) \ terminal index
>
> I work on systems where accessing memory near 0 produces an exception,
> so initializing addresses as 0 helps find bugs quickly where the
> allocation has not happened before the first read. Without
> initialization, the bug might go unnoticed for longer, making it
> harder to find.

My preferred solution was:

: INIT ( -- )
altered off \ clear
isiz reserve to ibuf \ console input
tlen reserve to tbuf \ temp terminal buffer
chunk reserve to sbuf \ swap/work buffer
tmax cells reserve to xbuf \ terminal index
;

( INIT)

\ Main
: INSTALL ( -- )
cls title init
open-target read-dta catalog
menu
close-target
;

Re: IS vs. DEFER!

<87pmk0us17.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18015&group=comp.lang.forth#18015

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER!
Date: Thu, 26 May 2022 10:23:32 -0700
Organization: A noiseless patient Spider
Lines: 7
Message-ID: <87pmk0us17.fsf@nightsong.com>
References: <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at>
<t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at>
<t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at>
<t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at>
<t6jv1t$1hhd$1@gioia.aioe.org>
<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
<t6n36g$1fge$1@gioia.aioe.org>
<2022May26.081224@mips.complang.tuwien.ac.at>
<t6nf29$5cp$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="3a35e3540c7f7f5ae97a7fb46388a898";
logging-data="3107"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19t6xDpzB4qN1iJ+CKk83EC"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:5nNmvhD7rxgNHnL13XeQ2dbPaYM=
sha1:okpdJ/Jc0WHj7+8Xt2Z5yziXICg=
 by: Paul Rubin - Thu, 26 May 2022 17:23 UTC

dxforth <dxforth@gmail.com> writes:
> Defining x VALUE FOO is misleading as it suggests FOO will be x
> whenever the program is run.

It only suggests that FOO is x until it gets updated. FOO should (if
possible) have a legitimate and meaningful value at all times, rather
than a dummy value.

Re: IS vs. DEFER! (was: Naming for parsing words)

<4e9a90c7-c576-4c85-8feb-a1245eb4589an@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18016&group=comp.lang.forth#18016

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:b986:0:b0:6a3:7eb3:b237 with SMTP id j128-20020a37b986000000b006a37eb3b237mr15836194qkf.459.1653598115934;
Thu, 26 May 2022 13:48:35 -0700 (PDT)
X-Received: by 2002:ad4:5d66:0:b0:462:eaa:67f with SMTP id fn6-20020ad45d66000000b004620eaa067fmr27959166qvb.72.1653598115609;
Thu, 26 May 2022 13:48:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Thu, 26 May 2022 13:48:35 -0700 (PDT)
In-Reply-To: <2022May24.124822@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=80.182.235.230; posting-account=ryzhhAoAAAAIqf1uqmG9E4uP1Bagd-k2
NNTP-Posting-Host: 80.182.235.230
References: <t60i6r$7m0$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4e9a90c7-c576-4c85-8feb-a1245eb4589an@googlegroups.com>
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
From: peter.m....@gmail.com (P Falth)
Injection-Date: Thu, 26 May 2022 20:48:35 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: P Falth - Thu, 26 May 2022 20:48 UTC

On Tuesday, 24 May 2022 at 13:50:41 UTC+2, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> >On 23/05/2022 21:23, Anton Ertl wrote:
> >> Q: Why does Gforth not support ADDR on value-flavoured words?
> >>
> >> A: E.g., because without ADDR a future version of Gforth can keep the
> >> value V in a register in the loop
> >>
> >> ?do ... v ... @ ... to v ... loop
> >>
> >> wheras with ADDR V that's not generally possible, and those cases that
> >> are possible require a lot of compiler complexity.
> >
> >Keeping things in registers usually refers to constants or locals.
> Sure, if you support ADDR, you cannot keep values in registers in many
> situations (and the remaining situations are probably so few that you
> just keep them in memory all the time).
>
> But there are also those who advocate not using locals, and to use
> variables or values instead. Aren't you one of them? Anyway, for
> those usages, among others, it would be beneficial to keep values in
> registers.
> >My understanding of VALUEs is that they're read far more often than
> >written and, as such, your use above would appear to be something of
> >an anomaly.
> Possibly. When a value is both read and written in a loop, allocating
> it in a register is particularly beneficial. Here's an example:
>
> : foo1 0 begin 2dup u> while 1+ repeat 2drop ;
> 0 value x
> : foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
>
> [/tmp:130361] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo1 bye"
> [/tmp:130362] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo2 bye"
>
> On a Skylake this produces:
>
> cycles instructions
> 1012951207 4010090522 foo1
> 5060982449 6010156213 foo2
>
> So allocating x in a register (what lxf does for stack items) is 5
> times faster than allocating it in memory (what lxf does for values).
> >FWIW I don't expect ADDR to be used much either
> Exactly. But the possible future use of ADDR on a value means that it
> always has to be kept in memory. So if you support ADDR on a value,
> you have to pay for it even if you don't use it (on that value, or at
> all).
>
> And that's why Gforth does not support ADDR on values. If you want to
> use ADDR on a word, you can define this particular word with VARUE.
> - anton

Anton, this is an interesting and somewhat unexpected development.
Can you share some more information on how you plan to implement it?

I can see some problems in that you can have more values defined then
you have registers available. In lxf I have 5 registers available for the code
generator, the rest are used by the system (stackpointers etc). Even if I only
use 1 register for values it will hurt the code generator. And what VALUE
would I dedicate that register to!

On a CPU with many register like ARM64 I could think of something like

1234 REGISTER-VALUE R1 test

to make test a value stored in register R1. This could be very useful
in some cases.

BR
Peter Fälth

> --
> 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: http://www.forth200x.org/forth200x.html
> EuroForth 2021: https://euro.theforth.net/2021

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6p3un$ae3$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18022&group=comp.lang.forth#18022

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Fri, 27 May 2022 09:53:58 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6p3un$ae3$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
<t6n36g$1fge$1@gioia.aioe.org> <2022May26.081224@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="10691"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Thu, 26 May 2022 23:53 UTC

On 26/05/2022 16:12, Anton Ertl wrote:
>>On 26/05/2022 06:23, Hans Bezemer wrote:
>>> ...
>>> And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
>>> like VARIABLE in Forth-79.
>
> From Forth-79:
> |VARIABLE 227
> | A defining word executed in the form:
> | VARIABLE <name>
> | to create a dictionary entry for <name> and allot two bytes
> | for storage in the parameter field. The application must
> | initialize the stored value.
>
> In fig-Forth VARIABLE took the initial value from the stack. I miss
> it every time I use VARIABLE.

AFAIK the 'n VARIABLE name' syntax originated with Moore. It is present
in Kitt Peak Forth and Forth Inc's microForth (from which fig-Forth likely
got it). It also appears in Forth-77 (which FD called a "standardized
glossary" - also based on Kitt Peak Forth). According to FD, Forth-79
was the first serious attempt at a standard and portability. I'm not
aware of any official explanation as why the initializing value of VARIABLE
was dropped in Forth-79 (it also seems to have disappeared by the time of
polyForth and Starting FORTH). The change didn't bother me. If anything,
I thought they were fixing a loop-hole.

So where did VALUE come from? All I know is TO first appeared in FD V1N4.
According to the author it was based on a suggestion by Moore. The
intention was:

n VARIABLE foo foo @ ( n)

would be replaced by:

VARIABLE foo n TO foo foo ( n)

I don't know who first came up with VALUE or when. The earliest I've
seen it implemented was in F-PC. I suspect however it was in use before
that. Perhaps someone knows?

Re: IS vs. DEFER!

<t6p65v$unj$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18024&group=comp.lang.forth#18024

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER!
Date: Fri, 27 May 2022 10:31:58 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6p65v$unj$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org>
<2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org>
<2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org>
<2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org>
<2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org>
<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
<t6n36g$1fge$1@gioia.aioe.org> <2022May26.081224@mips.complang.tuwien.ac.at>
<t6nf29$5cp$1@gioia.aioe.org> <87pmk0us17.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="31475"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Fri, 27 May 2022 00:31 UTC

On 27/05/2022 03:23, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Defining x VALUE FOO is misleading as it suggests FOO will be x
>> whenever the program is run.
>
> It only suggests that FOO is x until it gets updated. FOO should (if
> possible) have a legitimate and meaningful value at all times, rather
> than a dummy value.

It's not the case for DEFER. I would very much have preferred VALUE
required no initial value then I wouldn't need to include a dummy.

Re: IS vs. DEFER!

<165368307794.26142.6545480734223330781@media.vsta.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18045&group=comp.lang.forth#18045

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: van...@vsta.org (Andy Valencia)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER!
Date: Fri, 27 May 2022 13:24:37 -0700
Lines: 11
Message-ID: <165368307794.26142.6545480734223330781@media.vsta.org>
References: <87pmk0us17.fsf@nightsong.com> <t60i6r$7m0$1@dont-email.me> <t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at> <t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at> <t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at> <t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at> <t6jv1t$1hhd$1@gioia.aioe.org> <049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com> <t6n36g$1fge$1@gioia.aioe.org> <2022May26.081224@mips.complang.tuwien.ac.at> <t6nf29$5cp$1@gioia.aioe.org>
X-Trace: individual.net ntFNs7R0EPu/ZDXNS6ZDwwI6jbe0OkYCcIikcAR4zGB7Kjz2q7
X-Orig-Path: media
Cancel-Lock: sha1:ruFBdWXUnlWufbsbIhX0vG4Vf6Y=
User-Agent: rn.py v0.0.1
 by: Andy Valencia - Fri, 27 May 2022 20:24 UTC

Paul Rubin <no.email@nospam.invalid> writes:
> It only suggests that FOO is x until it gets updated. FOO should (if
> possible) have a legitimate and meaningful value at all times, rather
> than a dummy value.

Indeed, thus almost every language has initializers for things which can
subsequently have their value changed.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Re: IS vs. DEFER!

<t6s68r$1idn$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18049&group=comp.lang.forth#18049

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER!
Date: Sat, 28 May 2022 13:51:54 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6s68r$1idn$1@gioia.aioe.org>
References: <87pmk0us17.fsf@nightsong.com> <t60i6r$7m0$1@dont-email.me>
<t6cm0j$1ar7$1@gioia.aioe.org> <2022May22.091643@mips.complang.tuwien.ac.at>
<t6esq5$4eq$1@gioia.aioe.org> <2022May23.074038@mips.complang.tuwien.ac.at>
<t6fjuf$1u1s$1@gioia.aioe.org> <2022May23.132321@mips.complang.tuwien.ac.at>
<t6hbmd$55d$1@gioia.aioe.org> <2022May24.124822@mips.complang.tuwien.ac.at>
<t6jv1t$1hhd$1@gioia.aioe.org>
<049a1c19-a4e7-4f1a-aeb9-ba03ef67722cn@googlegroups.com>
<t6n36g$1fge$1@gioia.aioe.org> <2022May26.081224@mips.complang.tuwien.ac.at>
<t6nf29$5cp$1@gioia.aioe.org>
<165368307794.26142.6545480734223330781@media.vsta.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="51639"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Sat, 28 May 2022 03:51 UTC

On 28/05/2022 06:24, Andy Valencia wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>> It only suggests that FOO is x until it gets updated. FOO should (if
>> possible) have a legitimate and meaningful value at all times, rather
>> than a dummy value.
>
> Indeed, thus almost every language has initializers for things which can
> subsequently have their value changed.

Yes, but what sense does it make to initialize them at compile-time
when it's execution-time that matters.

Format to quoting a word (was: Naming for parsing words)

<t6t189$k0b$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=18059&group=comp.lang.forth#18059

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Format to quoting a word (was: Naming for parsing words)
Date: Sat, 28 May 2022 15:32:22 +0400
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <t6t189$k0b$1@dont-email.me>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 28 May 2022 11:32:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="36e741d8f6c71c813b359ef21569128c";
logging-data="20491"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+srZvJU/oxEZE1nRN4mCvJ"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:v1bjP1kDFWK4DDsOJcz0eotnbyM=
In-Reply-To: <2022May19.164709@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Ruvim - Sat, 28 May 2022 11:32 UTC

On 2022-05-19 18:47, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> Do you avoid the standard parsing words?
>> For example: "[']" "postpone" 's"' 'abort"'
>
> I avoid these unless there is some reason not to. In particular:
>
> Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
> interpretive code.

To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the
following reasons:
- it is closer to "[']" and "'" (so it's already connotated with
quoting a word in Forth);
- it is also used for quoting in some other languages (e.g., in Lisp,
to quote a list).

Possible disadvantage of this choice are as follows.

- Sometimes Tick is an actual part of a name. But those who use names
starting with a Tick probably will not use recognizers, but parsing words.

- Tick is used for character literals in Gforth. But is was a
suboptimal choice, I think.

[...]
>> To use them as:
>>
>> `foo :def 123 . ;
>>
>
> Why `FOO, not "FOO"?

For better readability.

I use Backtick for a space delimited string [1]. This form tells me that
the string is a name (a name of something, not necessary the name of a
definition). And it's better for readability. Also, this form is far
more concise than S" FOO", that was important before a recognizer for
"FOO" was introduced.

I think we should find some conventions for these forms (and maybe some
other), and give them names. After that, to avoid conflicts, a Forth
source code file (or code block) that relies on a convention, should
start with a declaration that mentions the convention's name.

The format of such a declaration probably should be standardized.

As an example, JavaScript uses "use strict" string literal as the first
item of a code block to declare strict mode.

We could use a list of recognizer names in the declaration. The scope of
this declaration (where this recognizers are in effect) should be
limited in obvious way.

[1] Not only I, see for example:
https://github.com/rufig/spf4-utf8/blob/9eaeb371ee2824082464cc39552390bf74308451/devel/%7Eygrek/lib/xmltag.f#L95

--
Ruvim

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor