dxf <dxforth@gmail.com> writes:

On 31/12/2023 2:54 am, Anton Ertl wrote:

: sorti3a ( addr u -- )
cells over + 0 -rot case ( 0 al1 ah1 .. aln ahn )
over cell+ over u< ?of partition contof
2drop dup 0= ?of drop endof
next-case ;

Same written more conventionally:

: sorti3a ( addr u -- )
cells over + 0 -rot
begin ( 0 al1 ah1 .. aln ahn )
begin
over cell+ over u< while
partition
repeat
2drop 0 of end
repeat ;

Reality check:

Gforth:
/nfs/a5/anton/tmp/xxx.fs:48: Undefined word
2drop 0 of >>>end<<<

iforth:
sorts, but leaves data on the stack

lxf:
/nfs/a5/anton/tmp/xxx.fs line: 46 col: 19
undefined word end

sf64:
/nfs/a5/anton/tmp/xxx.fs
48: 2drop 0 of end >>> end ?

vfx64:
Err# -22 ERR: Control structure mismatch.
Source: "/nfs/a5/anton/tmp/xxx.fs" on line 48

2drop 0 of end

^

Admittedly, I did not use the latest versions of these Forth systems,
but if they have added END in recent years (which I doubt), it's
"newfangled" rather than "conventionally".

The case of iforth is interesting: It has a word END. SEE END
decompiles to

: End 4096 ;

and looking at the machine code confirms this. Trying to compile

: foo if end ;
: bar of end ;

produces "Structure not balanced" errors in either case. So it seems
that what happened here and made your version of sorti3a almost work
on iforth is that

BEGIN ... 0 OF ... REPEAT

compiles like

BEGIN ... DUP 0 = WHILE ... REPEAT

on iforth. Replacing the OF in that way produced the same result,
including the extra stack items.

Bottom line: Your SORTI3a works on none of these Forth systems as
intended. On what do you base your "more conventionally" claim?

BTW, fig-Forth has a word END:

https://dwheeler.com/6502/fig-forth-glossary.txt says:
END P,C2,L0
This is an 'alias' or duplicate definition for UNTIL.

I would no longer call fig-Forth "conventional" (as the conventions
have changed since then), but defining a fig-Forth word name with a
new meaning that no widely used system implements is the contrary of "conventinal".

- 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: https://euro.theforth.net/2023

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

FYI: END is the name of a cursor-control key.

[ END already defined ]

FORTH> locate END
File: d:dfwforth/include/terminal.prf
37: $2500 =: <-- $2700 =: -->
38: $22700 =: ^--> $22500 =: ^<--
39: $0008 =: BS $0009 =: Tab
40>> $2400 =: Hme $2300 =: End
41: $2100 =: PgUp $2200 =: PgDn
42: $22400 =: ^Home $22300 =: ^End
43: $22100 =: ^PgUp $22200 =: ^PgDn ok

On Linux (conditional compilation) the value of END is different:
$0D00 =: --^ $0E00 =: --v
$0B00 =: <-- $0C00 =: -->
$1200 =: PgUp $1100 =: PgDn
$0F00 =: Hme $1000 =: End
$0008 =: BS $0009 =: Tab
$001B =: ESC $1600 =: Ins
$1400 =: Del
$0100 =: F1 $0200 =: F2

I don't think anything can be done to catch this kind of Forth
mistake (using word names that are defined on the target system
but have a different meaning there then on the host).

-marcel

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

mhx@iae.nl (mhx) writes:

FYI: END is the name of a cursor-control key.

Yes, the one that was standardized as K-END.

I don't think anything can be done to catch this kind of Forth
mistake (using word names that are defined on the target system
but have a different meaning there then on the host).

There are certainly things that could be done, it's just that not
enough Forth system implementors implement the necessary features (not
that implementing them would be particularly burdensome) and
consequently Forth programmers don't do the things that could be done.

In particular, we have "extension queries" <http://www.forth200x.org/extension-query.html>. So if dxf had made a
proposal for END and continued it to the CfV stage in the old
Forth200x process, there would be a unique extension name that could
be queried for, and one could then take appropriate action if the
system does not support dxf's END.

The CfV system has had a hiatus for several years when the process
converted to Web 2.0 and now is starting up again, but given the lack
of interest from system implementors in wordset queries and extension
queries up to now, I expect that we will not see a revival of the
extension queries.

The Forth community seems to have settled on [DEFINED] and [UNDEFINED]
being good enough, but END demonstrates that they are not.

For comparison, the C people have their "#include"s which allows them
to define sets of names, but in addition they have feature test macros <https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html>, which you define before the "#include" to tell the include file which
version of the sets of names defined in the file you want to have.

Admittedly they have a bigger problem: compilation fails if the same
name is declared twice with incompatible types, or if it is defined
twice. But I think this more rigid discipline in C also comes from
there being billions of lines of C code rather than a few million like
Forth, much of which is system-specific anyway. They want any name
conflicts to show up during compilation, instead of getting a spurious
success like dxf's SORTI3 compiling on iForth.

- 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: https://euro.theforth.net/2023

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