I've found an essentially no-cost way of implementing it.
Other than the novelty of being able to write ]] 123 [[
what are the reasons/examples for having it?

On Tuesday, April 27, 2021 at 5:03:24 PM UTC-7, dxforth wrote:
> I've found an essentially no-cost way of implementing it.
> Other than the novelty of being able to write ]] 123 [[
> what are the reasons/examples for having it?

My MACRO: and POST: have worked with literals for quite some time.
This is a comment from my code:
\ POST: LIT: DLIT: FLIT: "LIT: are used inside of immediate words that meta-compile.
\ This is similar to ]] but a lot better because it supports literals
\ and immediate words such as [CHAR] POSTPONE etc. that take data out of the input stream.

Why are you interested in Anton Ertl's ]] construct?
It is worthless from a technical standpoint. It was invented primarily as a workaround
for Anton Ertl's lack of disambiguifiers that Elizabeth Rather forbids him from using.
Anybody who uses ]] is just brown-nosing Anton Ertl who is brown-nosing
Elizabeth Rather --- an example of: "meta-brown-nosing" --- this is a pun, because my
MACRO: and POST: are used for meta-compiling (I explain this in case
any of the ANS-Forth cult didn't get the pun).

Note that my MACRO: and POST: are ANS-Forth code.
Your as-yet-undescribed way to POSTPONE literals is not going to be ANS-Forth.
Because of this, the ANS-Forth cult will not be interested in it.

I really doubt that anybody in the ANS-Forth cult understand meta-compiling.

On 28/04/2021 13:43, Hugh Aguilar wrote:
> On Tuesday, April 27, 2021 at 5:03:24 PM UTC-7, dxforth wrote:
>> I've found an essentially no-cost way of implementing it.
>> Other than the novelty of being able to write ]] 123 [[
>> what are the reasons/examples for having it?
>
> My MACRO: and POST: have worked with literals for quite some time.
> This is a comment from my code:
> \ POST: LIT: DLIT: FLIT: "LIT: are used inside of immediate words that meta-compile.
> \ This is similar to ]] but a lot better because it supports literals
> \ and immediate words such as [CHAR] POSTPONE etc. that take data out of the input stream.
>
> Why are you interested in Anton Ertl's ]] construct?
> It is worthless from a technical standpoint. It was invented primarily as a workaround
> for Anton Ertl's lack of disambiguifiers that Elizabeth Rather forbids him from using.
> Anybody who uses ]] is just brown-nosing Anton Ertl who is brown-nosing
> Elizabeth Rather --- an example of: "meta-brown-nosing" --- this is a pun, because my
> MACRO: and POST: are used for meta-compiling (I explain this in case
> any of the ANS-Forth cult didn't get the pun).
>
> Note that my MACRO: and POST: are ANS-Forth code.
> Your as-yet-undescribed way to POSTPONE literals is not going to be ANS-Forth.
> Because of this, the ANS-Forth cult will not be interested in it.

It may interest forth implementers that provide POSTPONE. ISTM an
oversight that POSTPONE shouldn't handle both 'words and numbers'
directly when any forth interpreter can.

A fig-style interpreter looks something like:

: interpret ( -- )
begin
bl word dup c@
while
find ?dup if
state @ if compile, else execute then
else
( c-addr) number
then ?stack
repeat drop ;

Given 'number', we can define:

: POSTPONE
?comp bl word find ?dup if
0< if compile compile then compile,
end number ; immediate

Such a POSTPONE will handle any literal that 'number' can.

\ Simple POSTPONE macro
: ]]
begin >in @ bl word count ?dup
while s" [[" compare
while >in ! [compile] postpone
repeat drop end 2drop ; immediate

> I really doubt that anybody in the ANS-Forth cult understand meta-compiling.
>

dxforth <dxforth@gmail.com> writes:
>It may interest forth implementers that provide POSTPONE. ISTM an
>oversight that POSTPONE shouldn't handle both 'words and numbers'
>directly when any forth interpreter can.

My guess ist that POSTPONE was not specified to handle numbers because
neither [COMPILE] nor COMPILE could handle numbers, and programmers
could work around the lack of POSTPONE 123 with 123 POSTPONE LITERAL.

>A fig-style interpreter looks something like:
>
>: interpret ( -- )
> begin
> bl word dup c@
> while
> find ?dup if
> state @ if compile, else execute then
> else
> ( c-addr) number
> then ?stack
> repeat drop ;
>
>Given 'number', we can define:
>
>: POSTPONE
> ?comp bl word find ?dup if
> 0< if compile compile then compile,
> end number ; immediate

This NUMBER is pretty "smart", leaving the number on the stack in
interpret state, performing the compilation semantics of LITERAL or
2LITERAL in compile state, and also knowing that one more level of
LITERAL or 2LITERAL is needed when it's called from POSTPONE.

I guess complications like that also discouraged the Forth-94
committee from standardizing POSTPONEing numbers.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 28/04/2021 16:29, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>It may interest forth implementers that provide POSTPONE. ISTM an
>>oversight that POSTPONE shouldn't handle both 'words and numbers'
>>directly when any forth interpreter can.
>
> My guess ist that POSTPONE was not specified to handle numbers because
> neither [COMPILE] nor COMPILE could handle numbers, and programmers
> could work around the lack of POSTPONE 123 with 123 POSTPONE LITERAL.
>
>>A fig-style interpreter looks something like:
>>
>>: interpret ( -- )
>> begin
>> bl word dup c@
>> while
>> find ?dup if
>> state @ if compile, else execute then
>> else
>> ( c-addr) number
>> then ?stack
>> repeat drop ;
>>
>>Given 'number', we can define:
>>
>>: POSTPONE
>> ?comp bl word find ?dup if
>> 0< if compile compile then compile,
>> end number ; immediate
>
> This NUMBER is pretty "smart", leaving the number on the stack in
> interpret state, performing the compilation semantics of LITERAL or
> 2LITERAL in compile state, and also knowing that one more level of
> LITERAL or 2LITERAL is needed when it's called from POSTPONE.

Not a problem since POSTPONE is required to postpone. The ?COMP
handles any attempt by a user to do otherwise.

>
> I guess complications like that also discouraged the Forth-94
> committee from standardizing POSTPONEing numbers.

If they considered it, surely they would have mentioned it. Their
'go to' reference was Hayes' Rochester Conference paper. Does anyone
have it? It would be interesting to know what it said.

>
> - anton
>

dxforth <dxforth@gmail.com> writes:
>On 28/04/2021 16:29, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>Given 'number', we can define:
>>>
>>>: POSTPONE
>>> ?comp bl word find ?dup if
>>> 0< if compile compile then compile,
>>> end number ; immediate
>>
>> This NUMBER is pretty "smart", leaving the number on the stack in
>> interpret state, performing the compilation semantics of LITERAL or
>> 2LITERAL in compile state, and also knowing that one more level of
>> LITERAL or 2LITERAL is needed when it's called from POSTPONE.
>
>Not a problem since POSTPONE is required to postpone.

How does that make NUMBER perform the extra LITERAL level?

Test case:

: foo postpone 123 ; immediate
: bar foo ;
bar . \ prints 123

>> I guess complications like that also discouraged the Forth-94
>> committee from standardizing POSTPONEing numbers.
>
>If they considered it, surely they would have mentioned it. Their
>'go to' reference was Hayes' Rochester Conference paper. Does anyone
>have it? It would be interesting to know what it said.

A number of Rochester Forth Conference Proceedings have appeared in
JFAR <http://soton.mpeforth.com/flag/jfar/index.html>. There are two
papers by Hayes listed in the author index:
<http://soton.mpeforth.com/flag/jfar/authors-H.html>, but they are
unlikely to be about POSTPONE.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 28/04/2021 17:37, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 28/04/2021 16:29, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>Given 'number', we can define:
>>>>
>>>>: POSTPONE
>>>> ?comp bl word find ?dup if
>>>> 0< if compile compile then compile,
>>>> end number ; immediate
>>>
>>> This NUMBER is pretty "smart", leaving the number on the stack in
>>> interpret state, performing the compilation semantics of LITERAL or
>>> 2LITERAL in compile state, and also knowing that one more level of
>>> LITERAL or 2LITERAL is needed when it's called from POSTPONE.
>>
>>Not a problem since POSTPONE is required to postpone.
>
> How does that make NUMBER perform the extra LITERAL level?
>
> Test case:
>
> : foo postpone 123 ; immediate
> : bar foo ;
> bar . \ prints 123
>

Omit immediate :)

POSTPONE 123 is akin to postponing an immediate word; it
will execute when later encountered, rather than compile.

123 POSTPONE LITERAL isn't postponing 123; it's postponing
LITERAL and 123 happens to be on the stack when it does.
IOW you're setting up a scenario to get a desired effect.

On 28/04/2021 19:02, dxforth wrote:
> On 28/04/2021 17:37, Anton Ertl wrote:
>>
>> How does that make NUMBER perform the extra LITERAL level?
>>
>> Test case:
>>
>> : foo postpone 123 ; immediate
>> : bar foo ;
>> bar . \ prints 123
>>
>
> Omit immediate :)
>
> POSTPONE 123 is akin to postponing an immediate word; it
> will execute when later encountered, rather than compile.

I'll have to concede this isn't useful. I had an example
but it turns out I had used a constant rather than a literal!

>
> 123 POSTPONE LITERAL isn't postponing 123; it's postponing
> LITERAL and 123 happens to be on the stack when it does.
> IOW you're setting up a scenario to get a desired effect.
>

On 2021-04-28 12:02, dxforth wrote:
> On 28/04/2021 17:37, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>> On 28/04/2021 16:29, Anton Ertl wrote:
>>>> dxforth <dxforth@gmail.com> writes:
>>>>> Given 'number', we can define:
>>>>>
>>>>> : POSTPONE
>>>>>   ?comp bl word find ?dup if
>>>>>     0< if compile compile then compile,
>>>>>   end  number ; immediate
>>>>
>>>> This NUMBER is pretty "smart", leaving the number on the stack in
>>>> interpret state, performing the compilation semantics of LITERAL or
>>>> 2LITERAL in compile state, and also knowing that one more level of
>>>> LITERAL or 2LITERAL is needed when it's called from POSTPONE.
>>>
>>> Not a problem since POSTPONE is required to postpone.
>>
>> How does that make NUMBER perform the extra LITERAL level?
>>
>> Test case:
>>
>> : foo postpone 123 ; immediate
>> : bar foo ;
>> bar . \ prints 123
>>
>
> Omit immediate :)
>
> POSTPONE 123 is akin to postponing an immediate word; it
> will execute when later encountered, rather than compile.

There is an approach that shows (or helps to understand) how POSTPONE
should work regardless of its argument kind.

: foo postpone 123 ; immediate

: bar foo ;

1. Substitute foo in bar by the body of bar in square brackets.
<==>
: bar [ postpone 123 ] ;

2. Suppose that interpretation semantics of POSTPONE X is to *perform*
compilation semantics of X. Remember that performing compilation
semantics of X is what the text interpreter does when it encounters X in
compilation state.
<==>
: bar 123 ;

Hence,

: bar foo ;

shall be equivalent to

: bar 123 ;

--
Ruvim

dxforth <dxforth@gmail.com> writes:
>On 28/04/2021 17:37, Anton Ertl wrote:
>> Test case:
>>
>> : foo postpone 123 ; immediate
>> : bar foo ;
>> bar . \ prints 123
>>
>
>Omit immediate :)
>
>POSTPONE 123 is akin to postponing an immediate word;

What would be the use of that? If we would want that, we could just
leave the POSTPONE away. Also, 123 does not behave like an immediate
word in normal compilation, so why would you want that POSTPONE 123
treats it as immediate? In normal text interpretation (interpret and
compile state), the number 123 behaves like

123 constant 123 \ no immediate

BTW, the example above works in the development version of Gforth, and
that's not a bug.

>123 POSTPONE LITERAL isn't postponing 123

If POSTPONE 123 does not work, I have to write 123 POSTPONE LITERAL,
and in Gforth the result after running the code is the same:

: foo1 postpone 123 ; immediate ok
: foo2 123 postpone literal ; immediate ok
: bar1 foo1 ; ok
: bar2 foo2 ; ok
simple-see bar1
$7F447B532DA0 lit
$7F447B532DA8 #123
$7F447B532DB0 ;s ok
simple-see bar2
$7F447B532DE0 lit
$7F447B532DE8 #123
$7F447B532DF0 ;s ok

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 28/04/2021 15:24, dxforth wrote:
> ...
> A fig-style interpreter looks something like:
>
> : interpret ( -- )
> begin
> bl word dup c@
> while
> find ?dup if
> state @ if compile, else execute then
> else
> ( c-addr) number
> then ?stack
> repeat drop ;
>
> Given 'number', we can define:
>
> : POSTPONE
> ?comp bl word find ?dup if
> 0< if compile compile then compile,
> end number ; immediate

That won't work per Anton's comment. POSTPONE needs to know the compiling
literal used by 'number'. Here are the tweaks:

0 value nlit \ xt of the literal used by NUMBER

: number ( c-addr -- | d|n|r )
...
2dup number? if
2nip dpl @ 0< if
drop ['] literal
else
['] 2literal
then to nlit true
else
fnumber \ defer for floats
then
...
( flag) ?defined \ 0 = fail & abort
state @ if nlit execute then ;

: POSTPONE
?comp bl word find ?dup if
0< if compile compile then
else number nlit then compile, ; immediate

\\ test

DX-Forth 4.45 2021-04-17

: foo postpone 123 : immediate LITERAL is system ok
: bar foo ; ok
bar . 123 ok
: foo2 postpone 123e : immediate FLITERAL is system ok
: bar2 foo2 ; ok
bar2 f. 123. ok

On 28/04/2021 21:09, Ruvim wrote:
> On 2021-04-28 12:02, dxforth wrote:
>> On 28/04/2021 17:37, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>> On 28/04/2021 16:29, Anton Ertl wrote:
>>>>> dxforth <dxforth@gmail.com> writes:
>>>>>> Given 'number', we can define:
>>>>>>
>>>>>> : POSTPONE
>>>>>>   ?comp bl word find ?dup if
>>>>>>     0< if compile compile then compile,
>>>>>>   end  number ; immediate
>>>>>
>>>>> This NUMBER is pretty "smart", leaving the number on the stack in
>>>>> interpret state, performing the compilation semantics of LITERAL or
>>>>> 2LITERAL in compile state, and also knowing that one more level of
>>>>> LITERAL or 2LITERAL is needed when it's called from POSTPONE.
>>>>
>>>> Not a problem since POSTPONE is required to postpone.
>>>
>>> How does that make NUMBER perform the extra LITERAL level?
>>>
>>> Test case:
>>>
>>> : foo postpone 123 ; immediate
>>> : bar foo ;
>>> bar . \ prints 123
>>>
>>
>> Omit immediate :)
>>
>> POSTPONE 123 is akin to postponing an immediate word; it
>> will execute when later encountered, rather than compile.
>
>
> There is an approach that shows (or helps to understand) how POSTPONE
> should work regardless of its argument kind.
>
>
> : foo postpone 123 ; immediate
>
> : bar foo ;
>
> 1. Substitute foo in bar by the body of bar in square brackets.
> <==>
> : bar [ postpone 123 ] ;

Result is ambiguous (POSTPONE inside brackets).

>
> 2. Suppose that interpretation semantics of POSTPONE X is to *perform*
> compilation semantics of X. Remember that performing compilation
> semantics of X is what the text interpreter does when it encounters X in
> compilation state.
> <==>
> : bar 123 ;
>
>
> Hence,
>
> : bar foo ;
>
> shall be equivalent to
>
> : bar 123 ;
>
>
> --
> Ruvim
>

On 2021-04-28 17:04, dxforth wrote:
> On 28/04/2021 21:09, Ruvim wrote:
>> On 2021-04-28 12:02, dxforth wrote:
>>> On 28/04/2021 17:37, Anton Ertl wrote:
>>>> dxforth <dxforth@gmail.com> writes:
>>>>> On 28/04/2021 16:29, Anton Ertl wrote:
>>>>>> dxforth <dxforth@gmail.com> writes:
>>>>>>> Given 'number', we can define:
>>>>>>>
>>>>>>> : POSTPONE
>>>>>>>   ?comp bl word find ?dup if
>>>>>>>     0< if compile compile then compile,
>>>>>>>   end  number ; immediate
>>>>>>
>>>>>> This NUMBER is pretty "smart", leaving the number on the stack in
>>>>>> interpret state, performing the compilation semantics of LITERAL or
>>>>>> 2LITERAL in compile state, and also knowing that one more level of
>>>>>> LITERAL or 2LITERAL is needed when it's called from POSTPONE.
>>>>>
>>>>> Not a problem since POSTPONE is required to postpone.
>>>>
>>>> How does that make NUMBER perform the extra LITERAL level?
>>>>
>>>> Test case:
>>>>
>>>> : foo postpone 123 ; immediate
>>>> : bar foo ;
>>>> bar . \ prints 123
>>>>
>>>
>>> Omit immediate :)
>>>
>>> POSTPONE 123 is akin to postponing an immediate word; it
>>> will execute when later encountered, rather than compile.
>>
>>
>> There is an approach that shows (or helps to understand) how POSTPONE
>> should work regardless of its argument kind.
>>
>>
>>     : foo postpone 123 ; immediate
>>
>>     : bar foo ;
>>
>> 1. Substitute foo in bar by the body of bar in square brackets.
>> <==>
>>     : bar [ postpone 123 ] ;
>
> Result is ambiguous (POSTPONE inside brackets).

It isn't a real code, it's a pseudo code, a conceptual model. And in any
case, the result is not ambiguous since the item 2 describes semantics
for POSTPONE inside brackets (i.e., the interpretation semantics for
POSTPONE). If it would be a real code, POSTPONE should be just redefined
to have these interpretation semantics. In one my framework (standard
compliant) this looks like the following:

: postpone
state @ if postpone postpone exit then
parse-lexeme ['] translate-lexeme execute-compiling ?nf
; immediate

\ If you want to go deeper:
\ translate-lexeme ( i*x sd-lexeme -- j*x flag )
\ -- https://git.io/J3Tkf
\ execute-compiling ( i*x xt -- j*x )
\ -- https://git.io/J3Tk5

>> 2. Suppose that interpretation semantics of POSTPONE X is to *perform*
>> compilation semantics of X. Remember that performing compilation
>> semantics of X is what the text interpreter does when it encounters X in
>> compilation state.
>> <==>
>>     : bar 123 ;
>>
>>
>> Hence,
>>
>>     : bar foo ;
>>
>> shall be equivalent to
>>
>>     : bar 123 ;

--
Ruvim

On 28/04/2021 22:38, dxforth wrote:
> ...
> POSTPONE needs to know the compiling
> literal used by 'number'. Here are the tweaks:

We can improve on that as nlit wasn't needed after all.
'number' now returns the xt directly.

: number ( c-addr -- [d|n|r] xt )
...
2dup number? if
2nip dpl @ 0< if
drop ['] literal
else
['] 2literal
then true
else
fnumber \ defer for floats
then
...
( flag) ?defined \ 0 = fail & abort
>r state @ if r@ execute then r> ;

: POSTPONE
?comp bl word find ?dup if
0< if compile compile then
else number then compile, ; immediate

'number' in INTERPRET will need to drop the xt:

: interpret ( -- )
begin
bl word dup c@
while
find ?dup if
state @ if compile, else execute then
else
( c-addr) number DROP
then ?stack
repeat drop ;

What was the cost of making POSTPONE handle numeric literals?
Comparing the old and new DX-Forth executables, it was an
extra 16 bytes.

\ tests

: foo postpone 123 : immediate LITERAL is system ok
: bar foo ; ok
bar . 123 ok
: foo2 postpone 123e : immediate FLITERAL is system ok
: bar2 foo2 ; ok
bar2 f. 123. ok

On Tuesday, April 27, 2021 at 11:43:15 PM UTC-4, Hugh Aguilar wrote:
> On Tuesday, April 27, 2021 at 5:03:24 PM UTC-7, dxforth wrote:
> > I've found an essentially no-cost way of implementing it.
> > Other than the novelty of being able to write ]] 123 [[
> > what are the reasons/examples for having it?
> My MACRO: and POST: have worked with literals for quite some time.
> This is a comment from my code:
> \ POST: LIT: DLIT: FLIT: "LIT: are used inside of immediate words that meta-compile.
> \ This is similar to ]] but a lot better because it supports literals
> \ and immediate words such as [CHAR] POSTPONE etc. that take data out of the input stream.
>
> Why are you interested in Anton Ertl's ]] construct?
> It is worthless from a technical standpoint. It was invented primarily as a workaround
> for Anton Ertl's lack of disambiguifiers that Elizabeth Rather forbids him from using.
> Anybody who uses ]] is just brown-nosing Anton Ertl who is brown-nosing
> Elizabeth Rather --- an example of: "meta-brown-nosing" --- this is a pun, because my
> MACRO: and POST: are used for meta-compiling (I explain this in case
> any of the ANS-Forth cult didn't get the pun).
>
> Note that my MACRO: and POST: are ANS-Forth code.
> Your as-yet-undescribed way to POSTPONE literals is not going to be ANS-Forth.
> Because of this, the ANS-Forth cult will not be interested in it.
>
> I really doubt that anybody in the ANS-Forth cult understand meta-compiling.
Hugh do you have an online forth tutorial?
ARe you able to do dynamic web sites in forth?

On 29/04/2021 12:14, azathot...@gmail.com wrote:
> On Tuesday, April 27, 2021 at 11:43:15 PM UTC-4, Hugh Aguilar wrote:
>> On Tuesday, April 27, 2021 at 5:03:24 PM UTC-7, dxforth wrote:
>> > I've found an essentially no-cost way of implementing it.
>> > Other than the novelty of being able to write ]] 123 [[
>> > what are the reasons/examples for having it?
>> My MACRO: and POST: have worked with literals for quite some time.
>> This is a comment from my code:
>> \ POST: LIT: DLIT: FLIT: "LIT: are used inside of immediate words that meta-compile.
>> \ This is similar to ]] but a lot better because it supports literals
>> \ and immediate words such as [CHAR] POSTPONE etc. that take data out of the input stream.
>>
>> Why are you interested in Anton Ertl's ]] construct?
>> It is worthless from a technical standpoint. It was invented primarily as a workaround
>> for Anton Ertl's lack of disambiguifiers that Elizabeth Rather forbids him from using.
>> Anybody who uses ]] is just brown-nosing Anton Ertl who is brown-nosing
>> Elizabeth Rather --- an example of: "meta-brown-nosing" --- this is a pun, because my
>> MACRO: and POST: are used for meta-compiling (I explain this in case
>> any of the ANS-Forth cult didn't get the pun).
>>
>> Note that my MACRO: and POST: are ANS-Forth code.
>> Your as-yet-undescribed way to POSTPONE literals is not going to be ANS-Forth.
>> Because of this, the ANS-Forth cult will not be interested in it.
>>
>> I really doubt that anybody in the ANS-Forth cult understand meta-compiling.
> Hugh do you have an online forth tutorial?
> ARe you able to do dynamic web sites in forth?
>

This guy can:

https://www.45office.com/

dxforth <dxforth@gmail.com> writes:
>On 28/04/2021 22:38, dxforth wrote:
>> ...
>> POSTPONE needs to know the compiling
>> literal used by 'number'. Here are the tweaks:
>
>We can improve on that as nlit wasn't needed after all.
>'number' now returns the xt directly.
>
>: number ( c-addr -- [d|n|r] xt )
> ...
> 2dup number? if
> 2nip dpl @ 0< if
> drop ['] literal
> else
> ['] 2literal
> then true
> else
> fnumber \ defer for floats
> then
> ...
> ( flag) ?defined \ 0 = fail & abort
> >r state @ if r@ execute then r> ;
>
>: POSTPONE
> ?comp bl word find ?dup if
> 0< if compile compile then
> else number then compile, ; immediate
>
>'number' in INTERPRET will need to drop the xt:
>
>: interpret ( -- )
> begin
> bl word dup c@
> while
> find ?dup if
> state @ if compile, else execute then
> else
> ( c-addr) number DROP
> then ?stack
> repeat drop ;

Or, instead of making NUMBER state-smart, you put the STATE handling
in INTERPRET:

Replace the last line of NUMBER with ";"

Define INTERPRET as:

: interpret ( -- )
begin
bl word dup c@
while
find ?dup if
state @ if compile, else execute then
else
( c-addr) number state @ if execute else drop then
then ?stack
repeat drop ;

And POSTPONE as:

: POSTPONE
bl word find ?dup if
0< if compile compile then
else number dup >r execute r> then compile, ; immediate

This POSTPONE is not STATE-"smart".

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 29/04/2021 16:09, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 28/04/2021 22:38, dxforth wrote:
>>> ...
>>> POSTPONE needs to know the compiling
>>> literal used by 'number'. Here are the tweaks:
>>
>>We can improve on that as nlit wasn't needed after all.
>>'number' now returns the xt directly.
>>
>>: number ( c-addr -- [d|n|r] xt )
>> ...
>> 2dup number? if
>> 2nip dpl @ 0< if
>> drop ['] literal
>> else
>> ['] 2literal
>> then true
>> else
>> fnumber \ defer for floats
>> then
>> ...
>> ( flag) ?defined \ 0 = fail & abort
>> >r state @ if r@ execute then r> ;
>>
>>: POSTPONE
>> ?comp bl word find ?dup if
>> 0< if compile compile then
>> else number then compile, ; immediate
>>
>>'number' in INTERPRET will need to drop the xt:
>>
>>: interpret ( -- )
>> begin
>> bl word dup c@
>> while
>> find ?dup if
>> state @ if compile, else execute then
>> else
>> ( c-addr) number DROP
>> then ?stack
>> repeat drop ;
>
> Or, instead of making NUMBER state-smart, you put the STATE handling
> in INTERPRET:
>
> Replace the last line of NUMBER with ";"
>
> Define INTERPRET as:
>
> : interpret ( -- )
> begin
> bl word dup c@
> while
> find ?dup if
> state @ if compile, else execute then
> else
> ( c-addr) number state @ if execute else drop then
> then ?stack
> repeat drop ;
>
> And POSTPONE as:
>
> : POSTPONE
> bl word find ?dup if
> 0< if compile compile then
> else number dup >r execute r> then compile, ; immediate
>
> This POSTPONE is not STATE-"smart".

Would you have an example of use where it would matter? POSTPONE
COMPILE LITERAL etc are either legally or technically compile-only.

In article <2021Apr29.080904@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>Or, instead of making NUMBER state-smart, you put the STATE handling
>in INTERPRET:
>
>Replace the last line of NUMBER with ";"
>
>Define INTERPRET as:
>
>: interpret ( -- )
> begin
> bl word dup c@
> while
> find ?dup if
> state @ if compile, else execute then
> else
> ( c-addr) number state @ if execute else drop then
> then ?stack
> repeat drop ;

Or, if `` number '' is handled by immediate prefixes you can just
leave the else part.
Note that prefixes like $ # % ' presort the different cases of numbers
to handle. ( $1234 #200 %10011100 'A' )

Or if INTERPRET monitors stack changes, all cases of `` number ''
would be simplified.

>
>And POSTPONE as:
>
>: POSTPONE
> bl word find ?dup if
> 0< if compile compile then
> else number dup >r execute r> then compile, ; immediate
>
>This POSTPONE is not STATE-"smart".

It is IMMEDIATE-"smart" , but that is less objectionable.

>- anton

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

dxforth <dxforth@gmail.com> writes:
>> This POSTPONE is not STATE-"smart".
>
>Would you have an example of use where it would matter?

: postpone postpone postpone ; immediate
: foo [ postpone . ] ; immediate

>POSTPONE
>COMPILE LITERAL etc are either legally or technically compile-only.

"Compile-only" is used in two different meanings:

1) Has undefined interpretation semantics.

2) Errors out when being run in interpret state.

The fixed POSTPONE is technically fine wrt either meaning: it has
interpretation semantics, and it does not produce error when it runs
in interpret state

Concerning "legally", the standard only specifies 1) for POSTPONE, and
that is easily fixed:

: postpone postpone postpone ; immediate

Apart from that, given all the slavery and freedom rethoric you have
been using wrt standard compliance, don't you want to provide the
dxforth programmers with the freedom to just write

: foo [ postpone . ] ;

Gforth, SwiftForth, and VFX provide this freedom.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2020: https://euro.theforth.net/2020

On 2021-04-29 11:54, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>> This POSTPONE is not STATE-"smart".
>>
>> Would you have an example of use where it would matter?
>
> : postpone postpone postpone ; immediate
> : foo [ postpone . ] ; immediate

It's ambiguous. It should be admitted, at the moment the standard
doesn't allow to perform compilation semantics in interpretation state.

But in any standard system, POSTPONE can be redefined in such a way that
your test will work as expected:

: postpone ( -- ) \ "name"
bl word find dup 0= if -13 throw then
swap postpone literal
1 = if ['] execute-compiling else ['] compile, then compile,
; immediate

--
Ruvim

On 29/04/2021 18:54, Anton Ertl wrote:
>
>>> This POSTPONE is not STATE-"smart".

I agree your mods correct the oddity of NUMBER doing work that is
properly the function of INTERPRET and POSTPONE. I'll be retaining
?COMP which in my actual code is positioned just before NUMBER in
POSTPONE. That's because my COMPILE already has ?COMP built-in for
crash prevention.

>>
>>Would you have an example of use where it would matter?
>
> : postpone postpone postpone ; immediate
> : foo [ postpone . ] ; immediate
>
>>POSTPONE
>>COMPILE LITERAL etc are either legally or technically compile-only.
>
> "Compile-only" is used in two different meanings:
>
> 1) Has undefined interpretation semantics.
>
> 2) Errors out when being run in interpret state.
>
> The fixed POSTPONE is technically fine wrt either meaning: it has
> interpretation semantics, and it does not produce error when it runs
> in interpret state
>
> Concerning "legally", the standard only specifies 1) for POSTPONE, and
> that is easily fixed:
>
> : postpone postpone postpone ; immediate
>
> Apart from that, given all the slavery and freedom rethoric you have
> been using wrt standard compliance, don't you want to provide the
> dxforth programmers with the freedom to just write
>
> : foo [ postpone . ] ;
>
> Gforth, SwiftForth, and VFX provide this freedom.
>

200x doesn't and the principals of those systems have been sitting on
its board since inception. If anyone is being disenfranchised, it
would appear to be 200x users.

On 29/04/2021 21:09, Ruvim wrote:
> On 2021-04-29 11:54, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>> This POSTPONE is not STATE-"smart".
>>>
>>> Would you have an example of use where it would matter?
>>
>> : postpone postpone postpone ; immediate
>> : foo [ postpone . ] ; immediate
>
> It's ambiguous. It should be admitted, at the moment the standard
> doesn't allow to perform compilation semantics in interpretation state.

Has the case been made that it should? That something now works
that previously didn't is a curiosity - not a demonstrated need.
The functionality described above can almost certainly be duplicated
by other means. I just haven't been able to find the many examples
of use that would justify changing POSTPONE to do it. Why I asked.
The same for POSTPONEing literals. I've just spent 21 bytes on
something I don't know I'll ever use. When forth's hacks start
thinking like Moore, the language may gain some credibility but
not until then.

On 2021-04-30 02:47, dxforth wrote:
> On 29/04/2021 21:09, Ruvim wrote:
>> On 2021-04-29 11:54, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>> This POSTPONE is not STATE-"smart".
>>>>
>>>> Would you have an example of use where it would matter?
>>>
>>> : postpone postpone postpone ; immediate
>>> : foo [ postpone . ] ; immediate
>>
>> It's ambiguous. It should be admitted, at the moment the standard
>> doesn't allow to perform compilation semantics in interpretation state.
>
> Has the case been made that it should?  That something now works
> that previously didn't is a curiosity - not a demonstrated need.
> The functionality described above can almost certainly be duplicated
> by other means.  I just haven't been able to find the many examples
> of use that would justify changing POSTPONE to do it.  Why I asked.
> The same for POSTPONEing literals.  I've just spent 21 bytes on
> something I don't know I'll ever use.  When forth's hacks start
> thinking like Moore, the language may gain some credibility but
> not until then.

So the question is why do we have (or why do we need to provide) some
features that are very rarely used and have the alternatives?

I see this problem as a problem of integrality and consistency.

A user expects that the system/language is (or should be) integral and
consistent. A user mentally builds a model of the system, and this model
allows to predict the system's behavior in edge case, or to extrapolate
behavior from one set of situations into another set.

If some prediction fails, the reason should be sound, convincing, and
clear to correct the model. Otherwise it will look like a bug or a flaw.

If POSTPONE works for words, why it cannot work for numbers? What is a
sound reason for that? Does it have some intrinsic uncertainty? Is it
difficult to implement?

If nothing of that, it's better to not break a more general model and
support applying POSTPONE to numbers.

Ditto about performing compilation semantics in interpretation state.
If a user (a program) explicitly directs a system to perform some
compilation semantics, why he should be concerned to also set
compilation state? The system can set compilation state by itself. It's
not difficult. And all required information is available for the system.

A small nuance is that the system should not revert the state if it was
explicitly directed to change the state. But it's also a simple thing,
see my the same example https://git.io/J3331

So there is no any sound reason to break (i.e. to not support) a more
general model.

--
Ruvim

In article <s6gos1$7jf$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2021-04-30 02:47, dxforth wrote:
>> On 29/04/2021 21:09, Ruvim wrote:
>>> On 2021-04-29 11:54, Anton Ertl wrote:
>>>> dxforth <dxforth@gmail.com> writes:
>>>>>> This POSTPONE is not STATE-"smart".
>>>>>
>>>>> Would you have an example of use where it would matter?
>>>>
>>>> : postpone postpone postpone ; immediate
>>>> : foo [ postpone . ] ; immediate
>>>
>>> It's ambiguous. It should be admitted, at the moment the standard
>>> doesn't allow to perform compilation semantics in interpretation state.
>>
>> Has the case been made that it should?  That something now works
>> that previously didn't is a curiosity - not a demonstrated need.
>> The functionality described above can almost certainly be duplicated
>> by other means.  I just haven't been able to find the many examples
>> of use that would justify changing POSTPONE to do it.  Why I asked.
>> The same for POSTPONEing literals.  I've just spent 21 bytes on
>> something I don't know I'll ever use.  When forth's hacks start
>> thinking like Moore, the language may gain some credibility but
>> not until then.
>
>
>So the question is why do we have (or why do we need to provide) some
>features that are very rarely used and have the alternatives?
>
>I see this problem as a problem of integrality and consistency.
>
>A user expects that the system/language is (or should be) integral and
>consistent. A user mentally builds a model of the system, and this model
>allows to predict the system's behavior in edge case, or to extrapolate
>behavior from one set of situations into another set.
>
>If some prediction fails, the reason should be sound, convincing, and
>clear to correct the model. Otherwise it will look like a bug or a flaw.
>
>
>
>If POSTPONE works for words, why it cannot work for numbers? What is a
>sound reason for that? Does it have some intrinsic uncertainty? Is it
>difficult to implement?
>
>If nothing of that, it's better to not break a more general model and
>support applying POSTPONE to numbers.
>
>
>
>
>Ditto about performing compilation semantics in interpretation state.
>If a user (a program) explicitly directs a system to perform some
>compilation semantics, why he should be concerned to also set
>compilation state? The system can set compilation state by itself. It's
>not difficult. And all required information is available for the system.
>
>A small nuance is that the system should not revert the state if it was
>explicitly directed to change the state. But it's also a simple thing,
>see my the same example https://git.io/J3331
>
>
>So there is no any sound reason to break (i.e. to not support) a more
>general model.

Your reasoning is sound. My conclusion is that with the kind of
abstraction POSTPONE offers we took a wrong turn. Instead of supporting
POSTPONE for numbers, I want to get rid of POSTPONE altogether.

>--
>Ruvim

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst