Put the following into a file and then load it:
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
I'm stunned at how many forths won't handle it. Caught me by surprise.
Am 25.10.2025 um 13:36 schrieb dxf:
Put the following into a file and then load it:
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
I'm stunned at how many forths won't handle it. Caught me by surprise.
During compilation I get "unexpected end of file" which is correct
On 25/10/2025 11:51 pm, minforth wrote:...
Am 25.10.2025 um 13:36 schrieb dxf:
Put the following into a file and then load it:
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
The implementation ANS-Forth provides in A.15.6.2.2533 leaves a 1 on the stack >albeit undisplayed.
dxf <dxforth@gmail.com> writes:
On 25/10/2025 11:51 pm, minforth wrote:...
Am 25.10.2025 um 13:36 schrieb dxf:
Put the following into a file and then load it:
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
The implementation ANS-Forth provides in A.15.6.2.2533 leaves a 1 on the stack
albeit undisplayed.
Of course there should be a 1 on the stack. There is nothing that
removes it. There is also nothing that displays it, so it's not
surprising that it's not displayed.
When you paste this code in a recent development Gforth, it becomes
pretty obvious what is happening:
1 ok 1
ok 1
0 [IF] scanning for [THEN]
scanning for [THEN]
2 scanning for [THEN]
scanning for [THEN]
0 [IF] scanning for [THEN]
scanning for [THEN]
3 scanning for [THEN]
scanning for [THEN]
[THEN] scanning for [THEN]
scanning for [THEN]
.S scanning for [THEN]
When you put it in a file and include that, you instead get:
include zzz.fs
zzz.fs:3:3: warning: unfinished [IF] at end of file ok 1
The end of the file finishes the [IF] for you in the development
version (it now says "ok", not "scanning for [THEN]", but not in
gforth-0.7.
On 26/10/2025 3:02 am, Anton Ertl wrote:...
dxf <dxforth@gmail.com> writes:
On 25/10/2025 11:51 pm, minforth wrote:...
Am 25.10.2025 um 13:36 schrieb dxf:
Put the following into a file and then load it:
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
Yes. I assumed the second 0 [IF] would be ignored.
What is the correct behaviour for the routine (as given and used in a file)?
Put the following into a file and then load it:
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
I'm stunned at how many forths won't handle it. Caught me by surprise.
1
0 [IF]
2
0 [IF]
3
[THEN]
.S
Using the implementation in the standard there are a few strange
behaviours with [if] e.g putting the above into 1 line for convenience
1 0 [if] 2 0 [if] 3 [then] \ this [then] .s \ ought to be ignored
In all Forths I tried the [then] in the comment is found by the first
[if] control starts interpreting and displays 1 so that the "ought to be >ignored" has to be commented out.
...
Also:
[else] can be used as a
multi-line comment [then]
On 4tH, it doesn't even compile:
$ pp4th -x pptest10.4th
Compiling; Word 29: Incomplete declaration
After adding the [THEN]:
$ pp4th -x pptest10.4th
1 (TOS)
Decompile:
4tH message: Incomplete declaration at word 29
Object size: 29 words
String size: 7 chars
Variables : 0 cells
Strings : 0 chars
Symbols : 1 names
Reliable : No
Addr| Opcode Operand Argument
20| rot 0
21| +literal -1 22| branch 13 23| drop 0
24| ." 0 (TOS)
25| drop 0
26| cr 0
27| exit 0 <<<< end of .S definition
28| literal 1
Message: Incomplete declaration (#23 M4NODECL)
Words: All defining words and compiler directives
Example: 10 CONSTANT CONSTANT NAME
Cause: 4. An [IF] is not balanced by a [THEN].
I forgot all about this thingy!
On 27/10/2025 1:10 am, Gerry Jackson wrote:
...
Also:
[else] can be used as a
multi-line comment [then]
SYNONYM [COMMENT] [ELSE]
On 26/10/2025 23:54, dxf wrote:<SNIP>
On 27/10/2025 1:10 am, Gerry Jackson wrote:
----
Gerry
Surprisingly (to me at least) the existing multi-line comment using parentheses ( and ) can be synonyms of [ELSE].
In article <10e03fr$3qgk5$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:
On 26/10/2025 23:54, dxf wrote:<SNIP>
On 27/10/2025 1:10 am, Gerry Jackson wrote:
Long story short
- never use nested conditional compilation
- use [THEN] not [then] , it is a string and there is no
mention that it is caseinsenstive.
- use conditional compilation for straight code, never mix
it with comment
and certainly don't mix it with invented
comments ( DOC ... ENDDOC , (* *) , \\ , '\* .. *\ )
- never comment out conditional compilation.
- never comment out conditional compilation.
Why? I've shown that it can be done using \, that means that any use of
[IF] etc in the rest of the comment line is not executed
Sorry Anton I read your message and was going to reply and I
accidentally did something that caused Thunderbird to lose your message.
I can't find it and it isn't in the 'deleted' folder. I'd be grateful if
you could repost it please.
From my memory the gist of your message was:
given
my-condition [if]
\ I have something witty to say about [if]
....
[else]
....
[then]
I think you said that if MY-CONDITION is TRUE then the first [if] let's
the Forth interpreter take over and so the second [IF] is ignored
because it's in a comment and all is good
But if MY-CONDITION is FALSE the second [IF] is reached with unknown >consequences.
Or are you saying that the second [if] should be found because that is
what is expected in a standard by the Forth standard
Or have I missed some nuance in your message?
I remember a comment about ." but don't remember anything else
Gerry Jackson <do-not-use@swldwa.uk> writes:
Sorry Anton I read your message and was going to reply and I
accidentally did something that caused Thunderbird to lose your message.
I can't find it and it isn't in the 'deleted' folder. I'd be grateful if
you could repost it please.
It's <2025Oct31.153524@mips.complang.tuwien.ac.at>. You can look it
up on, e.g., <https://al.howardknight.net/>.
From my memory the gist of your message was:
given
my-condition [if]
\ I have something witty to say about [if]
....
[else]
....
[then]
I think you said that if MY-CONDITION is TRUE then the first [if] let's
the Forth interpreter take over and so the second [IF] is ignored
because it's in a comment and all is good
But if MY-CONDITION is FALSE the second [IF] is reached with unknown
consequences.
The consequences are known, but probably unintended: the [ELSE] and
[THEN] are perceived as belonging to the second [IF], so at the end
one is still scanning for the [THEN] or [ELSE] that belongs to the
first [IF].
Or are you saying that the second [if] should be found because that is
what is expected in a standard by the Forth standard
Yes, a system that ignores [IF] in comments would not be
standard-conforming, and not in line with existing practice in
systems.
Given that nobody will write something like the example above (if
their system is standard-conformung), does it matter? Let's see if I
can construct an example that might occur and where it matters:
my-condition [if]
.( a)
[else]
.( b)
\ [else]
.( c)
[then]
.( d)
I tested on gforth 0.7, iforth-5.1 mini, lxf, sf64-4.0.0-rc89, and vfx64-5.43. I put the lines above into /tmp/xxx.fs.
With
true constant my-condition include /tmp/xxx.fs cr bye
all systems except iforth output "acd", as specified by the standard.
iforth outputs "ad", i.e., it has a scanner that treats "\"
especially. For
false constant my-condition include /tmp/xxx.fs cr bye
every system outputs "bcd", as specified by the standard.
Again, I doubt that anybody will use that intentionally in production
code. There might be some opccurences by mistake, where, rather than
fixing the problem (the [ELSE] in text that's not text-interpreted),
some workaround was implemented. Still, these cases should be so rare
that a change should be doable, if it was really wanted.
The bigger problem is that you get the same problem with other parsing
words. Parsing words can be user-defined, and with search order
changes one can make things even harder for an [IF] etc. set of words
that try to be smart about such uses. So where would we stop? Should
we stop right at the beginning before special-casing any parsing word?
Or have I missed some nuance in your message?
I remember a comment about ." but don't remember anything else
I gave an example where ." was used as a parsing word that parses [IF]
and [ELSE]. But nothing fundamentally different from the cases
involving \.
On 30/10/2025 19:46, albert@spenarnc.xs4all.nl wrote:
In article <10e03fr$3qgk5$1@dont-email.me>,Wow, what a lot of advice, some good, some irrelevant. I get the
Gerry Jackson <do-not-use@swldwa.uk> wrote:
On 26/10/2025 23:54, dxf wrote:<SNIP>
On 27/10/2025 1:10 am, Gerry Jackson wrote:
impression that you saw that I was using [ELSE] for multi-line comments
and that I had included the comment code definitions in with the
conditional code definitions (done for convenience). Then you jumped to
the conclusion that I was mixing application executable conditional >compilation with comments without looking at the code in detail.
----
Gerry
On 30/10/2025 19:46, albert@spenarnc.xs4all.nl wrote:
...
- never comment out conditional compilation.
Why? I've shown that it can be done using \, that means that any use of [IF] etc in the rest of the comment line is not executed
On 1/11/2025 12:45 am, Gerry Jackson wrote:
On 30/10/2025 19:46, albert@spenarnc.xs4all.nl wrote:
...
- never comment out conditional compilation.
Why? I've shown that it can be done using \, that means that any use of [IF] etc in the rest of the comment line is not executed
This in fact was my intent during a debug session i.e. the [IF] was moved elsewhere temporarily. I didn't want to delete the original as it was
always going to be restored - hence my adding a preceding \ (which didn't work as I had hoped). I knew what I wanted to do. It's just that the existing tools didn't allow me.
On 1/11/2025 11:37 am, dxf wrote:
On 1/11/2025 12:45 am, Gerry Jackson wrote:
On 30/10/2025 19:46, albert@spenarnc.xs4all.nl wrote:
...
- never comment out conditional compilation.
Why? I've shown that it can be done using \, that means that any use of [IF] etc in the rest of the comment line is not executed
This in fact was my intent during a debug session i.e. the [IF] was moved
elsewhere temporarily. I didn't want to delete the original as it was
always going to be restored - hence my adding a preceding \ (which didn't
work as I had hoped). I knew what I wanted to do. It's just that the
existing tools didn't allow me.
Below is hack that implements it. To what extent it's useful in debugging is >for each to determine. I'm less excited about [ELSE] as a comment tool due >to potential clashes. I have a simple one-liner for that (* *). Again, it's >not something a screen user tends to use.
\ Original
: [ELSE] ( -- )
1 BEGIN
BL WORD COUNT ( 2DUP UPPER) DUP IF
2DUP S" [IF]" COMPARE IF
2DUP S" [ELSE]" COMPARE IF
S" [THEN]" COMPARE 0=
ELSE 2DROP DUP 1 = THEN
ELSE 2DROP 1 THEN +
ELSE 2DROP REFILL AND THEN
?DUP 0=
UNTIL
; IMMEDIATE
: [IF] 0= IF POSTPONE [ELSE] THEN ; IMMEDIATE
: [THEN ; IMMEDIATE
\ Modified to recognize '\' in skipped code
: [ELSE] ( -- )
1 BEGIN BEGIN
BL WORD COUNT ( 2DUP UPPER) DUP IF [ 1 CS-ROLL ]
2DUP S" \" COMPARE 0= WHILE 2DROP POSTPONE \ REPEAT
2DUP S" [IF]" COMPARE IF
2DUP S" [ELSE]" COMPARE IF
S" [THEN]" COMPARE 0=
ELSE 2DROP DUP 1 = THEN
ELSE 2DROP 1 THEN +
ELSE 2DROP REFILL AND THEN
?DUP 0=
UNTIL
; IMMEDIATE
In article <6906a681$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 1/11/2025 11:37 am, dxf wrote:
On 1/11/2025 12:45 am, Gerry Jackson wrote:
On 30/10/2025 19:46, albert@spenarnc.xs4all.nl wrote:
...
- never comment out conditional compilation.
Why? I've shown that it can be done using \, that means that any use of [IF] etc in the rest of the comment line is not executed
This in fact was my intent during a debug session i.e. the [IF] was moved >>> elsewhere temporarily. I didn't want to delete the original as it was
always going to be restored - hence my adding a preceding \ (which didn't >>> work as I had hoped). I knew what I wanted to do. It's just that the
existing tools didn't allow me.
Below is hack that implements it. To what extent it's useful in debugging is
for each to determine. I'm less excited about [ELSE] as a comment tool due >> to potential clashes. I have a simple one-liner for that (* *). Again, it's
not something a screen user tends to use.
\ Original
: [ELSE] ( -- )
1 BEGIN
BL WORD COUNT ( 2DUP UPPER) DUP IF
2DUP S" [IF]" COMPARE IF
2DUP S" [ELSE]" COMPARE IF
S" [THEN]" COMPARE 0=
ELSE 2DROP DUP 1 = THEN
ELSE 2DROP 1 THEN +
ELSE 2DROP REFILL AND THEN
?DUP 0=
UNTIL
; IMMEDIATE
: [IF] 0= IF POSTPONE [ELSE] THEN ; IMMEDIATE
: [THEN ; IMMEDIATE
\ Modified to recognize '\' in skipped code
: [ELSE] ( -- )
1 BEGIN BEGIN
BL WORD COUNT ( 2DUP UPPER) DUP IF [ 1 CS-ROLL ]
2DUP S" \" COMPARE 0= WHILE 2DROP POSTPONE \ REPEAT
2DUP S" [IF]" COMPARE IF
2DUP S" [ELSE]" COMPARE IF
S" [THEN]" COMPARE 0=
ELSE 2DROP DUP 1 = THEN
ELSE 2DROP 1 THEN +
ELSE 2DROP REFILL AND THEN
?DUP 0=
UNTIL
; IMMEDIATE
So you use conditional compilation to be able to run your soduku
solver on e.g. gforth.
Now you impose conditions how conditional compilation is supposed to
work on gforth, totally defeating the purpose of using conditional compilation to enhance portability.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,075 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 106:59:11 |
| Calls: | 13,798 |
| Files: | 186,990 |
| D/L today: |
1,954 files (535M bytes) |
| Messages: | 2,438,897 |