Re: Juggling system-compilation items

On 12/08/2024 10:00, Ruvim wrote:

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

Yes that would be the case, a separate control stack with existing associated words CS-PICK CS-ROLL and CS-DROP (because it has been needed). There is still a need for user defined control structures.

 

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

I doubt that a change like a mandated separate control stack would be accepted as too much existing code would be broken. A possible step in that direction could be:
- have the default position to be as it is a present i.e. the control stack to use the data stack or not. Label this as obsolescent
- provision of a word to define the memory region to be used for the control stack, such a word would have the stack effect ( ad u -- ) where u is a maximum number of sys type items e.g. orig etc. That would enable a user to ALLOT or ALLOCATE the memory.
In another discussion I advanced the opinion that transient memory areas such as PAD and other buffers were also an anachronism due to early systems being memory limited. ISTM that a similar solution to making those permanent could be applied to those e.g.
- have the default position as it is at present i.e. transient or not, marked as obsolescent
- provide words to define the memory region to be used for the currently   transient regions. That could enable <# buffers to be nested, multiple PADs.
--
Gerry