Re: Juggling system-compilation items

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.
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.
--
Gerry