Re: Juggling system-compilation items

On 2024-08-12 02:26, Gerry Jackson wrote:

On 09/08/2024 15:05, Ruvim wrote:

Do you know a Forth system in which the following definition for "const" is compiled but does not work as expected?
>
>
: const ( x "<spaces>name" -- )
   depth >r          ( x )                   ( R: n.depth )
   :                 ( x colon-sys )         ( R: n.depth )
   depth r> -        ( x colon-sys n.size )  ( R: )
   n>r               ( x )                   ( R: i*x n.size )
   postpone literal  (   )                   ( R: i*x n.size )
   nr>               ( colon-sys n.size )    ( R: )
   drop              ( colon-sys )
   postpone ;        (   )
;
>
>
t{ 123 const foo -> }t
t{ foo -> 3 }t
>
>
Note 3.1.5.1 System-compilation types <https://forth-standard.org/ standard/usage#subsubsection.3.1.5.1>
>
>

 ISTM that using the data stack to hold the control stack is an anachronism that was used in early Forth systems because of the limited amount of memory available. I also think that the system should not get in the way of user programs as putting control stack data on the data stack certainly does.

This is a more restrictive requirement to the systems, than a requirement to be independent of the data stack depth.
This requirement can be reasonable. But a problem is that user-defined control-flow and alike structures will leave their intermediate data on the data stack anyway (unless they are implemented as parsing words, or using a user-defined control-flow stack).
Therefore, if the standard will require the control-flow stack be separate, it should probably provide programs access to this stack (to save intermediate data in compile time).

 Therefore I developed my system (for desktop systems only) with a separate control flow stack. It doesn't stop checking for unbalanced stack errors. As it is only used when compiling speed isn't important it can be a linked list implementation discarded at runtime. It allows data to be passed into or out of colon definitions or other control structures without considering the control stack unless you are trying to write portable software.
 So in your definition above the use of DEPTH, N>R etc is unnecessary as
   DEPTH >R : DEPTH R> -
returns 0 for my system. CONST works.
 

It's possible to implement a library that defines a separate control-flow stack and redefines all the standard words to use this stack.
It can make sense only if control-flow checking is data stack depth independent in the Forth system.
--
Ruvim