Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #43719 > unrolled thread

POSTPONE behaviour

Back to article view | Back to comp.lang.forth

Contents

  POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 21:18 -0800
    Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 22:00 -0800
      Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 22:15 -0800
        Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 22:54 -0800
          Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 23:09 -0800
          Re: POSTPONE behaviour Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 08:15 +0100
            Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 23:38 -0800
              Re: POSTPONE behaviour Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 08:46 +0100
                Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 00:04 -0800
              Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 03:01 -0500
                Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 00:09 -0800
                  Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 03:23 -0500
                    Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 01:09 -0800
                      Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 10:49 -0500
                        Re: POSTPONE behaviour "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 09:10 -1000
                  Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 09:18 +0000
                    Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 02:21 -0800
                      Re: POSTPONE behaviour Mark Wills <markwills1970@gmail.com> - 2015-11-25 02:47 -0800
                      Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 13:58 +0000
                        Re: POSTPONE behaviour Mark Wills <markwills1970@gmail.com> - 2015-11-25 06:35 -0800
                          Re: POSTPONE behaviour Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 18:45 +0100
                        Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 22:11 -0800
                          Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-26 07:42 +0000
                            Re: POSTPONE behaviour "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-26 05:20 -0500
                              Re: POSTPONE behaviour anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 16:50 +0000
                              Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-26 17:59 +0000
                                Re: POSTPONE behaviour Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 19:07 +0100
                                  Re: POSTPONE behaviour anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:24 +0000
                      Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-11-26 12:29 -0800
                        Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 09:53 +0000
                          Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-11-29 21:48 -0800
                            Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 12:18 +0000
                              Re: POSTPONE behaviour Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-30 13:41 +0100
                              Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-11-30 19:56 -0800
                                Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 09:59 +0000
                                  Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-12-01 22:46 -0800
                                    Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-02 07:50 +0000
                Re: POSTPONE behaviour anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 13:45 +0000
                  Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 10:54 -0500
          Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 07:39 +0000
            Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 23:48 -0800
              Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 08:03 +0000
      Re: POSTPONE behaviour Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 18:37 +0100
    Re: POSTPONE behaviour "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-25 01:27 -0500
      Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 22:51 -0800
    Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-25 21:19 -0800

Page 1 of 3  [1] 2 3  Next page →

#43719 — POSTPONE behaviour

Hi All,

I having trouble implementing POSTPONE word. Can someone help me with simple explanation of how POSTPONE works?
ANS94 standard have long retrospective, and very brief explanation.

Here is an related issue: https://github.com/drom/forth/issues/3

[toc] | [next] | [standalone]

#43721

POSTPONE lets you compile immediate words. Immediate words are executed at 
compile time, not compiled. Like the famous IF. IF will be executed at
compile time. Your only chance to compile IF in a definition  is to POSTPONE 
it.

If the word postponed is not immediate, then postpone is redundant. 
... FOO ... and 
... POSTPONE FOO ... is the same thing if the FOO is not immediate.

[toc] | [prev] | [next] | [standalone]

#43722

Hi Raimond,
That was my impression too but I am passing ANS94 test for postponing immediate words.

Like:
T{ : GT6 345 ; IMMEDIATE -> }T
T{ : GT7 POSTPONE GT6 ; -> }T
T{ GT7 -> 345 }T

And:
T{ : NOP : POSTPONE ; ; -> }T
T{ NOP NOP1 NOP NOP2 -> }T
T{ NOP1 -> }T
T{ NOP2 -> }T

But failing in this case:
T{ : GT1 123 ; -> }T
T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
T{ : GT5 GT4 ; -> }T
T{ GT5 -> 123 }T

Error: in line: 647 T{ : GT5 GT4 ; -> }T  expected [ 291 ] to deeply equal [].
Error: in line: 648 T{ GT5 -> 123 }T  expected [] to deeply equal [ 291 ].

See details here.
https://github.com/drom/forth/issues/3

Regards,
Alexey


On Tuesday, November 24, 2015 at 10:00:16 PM UTC-8, Raimond Dragomir wrote:
> POSTPONE lets you compile immediate words. Immediate words are executed at 
> compile time, not compiled. Like the famous IF. IF will be executed at
> compile time. Your only chance to compile IF in a definition  is to POSTPONE 
> it.
> 
> If the word postponed is not immediate, then postpone is redundant. 
> ... FOO ... and 
> ... POSTPONE FOO ... is the same thing if the FOO is not immediate.

[toc] | [prev] | [next] | [standalone]

#43728

> But failing in this case:
> T{ : GT1 123 ; -> }T
> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
> T{ : GT5 GT4 ; -> }T
> T{ GT5 -> 123 }T

Well, think about it: GT4 is immediate. It is executed directly when you 
define GT5. When executed it will call GT1 which leaves 123 on the data stack.

So you already have 123 on the stack after GT5 definition.
Also, GT5 body is just a nop, because you compiled nothing (GT4 just
executed at compile time).
So when you lastly execute GT5 it will leave nothing (but you expect 123)

Hope it helps



 

[toc] | [prev] | [next] | [standalone]

#43730

Hi Raimond,
That is exactly my problem:

4 lines of code is from the core.fth
Which is ANS94 compliance test.
So, it is no what I expect, it is what ANS94 standard expects.
Nothing after GT5 definition, and 123 after GT5 execution.

On Tuesday, November 24, 2015 at 10:54:36 PM UTC-8, Raimond Dragomir wrote:
> > But failing in this case:
> > T{ : GT1 123 ; -> }T
> > T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
> > T{ : GT5 GT4 ; -> }T
> > T{ GT5 -> 123 }T
> 
> Well, think about it: GT4 is immediate. It is executed directly when you 
> define GT5. When executed it will call GT1 which leaves 123 on the data stack.
> 
> So you already have 123 on the stack after GT5 definition.
> Also, GT5 body is just a nop, because you compiled nothing (GT4 just
> executed at compile time).
> So when you lastly execute GT5 it will leave nothing (but you expect 123)
> 
> Hope it helps

[toc] | [prev] | [next] | [standalone]

#43731

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> But failing in this case:
>> T{ : GT1 123 ; -> }T
>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>> T{ : GT5 GT4 ; -> }T
>> T{ GT5 -> 123 }T
>
> Well, think about it: GT4 is immediate. It is executed directly when
> you define GT5. When executed it will call GT1 which leaves 123 on the
> data stack.

No, in an ANS Forth, GT4 should not call GT1.

[toc] | [prev] | [next] | [standalone]

#43734

miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >> But failing in this case:
> >> T{ : GT1 123 ; -> }T
> >> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
> >> T{ : GT5 GT4 ; -> }T
> >> T{ GT5 -> 123 }T
> >
> > Well, think about it: GT4 is immediate. It is executed directly when
> > you define GT5. When executed it will call GT1 which leaves 123 on the
> > data stack.
> 
> No, in an ANS Forth, GT4 should not call GT1.

And do what else?
GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
When GT4 is executed (not compiled). And this happens when GT5 is defined
because GT4 is immediate.

[toc] | [prev] | [next] | [standalone]

#43737

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> >> But failing in this case:
>> >> T{ : GT1 123 ; -> }T
>> >> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>> >> T{ : GT5 GT4 ; -> }T
>> >> T{ GT5 -> 123 }T
>> >
>> > Well, think about it: GT4 is immediate. It is executed directly when
>> > you define GT5. When executed it will call GT1 which leaves 123 on the
>> > data stack.
>> 
>> No, in an ANS Forth, GT4 should not call GT1.
>
> And do what else?

When GT4 is executed, it should compile code to execute GT1.  In this
case GT5 should call GT1.  That's why 123 is expected in the last test.

[toc] | [prev] | [next] | [standalone]

#43740

miercuri, 25 noiembrie 2015, 09:53:39 UTC+2, Lars Brinkhoff a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >> >> But failing in this case:
> >> >> T{ : GT1 123 ; -> }T
> >> >> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
> >> >> T{ : GT5 GT4 ; -> }T
> >> >> T{ GT5 -> 123 }T
> >> >
> >> > Well, think about it: GT4 is immediate. It is executed directly when
> >> > you define GT5. When executed it will call GT1 which leaves 123 on the
> >> > data stack.
> >> 
> >> No, in an ANS Forth, GT4 should not call GT1.
> >
> > And do what else?
> 
> When GT4 is executed, it should compile code to execute GT1.  In this
> case GT5 should call GT1.  That's why 123 is expected in the last test.

What an obfuscated behaviour. I remembered now why I don't have a postpone word 
in my system. Yes, I have to know what words are immediate and what words
are not (few words are immediate though, and the obvious ones) but at least
I know what I'm doing.

And Alexei is right: The ANS definition is so short... Probably it considers
POSTPONE as trivial as DUP or 1+ ...

[toc] | [prev] | [next] | [standalone]

#43738

On 11/25/2015 2:38 AM, Raimond Dragomir wrote:
> miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>>> But failing in this case:
>>>> T{ : GT1 123 ; -> }T
>>>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>>>> T{ : GT5 GT4 ; -> }T
>>>> T{ GT5 -> 123 }T
>>>
>>> Well, think about it: GT4 is immediate. It is executed directly when
>>> you define GT5. When executed it will call GT1 which leaves 123 on the
>>> data stack.
>>
>> No, in an ANS Forth, GT4 should not call GT1.
>
> And do what else?
> GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
> When GT4 is executed (not compiled). And this happens when GT5 is defined
> because GT4 is immediate.

This wasn't clear to me until I read these sections of the standard... 
well, the 2012 standard.  Is any of this different from the 94 standard 
that seems to be the one under discussion?

6.1.2033 POSTPONE CORE
Interpretation: Interpretation semantics for this word are undefined.
Compilation: ( “(spaces)name” -- )
Skip leading space delimiters. Parse name delimited by a space. Find 
name. Append the compilation semantics of name to the current 
definition. An ambiguous condition exists if name is not found.

3.4.3.3 Compilation semantics
Unless otherwise specified in a “ Compilation: ” section of the glossary 
entry, the compilation semantics of a Forth definition shall be to 
append its execution semantics to the execution semantics of the current 
definition.

So postponing a word that is not immediate does nothing special, right? 
  In essence, for a non-immediate word POSTPONE is a noop.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#43742

miercuri, 25 noiembrie 2015, 10:01:17 UTC+2, rickman a scris:
> On 11/25/2015 2:38 AM, Raimond Dragomir wrote:
> > miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
> >> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >>>> But failing in this case:
> >>>> T{ : GT1 123 ; -> }T
> >>>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
> >>>> T{ : GT5 GT4 ; -> }T
> >>>> T{ GT5 -> 123 }T
> >>>
> >>> Well, think about it: GT4 is immediate. It is executed directly when
> >>> you define GT5. When executed it will call GT1 which leaves 123 on the
> >>> data stack.
> >>
> >> No, in an ANS Forth, GT4 should not call GT1.
> >
> > And do what else?
> > GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
> > When GT4 is executed (not compiled). And this happens when GT5 is defined
> > because GT4 is immediate.
> 
> This wasn't clear to me until I read these sections of the standard... 
> well, the 2012 standard.  Is any of this different from the 94 standard 
> that seems to be the one under discussion?
> 
> 6.1.2033 POSTPONE CORE
> Interpretation: Interpretation semantics for this word are undefined.
> Compilation: ( "(spaces)name" -- )
> Skip leading space delimiters. Parse name delimited by a space. Find 
> name. Append the compilation semantics of name to the current 
> definition. An ambiguous condition exists if name is not found.
> 
> 3.4.3.3 Compilation semantics
> Unless otherwise specified in a " Compilation: " section of the glossary 
> entry, the compilation semantics of a Forth definition shall be to 
> append its execution semantics to the execution semantics of the current 
> definition.
> 
> So postponing a word that is not immediate does nothing special, right? 
>   In essence, for a non-immediate word POSTPONE is a noop.
> 
> -- 
> 
> Rick

Rick, this behaviour is so obvious to so many people, yet the ANS standard
seems to define it totally different for non-immediate words. I just wonder
now how much % of the forth programmers really understand the POSTPONE in
the ANS way.

One thing is clear to me: ANS document should explain it MUCH better and
more carefully.

As for me personally I don't have a postpone word in my system. It is so
much mis-understood and hard to understand that I 'm better off.
I have very few immediate words anyway, and those ones are the obvious ones
(like IF, BEGIN, WHILE, etc).

[toc] | [prev] | [next] | [standalone]

#43743

On 11/25/2015 3:09 AM, Raimond Dragomir wrote:
> miercuri, 25 noiembrie 2015, 10:01:17 UTC+2, rickman a scris:
>> On 11/25/2015 2:38 AM, Raimond Dragomir wrote:
>>> miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
>>>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>>>>> But failing in this case:
>>>>>> T{ : GT1 123 ; -> }T
>>>>>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>>>>>> T{ : GT5 GT4 ; -> }T
>>>>>> T{ GT5 -> 123 }T
>>>>>
>>>>> Well, think about it: GT4 is immediate. It is executed directly when
>>>>> you define GT5. When executed it will call GT1 which leaves 123 on the
>>>>> data stack.
>>>>
>>>> No, in an ANS Forth, GT4 should not call GT1.
>>>
>>> And do what else?
>>> GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
>>> When GT4 is executed (not compiled). And this happens when GT5 is defined
>>> because GT4 is immediate.
>>
>> This wasn't clear to me until I read these sections of the standard...
>> well, the 2012 standard.  Is any of this different from the 94 standard
>> that seems to be the one under discussion?
>>
>> 6.1.2033 POSTPONE CORE
>> Interpretation: Interpretation semantics for this word are undefined.
>> Compilation: ( "(spaces)name" -- )
>> Skip leading space delimiters. Parse name delimited by a space. Find
>> name. Append the compilation semantics of name to the current
>> definition. An ambiguous condition exists if name is not found.
>>
>> 3.4.3.3 Compilation semantics
>> Unless otherwise specified in a " Compilation: " section of the glossary
>> entry, the compilation semantics of a Forth definition shall be to
>> append its execution semantics to the execution semantics of the current
>> definition.
>>
>> So postponing a word that is not immediate does nothing special, right?
>>    In essence, for a non-immediate word POSTPONE is a noop.
>>
>> --
>>
>> Rick
>
> Rick, this behaviour is so obvious to so many people, yet the ANS standard
> seems to define it totally different for non-immediate words. I just wonder
> now how much % of the forth programmers really understand the POSTPONE in
> the ANS way.

Hmmm.. At first I thought you were not reading the same standard I was, 
but on reading it again, I think I am mis-interpreting the standard. 
When postpone says, "Append the compilation semantics of name to the 
current definition."  I guess for a non-immediate word that could mean 
to append to the current definition the action of compiling the 
execution semantics of the word postponed.


> One thing is clear to me: ANS document should explain it MUCH better and
> more carefully.

Yeah, I guess you might be right.  The appendix section A.6.1.2033 
POSTPONE talks about how COMPILE and [COMPILE] require the user to know 
if the word affected is immediate or not, but doesn't clarify what 
POSTPONE will do with a non-immediate word.


> As for me personally I don't have a postpone word in my system. It is so
> much mis-understood and hard to understand that I 'm better off.
> I have very few immediate words anyway, and those ones are the obvious ones
> (like IF, BEGIN, WHILE, etc).

So what do standard systems do?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#43744

> > As for me personally I don't have a postpone word in my system. It is so
> > much mis-understood and hard to understand that I 'm better off.
> > I have very few immediate words anyway, and those ones are the obvious ones
> > (like IF, BEGIN, WHILE, etc).
> 
> So what do standard systems do?
> 
> -- 
> 
> Rick

In my system I have COMPILE which does the obvious thing that everyone
expects: compiles immediate words AND non-immediate words (like you said,
for non-immediate words it acts as a noop). The reason behind it is to
have a "tool" to compile immediate words exactly like non-immediate ones
(otherwise you have no chance to compile immediate words because they
are executed at compile time). The usage is intended for immediate words
and has the obvious effect on non-immediate words. In fact I use the term
"normal" words for non-immediate words because I always think about
immediate words as kind of "special".

For generating code that compiles a word programatically, I have COMPILE,
that can be used like that: ' word compile,

Yes, I have to know what word is immediate or not, but this is very simple
in my system where the obvious control words are immediate.

When reading the ANS standard and the "compilation semantincs" it sounds
that a "normal" word (non-immediate) kind of compiles itself into the
definition (or it has a different "brother" word that compiles it) and 
postponing the non-immediate word will compile this "brother" word.

[toc] | [prev] | [next] | [standalone]

#43759

On 11/25/2015 4:09 AM, Raimond Dragomir wrote:
>>> As for me personally I don't have a postpone word in my system. It is so
>>> much mis-understood and hard to understand that I 'm better off.
>>> I have very few immediate words anyway, and those ones are the obvious ones
>>> (like IF, BEGIN, WHILE, etc).
>>
>> So what do standard systems do?
>>
>> --
>>
>> Rick
>
> In my system I have COMPILE which does the obvious thing that everyone
> expects: compiles immediate words AND non-immediate words (like you said,
> for non-immediate words it acts as a noop). The reason behind it is to
> have a "tool" to compile immediate words exactly like non-immediate ones
> (otherwise you have no chance to compile immediate words because they
> are executed at compile time). The usage is intended for immediate words
> and has the obvious effect on non-immediate words. In fact I use the term
> "normal" words for non-immediate words because I always think about
> immediate words as kind of "special".
>
> For generating code that compiles a word programatically, I have COMPILE,
> that can be used like that: ' word compile,
>
> Yes, I have to know what word is immediate or not, but this is very simple
> in my system where the obvious control words are immediate.
>
> When reading the ANS standard and the "compilation semantincs" it sounds
> that a "normal" word (non-immediate) kind of compiles itself into the
> definition (or it has a different "brother" word that compiles it) and
> postponing the non-immediate word will compile this "brother" word.

You lost me there.  Actually, I read the appendix again and I see this 
which clarifies it a bit better.  "POSTPONE replaces most of the 
functionality of COMPILE and [COMPILE]. COMPILE and [COMPILE] are used 
for the same purpose: postpone the compilation behavior of the next word 
in the parse area."  So if POSTPONE is intended to replace this pair of 
words, then it should delay the compilation behavior of non-immediate 
words as well and compile them into the definition POSTPONE is used in. 
  No?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#43773

On 11/25/15 5:49 AM, rickman wrote:
> On 11/25/2015 4:09 AM, Raimond Dragomir wrote:
>>>> As for me personally I don't have a postpone word in my system. It
>>>> is so
>>>> much mis-understood and hard to understand that I 'm better off.
>>>> I have very few immediate words anyway, and those ones are the
>>>> obvious ones
>>>> (like IF, BEGIN, WHILE, etc).
>>>
>>> So what do standard systems do?
>>>
>>> --
>>>
>>> Rick
>>
>> In my system I have COMPILE which does the obvious thing that everyone
>> expects: compiles immediate words AND non-immediate words (like you said,
>> for non-immediate words it acts as a noop). The reason behind it is to
>> have a "tool" to compile immediate words exactly like non-immediate ones
>> (otherwise you have no chance to compile immediate words because they
>> are executed at compile time). The usage is intended for immediate words
>> and has the obvious effect on non-immediate words. In fact I use the term
>> "normal" words for non-immediate words because I always think about
>> immediate words as kind of "special".
>>
>> For generating code that compiles a word programatically, I have COMPILE,
>> that can be used like that: ' word compile,
>>
>> Yes, I have to know what word is immediate or not, but this is very
>> simple
>> in my system where the obvious control words are immediate.
>>
>> When reading the ANS standard and the "compilation semantincs" it sounds
>> that a "normal" word (non-immediate) kind of compiles itself into the
>> definition (or it has a different "brother" word that compiles it) and
>> postponing the non-immediate word will compile this "brother" word.
>
> You lost me there.  Actually, I read the appendix again and I see this
> which clarifies it a bit better.  "POSTPONE replaces most of the
> functionality of COMPILE and [COMPILE]. COMPILE and [COMPILE] are used
> for the same purpose: postpone the compilation behavior of the next word
> in the parse area."  So if POSTPONE is intended to replace this pair of
> words, then it should delay the compilation behavior of non-immediate
> words as well and compile them into the definition POSTPONE is used in.
>   No?

: ?IF ( -- ) POSTPONE ?DUP POSTPONE IF ; IMMEDIATE  ok
   ok
: TEST ( n -- ) ?IF . THEN ;  ok
   ok
1 test 1  ok
0 test  ok

?IF will compile ?DUP (non-immediate) followed by IF (immediate) in the 
definition of TEST. It's really quite simple! The point is, you don't 
need to treat immediate and non-immediate words differently when you're 
making a new compiler directive.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43745

On 25/11/2015 08:09, Raimond Dragomir wrote:
> miercuri, 25 noiembrie 2015, 10:01:17 UTC+2, rickman a scris:
>> On 11/25/2015 2:38 AM, Raimond Dragomir wrote:
>>> miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
>>>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>>>>> But failing in this case:
>>>>>> T{ : GT1 123 ; -> }T
>>>>>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>>>>>> T{ : GT5 GT4 ; -> }T
>>>>>> T{ GT5 -> 123 }T
>>>>>
>>>>> Well, think about it: GT4 is immediate. It is executed directly when
>>>>> you define GT5. When executed it will call GT1 which leaves 123 on the
>>>>> data stack.
>>>>
>>>> No, in an ANS Forth, GT4 should not call GT1.
>>>
>>> And do what else?
>>> GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
>>> When GT4 is executed (not compiled). And this happens when GT5 is defined
>>> because GT4 is immediate.
>>
>> This wasn't clear to me until I read these sections of the standard...
>> well, the 2012 standard.  Is any of this different from the 94 standard
>> that seems to be the one under discussion?
>>
>> 6.1.2033 POSTPONE CORE
>> Interpretation: Interpretation semantics for this word are undefined.
>> Compilation: ( "(spaces)name" -- )
>> Skip leading space delimiters. Parse name delimited by a space. Find
>> name. Append the compilation semantics of name to the current
>> definition. An ambiguous condition exists if name is not found.
>>
>> 3.4.3.3 Compilation semantics
>> Unless otherwise specified in a " Compilation: " section of the glossary
>> entry, the compilation semantics of a Forth definition shall be to
>> append its execution semantics to the execution semantics of the current
>> definition.
>>
>> So postponing a word that is not immediate does nothing special, right?
>>    In essence, for a non-immediate word POSTPONE is a noop.
>>
>> --
>>
>> Rick
>
> Rick, this behaviour is so obvious to so many people, yet the ANS standard
> seems to define it totally different for non-immediate words. I just wonder
> now how much % of the forth programmers really understand the POSTPONE in
> the ANS way.
>
> One thing is clear to me: ANS document should explain it MUCH better and
> more carefully.

I think the ANS standard specification for POSTPONE is precise and 
concise - a good thing in a standard. As immediacy is irrelevant it 
doesn't have to mention it. The fact that you came to it with 
pre-conceived notions about immediacy and misunderstood it is not the 
fault of the standard and no reason to blame it.

>
> As for me personally I don't have a postpone word in my system. It is so
> much mis-understood and hard to understand

What's so hard to understand about ... POSTPONE DROP ... in a definition 
for example. It simply defers compilation of DROP. Similarly ... 
POSTPONE IF ... defers compilation of IF. That seems straightforward enough.

> that I 'm better off.
> I have very few immediate words anyway, and those ones are the obvious ones
> (like IF, BEGIN, WHILE, etc).
>

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#43748

> I think the ANS standard specification for POSTPONE is precise and 
> concise - a good thing in a standard. As immediacy is irrelevant it 
> doesn't have to mention it. The fact that you came to it with 
> pre-conceived notions about immediacy and misunderstood it is not the 
> fault of the standard and no reason to blame it.
> 
> >
> > As for me personally I don't have a postpone word in my system. It is so
> > much mis-understood and hard to understand
> 
> What's so hard to understand about ... POSTPONE DROP ... in a definition 
> for example. It simply defers compilation of DROP. Similarly ... 
> POSTPONE IF ... defers compilation of IF. That seems straightforward enough.

POSTPONE IF just compiles IF, that's the big difference. The compilation of IF
is not deffered. OTOH the compilation of DROP is deffered indeed.

For me these are two entirely different things, that should have been treated
separately and not under the same umbrella of a word.

I don't think I have some weird view of immediacy or anything else. I think
the standard just tries to accomodate EVERY system in the world (including
those with dual xts, special words (a third species of words that aren't 
immediate nor non-immediate) and who knows what else). Or if not "every"
maybe "too many".

[toc] | [prev] | [next] | [standalone]

#43750

On Wednesday, 25 November 2015 10:21:22 UTC, Raimond Dragomir  wrote:
> > I think the ANS standard specification for POSTPONE is precise and 
> > concise - a good thing in a standard. As immediacy is irrelevant it 
> > doesn't have to mention it. The fact that you came to it with 
> > pre-conceived notions about immediacy and misunderstood it is not the 
> > fault of the standard and no reason to blame it.
> > 
> > >
> > > As for me personally I don't have a postpone word in my system. It is so
> > > much mis-understood and hard to understand
> > 
> > What's so hard to understand about ... POSTPONE DROP ... in a definition 
> > for example. It simply defers compilation of DROP. Similarly ... 
> > POSTPONE IF ... defers compilation of IF. That seems straightforward enough.
> 
> POSTPONE IF just compiles IF, that's the big difference. The compilation of IF
> is not deffered. OTOH the compilation of DROP is deffered indeed.
> 
> For me these are two entirely different things, that should have been treated
> separately and not under the same umbrella of a word.
> 
> I don't think I have some weird view of immediacy or anything else. I think
> the standard just tries to accomodate EVERY system in the world (including
> those with dual xts, special words (a third species of words that aren't 
> immediate nor non-immediate) and who knows what else). Or if not "every"
> maybe "too many".

Raimond,

Try my attempt to explain POSTPONE which you'll find here:

http://turboforth.net/resources/postpone.html

It's only confusing when postponing immediate words, but, when you think
about it, it does make sense:

: 2dup compile over   compile over  ; immediate
: 2dup postpone over  postpone over ; immediate

are equivalent.

: my-if [compile] if ; immediate
: my-if postpone if ; immediate

are equivalent. (Cue pendantry in-rush).

POSTPONE IF simply postpones the *execution* of IF until my-if is
executed.

[toc] | [prev] | [next] | [standalone]

#43757

On 25/11/2015 10:21, Raimond Dragomir wrote:
>> I think the ANS standard specification for POSTPONE is precise and
>> concise - a good thing in a standard. As immediacy is irrelevant it
>> doesn't have to mention it. The fact that you came to it with
>> pre-conceived notions about immediacy and misunderstood it is not the
>> fault of the standard and no reason to blame it.
>>
>>>
>>> As for me personally I don't have a postpone word in my system. It is so
>>> much mis-understood and hard to understand
>>
>> What's so hard to understand about ... POSTPONE DROP ... in a definition
>> for example. It simply defers compilation of DROP. Similarly ...
>> POSTPONE IF ... defers compilation of IF. That seems straightforward enough.
>
> POSTPONE IF just compiles IF, that's the big difference. The compilation of IF
> is not deffered. OTOH the compilation of DROP is deffered indeed.
>
> For me these are two entirely different things, that should have been treated
> separately and not under the same umbrella of a word.

When the compiler encounters POSTPONE IF in a definition it doesn't 
cause the compilation semantics of IF to be executed, it compiles some 
code that causes the compilation semantics of IF (i.e. IF's special 
compilation semantics) to be executed when its enclosing definition is 
called in a later definition.

When the compiler encounters POSTPONE DROP in a definition it doesn't 
cause the compilation semantics of DROP to be executed, it compiles some 
code that causes the compilation semantics of DROP (i.e. default 
compilation semantics) to be executed when its enclosing definition is 
called in a later definition.

Apart from the bit in parentheses and the words IF and DROP, what's the 
  difference?

>
> I don't think I have some weird view of immediacy or anything else.

I never said you did. You brought immediacy into the discussion of 
POSTPONE when it is irrelevant as far as an application programmer is 
concerned and gave an incorrect explanation to the OP. Just admit it and 
stop trying to shift blame onto the standard.

I think
> the standard just tries to accomodate EVERY system in the world (including
> those with dual xts, special words (a third species of words that aren't
> immediate nor non-immediate) and who knows what else). Or if not "every"
> maybe "too many".
>

The standard just avoids mandating implementation techniques. That's a 
desirable aim isn't it?

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#43758

On Wednesday, 25 November 2015 13:58:01 UTC, Gerry  wrote:
> 
> The standard just avoids mandating implementation techniques. That's a 
> desirable aim isn't it?
> 
> -- 
> Gerry

It is, yes. But if it (un-intentionally) leads to portability issues
due to the standard being too permissive, then further work is needed
to the standrd to be to be more presciptive. 

Lessons were learned with Forth-83, however, the committee should not
be afraid to make tough decisions, especially if it gives rise to
greater portability.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web