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


Groups > comp.lang.forth > #43757

Re: POSTPONE behaviour

From Gerry Jackson <gerry@jackson9000.fsnet.co.uk>
Newsgroups comp.lang.forth
Subject Re: POSTPONE behaviour
Date 2015-11-25 13:58 +0000
Organization A noiseless patient Spider
Message-ID <n34ekq$con$1@dont-email.me> (permalink)
References (5 earlier) <b18ae92a-815d-4c01-a570-052215b96346@googlegroups.com> <n33pnt$2tq$1@dont-email.me> <91b7cce8-9779-4ab4-84bf-6f4b04115189@googlegroups.com> <n33u8h$h4j$1@dont-email.me> <29d96442-5161-4d80-ae1a-5592f9509389@googlegroups.com>

Show all headers | View raw


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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web