Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #134751 > unrolled thread

Re: kForth-32 v 2.7.0

Back to article view | Back to comp.lang.forth

Contents

  Re: kForth-32 v 2.7.0 thresh3@fastmail.com (Lev) - 2026-03-20 03:15 +0000
    Re: kForth-32 v 2.7.0 Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-20 06:50 -0500
      Re: kForth-32 v 2.7.0 Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-20 09:19 -0500
      Re: kForth-32 v 2.7.0 dxf <dxforth@gmail.com> - 2026-03-21 13:22 +1100
        Re: kForth-32 v 2.7.0 Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-20 22:34 -0500
        Re: kForth-32 v 2.7.0 albert@spenarnc.xs4all.nl - 2026-03-21 09:22 +0100

#134751 — Re: kForth-32 v 2.7.0

Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

> Yes, I thing factoring the interpreter/compiler in this manner
> added useful factors which are available to the user.

The base prefix support is a good example of the recognizer paying
for itself early.  Before factoring, adding $FF or 0xFF recognition
means editing INTERPRET directly.  After, you drop in a recognizer
and the interpreter does not know or care.

> In the case of kForth, I had to support a non-standard feature of
> deferred execution in State 0.

Can you give a short example of deferred execution in State 0?

> --  use user-defined recognizers and recognizer sequences
> --  substitute the interpreter with a user-defined interpreter

So you could build a recognizer that handles embedded DSLs without
touching the core.  Closer to Lisp reader macros than anything I
have seen in Forth.

> This is a legacy feature of kForth-32 which has been around
> since 1998.  At that time, I needed a replacement for LMI
> UR/Forth

The [IF] conditional approach for sharing source between
kForth-32 and kForth-64 is pragmatic.  Most people would
have just forked the codebase.

[toc] | [next] | [standalone]

#134757

On 3/19/26 22:15, Lev wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
> 
>> Yes, I thing factoring the interpreter/compiler in this manner
>> added useful factors which are available to the user.
> 
> The base prefix support is a good example of the recognizer paying
> for itself early.  Before factoring, adding $FF or 0xFF recognition
> means editing INTERPRET directly.  After, you drop in a recognizer
> and the interpreter does not know or care.
> 

A funny thing about implementing the translators is that my initial idea 
was to use a string expression for a :NONAME expression and pass it to 
EVALUATE to obtain the xt for the translator in a given State. This did 
not work at all, and it became immediately obvious why, because EVALUATE 
calls INTERPRET which doesn't work until the translators exist! So, 
bootstrapping the translators (by directly generating bytecode 
arrays/vectors e.g. compiling Forth by hand) was essential to making it 
work.

>> In the case of kForth, I had to support a non-standard feature of
>> deferred execution in State 0.
> 
> Can you give a short example of deferred execution in State 0?
> 
1 100 0 do i dup rot +loop drop
  ok
.s

		89
		55
		34
		21
		13
		8
		5
		3
		2
		1
		1
		0
  ok

Expressions with other control structures may also be entered directly 
at the interpreter, with defining a named word or :noname . The are 
limitations, however -- these are discussed in the User's Manual.


>> --  use user-defined recognizers and recognizer sequences
>> --  substitute the interpreter with a user-defined interpreter
> 
> So you could build a recognizer that handles embedded DSLs without
> touching the core.  Closer to Lisp reader macros than anything I
> have seen in Forth.
> 

Yes, multi-language coding e.g. mixing sections of Lisp and Fortran code 
into a Forth program, *when it makes sense to do so.*

>> This is a legacy feature of kForth-32 which has been around
>> since 1998.  At that time, I needed a replacement for LMI
>> UR/Forth
> 
> The [IF] conditional approach for sharing source between
> kForth-32 and kForth-64 is pragmatic.  Most people would
> have just forked the codebase.

The conditional is used sparingly, only for reasons of efficiency. I 
don't want to maintain different versions of Forth libraries or programs 
just because of integrated stack vs separate stack.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#134759

On 3/20/26 06:50, Krishna Myneni wrote:
> On 3/19/26 22:15, Lev wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
...
>>> In the case of kForth, I had to support a non-standard feature of
>>> deferred execution in State 0.
>>
>> Can you give a short example of deferred execution in State 0?
>>
> 1 100 0 do i dup rot +loop drop
>   ok
> .s
> 
>          89
>          55
>          34
>          21
>          13
>          8
>          5
>          3
>          2
>          1
>          1
>          0
>   ok
> 
> Expressions with other control structures may also be entered directly 
> at the interpreter, with defining a named word or :noname . ...

Edit: should be "... without defining a named word or :noname ."

--
KM

[toc] | [prev] | [next] | [standalone]

#134760

On 20/03/2026 10:50 pm, Krishna Myneni wrote:
> ... 
> The conditional is used sparingly, only for reasons of efficiency. I don't want to maintain different versions of Forth libraries or programs just because of integrated stack vs separate stack.

Coding for integrated stack always works but presumably you no longer have an incentive?

[toc] | [prev] | [next] | [standalone]

#134761

On 3/20/26 21:22, dxf wrote:
> On 20/03/2026 10:50 pm, Krishna Myneni wrote:
>> ...
>> The conditional is used sparingly, only for reasons of efficiency. I don't want to maintain different versions of Forth libraries or programs just because of integrated stack vs separate stack.
> 
> Coding for integrated stack always works but presumably you no longer have an incentive?
> 

The 2.x version of kForth-32 (integrated stack version) will continue to 
be maintained.

Any floating point code I write for separate fp stack versions of kForth 
e.g. kForth-64, can easily be made to run under the integrated stack 
version.

Currently kForth-Win32 2.x (also integrated stack) has been lagging in 
maintenance and updates. I no longer have access to a Windows machine 
for testing, but I can continue to maintain it under Linux with Wine.

--
Krishna

[toc] | [prev] | [next] | [standalone]

#134762

In article <69be0100@news.ausics.net>, dxf  <dxforth@gmail.com> wrote:
>On 20/03/2026 10:50 pm, Krishna Myneni wrote:
>> ...
>> The conditional is used sparingly, only for reasons of efficiency. I don't want to maintain different versions of Forth libraries or programs just because of integrated stack vs separate stack.
>
>Coding for integrated stack always works but presumably you no longer have an incentive?
>

I use m4 to use condional inclusion. I have 19 configurations for i86,
with at least 4 currently maintained.

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web