Hans Bezemer <the.beez.speaks@gmail.com> writes:

On 16-04-2025 23:26, Anton Ertl wrote:

OTOH, Forth is worse suited to deal with dial-your-language-version
options: C uses separate compilation, so if the main program uses some
version of the standard, and a library uses a different version,
that's typically no problem, because they are both compiled with
different compiler calls (which may have different options).

Forth, OTOH, compiles all the sources in one compilation run, and any
choices you dial at one point tend to affect all the rest of the
compilation, even if it compiles some independently developed library.
One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support; some would
call that "WIBNI"s, while others would point out that Chuck Moore did
not bring these ideas down from the mountain.

- anton

I don't think so. Using K&R prototypes is significantly different from
ANSI prototypes. That must have broken quite some code - unless specific >measures were taken to allow "old format" codes as well.

They certainly were, and still are. E.g, for the following function
definition in pre-C89 style:

foo(x)
int x;
{
return bar(x);
}

gcc-12 produces some warnings:

xxx.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | foo(x)
| ^~~
xxx.c: In function ‘foo’:
xxx.c:4:10: warning: implicit declaration of function ‘bar’ [-Wimplicit-function-declaration]
4 | return bar(x);
| ^~~

but it compiles the code. In the old times the calling conventions
were designed to work for undeclared functions, so the compiled code
also worked. Things like the I32LP64 mistake and newer calling
conventions were designed for programs with fully-blown prototypes, so
on newer platforms some of the old code does not work (in particular,
when passing a double or an undeclared pointer), but that's the choice
of the implementors, not due to the C standard introducing an
incompatible requirement.

restrict,
nullptr, inline, bool - the list of added keywords is endless.

The number of keywords is finite (to be exact, C23 has 59 keywords,
including 5 obsolescent keywords), which means that the number of
added keywords is finite, too.

BTW, so
is the list of deprecated keywords, like "_Bool" with was replaced by
the far less ugly "bool" in 2023.

The number of obsolescent keywords in C23 is 5. Endless?

And I don't think the argument that "Forth compiles in one go" holds up
as an argument to avoid cleaning up historical clutter. The different >versions of a "keyword" could be created as their names, followed by a >postfix of the standard, e.g. DO_79, DO_82, DO_94. Let's call 'em
"version words".

There are no keywords in Forth, which makes changes less problematic
than in C. And names can be redefined in Forth, which also makes
changes less problematic.

As for introducing changes that are so disruptive that you would then
need dial-your-standard features to provide backwards compatibility
(e.g., stuff like the Forth-83 disruptions to Forth-79, e.g., the
changes to NOT and PICK), yes, one could propose technical workarounds
for that. It's just that the Forth community and the Forth-200x will
not find a consensus for taking such measures.

E.g., consider requiring the text interpreter of Forth systems to
treat 1.0 as FP value; currently this is not standardized, but common
practice (gforth, iForth, lxf, SwiftForth, VFX) is to treat it as
equivalent to 10., i.e., a double-cell integer.

One way to keep backwards compatibility with the current common
practice would be to require having a word FORTH-2030-FP-SYNTAX (or
maybe just FORTH-2030) in every file that uses the new FP syntax
before the use of that syntax. If that word does not appear in that
file, "1.0" would still be non-standardized.

Next: "1.". If we had such declarations, we could even support "1." (standardized as double-cell in Forth-94 and Forth-2012) as FP number.
The alternative would be to treat "1." as double-cell and 1.0 as FP
value, which IMO is even worse than requiring an "e" in every FP
value.

But back to the dial-a-standard things: I have never seen such a
proposal that limits the dialing to one file. Instead, the proposals
and existing practice is to dial for the rest of text interpretation
(or until somthing else is dialed). That would mean that previously
working files might no longer work when included after dialing the new
FP syntax. E.g., all versions of the recognizer proposal have been
along these lines, and Bernd Paysan has actually proposed allowing to
treat "1." as FP value by swapping the integer and FP recognizer in
the recognizer order, which would have exactly this effect. And Bernd
Paysan is not the only one: Among other dialing features that all are
not limited to the file, VFX supports disabling the recognition of
"1." as double, which then leads to its recognition as FP number; but
that disabling is not limited to a file, but extends to the rest of
the text interpretation.

Here's the example for VFX:

',' dp-char 1+ c! ok
1. ok F:-1
f. 1. ok

So you could try to propose a word like FORTH-2030-FP-SYNTAX, but I
expect that the reactions would be along the following lines (in the
community and in the standardization committee):

1) A number of people consider this completely unnecessary, and
actually heretical, because Chuck Moore came down from the mountain
with doubles, not floats, so that's the way it was always meant to
be. Some would argue that treating "1.0" or "1." as FP number is
proposed just to cater to C programmers, and that Forthers should
take pride in deviating from the beaten path.

2) A number of people would argue against the limitation to a specific
file because of "complexity" (meaning implementation complexity),
"WIBNI", or because Chuck Moore came down from the mountain without
that idea, and that Chuck Moore has argued against libraries, that
he has argued against saving and restoring state, and instead has
argued for always setting it. And that the common practice (e.g.,
in VFX) is to just set the state, and never

3) And if you changed your proposal to just affect the rest of text
interpretation (and include another word FORTH-2012-FP-SYNTAX or
somesuch to switch back), some people (including me) would argue
that this variant of FORTH-2030-FP-SYNTAX would break existing
code, and that introducing FORTH-2012-FP-SYNTAX is a poor and
error-prone substitute for defining FORTH-2030-FP-SYNTAX properly.
Word counters would dislike this variant because it introduces an
additional word, and the people who argue 1) would also dislike the
proposal.

The bottom line is that the proposal would probably not find a
consensus and would not be accepted by the committee. The bottom line
is:

One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support

And the bottom line of that is that proposals for incompatible changes
have little chance of being accepted.

There could be special words like [FORTH78], [ANSFORTH] - which would no >nothing but:
- Either hiding words in the dictionary that should be disabled;
- Activating words that are part of this standard;

Interestingly, Forth-79 includes a word 79-STANDARD, and Forth-83
includes a word FORTH-83, but Forth-94 and Forth-2012 do not include
such words. We had a discussion whether we should have Forth-94 and
Forth-2012 versions of environmental queries for wordsets in
Forth-2012, but the committee decided against that.

In any case, if you want to support including libraries written for a
different standard, the effect of such words should be limited to a
specific file. If the standards are incompatible and you want
libraries, and you do not provide this kind of dialing, you can take a
look at the Python 3 transition pain (or worse, what happened with
Perl6) to see what happens. The Python community has learned from
that experience not to introduce such incompatible changes again.

- Assigning the proper "version" words to trampolines or DEFERs.

That's exactly the wrong thing to do. You want to statically bind the
name to the word with the right version. E.g. if you have a Forth-83 program

forth-83
100 load ( includes a library written in Forth-79)

: foo ( ... -- ... )
... not ... ;

and the library contains

79-standard
: bar ( ... -- ... )
... not ... ;

you want the use of NOT in FOO to be statically bound to (what
Forth-94 calls) INVERT and the NOT in BAR to be statically bound to
0=; you usually don't want BAR or FOO to change its behaviour
depending on which standard is selected.

But I think maybe, just maybe the same effect could be achieved by using >wordsets.

I assume you mean wordlists. Yes, the effect of switching between the
Forth-83 NOT and the Forth-79 NOT can be achieved by having a wordlist containing the Forth-79 words and a wordlist containing the Forth-83
words, and putting it in the search order.

So, if we compile an external library using a mix of Forth-79, ANS Forth
and Forth 2012, it could be as simple as:

INCLUDE a.fs
INCLUDE b.fs
[FORTH2012]

a.fs:
[FORTH79]
...

b.fs:
[ANSFORTH]
...

There is 79-STANDARD, but there is no word equivalent to [FORTH2012]
or [ANSFORTH]. So a program that contains "[FORTH2012]" without first
defining it is not Forth-2012-compliant. And a program that contains [ANSFORTH] without first defining it is not Forth-94 compliant.

That's much like setting the radix.

BASE is one of the misfeatures of Forth, and demonstrates the
disadvantage of having a state for the rest of the text
interpretation, and the Chuck Moore approach to . Do you start every
file with DECIMAL or HEX? Looking at SwiftForth (where one might
expect the most Chuck Moore influence), I see 26 occurences of DECIMAL
and 16 occurences of HEX, and usually not before the first occurence
of an integer with several digits. As an example, the file that
contains the definition

: DECIMAL ( -- ) 10 BASE ! ;

does not contain an invocation of DECIMAL before this use of "10".

So - why couldn't this work?

As mentioned, there is no [FORTH2012] and no [ANSFORTH].

Moreover, this general approach does not work for BASE: If the next
standard required that systems start out in, say, octal, I am sure
that a lot of the existing source files would fail unless you invoked
DECIMAL before the INCLUDE. BASE only works (and only so-so) because
every sane system defaults to DECIMAL, and that does not change
between standard versions.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2025Apr18.082817@mips.complang.tuwien.ac.at>,

One way to keep backwards compatibility with the current common
practice would be to require having a word FORTH-2030-FP-SYNTAX (or
maybe just FORTH-2030) in every file that uses the new FP syntax
before the use of that syntax. If that word does not appear in that
file, "1.0" would still be non-standardized.

This would be easy enough
The file
dbase_FORTH-2xxxx.frt
contains
"
ALSO FORTH-2xxxx \ A named vocabulary
do
your
thing
PREVIOUS
"
wordlist are underused. You could have two independant random
number generators, by loading the source twice.

Because ciforth uses prefixes 0 1 2 .. 9 parse a number I can redefine
(in a separate wordlist or just in FORTH)

: 7
-1 PP +! (NUMBER) POSTPONE SDLITERAL
; IMMEDIATE PREFIX

It is sufficient to revector SDLITERAL

Now SDLITERAL is
(DPL is the position of the decimal point, initialised at NULL)
: SDLITERAL DPL @ IF POSTPONE DLITERAL ELSE DROP POSTPONE LITERAL THEN
; IMMEDIATE

I could revector it with
: SDLITERAL DPL @ 0<> 10 ?ERROR DROP POSTPONE LITERAL ;

(With 10 meaning "not a valid digit")

By the way. Do you really need numbers like 340282366920938463463374607431764264639

Maybe it is time to ditch double integers, the decimal point is a
seventy's kludge. The most characteristic feature of integers is ...
that they don't contain a decimal point, embedded or trailing.
Simply put, it is time to reserve the decimal point for floats.

If you really are into number theory, primes whatnot,
you could think of a proposed prefix (recognizer)

\ DMAXUINT in decimal:
##340282366920938463463374607431764264639

and maybe
$$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

I see Marcel Hendrix programs and there constant integers have
a $ or a # prefix anyway.

Groetjes Albert

Next: "1.". If we had such declarations, we could even support "1." >(standardized as double-cell in Forth-94 and Forth-2012) as FP number.
The alternative would be to treat "1." as double-cell and 1.0 as FP
value, which IMO is even worse than requiring an "e" in every FP
value.

But back to the dial-a-standard things: I have never seen such a
proposal that limits the dialing to one file. Instead, the proposals
and existing practice is to dial for the rest of text interpretation
(or until somthing else is dialed). That would mean that previously
working files might no longer work when included after dialing the new
FP syntax. E.g., all versions of the recognizer proposal have been
along these lines, and Bernd Paysan has actually proposed allowing to
treat "1." as FP value by swapping the integer and FP recognizer in
the recognizer order, which would have exactly this effect. And Bernd
Paysan is not the only one: Among other dialing features that all are
not limited to the file, VFX supports disabling the recognition of
"1." as double, which then leads to its recognition as FP number; but
that disabling is not limited to a file, but extends to the rest of
the text interpretation.

Here's the example for VFX:

',' dp-char 1+ c! ok
1. ok F:-1
f. 1. ok

So you could try to propose a word like FORTH-2030-FP-SYNTAX, but I
expect that the reactions would be along the following lines (in the >community and in the standardization committee):

1) A number of people consider this completely unnecessary, and
actually heretical, because Chuck Moore came down from the mountain
with doubles, not floats, so that's the way it was always meant to
be. Some would argue that treating "1.0" or "1." as FP number is
proposed just to cater to C programmers, and that Forthers should
take pride in deviating from the beaten path.

2) A number of people would argue against the limitation to a specific
file because of "complexity" (meaning implementation complexity),
"WIBNI", or because Chuck Moore came down from the mountain without
that idea, and that Chuck Moore has argued against libraries, that
he has argued against saving and restoring state, and instead has
argued for always setting it. And that the common practice (e.g.,
in VFX) is to just set the state, and never

3) And if you changed your proposal to just affect the rest of text
interpretation (and include another word FORTH-2012-FP-SYNTAX or
somesuch to switch back), some people (including me) would argue
that this variant of FORTH-2030-FP-SYNTAX would break existing
code, and that introducing FORTH-2012-FP-SYNTAX is a poor and
error-prone substitute for defining FORTH-2030-FP-SYNTAX properly.
Word counters would dislike this variant because it introduces an
additional word, and the people who argue 1) would also dislike the
proposal.

The bottom line is that the proposal would probably not find a
consensus and would not be accepted by the committee. The bottom line
is:

One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support

And the bottom line of that is that proposals for incompatible changes
have little chance of being accepted.

There could be special words like [FORTH78], [ANSFORTH] - which would no >>nothing but:
- Either hiding words in the dictionary that should be disabled;
- Activating words that are part of this standard;

Interestingly, Forth-79 includes a word 79-STANDARD, and Forth-83
includes a word FORTH-83, but Forth-94 and Forth-2012 do not include
such words. We had a discussion whether we should have Forth-94 and >Forth-2012 versions of environmental queries for wordsets in
Forth-2012, but the committee decided against that.

In any case, if you want to support including libraries written for a >different standard, the effect of such words should be limited to a
specific file. If the standards are incompatible and you want
libraries, and you do not provide this kind of dialing, you can take a
look at the Python 3 transition pain (or worse, what happened with
Perl6) to see what happens. The Python community has learned from
that experience not to introduce such incompatible changes again.

- Assigning the proper "version" words to trampolines or DEFERs.

That's exactly the wrong thing to do. You want to statically bind the
name to the word with the right version. E.g. if you have a Forth-83 program

forth-83
100 load ( includes a library written in Forth-79)

: foo ( ... -- ... )
... not ... ;

and the library contains

79-standard
: bar ( ... -- ... )
... not ... ;

you want the use of NOT in FOO to be statically bound to (what
Forth-94 calls) INVERT and the NOT in BAR to be statically bound to
0=; you usually don't want BAR or FOO to change its behaviour
depending on which standard is selected.

But I think maybe, just maybe the same effect could be achieved by using >>wordsets.

I assume you mean wordlists. Yes, the effect of switching between the >Forth-83 NOT and the Forth-79 NOT can be achieved by having a wordlist >containing the Forth-79 words and a wordlist containing the Forth-83
words, and putting it in the search order.

So, if we compile an external library using a mix of Forth-79, ANS Forth >>and Forth 2012, it could be as simple as:

INCLUDE a.fs
INCLUDE b.fs
[FORTH2012]

a.fs:
[FORTH79]
...

b.fs:
[ANSFORTH]
...

There is 79-STANDARD, but there is no word equivalent to [FORTH2012]
or [ANSFORTH]. So a program that contains "[FORTH2012]" without first >defining it is not Forth-2012-compliant. And a program that contains >[ANSFORTH] without first defining it is not Forth-94 compliant.

That's much like setting the radix.

BASE is one of the misfeatures of Forth, and demonstrates the
disadvantage of having a state for the rest of the text
interpretation, and the Chuck Moore approach to . Do you start every
file with DECIMAL or HEX? Looking at SwiftForth (where one might
expect the most Chuck Moore influence), I see 26 occurences of DECIMAL
and 16 occurences of HEX, and usually not before the first occurence
of an integer with several digits. As an example, the file that
contains the definition

: DECIMAL ( -- ) 10 BASE ! ;

does not contain an invocation of DECIMAL before this use of "10".

So - why couldn't this work?

As mentioned, there is no [FORTH2012] and no [ANSFORTH].

Moreover, this general approach does not work for BASE: If the next
standard required that systems start out in, say, octal, I am sure
that a lot of the existing source files would fail unless you invoked
DECIMAL before the INCLUDE. BASE only works (and only so-so) because
every sane system defaults to DECIMAL, and that does not change
between standard versions.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html >comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18 Apr 25 at group /comp/lang/forth in article 2025Apr18.082817@mips.complang.tuwien.ac.at
<anton@mips.complang.tuwien.ac.at> (anton@mips.complang.tuwien.ac.at) wrote:

That's much like setting the radix.

BASE is one of the misfeatures of Forth, and demonstrates the
disadvantage of having a state for the rest of the text
interpretation, and the Chuck Moore approach to . Do you start every
file with DECIMAL or HEX? Looking at SwiftForth (where one might
expect the most Chuck Moore influence), I see 26 occurences of DECIMAL
and 16 occurences of HEX, and usually not before the first occurence
of an integer with several digits. As an example, the file that
contains the definition

: DECIMAL ( -- ) 10 BASE ! ;

does not contain an invocation of DECIMAL before this use of "10".

So - why couldn't this work?

As mentioned, there is no [FORTH2012] and no [ANSFORTH].

Moreover, this general approach does not work for BASE: If the next
standard required that systems start out in, say, octal, I am sure
that a lot of the existing source files would fail unless you invoked
DECIMAL before the INCLUDE. BASE only works (and only so-so) because
every sane system defaults to DECIMAL, and that does not change
between standard versions.

In all of my applications $0A BASE ! is one of the 1st words, because of
the DECIMAL issue. and ICECOLD and COLD also set it to $0A

Also all my developed HW (w/ and w/ FORTH) I made a 0,1uf || 100k from GND
to PE and spent a good PWRup/BROWNout chip.

and my ICECOLD sets the RAM all regs of CPU and peripheral to the default
state or 0 if there is none.

So all my aps start with a defined state of all regs, vars...

Covered my ass very good for nearly 60 yrs of working!

YMMV and masochists don't do it :)





Saludos (an alle Vernⁿnftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukⁿnftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

: DECIMAL ( -- ) 10 BASE ! ;
does not contain an invocation of DECIMAL before this use of "10".

: DECIMAL ( -- ) 5 5 + BASE ! ;

should usually work.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/04/2025 09:18, Paul Rubin wrote:

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

: DECIMAL ( -- ) 10 BASE ! ;
does not contain an invocation of DECIMAL before this use of "10".

: DECIMAL ( -- ) 5 5 + BASE ! ;

should usually work.

As part of the Forth test suite there is a preliminary test program to
be run before the Hayes core tests intended to aid in the development of
a Forth systems with as few assumptions as possible, including not
assuming the value of BASE. Having tested 0 and 1+ the system is set to
decimal by:

0 1+ 1+ BASE !
It then tests BASE = 2, then
1010 BASE !
should always work

--
Gerry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxf <dxforth@gmail.com> writes:

Perhaps it's been updated since as the SwiftForth file I have has:

: DECIMAL ( -- ) $0A BASE ! ;

Interesting: SwiftForth 3.10.4, 3.11.0, and 4.0.0-RC52 contain

: DECIMAL ( -- ) $0A BASE ! ;

while SwiftForth 4.0.0-RC87 and 4.0.0-RC89 contain

: DECIMAL ( -- ) 10 BASE ! ;

Gforth has the worst of both worlds:

: decimal ( -- ) \ core
\G Set @code{base} to &10 (decimal). Don't use @code{decimal}, use
\G @code{base-execute} instead.
a base ! ;

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxf <dxforth@gmail.com> wrote:

Really annoying was LMI which on error switched to DECIMAL ...

Someone here awhile back posted modifying LOAD and LIST to convert
the TOS number to decimal regardless of current BASE setting.
Gave it a try and found it indeed helpful.

I'm currently using many vocabularies and my main vocabulary is TOAD and
often I'm working in vocabulary WRK . I kept ABORT to reset vocabulary
to FORTH as well as setting BASE to decimal but it doesn't do
EMPTY-BUFFERS (however that is done on an abort signal from the OS).
Not too annoying since I'm well aware of what to expect on error so
my automatic response to an error is TOAD WRK . The above changes
to LOAD and LIST also help along with a quick status word double-dot
'..' that displays CONTEXT CURRENT BASE LATEST and data stack.
Also have a switch to replace ABORT with an abort in (ABORT) that
doesn't reset vocabulary, base nor clear data stack.

Had setup that split the display with a status line on the display
bottom where data stack status (dots), error and user messages where
shown after every command run. Don't use anymore, no need to be that
fancy.

Not a language issue but a matter of application. These things don't
go into production word definitions but pertain to operations.
I'm sure everyone has his pet setup to help suppress frustrations.

--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <757e2ced7a6ff4b73d9fa4531d29ff611dc72e10@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 20/04/2025 6:18 pm, Paul Rubin wrote:

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

: DECIMAL ( -- ) 10 BASE ! ;
does not contain an invocation of DECIMAL before this use of "10".

: DECIMAL ( -- ) 5 5 + BASE ! ;

should usually work.

Perhaps it's been updated since as the SwiftForth file I have has:

: DECIMAL ( -- ) $0A BASE ! ;

Closest thing to a BASE issue I've encountered was invoking the
screen editor while in HEX. After doing that a few times I fixed
the editor!

Really annoying was LMI which on error switched to DECIMAL ...

They had it half right. All error numbers should be printed in
decimal. First aid read the paragraphs in de documentation
pertaining to this error.

Groetjes Albert

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxf <dxforth@gmail.com> wrote:

Out of curiosity what was the conversion method?

-- CVD ( n_x -- n_decimal)
-- Convert to decimal
-- Split given 3 digit number into digits and
-- reassemble digits into a decimal number.

Base is used to get the digits but regardless of the base each digit
is treated as a decimal value, what the user had intended, and assembled
into a decimal number.

--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 22 Apr 2025 0:50:13 +0000, dxf wrote:

On 22/04/2025 12:19 am, sjack wrote:

dxf <dxforth@gmail.com> wrote:

[..]

16 base ! 10 cvd decimal . 10 ok
2 base ! 10 cvd decimal . 10 ok
36 base ! -10 cvd decimal . -10 ok

Why not store the number as text in this case?

What is the advantage? As a user I still need
to know the BASE (unless it is assumed to be
always 10).

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mhx <mhx@iae.nl> wrote:

Why not store the number as text in this case?

What is the advantage? As a user I still need
to know the BASE (unless it is assumed to be
always 10).

CVD is not for user to switch base when he intends so.
Its an aid for the user when doing operation like LIST or
LOAD where he enters screen number intended to be in decimal
but unbeknownst the BASE was not decimal.

' list see
LIST
134542736 CVD
134542740 LIST
134542744 ;S
' load see
LOAD
134542764 CVD
134542768 LOAD
134542772 ;S

..CURRENT and CONTEXT are WRK BASE: 10 Latest:
S?: empty
0 101 .line This is indeed screen 101 (decimal)
2 base !
..CURRENT and CONTEXT are WRK BASE: 2 Latest:
S?: empty
101 list
SCR # 101
0 This is indeed screen 101 (decimal)
1
--- Snip ---
14
15

..CURRENT and CONTEXT are WRK BASE: 10 Latest:
S?: empty

The user got the intended screen listing, #101 (decimal)
due to CVD .
Added bonus, the original LIST set the BASE back to decimal.

Not fool proof for LOAD. At least the correct screen is loaded
but if the base is not set in the screen it could be a problem
but usually will be noticeable. And if not, "c'est la vie".

--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 23 Apr 2025 14:22:28 +0000, sjack wrote:

mhx <mhx@iae.nl> wrote:

[..]

CVD is not for user to switch base when he intends so.

DWIM ? I really don't expect that in Forth.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <nnd$7cd5eca1$455e887d@ea22aa12ceb9f46f>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 21-04-2025 09:38, dxf wrote:

On 21/04/2025 6:34 am, albert@spenarnc.xs4all.nl wrote:

In article <757e2ced7a6ff4b73d9fa4531d29ff611dc72e10@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 20/04/2025 6:18 pm, Paul Rubin wrote:

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

: DECIMAL ( -- ) 10 BASE ! ;
does not contain an invocation of DECIMAL before this use of "10".

: DECIMAL ( -- ) 5 5 + BASE ! ;

should usually work.

Perhaps it's been updated since as the SwiftForth file I have has:

: DECIMAL ( -- ) $0A BASE ! ;

Closest thing to a BASE issue I've encountered was invoking the
screen editor while in HEX. After doing that a few times I fixed
the editor!

Really annoying was LMI which on error switched to DECIMAL ...

They had it half right. All error numbers should be printed in
decimal. First aid read the paragraphs in de documentation
pertaining to this error.

I notice I did that for THROW numbers that don't have a message - after which it reverts to the current BASE. I should document that

somewhere...

To force myself to add messages to THROWs (especially in libs with
special conditions) I added THROW" - it works like a combination of
ABORT" and THROW. You need to specify a THROW code, you need to specify
a flag and you need to specify a message.

This perpetuates the myth that a message is documentation.
Error documentation in my manual can run over half a page, as
did the FORTRAN errors in IBM manual.
You don't actually want an error message, you want to know what
you can do about it.

Hans Bezemer

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxf <dxforth@gmail.com> wrote:

What happens in the case of CATCH - what's left on the stack?

Nowadays I don't use catch/throw, not that I have anything against it;
I'm just being retro. But from past experience, if I recall right, the
data stack may have been reset to its former position at the time of
catch but the data on the stack could be dirty. Any on-error action,
e.g. i/o cleanup, prior to abort would be prudent in avoiding the
use of data left on the data stack (if catch hadn't restored it from
a clone copy).

--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Although it's wonderful to list in detail what might have caused the
error - and how to fix it - sometimes all you need is a clue to
hang a picture on.

Well, my life would be quite miserable if iForth did not give
me an error message, a stack-trace, and the file + line-number
where the error occurred. I know quite well how to fix errors,
the problem is to first find where they are (in a 10,000 line
program) so that I can check Git for my changes and the
surrounding text for 'documentation' on things I changed
6 months ago.

('Documentation' is in many cases just this programmer's
description of how he hopes his code works and never
afterwards updated to reality.)

Once the error is found, I break out my trusty ^^ tool to set a
printing break-point (with extra code to give variable and
pointer information, or to skip breaking until the umpteenth
iteration or some other computable event).

In very difficult cases I attach a C debugging environment to
trace memory overwrites, but in almost all other situations
Forth is *much* easier for debugging. C debuggers are getting
better though, they are able to evaluate sizable pieces of code
interactively nowadays but no 'on-the-spot' macros or accurate
and immediate on-the-spot re-compiles yet.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1 May 2025 at 03:23:53 CEST, "dxf" <dxforth@gmail.com> wrote:

AFAIK on most forth systems exceptions generate either an error code or an error message (the latter via ABORT" or caught code). In short, what good
is having both a msg and a code?

THROWs are defined to be defined by their throw number. Whether or not a message is associated with the throw number is a factor of the Forth implementation.
In VFX, the return to the text interpreter looks for a message associated with the throw number and displays it if found.

There are three benefits of this.
1) it is less code to reuse a THROW by number rather than by text,
2) I can change the text in one place only for all uses,
3) Internationalisartion is much easier.

Stephen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1 May 2025 at 13:17:27 CEST, "John Doe" <john.doe@myemail.invalid> wrote:

On 1 May 2025 at 03:23:53 CEST, "dxf" <dxforth@gmail.com> wrote:

AFAIK on most forth systems exceptions generate either an error code or an >> error message (the latter via ABORT" or caught code). In short, what good >> is having both a msg and a code?

THROWs are defined to be defined by their throw number. Whether or not a message is associated with the throw number is a factor of the Forth implementation.
In VFX, the return to the text interpreter looks for a message associated with
the throw number and displays it if found.

There are three benefits of this.
1) it is less code to reuse a THROW by number rather than by text,
2) I can change the text in one place only for all uses,
3) Internationalisartion is much easier.

Stephen

Sorry for the faIled transition to a new machine.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Doe <john.doe@myemail.invalid> writes:

In VFX, the return to the text interpreter looks for a message associated with >the throw number and displays it if found.

There are three benefits of this.
1) it is less code to reuse a THROW by number rather than by text,
2) I can change the text in one place only for all uses,

Moreover, it ensures that a specific throw code is associated with a
specific error message (rather than having different messages for the
same throw code). Gforth gives you a way to get a previously
unoccupied throw code and associate an error message with it:

s" Completely unheard-of condition" exception constant WTF
WTF throw

This outputs:

*the terminal*:4:5: error: Completely unheard-of condition
WTF >>>throw<<<

But you can also catch this condition

: handle-WTF ( xt )
catch dup WTF = if 2drop ." recovering from WTF" 0 then
throw ;

WTF ' throw handle-WTF \ output: "recovering from WTF ok"

3) Internationalisartion is much easier.

True, but I find it more useful not to have internationalized error
messages. I can search for the error message in the WWW, and then
find more pages (and hopefully a relevant one) than if I use a
localized error message. However, some error messages are inherited
from other layers, so if you use a non-English-language locale, Gforth
gives you localized stuff:

[~/gforth:157334] LANG=de_AT.utf8 gforth
Gforth 0.7.9_20250409
...
include sdfl
*the terminal*:1:9: error: Datei oder Verzeichnis nicht gefunden
include >>>sdfl<<<
...

But at least the messages coming from the Forth level are not
localized:

0 @
*the terminal*:2:3: error: Invalid memory address
0 >>>@<<<

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <nnd$1667d791$2eba7243@d7216ffec373a0d9>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 01-05-2025 03:23, dxf wrote:

On 30/04/2025 11:58 pm, Hans Bezemer wrote:

On 30-04-2025 04:37, dxf wrote:

On 30/04/2025 2:50 am, Hans Bezemer wrote:

...
To force myself to add messages to THROWs (especially in libs with special conditions) I added THROW" - it works like a combination of ABORT" and THROW. You need to

specify a THROW code, you need to specify a flag and you need to specify a message.

What happens in the case of CATCH - what's left on the stack?

Surprise, surprise - THROW" calls THROW (actually, it inlines the whole shebang). So - what do you think?

For ABORT" the string is suppressed and only the code (-2) is left.
Is that what THROW" does with the string?

AFAIK on most forth systems exceptions generate either an error code or an >> error message (the latter via ABORT" or caught code). In short, what good >> is having both a msg and a code?

In 4tH, ABORT is really abort. It does what the label says. It can't be >caught. If you want to abort, I assume you want to abort. If you wanna
catch it, use THROW. C'mon. I designed it as a man's language ;-)

ABORT is at least kind of an exception. But look at QUIT.
Actually QUIT is the READ-EVALUATE-PRINT-REPEAT loop of
Forth. How can this ever be considered an exception or
"caught".
I struggled with giving a meaning to QUIT and ABORT.
I arrived at
QUIT initialises both stacks and goes interpreting.
ABORT only initialises the return stack and goes interpreting.

(if there is an exception system, both must initialise that too.
I can't think of a QUIT that can be caught and at the same time
initialises the exceptions.)

Hans Bezemer

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <nnd$595f502c$48101358@27425914746d2863>,
<albert@spenarnc.xs4all.nl> wrote:

In article <nnd$1667d791$2eba7243@d7216ffec373a0d9>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 01-05-2025 03:23, dxf wrote:

On 30/04/2025 11:58 pm, Hans Bezemer wrote:

On 30-04-2025 04:37, dxf wrote:

On 30/04/2025 2:50 am, Hans Bezemer wrote:

...
To force myself to add messages to THROWs (especially in libs with >special conditions) I added THROW" - it works like a combination of

ABORT" and THROW. You need to

specify a THROW code, you need to specify a flag and you need to

specify a message.

What happens in the case of CATCH - what's left on the stack?

Surprise, surprise - THROW" calls THROW (actually, it inlines the

whole shebang). So - what do you think?

For ABORT" the string is suppressed and only the code (-2) is left.
Is that what THROW" does with the string?

AFAIK on most forth systems exceptions generate either an error code or an >>> error message (the latter via ABORT" or caught code). In short, what good >>> is having both a msg and a code?

In 4tH, ABORT is really abort. It does what the label says. It can't be >>caught. If you want to abort, I assume you want to abort. If you wanna >>catch it, use THROW. C'mon. I designed it as a man's language ;-)

ABORT is at least kind of an exception. But look at QUIT.
Actually QUIT is the READ-EVALUATE-PRINT-REPEAT loop of
Forth. How can this ever be considered an exception or
"caught".
I struggled with giving a meaning to QUIT and ABORT.
I arrived at
QUIT initialises both stacks and goes interpreting.
ABORT only initialises the return stack and goes interpreting.

Actually that is the other way around, but whatever.

(if there is an exception system, both must initialise that too.
I can't think of a QUIT that can be caught and at the same time
initialises the exceptions.)

Hans Bezemer

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <d9149a9d12db559e2720156b315fcfdcdd90e3fe@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 2/05/2025 10:16 pm, albert@spenarnc.xs4all.nl wrote:

...
I struggled with giving a meaning to QUIT and ABORT.

Me too.

I arrived at
QUIT initialises both stacks and goes interpreting.
ABORT only initialises the return stack and goes interpreting.

(if there is an exception system, both must initialise that too.
I can't think of a QUIT that can be caught and at the same time
initialises the exceptions.)

Technically both end an application distinguished only by the fact
QUIT lets you examine what was on the stack. Presumably this was
for debugging purposes. For reasons known only to ANS (and maybe
Mitch Bradley) both were assigned exception codes and thus CATCHable.

As I wanted a fool-proof way of ending a turnkey app for any reason
I let QUIT do that. That it may leave stuff on the data stack is of
no consequence to a turnkey. A QUIT is considered by the OS as a
'success' whereas as an uncaught ABORT (or other exception) means
'failure'.

Interpretation of QUIT as a REPL is IMHO the more useful.

Look at the end of my turnkey lisp, build with
lina -c lispl.frt

---- lispl.frt ------------
....
"more.scm" lisp-load-from-file
: doit 'ERROR RESTORED lisp-on QUIT ;
---------------------------
The doit is the entry point of the turnkey.
Forth is morphed into a lisp interpreter and goes repl-ing
according to QUIT.
[ It understand
(define (first-denomination kinds-of-coins)
(cond ((= kinds-of-coins 1) 1)
...
with surprisingly little modification of the interpreter.
using PREFIX and a revectoring of NAME ('BL WORD' replacement). ]

You can replace QUIT by EXIT, and the doit would end normally,
with a return code OKAY (0). You can of course leave out the
EXIT, because this is implied at the end of each definition.
Also if you lisped decently, of course, you get OKAY.

If QUIT is replaced by 19 THROW, it would end with a return code 19.

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)