Sujet : Re: Juggling system-compilation items
De : krishna.myneni (at) *nospam* ccreweb.org (Krishna Myneni)
Groupes : comp.lang.forthDate : 12. Aug 2024, 13:09:36
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v9cu20$39h63$1@dont-email.me>
References : 1 2
User-Agent : Mozilla Thunderbird
On 8/11/24 17: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.
Agreed. Placing control stack items on the data stack shouldn't be necessary now. I favor standardization of a separate control stack. Indeed, in kForth it is possible to define const simply as
: const : postpone literal postpone ; ;
No return stack juggling needed because ":" does not introduce anything onto the data stack. Balancing of control structures are verified.
This is quite useful when passing args to colon defs as well as to quotations.
My test of Ruvim's code simply validated the portable version for the current standard.
-- Krishna