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

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

defer this not

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

Contents

  defer this not Enoch <ixew@hotmail.com> - 2016-07-06 14:21 -0700
    Re: defer this not lawrencedo99@gmail.com - 2016-07-06 18:31 -0700
      Re: defer this not hughaguilar96@gmail.com - 2016-07-06 18:45 -0700
        Re: defer this not lawrencedo99@gmail.com - 2016-07-06 19:54 -0700
          Re: defer this not hughaguilar96@gmail.com - 2016-07-06 22:53 -0700
            Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-06 23:13 -0700
              Re: defer this not Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-07 08:24 +0200
                Re: defer this not hughaguilar96@gmail.com - 2016-07-06 23:43 -0700
                Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-06 20:52 -1000
                  Re: defer this not JennyB <jennybrien@googlemail.com> - 2016-07-07 00:12 -0700
                    Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-07 03:52 -0700
                  Re: defer this not hughaguilar96@gmail.com - 2016-07-07 00:53 -0700
                    Re: defer this not Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-07 10:01 +0100
                    Re: defer this not Coos Haak <chforth@hccnet.nl> - 2016-07-07 12:46 +0200
                      Re: defer this not hughaguilar96@gmail.com - 2016-07-07 16:19 -0700
                        Re: defer this not Coos Haak <chforth@hccnet.nl> - 2016-07-08 01:39 +0200
                          Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-07 14:31 -1000
                            Re: defer this not hughaguilar96@gmail.com - 2016-07-07 17:46 -0700
                            Re: defer this not Brad Eckert <hwfwguy@gmail.com> - 2016-07-12 19:48 -0700
                              Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-12 20:58 -1000
                          Re: defer this not hughaguilar96@gmail.com - 2016-07-07 17:41 -0700
                Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-07 00:11 -0700
                  Re: defer this not Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-07 09:33 +0200
                    Re: defer this not Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-07 03:42 -0700
                      Re: defer this not Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-07 20:31 +0200
                  Re: defer this not "Elizabeth D. Rather" <erather@forth.com> - 2016-07-06 22:22 -1000
    defer this not JennyB <jennybrien@googlemail.com> - 2016-07-06 23:42 -0700
      Re: defer this not hughaguilar96@gmail.com - 2016-07-06 23:49 -0700
    Re: defer this not Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-07-07 13:59 +0200
      Re: defer this not Enoch <ixew@hotmail.com> - 2016-07-07 11:37 -0700
        Re: defer this not Julian Fondren <julian.fondren@gmail.com> - 2016-07-07 12:09 -0700
        Re: defer this not Alex Dowad <alexinbeijing@gmail.com> - 2016-07-07 13:01 -0700
          Re: defer this not Paul Rubin <no.email@nospam.invalid> - 2016-07-07 13:32 -0700
            Re: defer this not Julian Fondren <julian.fondren@gmail.com> - 2016-07-07 14:54 -0700
          Re: defer this not lawrencedo99@gmail.com - 2016-07-12 15:32 -0700

Page 1 of 2  [1] 2  Next page →

#48843 — defer this not

Request for Discussion
======================

defer is Forth standard way of dealing with forward references (e.g., see Gforth  section 5.9.10 on deferred words).

Would you agree that to resolve a forward reference via defer is inefficient and/or cumbersome?

Having a case of mutual recursion where A calls B and B calls A. How can we really justify the need for a deferred-B construct simply because A is compiled before B.

Indeed, some Forth systems spent a great deal of effort on avoiding such defer-s. See openfirmware/forth/kernel/forward.fth

May I suggest that modern Forth systems would be *required* to deal with forward references silently, even the one pass compile type. That is, create some dictionary place holder when encountering the forward reference first and then, when the definition is presented, replace that place holder. An attempt to execute an unresolved forward reference should cause a specific exception number.

TIA, Enoch.

[toc] | [next] | [standalone]

#48849

On Thursday, July 7, 2016 at 9:21:46 AM UTC+12, Enoch wrote:

> May I suggest that modern Forth systems would be *required* to deal with
> forward references silently, even the one pass compile type. That is, create
> some dictionary place holder when encountering the forward reference first
> and then, when the definition is presented, replace that place holder. An
> attempt to execute an unresolved forward reference should cause a specific
> exception number.

That would mean a reference to an undefined name could only be picked up at run-time, not compile-time.

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

#48851

On Wednesday, July 6, 2016 at 6:31:19 PM UTC-7, lawren...@gmail.com wrote:
> On Thursday, July 7, 2016 at 9:21:46 AM UTC+12, Enoch wrote:
> 
> > May I suggest that modern Forth systems would be *required* to deal with
> > forward references silently, even the one pass compile type. That is, create
> > some dictionary place holder when encountering the forward reference first
> > and then, when the definition is presented, replace that place holder. An
> > attempt to execute an unresolved forward reference should cause a specific
> > exception number.
> 
> That would mean a reference to an undefined name could only be picked up at run-time, not compile-time.

No, it could be done at compile-time. I could add this idea to Straight Forth easily enough. 

If a function is called that references an unknown word, the function would still compile, but it would give a warning such as: "unknown word: xxx ". Also, if the function is executed it aborts with an error message such as: "function incomplete; references unknown word". If the unknown word later gets written, then the function that references it gets patched so that it can be executed.

DEFER is inefficient because an indirect call is being done. This would still be useful in a program (my LowDraw.4th is an example) in which multiple functions are available to be plugged into the vector depending upon what the user requests (in the case of LowDraw.4th, depending upon which drawing-strategy is being tested).

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

#48853

On Thursday, July 7, 2016 at 1:45:03 PM UTC+12, hughag...@gmail.com wrote:
>
> On Wednesday, July 6, 2016 at 6:31:19 PM UTC-7, Lawrence D’Oliveiro wrote:
>>
>> That would mean a reference to an undefined name could only be picked up
>> at run-time, not compile-time.
> 
> No, it could be done at compile-time. I could add this idea to Straight
> Forth easily enough. 
> 
> If a function is called that references an unknown word, the function would
> still compile, but it would give a warning such as: "unknown word: xxx ".

Warnings, yuk. Those either get ignored or turned off.

> Also, if the function is executed it aborts with an error message such as:
> "function incomplete; references unknown word".

That’s not compile-time any more, that’s run-time.

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

#48867

On Wednesday, July 6, 2016 at 7:54:35 PM UTC-7, lawren...@gmail.com wrote:
> On Thursday, July 7, 2016 at 1:45:03 PM UTC+12, hughag...@gmail.com wrote:
> >
> > On Wednesday, July 6, 2016 at 6:31:19 PM UTC-7, Lawrence D’Oliveiro wrote:
> >>
> >> That would mean a reference to an undefined name could only be picked up
> >> at run-time, not compile-time.
> > 
> > No, it could be done at compile-time. I could add this idea to Straight
> > Forth easily enough. 
> > 
> > If a function is called that references an unknown word, the function would
> > still compile, but it would give a warning such as: "unknown word: xxx ".
> 
> Warnings, yuk. Those either get ignored or turned off.

I said that I "could" add this to StraightForth --- I didn't say that I necessarily would.

I agree that if the warning is ignored (likely), fixing the problem would be delayed significantly because the programmer wouldn't find out about the problem until run-time (and only if the function gets executed).

Mutual-recursion isn't very common --- other than in the novice-package in which every example program involves recursion (except the N-Queens program) --- so making mutual-recursion slightly more efficient isn't a major priority for me.

> > Also, if the function is executed it aborts with an error message such as:
> > "function incomplete; references unknown word".
> 
> That’s not compile-time any more, that’s run-time.

True enough.

I meant to say that the error message would be:
"function incomplete; references unknown word: xxx"
That would be a pretty clear error-message that would tell the programmer exactly what went wrong.

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

#48868

DEFER is a simple way to avoid complications and keep the system simple.
The compiler can have any complexity you like. A simple compiler will
compile indirect calls. A more elaborate one will compile direct calls.

DEFER should be used only to resolve mutual-recursions.

For vectored execution there is always VARIABLE and then @ EXECUTE.
If one don't like how it looks, one can implement a VECTOR or some
other naming for a word that just acts as VARIABLE when reserving the
memory cell and like @ EXECUTE when used.

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

#48869

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> DEFER should be used only to resolve mutual-recursions.
> For vectored execution there is always VARIABLE and then @ EXECUTE.

Why not use DEFER for vectored execution?

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

#48872

On Wednesday, July 6, 2016 at 11:24:54 PM UTC-7, Lars Brinkhoff wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> > DEFER should be used only to resolve mutual-recursions.
> > For vectored execution there is always VARIABLE and then @ EXECUTE.
> 
> Why not use DEFER for vectored execution?

I reviewed LowDraw.4th and I don't use DEFER --- I just pass the xt in as a parameter --- now that I think about it, DEFER wouldn't be useful for vectored execution because IS only works at compile-time not run-time.

So, Raimond was right.

Well, actually I have VECTOR in the novice-package that is more efficient than DEFER --- so Raimond was half right.

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

#48874

On 7/6/16 8:24 PM, Lars Brinkhoff wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> DEFER should be used only to resolve mutual-recursions.
>> For vectored execution there is always VARIABLE and then @ EXECUTE.
>
> Why not use DEFER for vectored execution?

DEFER was invented for vectored execution, and for many years has been 
principally used that purpose. Mutual recursion is a small minority 
reason for it to exist.

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]

#48878

Yes. Mutual recursion is not common, and very much a minority use case for Defer ... Is. 

If I found myself doing it a lot I might be tempted to write Forward and Resolve as aliases for Defer and Is just to clarify what was going on, and so I could rewrite them to resolve at compile time if it turned out that the speed difference between a direct and indirect call really mattered.

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

#48898

joi, 7 iulie 2016, 10:12:51 UTC+3, JennyB a scris:
> Yes. Mutual recursion is not common, and very much a minority use case for Defer ... Is. 
> 
> If I found myself doing it a lot I might be tempted to write Forward and Resolve as aliases for Defer and Is just to clarify what was going on, and so I could rewrite them to resolve at compile time if it turned out that the speed difference between a direct and indirect call really mattered.

In your system where the DEFER can work both as a vectored execution and
mutual recursion you can do that.

In my system where the code space is in flash and data space is in ram,
I can't. I'm forced to implement these at the low level. The compiler should
compile mutual rescursions in flash, vectored execution is happening at 
runtime using ram. Tell me why should I choose DEFER for vectored
execution and another naming for mutual recursion compilation? 
In any case, my system will not be compatible with ANS Standard...

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

#48887

On Wednesday, July 6, 2016 at 11:52:17 PM UTC-7, Elizabeth D. Rather wrote:
> On 7/6/16 8:24 PM, Lars Brinkhoff wrote:
> > Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >> DEFER should be used only to resolve mutual-recursions.
> >> For vectored execution there is always VARIABLE and then @ EXECUTE.
> >
> > Why not use DEFER for vectored execution?
> 
> DEFER was invented for vectored execution, and for many years has been 
> principally used that purpose. Mutual recursion is a small minority 
> reason for it to exist.

As I said, DEFER doesn't work for vectored-execution because IS only works at compile-time --- with vectored-execution you typically want to choose the vector at run-time depending upon the user's input.

Also, if you know what DEFER is used for (I don't think you do), then why is it that ANS-Forth doesn't have any deferred words? For example, LITERAL could be deferred --- this would help make it easy to write a cross-compiler  in ANS-Forth that uses the built-in outer-interpreter because LITERAL could be revectored by the HOST colon to compile the literal into the target memory rather than the host memory, and then revectored back to the default by semicolon.

This is not the only example of how Forth can be made more extensible by making various low-level words vectored --- I'm not the only Forther who is aware of this --- Stephen Pelc made a lot of low-level words vectored in VFX.

ANS-Forth is cripple-ware! You purposely crippled ANS-Forth so that it could only be used for writing toy programs --- you did this to prevent ANS-Forth programmers from writing useful programs in competition with Forth Inc. and MPE --- if they do write useful programs, they have to abandon ANS-Forth compliance on the first day of the project, then you howl that their program is non-standard (being non-standard makes it difficult to sell a program because the customer worries that the program can't be ported to another compiler if the compiler-vendor goes out of business).

Stephen Pelc is well aware that ANS-Forth is cripple-ware --- this is why he works around the bugs in ANS-Forth in his VFX --- he makes no effort to fix the ANS-Forth bugs in Forth-200x, because his only goal is to sell VFX, not to provide the Forth community with a usable Standard.

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

#48893

On 07/07/2016 08:53, hughaguilar96@gmail.com wrote:
> On Wednesday, July 6, 2016 at 11:52:17 PM UTC-7, Elizabeth D. Rather wrote:
>> >On 7/6/16 8:24 PM, Lars Brinkhoff wrote:
>>> > >Raimond Dragomir<raimond.dragomir@gmail.com>  writes:
>>>> > >>DEFER should be used only to resolve mutual-recursions.
>>>> > >>For vectored execution there is always VARIABLE and then @ EXECUTE.
>>> > >
>>> > >Why not use DEFER for vectored execution?
>> >
>> >DEFER was invented for vectored execution, and for many years has been
>> >principally used that purpose. Mutual recursion is a small minority
>> >reason for it to exist.
> As I said, DEFER doesn't work for vectored-execution because IS only works at compile-time --- with vectored-execution you typically want to choose the vector at run-time depending upon the user's input.

http://forth-standard.org/standard/core/DEFERStore overcomes that 
problem. Also IS can be used in a word that does the switching if the 
target is known at compile time.

-- 
Gerry

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

#48897

Op Thu, 7 Jul 2016 00:53:01 -0700 (PDT) schreef hughaguilar96@gmail.com:

<snip>
> As I said, DEFER doesn't work for vectored-execution because IS only
> works at compile-time --- with vectored-execution you typically want
> to choose the vector at run-time depending upon the user's input.

IS works in compilation as well as during interpretation.

RTFM stupid!

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

#48927

On Thursday, July 7, 2016 at 3:47:17 AM UTC-7, Coos Haak wrote:
> Op Thu, 7 Jul 2016 00:53:01 -0700 (PDT) schreef hughaguilar96@gmail.com:
> 
> <snip>
> > As I said, DEFER doesn't work for vectored-execution because IS only
> > works at compile-time --- with vectored-execution you typically want
> > to choose the vector at run-time depending upon the user's input.
> 
> IS works in compilation as well as during interpretation.
> 
> RTFM stupid!

DEFER isn't in the ANS-Forth document, so I can't RTFM. If IS is STATE-smart (it is in the novice-package) then it will work during compilation --- with most implementations it only works during interpretation --- because it is not standardized in ANS-Forth, the ANS-Forth programmer can't expect any particular behavior (if he assumes interpretation only, then his code should be portable to most systems).

This code is in the novice-package:

: bad-vector                                    \ pre-initialize vectors with this and overwrite it with a good vector later
    true abort" *** uninitialized vector ***" ;

: defer ( -- )          \ stream: name                          \ defines a deferred word
    create  ['] bad-vector  ,
    does>
        @ execute ;

: is ( xt -- )          \ stream: name                          \ resolves a deferred word
    state @ if
        postpone [']
        postpone >body
        !,
    else
        '  >body !  then ;
immediate

\ DEFER and IS are very traditional, so I provided them.
\ VECTOR is much more efficient.

: <vector> { name | xt -- }
    here  ['] bad-vector ,  to xt
    c" is-" name  get-current :2name                    \ runtime: xt --
        xt lit, !, ;,
    name get-current :name                              \ runtime: --   \runtime runtime: i*x -- j*x
        state@, if,     xt lit,  postpone lit,  postpone @,  postpone execute,
        else,           xt lit,  @,  execute,                                       then,  ;,
        immediate
    ;

: vector ( -- )
    bl word hstr  dup >r  <vector>  r> dealloc ;

Under SwiftForth, this is what gets compiled for DEFER words:

defer aaa  ok
: test-aaa  aaa ;  ok

see test-aaa
48E98F   48E94F ( aaa ) JMP             E9BBFFFFFF ok

see aaa
48E94F   4867D9 ( defer +1A ) CALL      E8857EFFFF

see defer
4867BF   40FAFF ( CREATE ) CALL         E83B93F8FF
4867C4   4 # EBP SUB                    83ED04
4867C7   EBX 0 [EBP] MOV                895D00
4867CA   8276F # EBX MOV                BB6F270800
4867CF   40AA2F ( , ) CALL              E85B42F8FF
4867D4   40DA4F ( (;CODE) ) CALL        E87672F8FF
4867D9   4 # EBP SUB                    83ED04
4867DC   EBX 0 [EBP] MOV                895D00
4867DF   EBX POP                        5B
4867E0   0 [EBX] EBX MOV                8B1B
4867E2   40434F ( EXECUTE ) JMP         E968DBF7FF ok

see execute
40434F   EBX ECX MOV                    8BCB
404351   0 [EBP] EBX MOV                8B5D00
404354   4 # EBP ADD                    83C504
404357   ECX ECX OR                     09C9
404359   40435F JZ                      7404
40435B   EDI ECX ADD                    01F9
40435D   ECX JMP                        FFE1
40435F   RET                            C3 ok

This is what gets compiled for VECTOR words:

vector bbb  ok
: test-bbb  bbb ;  ok

see test-bbb
48EA3F   4 # EBP SUB                    83ED04
48EA42   EBX 0 [EBP] MOV                895D00
48EA45   48E994 # EBX MOV               BB94E94800
48EA4A   0 [EBX] EBX MOV                8B1B
48EA4C   40434F ( EXECUTE ) JMP         E9FE58F7FF ok

As you can see, my VECTOR is more efficient than DEFER is.

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

#48928

Op Thu, 7 Jul 2016 16:19:28 -0700 (PDT) schreef hughaguilar96@gmail.com:

> On Thursday, July 7, 2016 at 3:47:17 AM UTC-7, Coos Haak wrote:
>> Op Thu, 7 Jul 2016 00:53:01 -0700 (PDT) schreef hughaguilar96@gmail.com:
>> 
>> <snip>
>>> As I said, DEFER doesn't work for vectored-execution because IS only
>>> works at compile-time --- with vectored-execution you typically want
>>> to choose the vector at run-time depending upon the user's input.
>> 
>> IS works in compilation as well as during interpretation.
>> 
>> RTFM stupid!
> 
> DEFER isn't in the ANS-Forth document, so I can't RTFM. If IS is STATE-smart (it is in the novice-package) then it will work during compilation --- with most implementations it only works during interpretation --- because it is not standardized in ANS-Forth, the ANS-Forth programmer can't expect any particular behavior (if he assumes interpretation only, then his code should be portable to most systems).
>

Right, OK. But then you can't say anything about it (and IS) if it works
during compilation or during interpretation.
You meant 'in my implementation DEFER doesn't work...'

groet Coos

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

#48931

On 7/7/16 1:39 PM, Coos Haak wrote:
...
>> DEFER isn't in the ANS-Forth document, so I can't RTFM. If IS is STATE-smart (it is in the novice-package) then it will work during compilation --- with most implementations it only works during interpretation --- because it is not standardized in ANS-Forth, the ANS-Forth programmer can't expect any particular behavior (if he assumes interpretation only, then his code should be portable to most systems).
>>
>
> Right, OK. But then you can't say anything about it (and IS) if it works
> during compilation or during interpretation.
> You meant 'in my implementation DEFER doesn't work...'

DEFER is a defining word (like VARIABLE), whose behavior is to execute 
an xt in its data space. Possible (common) definitions are:

:NONAME ABORT" Unitialized DEFER" ;

: DEFER ( xt -- )   CREATE ,
    DOES> @ EXECUTE ;
	
DEFER MYTYPE   ' TYPE IS MYTYPE

Whether it is initialized when it's defined and how you handle an 
uninitialized DEFER, etc., are not specified; it's an ambiguous 
condition if it's uninitialized or if the object of IS is not defined by 
DEFER.

The full definitions of DEFER, IS, and related words are in Forth2012, 
although they're consistent with long-standing common usage. There was 
actually discussion of standardizing them in Forth94, but the prospect 
was raised so late in the process no one had the energy to pursue it.

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]

#48933

On Thursday, July 7, 2016 at 5:31:57 PM UTC-7, Elizabeth D. Rather wrote:
> The full definitions of DEFER, IS, and related words are in Forth2012, 
> although they're consistent with long-standing common usage. There was 
> actually discussion of standardizing them in Forth94, but the prospect 
> was raised so late in the process no one had the energy to pursue it.

You didn't put DEFER or VECTOR or any such thing in ANS-Forth because you don't know what deferred words are used for.

If you knew what DEFER is used for, then why is it that ANS-Forth doesn't have any deferred words? For example, LITERAL could be deferred --- this would help make it easy to write a cross-compiler  in ANS-Forth that uses the built-in outer-interpreter because LITERAL could be revectored by the HOST colon to compile the literal into the target memory rather than the host memory, and then revectored back to the default by semicolon. 

This is not the only example of how Forth can be made more extensible by making various low-level words vectored --- I'm not the only Forther who is aware of this --- Stephen Pelc made a lot of low-level words vectored in VFX. 

ANS-Forth is cripple-ware! You purposely crippled ANS-Forth so that it could only be used for writing toy programs --- you did this to prevent ANS-Forth programmers from writing useful programs in competition with Forth Inc. and MPE --- if they do write useful programs, they have to abandon ANS-Forth compliance on the first day of the project, then you howl that their program is non-standard (being non-standard makes it difficult to sell a program because the customer worries that the program can't be ported to another compiler if the compiler-vendor goes out of business). 

Stephen Pelc is well aware that ANS-Forth is cripple-ware --- this is why he works around the bugs in ANS-Forth in his VFX --- he makes no effort to fix the ANS-Forth bugs in Forth-200x, because his only goal is to sell VFX, not to provide the Forth community with a usable Standard. 

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

#49100

On Thursday, July 7, 2016 at 5:31:57 PM UTC-7, Elizabeth D. Rather wrote:
> 
> The full definitions of DEFER, IS, and related words are in Forth2012, 
> although they're consistent with long-standing common usage. There was 
> actually discussion of standardizing them in Forth94, but the prospect 
> was raised so late in the process no one had the energy to pursue it.
> 

I'm only using a small subset of the DEFER standard, just for forward references in ROM. IS resolves a forward branch (similar to THEN). I can see how your example provided above could do something similar in CDATA space (a non-modifiable xt) and behave more like the classic DEFER in IDATA space.

I never got around to a full DEFER because my new favorite word for declaring execution vectors is BUFFER:. MOVE performs the function of IS.

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

#49107

On 7/12/16 4:48 PM, Brad Eckert wrote:
> On Thursday, July 7, 2016 at 5:31:57 PM UTC-7, Elizabeth D. Rather wrote:
>>
>> The full definitions of DEFER, IS, and related words are in Forth2012,
>> although they're consistent with long-standing common usage. There was
>> actually discussion of standardizing them in Forth94, but the prospect
>> was raised so late in the process no one had the energy to pursue it.
>>
>
> I'm only using a small subset of the DEFER standard, just for forward references in ROM. IS resolves a forward branch (similar to THEN). I can see how your example provided above could do something similar in CDATA space (a non-modifiable xt) and behave more like the classic DEFER in IDATA space.
>
> I never got around to a full DEFER because my new favorite word for declaring execution vectors is BUFFER:. MOVE performs the function of IS.

Well, sure, if a bunch of things need to be changed, like the responses 
to a button panel.

DEFER/IS is mostly for single things that need to change, such as your 
terminal display & keyboard.

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web