On 01/02/2024 11:27, albert@spenarnc.xs4all.nl wrote:
> In article <upfjl6$1vmfh$1@dont-email.me>,
> Gerry Jackson <do-not-use@swldwa.uk> wrote:
>> On 31/01/2024 09:59, Anton Ertl wrote:
>>> minforth@gmx.net (minforth) writes:
>>>>>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>>>>>> : days/month 15662003 swap 1- 2* rshift 3 and 28 or ;
>>> ...
>>>> Even my dumb compiler (TOS cached) already translates this to:
>>> ...
>>>> 0000000000406242 <mf_DAYSslashMONTH>:
>>>> 406242: 4c 89 e0 mov %r12,%rax
>>>> 406245: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
>>>> 40624b: 48 8d 44 00 fe lea -0x2(%rax,%rax,1),%rax
>>>> 406250: 49 89 c4 mov %rax,%r12
>>>> 406253: 41 bc b3 fb ee 00 mov $0xeefbb3,%r12d
>>>> 406259: c4 42 fb f7 e4 shrx %rax,%r12,%r12
>>>> 40625e: 4d 89 27 mov %r12,(%r15)
>>>> 406261: 41 bc 03 00 00 00 mov $0x3,%r12d
>>>> 406267: 49 8b 07 mov (%r15),%rax
>>>> 40626a: 83 e0 03 and $0x3,%eax
>>>> 40626d: 49 89 07 mov %rax,(%r15)
>>>> 406270: 41 bc 1c 00 00 00 mov $0x1c,%r12d
>>>> 406276: 49 89 c4 mov %rax,%r12
>>>> 406279: 49 83 cc 1c or $0x1c,%r12
>>>> 40627d: c3 retq
>>>
>>> Yes, this is a case (straight-line code) where existing Forth systems
>>> do well. Let's see:
>>>
>>> gforth-fast (development):
>>> $7FA5FDC99158 lit 1->2
>>> $7FA5FDC99160 #15662003
>>> 7FA5FD93F812: mov r15,$08[rbx]
>>> $7FA5FDC99168 swap 2->1
>>> 7FA5FD93F816: mov $00[r13],r15
>>> 7FA5FD93F81A: sub r13,$08
>>> $7FA5FDC99170 1- 1->1
>>> 7FA5FD93F81E: sub r8,$01
>>> $7FA5FDC99178 2* 1->1
>>> 7FA5FD93F822: add r8,r8
>>> $7FA5FDC99180 rshift 1->1
>>> 7FA5FD93F825: mov rax,$08[r13]
>>> 7FA5FD93F829: mov ecx,r8d
>>> 7FA5FD93F82C: add r13,$08
>>> 7FA5FD93F830: shr rax,CL
>>> 7FA5FD93F833: mov r8,rax
>>> $7FA5FDC99188 lit and 1->1
>>> $7FA5FDC99190 #3
>>> $7FA5FDC99198 and
>>> 7FA5FD93F836: add rbx,$48
>>> 7FA5FD93F83A: and r8,-$10[rbx]
>>> $7FA5FDC991A0 lit 1->2
>>> $7FA5FDC991A8 #28
>>> 7FA5FD93F83E: mov r15,$08[rbx]
>>> $7FA5FDC991B0 or 2->1
>>> 7FA5FD93F842: or r8,r15
>>> $7FA5FDC991B8 ;s 1->1
>>> 7FA5FD93F845: mov rbx,[r14]
>>> 7FA5FD93F848: add r14,$08
>>> 7FA5FD93F84C: mov rax,[rbx]
>>> 7FA5FD93F84F: jmp eax
>>>
>>> iforth lxf SwiftForth x64 vfx64
>>> pop rbx dec ebx -8 [RBP] RBP LEA DEC RBX
>>> lea rbx, [rbx -1 +] shl ebx, 1h EEFBB3 # 0 [RBP] MOV SHL RBX, #1
>>> lea rbx, [rbx*2 0 +] mov eax, #EEFBB3h RBX DEC MOV RCX, RBX
>>> mov rcx, rbx mov ecx, ebx RBX SHL MOV EBX, #00EEFBB3
>>> mov rbx, $00EEFBB3 d# shr eax, cl RBX RCX MOV SHR RBX, CL
>>> shr rbx, cl and eax, #3h 0 [RBP] RBX MOV AND RBX, #03
>>> and rbx, 3 b# or eax, #1Ch 8 [RBP] RBP LEA OR RBX, #1C
>>> or rbx, #28 b# mov ebx, eax RBX CL SHR RET/NEXT
>>> push rbx ret near 3 # RBX AND
>>> ; 1C # RBX OR
>>> RET
>>>
>>> - anton
>>>
>>
>> How does this simple lookup solution compare?
>>
>> : d/m s\" 0\x1f\x1c\x1f\x1e\x1f\x1e\x1f\x1f\x1e\x1f\x1e\x1f" drop + c@ ;
>> : x 13 1 do i d/m . loop ;
>> x 31 28 31 30 31 30 31 31 30 31 30 31 ok
>
> Four year period is better:
> 2 : | OVER , + ; : 5m 31 | 30 | 31 | 30 | 31 | ;
> 3 DATA TABLE ( start of month within leap period) -1
> 4 31 | 28 | 5m 5m 31 | 28 | 5m 5m 31 | 29 | 5m 5m
> 5 31 | 28 | 5m 5m , : T[] CELLS TABLE + @ ;
>
>>

A leap year shouldn't be difficult to handle, a typical algorithm is

: leap-year? ( y -- 0 | 1 ) \ Returns 1 for a leap year, otherwise 0
dup 3 and if 0= exit then \ Return 0 if not divisible by 4
dup 400 mod 0= if drop 1 exit then
100 mod if 1 exit then
0
;p

and use it with:

\ days/month ignores leap years
: days/month ( month -- days )
s\" 0\x1f\x1c\x1f\x1e\x1f\x1e\x1f\x1f\x1e\x1f\x1e\x1f"
drop + c@
;

: days-in-month ( year month -- n )
days/month dup 28 > if nip exit then \ Exit if not February
swap leap-year? +
;

That definition of leap year is a bit slow with the MODs and can be
better, particularly if the range of years is restricted. For example
if the range is restricted to 1901 to 2099, LEAP-YEAR? can be defined as
: leap-year? ( year -- 0 | 1) 3 and 0= negate ;
as the year 2000 was a leap year

If only a few non-leap year century dates like 1900 are in the range,
they can be tested for specifically.

If a wider range is needed a bit vector can be used. In a 64 bit Forth,
500 years would take only 8 cells.

A completely general solution isn't feasible as the year in which
various countries adopted the Gregorian calendar varies from the 16th
century to the 20th century so days per month varies by country e.g. in
the UK September 1752 had only 19 days.

--
Gerry

In article <upeigu$1n4af$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
<SNIP>
>Perhaps not, but for me it does. Let's talk about expectations since
>we all have them.
>
>A non-Forth programmer acquaintance said he thought it (Forth) wasn't
>a HLL at all - more like assembler (and he was well-versed in asm).
>Apparently even asm coders have expectations and straying too far
>doesn't go down well. Hence prefix assemblers in forth, $ prefix
>to denote a hex number, recognizers etc. When Mitch Bradley suggested
>parsers h# f# for hex and float respectively one could hear the
>proverbial pin drop. Personally I'd wear it in a forth environment but
>finding another so-inclined would be difficult. Harder still would be
>finding an app end-user that tolerated Albert's approach to command-line
>parsing. Giving end-users what they expect is the best policy. They
>don't care what language the app was written in or in making things easy
>for the programmer.
>

Seriously, what Mitch and I are doing is close to classical Forth.
I don't change any thing about parsing. I just introduce A PREFIX flag
that allows matching a dictionary entry if it is merely a prefix of
another word. The result is that `` H# 0A '' can be collated to
`` H#0A ''. The world has not noticed yet that it amounts to a netto
simplification of the Forth systems.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

On 5/02/2024 10:15 pm, albert@spenarnc.xs4all.nl wrote:
> In article <upeigu$1n4af$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
> <SNIP>
>> Perhaps not, but for me it does. Let's talk about expectations since
>> we all have them.
>>
>> A non-Forth programmer acquaintance said he thought it (Forth) wasn't
>> a HLL at all - more like assembler (and he was well-versed in asm).
>> Apparently even asm coders have expectations and straying too far
>> doesn't go down well. Hence prefix assemblers in forth, $ prefix
>> to denote a hex number, recognizers etc. When Mitch Bradley suggested
>> parsers h# f# for hex and float respectively one could hear the
>> proverbial pin drop. Personally I'd wear it in a forth environment but
>> finding another so-inclined would be difficult. Harder still would be
>> finding an app end-user that tolerated Albert's approach to command-line
>> parsing. Giving end-users what they expect is the best policy. They
>> don't care what language the app was written in or in making things easy
>> for the programmer.
>>
>
> Seriously, what Mitch and I are doing is close to classical Forth.
> I don't change any thing about parsing. I just introduce A PREFIX flag
> that allows matching a dictionary entry if it is merely a prefix of
> another word. The result is that `` H# 0A '' can be collated to
> `` H#0A ''. The world has not noticed yet that it amounts to a netto
> simplification of the Forth systems.

Not that simple if the interpreter and headers need changing. At the
time of ANS many forths already supported floats and hex in the form
we know. Changing that would require a strong argument. In practice
200x only added quoted characters. The latter being redundant it was
looks over substance.

In article <uptlcd$u5lq$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>On 5/02/2024 10:15 pm, albert@spenarnc.xs4all.nl wrote:
<SNIP>
>> Seriously, what Mitch and I are doing is close to classical Forth.
>> I don't change any thing about parsing. I just introduce A PREFIX flag
>> that allows matching a dictionary entry if it is merely a prefix of
>> another word. The result is that `` H# 0A '' can be collated to
>> `` H#0A ''. The world has not noticed yet that it amounts to a netto
>> simplification of the Forth systems.
>
>Not that simple if the interpreter and headers need changing. At the
>time of ANS many forths already supported floats and hex in the form
>we know. Changing that would require a strong argument. In practice
>200x only added quoted characters. The latter being redundant it was
>looks over substance.
>

That argument backfires. ciforth contains no floating point.
Without changing "the interpreter and headers", I can add floating
point, *including* the denotations for floating point literals.
I repeat:
"
The world has not noticed yet that it amounts to a netto
simplification of the Forth systems.
"

The hex additions by $ triggered me to make this invention in the first
place. I was confronted by loads of Marcel Hendrix programs freely using
$ hex constants. There was no way I'd tolerate this pollution of the
kernel forth. So I made it a loadable extension.
Maybe we come to our senses and adopt 0x for the hex prefix, such as
used in Win32Forth. In ciforth this means change in one line in a
loadable screen:
"
: $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
PREFIX IMMEDIATE
"
The change is $ --> 0x .

People that would rather not be bothered by prefixes either way,
can ignore the subject. They can keep PREFIX in the back of their mind
in case they need it. No $1 , no 0x1 .
A library sits there, and is invisible.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Out of curiosity: How do we postpone `` H# 0A '' ?

-marcel

mhx@iae.nl (mhx) writes:
>Out of curiosity: How do we postpone `` H# 0A '' ?

h# 0a postpone literal

Apart from the H# this is the Forth-94 and -2012 way to postpone an
integer number.

Let's see which systems already support

: foo postpone $0a ; immediate
: bar foo ;
bar .

Gforth-0.7.3: undefined word (at the $0a)
Gforth development: bar prints 10 (as intended)
iforth (5.1-mini): $0a ?
SwiftForth x64: $0a ?
VFX 64: bar prints 10 (as intended)

Yes, I don't have the latest versions of all systems installed, let me
know if your system has learned new tricks in the meantime.

Anyway, for the fans of H#, how do you write the equivalent of
"postpone $0a" (as supported by development Gforth and VFX 64)? And
why is your equivalent better IYO?

- 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

In article <0c5c6838a692f81cab2239d84212245a@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:
>Out of curiosity: How do we postpone `` H# 0A '' ?

That is the reason you don't us that type of prefixes, and
that you avoid postponing arbitrary parsing expressions.

In my book H#0A is a number and behaves the same in interpreter and
compilation mode. Same a 1.03E-10 .

>
>-marcel
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

On 8/02/2024 5:39 am, Anton Ertl wrote:
> mhx@iae.nl (mhx) writes:
>> Out of curiosity: How do we postpone `` H# 0A '' ?
>
> h# 0a postpone literal
>
> Apart from the H# this is the Forth-94 and -2012 way to postpone an
> integer number.
>
> Let's see which systems already support
>
> : foo postpone $0a ; immediate
> : bar foo ;
> bar .
>
> Gforth-0.7.3: undefined word (at the $0a)
> Gforth development: bar prints 10 (as intended)
> iforth (5.1-mini): $0a ?
> SwiftForth x64: $0a ?
> VFX 64: bar prints 10 (as intended)
>
> Yes, I don't have the latest versions of all systems installed, let me
> know if your system has learned new tricks in the meantime.
>
> Anyway, for the fans of H#, how do you write the equivalent of
> "postpone $0a" (as supported by development Gforth and VFX 64)? And
> why is your equivalent better IYO?

The only system I'm aware actively using H# et al is Bradley's. It's
possible he has no use for what you ask in which case why support it?
Certainly no Forth standard has deemed it necessary and systems that
support it appear to be in the minority. If you wish you may add
DX-Forth to the list.

albert@spenarnc.xs4all.nl wrote:

> In article <0c5c6838a692f81cab2239d84212245a@www.novabbs.com>,
> mhx <mhx@iae.nl> wrote:
>>Out of curiosity: How do we postpone `` H# 0A '' ?

> That is the reason you don't us that type of prefixes, and
> that you avoid postponing arbitrary parsing expressions.

Yes. Say I want to postpone a number and store it in a rewritten
colon definition. Not only do I have to parse the parsing
expression `` H# 0A '' in the original, I have to store it
in the rewritten definition as `` H# 0A '' again, because
it is too dangerous to say `` 0A '' or `` 10 '' and
of course I can't use `` $0A '' or `` #10 '', much less
`` H#0A '' :--)

-marcel

On 8/02/2024 1:10 am, albert@spenarnc.xs4all.nl wrote:
> In article <uptlcd$u5lq$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>> On 5/02/2024 10:15 pm, albert@spenarnc.xs4all.nl wrote:
> <SNIP>
>>> Seriously, what Mitch and I are doing is close to classical Forth.
>>> I don't change any thing about parsing. I just introduce A PREFIX flag
>>> that allows matching a dictionary entry if it is merely a prefix of
>>> another word. The result is that `` H# 0A '' can be collated to
>>> `` H#0A ''. The world has not noticed yet that it amounts to a netto
>>> simplification of the Forth systems.
>>
>> Not that simple if the interpreter and headers need changing. At the
>> time of ANS many forths already supported floats and hex in the form
>> we know. Changing that would require a strong argument. In practice
>> 200x only added quoted characters. The latter being redundant it was
>> looks over substance.
>>
>
> That argument backfires. ciforth contains no floating point.
> Without changing "the interpreter and headers", I can add floating
> point, *including* the denotations for floating point literals.
> I repeat:
> "
> The world has not noticed yet that it amounts to a netto
> simplification of the Forth systems.
> "

What is simple about H#0A ? H# 0A is simple because it requires no
system changes. But it also contradicts the notion forth understands
numbers. If it's ok for forth to differentiate doubles from singles,
why not floats, hex etc.

dxf wrote:
[..]
> What is simple about H#0A ? H# 0A is simple because it requires no
> system changes. But it also contradicts the notion forth understands
> numbers. If it's ok for forth to differentiate doubles from singles,
> why not floats, hex etc.

IMHO there isn't anything wrong with a standard conforming system
that has an humpty-dumpty facility to redefine or define words that
recognize `` H#0A '' for what I want it to mean.

In fact, I *expect* to be able to modify any Forth to do exactly
what I want. The `problems` with that start when I want to use
my new features in a Standard Program, or when I want to use a
Forth that has non-standard facilities that clash with my own
vision on how they should behave.

The easy way out is to wait for a standard Forth that is dumb
as a brick (no problem) but generates Vfx performance-quality code,
with a library that extends it to (e.g.) Gforth that can target
anything from standard phones to super computers.

-marcel

On Wednesday, February 7, 2024 at 6:50:52 PM UTC+1, mhx wrote:
> Out of curiosity: How do we postpone `` H# 0A '' ?
>
> -marcel
I'd say: don't over complicate it:

hex
0A constant #0A
decimal

Solved.. Worst case scenario: you have to define 256 constants. But how often does THAT happen?

Hans Bezemer

On 8/02/2024 7:16 pm, mhx wrote:
> dxf wrote:
> [..]
>> What is simple about H#0A ?  H# 0A  is simple because it requires no
>> system changes.  But it also contradicts the notion forth understands
>> numbers.  If it's ok for forth to differentiate doubles from singles,
>> why not floats, hex etc.
>
> IMHO there isn't anything wrong with a standard conforming system
> that has an humpty-dumpty facility to redefine or define words that recognize `` H#0A '' for what I want it to mean.

How many compiler/languages support this? AFAIK if an application required
an interpreter, the programmer wrote one. That has to be better than
shoe-horning forth's interpreter to do it.

"I don't like the idea of a Forth, old or new, that does everything." - Moore

In article <18c959289e22ab302d9fd37aa0d85b1d@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:
>albert@spenarnc.xs4all.nl wrote:
>
>> In article <0c5c6838a692f81cab2239d84212245a@www.novabbs.com>,
>> mhx <mhx@iae.nl> wrote:
>>>Out of curiosity: How do we postpone `` H# 0A '' ?
>
>> That is the reason you don't us that type of prefixes, and
>> that you avoid postponing arbitrary parsing expressions.
>
>Yes. Say I want to postpone a number and store it in a rewritten
>colon definition. Not only do I have to parse the parsing
>expression `` H# 0A '' in the original, I have to store it
>in the rewritten definition as `` H# 0A '' again, because
>it is too dangerous to say `` 0A '' or `` 10 '' and
>of course I can't use `` $0A '' or `` #10 '', much less
>`` H#0A '' :--)

It hurts. Don't do that.

>
>-marcel
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

In article <uq1g1t$1ln91$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>On 8/02/2024 1:10 am, albert@spenarnc.xs4all.nl wrote:

>What is simple about H#0A ? H# 0A is simple because it requires no
>system changes. But it also contradicts the notion forth understands
>numbers. If it's ok for forth to differentiate doubles from singles,
>why not floats, hex etc.

Forth must not ony understand numbers, but all literals that come
with an application program. Used definable prefixes is ideal
for that. This contradicts nothing.
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Flexibilty is the inportant advantage. Prefixes may simplify parsing;
iow if it helps it helps, not much to discuss there.

E.g. parsing csv tables does not need prefixes, but Forth's flexibility
and compactness helps a lot.

On 8/02/2024 10:43 pm, albert@spenarnc.xs4all.nl wrote:
> In article <uq1g1t$1ln91$1@dont-email.me>, dxf <dxforth@gmail.com> wrote:
>> On 8/02/2024 1:10 am, albert@spenarnc.xs4all.nl wrote:
>
>> What is simple about H#0A ? H# 0A is simple because it requires no
>> system changes. But it also contradicts the notion forth understands
>> numbers. If it's ok for forth to differentiate doubles from singles,
>> why not floats, hex etc.
>
> Forth must not ony understand numbers, but all literals that come
> with an application program.

Why - what other language compiler does?

> Used definable prefixes is ideal
> for that. This contradicts nothing.

Simply saying 'I can make my compiler do that' is no reason in itself.
ISTM if it were very important end-applications carry an extensible
compiler around with them, the world - not to mention forth target
compilers - would be following the lead.

25 years ago Jeff Fox predicted:

"I see ANSI Forth [...] can become one more failed attempt to find
the ideal portable scripting language."

It was uncannily accurate.

dxf <dxforth@gmail.com> writes:
>> IMHO there isn't anything wrong with a standard conforming system
>> that has an humpty-dumpty facility to redefine or define words that recognize `` H#0A '' for what I want it to mean.
>
>How many compiler/languages support this?

Most Forth systems support extending the text interpreter.

Concerning other languages: I expect that Lisp and Prolog systems have
such capabilities.

>AFAIK if an application required
>an interpreter, the programmer wrote one. That has to be better than
>shoe-horning forth's interpreter to do it.

Why do you think so?

Greenspun's tenth rule is:

|Any sufficiently complicated C or Fortran program contains an ad hoc,
|informally-specified, bug-ridden, slow implementation of half of
|Common Lisp.

So, yes indeed, any sufficiently complicated application requires an
interpreter, and C and Fortran programmers write one. And the result
is bug-ridden and slow. Does not sound better to me.

>"I don't like the idea of a Forth, old or new, that does everything." - Moore

That's why we have Forth systems that are extensible.

- 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

On 10/02/2024 3:12 am, Anton Ertl wrote:
> ...
> Greenspun's tenth rule is:
>
> |Any sufficiently complicated C or Fortran program contains an ad hoc,
> |informally-specified, bug-ridden, slow implementation of half of
> |Common Lisp.
>
> So, yes indeed, any sufficiently complicated application requires an
> interpreter, and C and Fortran programmers write one. And the result
> is bug-ridden and slow. Does not sound better to me.
>
>> "I don't like the idea of a Forth, old or new, that does everything." - Moore
>
> That's why we have Forth systems that are extensible.

You may - but does Moore? IIRC he said Forth should be small enough that
it can be thrown away. The only reason I see for doing that is when it's
no longer fit for purpose. This, of course, contrasts with an industry
that promotes the compiler. ISTM application code written with primitives
is going be simpler and more easily altered when the time comes than code
hooked to, and reliant upon, on a specific compiler. I certainly don't
want to make my complier any more complicated than it is. I'm kind of
glad I'm at the point where I can forget about how it works (or ought to
work).

On 10/02/2024 3:12 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>>> IMHO there isn't anything wrong with a standard conforming system
>>> that has an humpty-dumpty facility to redefine or define words that recognize `` H#0A '' for what I want it to mean.
>>
>> How many compiler/languages support this?
>
> Most Forth systems support extending the text interpreter.
>
> Concerning other languages: I expect that Lisp and Prolog systems have
> such capabilities.
>
>> AFAIK if an application required
>> an interpreter, the programmer wrote one. That has to be better than
>> shoe-horning forth's interpreter to do it.
>
> Why do you think so?

Because it's almost always not what you wanted. Using CATCH to stop the
interpreter aborting is a workaround. Feeding CREATE to EXECUTE-PARSING
is a workaround. Much easier to write the function you want it than to
retrofit an existing one. When complaints were made to ANS that OF was
inadequate, the response was the user can always contrive something that
OF will swallow.