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

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

Can i rely on >BODY for anything at all?

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

Contents

  Can i rely on >BODY for anything at all? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-20 01:03 +0000
    Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 02:18 +0100
      Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-20 13:58 +1100
        Re: Can i rely on >BODY for anything at all? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-19 23:59 -0700
          Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-21 23:17 +1100
            Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 07:27 -0500
              Re: Can i rely on >BODY for anything at all? Sieur de Bienville <morrimichael@gmail.com> - 2013-03-21 07:01 -0700
                Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 09:14 -0500
                  DEFER@ (was: Can i rely on >BODY for anything at all?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-21 17:31 +0000
                  Re: Can i rely on >BODY for anything at all? Sieur de Bienville <morrimichael@gmail.com> - 2013-03-22 14:30 -0700
                    Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-23 05:34 -0500
                      Re: Can i rely on >BODY for anything at all? Brad Eckert <hwfwguy@gmail.com> - 2013-03-25 09:44 -0700
              Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-22 01:30 +1100
                Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-21 08:17 -0700
                  Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-22 12:14 +1100
                    Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-22 03:33 -0700
                Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 15:15 -0500
        Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-22 00:24 +0100
          Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-22 11:49 +1100
            Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-22 04:22 -0700
            Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-22 22:38 +0100
              Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-23 21:37 +1100
                Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-23 05:06 -0700
                Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-23 13:18 +0100
                  Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-24 00:17 +1100
                    Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-23 15:10 +0100
                      Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-24 01:25 +0100
                        Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-26 12:55 +1100
                          Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-26 05:51 -0500
                            Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-28 23:31 +1100
                              Re: Can i rely on >BODY for anything at all? stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-28 12:57 +0000
                              Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-28 08:15 -0500
                                Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-30 12:56 +1100
                                  Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-30 04:56 -0500
                                  Re: Can i rely on >BODY for anything at all? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 10:32 +0000
                                    Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-04-04 12:36 +1000
                              Re: Can i rely on >BODY for anything at all? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-28 17:39 +0000
                          Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-28 21:32 +1100
                            Re: Can i rely on >BODY for anything at all? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-28 11:58 +0000
                              Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-29 00:59 +1100
                            Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-28 08:41 -1000
                              Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-30 12:43 +1100
                        Re: Can i rely on >BODY for anything at all? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-27 17:15 +0000
                          Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-27 22:04 +0100
                            Re: Can i rely on >BODY for anything at all? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-28 12:17 +0000
                      Re: Can i rely on >BODY for anything at all? "Ed" <invalid@nospam.com> - 2013-03-26 13:13 +1100
                    Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-24 01:21 +0100
      Re: Can i rely on >BODY for anything at all? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-20 00:01 -0700
        Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-19 22:02 -1000
    Re: Can i rely on >BODY for anything at all? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-20 05:27 -0400
      Re: Can i rely on >BODY for anything at all? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-20 10:27 +0000
        Re: Can i rely on >BODY for anything at all? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-20 03:23 -0700
          Re: Can i rely on >BODY for anything at all? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-20 17:22 +0000
        Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-20 07:52 -1000
          Re: Can i rely on >BODY for anything at all? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-20 18:56 +0000
          OT: SF-translations Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-20 21:44 +0000
            Re: OT: SF-translations Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 23:12 +0100
              Re: OT: SF-translations Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-20 22:45 +0000
                Re: OT: SF-translations Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-21 15:50 +0100
            Re: OT: SF-translations "Elizabeth D. Rather" <erather@forth.com> - 2013-03-20 12:38 -1000
          Re: Can i rely on >BODY for anything at all? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-21 05:52 -0400
            Re: Can i rely on >BODY for anything at all? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-21 10:08 +0000
            Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-21 08:17 -1000
              Re: Can i rely on >BODY for anything at all? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-21 18:46 +0000
              Re: Can i rely on >BODY for anything at all? mhx@iae.nl (Marcel Hendrix) - 2013-03-21 20:20 +0200
                Re: Can i rely on >BODY for anything at all? Brad Eckert <hwfwguy@gmail.com> - 2013-03-22 08:41 -0700
                  Re: Can i rely on >BODY for anything at all? m.a.m.hendrix@tue.nl - 2013-03-22 09:03 -0700
                    Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-22 08:05 -1000
                      Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-22 22:17 +0100
                        Re: Can i rely on >BODY for anything at all? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-23 12:07 +0000
                          Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-24 01:40 +0100
                            Re: Can i rely on >BODY for anything at all? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-24 03:55 -0500
                            Re: Can i rely on >BODY for anything at all? stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-24 12:18 +0000
                              Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-24 06:04 -0700
                              Re: Can i rely on >BODY for anything at all? Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-24 15:31 +0100
                      Re: Can i rely on >BODY for anything at all? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-23 02:26 +0000
                        Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-22 17:39 -1000
        Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-20 19:18 +0100
          Re: Can i rely on >BODY for anything at all? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-21 16:18 +0000
            Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-22 00:34 +0100
              Re: Can i rely on >BODY for anything at all? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-21 23:54 +0000
                Re: Can i rely on >BODY for anything at all? Coos Haak <chforth@hccnet.nl> - 2013-03-22 00:54 +0100
                Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-21 14:37 -1000
      Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-20 04:48 -0700
        Re: Can i rely on >BODY for anything at all? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-21 05:43 -0400
          Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-21 08:30 -0700
            Re: Can i rely on >BODY for anything at all? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-22 03:31 -0400
              Re: Can i rely on >BODY for anything at all? "Elizabeth D. Rather" <erather@forth.com> - 2013-03-21 22:07 -1000
              Re: Can i rely on >BODY for anything at all? Alex McDonald <blog@rivadpm.com> - 2013-03-22 03:37 -0700
      Re: Can i rely on >BODY for anything at all? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-20 17:14 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#20956

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:9YmdnVQMC9HratTMnZ2dnUVZ_tqdnZ2d@supernews.com...
> On 3/20/13 12:27 AM, Zbiggy wrote:
> > In comp.lang.forth, Rod Pemberton wrote:

> >> Basically, stick to using >BODY only on CREATEd words you
> >> created.
> >
> > I recalled chapter 10 of "Starting Forth", where >BODY has
> > been used for colon word's "innards" examination
> > ( [link] ).
> >
> > Yes, SF has been written in pre-ANS days. Actually, in most of
> > the present Forth implementations >BODY still shows, well,
> > "something". At least it seems, that that "something" is taken
> > from proper place.
>
> Starting Forth was written 35 years ago. ANS Forth specified
> that >BODY could be portably used only on words defined by
> CREATE 20 years ago. Are you still writing C programs using
> *only* K&R as your guide?
>

Zbiggy, did she just ask you if you're writing C programs?  Do
you?  Well, I didn't know you did, if you do.  I do.  So, why do I
suspect that question was for me, but the statement was for you?

(No, I've never used K&R as my guide.  I did only use a subset of
modern C for a long time to avoid certain coding mistakes.
Lately, I've almost exclusively reverted to pure ANSI C, or at
least where I can...  Modern C is not needed.  All of C is not
needed.  Only C's <stdio.h> from it's library is needed for file
I/O.  So, most of C's standard libary is not needed.  I.e., most
of C is optional to a good programmer.  However, much of it is
convenient in reducing amount of coding time required.)

> And, yes, the only way to know that an object was built using
> CREATE is to limit your expectations to words you yourself
> wrote.
>

Well, I asked if anyone wanted:  isCREATE?   Perhaps, it should be
called:  isCREATEd?  If there was an actual need for this, I'd
suspect it would've come up by now...

My solution to ensure >BODY works when the user so desired was to
make sure : (colon) :NONAME VARIABLE CONSTANT VALUE
use CREATE.  I didn't have to use CREATE for : (colon) or :NONAME.
In fact, it was quite some work to transform my : (colon) to do
so.  It was coded in C.


Rod Pemberton

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

#20958

In comp.lang.forth, Rod Pemberton wrote:

> Zbiggy, did she just ask you if you're writing C programs?  Do
> you?  Well, I didn't know you did, if you do.  I do.  So, why do I
> suspect that question was for me, but the statement was for you?

I thought, it was a "rhetorical question".

Yes, I create programs in C - sometimes - and although I read more than
"The C programming language", I prefer "plain C" over C++/C#/C-whatever,
because it's the simplest variant of C, and I don't need "polymorphisms"
neither "classes" nor "inheritances". Somehow I can live without OOP at
all - and even in case, I decided to use it, I could as well dispose of it.
-- 
The consensus was, as usual in this community, that there is no consensus. (RA)

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

#20989

On 3/20/13 11:52 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote in message
> news:9YmdnVQMC9HratTMnZ2dnUVZ_tqdnZ2d@supernews.com...
>> On 3/20/13 12:27 AM, Zbiggy wrote:
>>> In comp.lang.forth, Rod Pemberton wrote:
>
>>>> Basically, stick to using >BODY only on CREATEd words you
>>>> created.
>>>
>>> I recalled chapter 10 of "Starting Forth", where >BODY has
>>> been used for colon word's "innards" examination
>>> ( [link] ).
>>>
>>> Yes, SF has been written in pre-ANS days. Actually, in most of
>>> the present Forth implementations >BODY still shows, well,
>>> "something". At least it seems, that that "something" is taken
>>> from proper place.
>>
>> Starting Forth was written 35 years ago. ANS Forth specified
>> that >BODY could be portably used only on words defined by
>> CREATE 20 years ago. Are you still writing C programs using
>> *only* K&R as your guide?
>>
>
> Zbiggy, did she just ask you if you're writing C programs?  Do
> you?  Well, I didn't know you did, if you do.  I do.  So, why do I
> suspect that question was for me, but the statement was for you?
>
> (No, I've never used K&R as my guide.  I did only use a subset of
> modern C for a long time to avoid certain coding mistakes.
> Lately, I've almost exclusively reverted to pure ANSI C, or at
> least where I can...  Modern C is not needed.  All of C is not
> needed.  Only C's <stdio.h> from it's library is needed for file
> I/O.  So, most of C's standard libary is not needed.  I.e., most
> of C is optional to a good programmer.  However, much of it is
> convenient in reducing amount of coding time required.)

My question was mainly rhetorical, directed at folks who think they can 
learn Forth from a popular book (as opposed to a standard or formal 
manual) written 35 years ago, rather than more contemporary materials.

>> And, yes, the only way to know that an object was built using
>> CREATE is to limit your expectations to words you yourself
>> wrote.
>>
>
> Well, I asked if anyone wanted:  isCREATE?   Perhaps, it should be
> called:  isCREATEd?  If there was an actual need for this, I'd
> suspect it would've come up by now...
>
> My solution to ensure >BODY works when the user so desired was to
> make sure : (colon) :NONAME VARIABLE CONSTANT VALUE
> use CREATE.  I didn't have to use CREATE for : (colon) or :NONAME.
> In fact, it was quite some work to transform my : (colon) to do
> so.  It was coded in C.

In my experience there is virtually no demand for >BODY. The cases I've 
seen of its use could usually have been managed more effectively using a 
different data object or access code.

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]

#20990

In comp.lang.forth, Elizabeth D. Rather wrote:

> My question was mainly rhetorical, directed at folks who think they can 
> learn Forth from a popular book (as opposed to a standard or formal 
> manual) written 35 years ago, rather than more contemporary materials.

Well, exactly there was a bit longer example using >BODY - which I could
refer to.
-- 
The consensus was, as usual in this community, that there is no consensus. (RA)

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

#20993

"Elizabeth D. Rather" <erather@forth.com> writes Re: Can i rely on >BODY for anything at all?
[..]
> In my experience there is virtually no demand for >BODY. The cases I've 
> seen of its use could usually have been managed more effectively using a 
> different data object or access code.

Let's see ...

Searching for: >BODY

chess.frt(37): : is	' >body postpone literal  
basic\basic.frt(155): VOCABULARY KEYWORDS  ' KEYWORDS >BODY =: keyword.wid  PRIVATE
SieveOfZakiya4.frt(27): lndx ALLOCATE ?ALLOCATE ['] sieve >BODY ! 
mini-oof.frt(8): : defines ( xt class "name" -- ) ' >body @ + ! ;
expert90\expert1.frt(170): : HAS	 TRUE  ' >BODY ! ;  : DOES	HAS    ;  ( Brad Rodriguez' expert system )
tetris.frt(201): >BODY ['] BRICK >BODY #32 CMOVE ; PRIVATE
gray-3\miniasm2.frt(241): getvar >body ;
lisp\lisp.frt(539): IF >BODY @ ELSE DROP NIL ENDIF
hobjects.frt(186): >body @ ;
lists.frt(860): IF >body a@ ELSE drop nil THEN
mergesort.frt(42): limit CELLS ALLOCATE THROW ['] []temp >BODY !  \ temporary array of same size 
objects.frt(176): IF NIP   >BODY
mix.frt(1317): ' >BODY @ ! ; ( Knut's MIX )
ftran1.frt(100): ' >BODY 
manx.frt(782): : (N?)	' >BODY CELL+ 2@ \ ( name --- u )
pl1.frt(869): : h>b head> @ >body ; PRIVATE	( 'head -- 'body ) ( My PL1 compiler )
sod64\cross.frt(287): TRANSIENT ' >BODY  @		\ Find the forward ref word in the
asm.frt(1197): ' >BODY @ POSTPONE LITERAL ; PRIVATE ALSO FORTH IMMEDIATE PREVIOUS
complex.frt(142): : DEFINES	' >BODY @ (DEFINES) ;  PRIVATE	\ <exec-token> "name" --> <> 
queues.frt(228): ['] q >BODY LOCAL 'adm
strings.frt(393): : DEFINES	' >BODY @ (DEFINES) ;  		\ <exec-token> "name" --> <> 
structs.frt(184): : BEGIN-STRUCTURE ( "name" -- addr 1 0 ) 0 VALUE  @LATEST HEAD> @ >BODY 1 0 ;
xopg.frt(720): >BODY CELL+ @
fjack\types.frt(101): >BODY COMP-CHANNEL, @iFORTH-OPS COMP-VALUE ;

Found 256 occurrence(s)

It seems I got some improving to do:-)

-marcel

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

#21046

On Thursday, March 21, 2013 11:20:01 AM UTC-7, Marcel Hendrix wrote:
> "Elizabeth D. Rather"  writes Re: Can i rely on >BODY for anything at all?
> 
> [..]
> 
> > In my experience there is virtually no demand for >BODY. The cases I've 
> > seen of its use could usually have been managed more effectively using a 
> > different data object or access code.
> 
> It seems I got some improving to do:-)
> 
SwiftForth i386-Win32 3.4.3 23-Jun-2012
wh >body
WORDLIST: FORTH
C:\ForthInc\SwiftForth\src\kernel\dictionary.f
  9__83| ICODE >BODY ( xt -- n )
  9_137| : N>BODY ( nfa -- body )   NAME> >BODY ;
C:\ForthInc\SwiftForth\src\kernel\win32\imports.f
 13_115| @+ R@ + @ ['] ExitProcess      >BODY !
 13_116| @+ R@ + @ ['] LoadLibrary      >BODY !
 13_117| @+ R@ + @ ['] GetProcAddress   >BODY !
 13_118| @+ R@ + @ ['] GetModuleHandle  >BODY !
 13_119| @  R> + @ ['] MessageBox       >BODY ! ;
C:\ForthInc\SwiftForth\src\kernel\interp.f
 23_300| LAST @ NAME> >BODY -
C:\ForthInc\SwiftForth\src\kernel\files.f
 25_125| @REL DUP WHILE  DUP LINK> >BODY @ R@ = IF ( match)
C:\ForthInc\SwiftForth\src\kernel\defining.f
 27_141| : >BODY! ( n xt -- )   >BODY ! ;
 27_142| : >BODY+! ( n xt -- )   >BODY +! ;
 27_169| STATE @ IF  POSTPONE LITERAL POSTPONE >BODY  EXIT  THEN   >BODY ;
C:\ForthInc\SwiftForth\src\kernel\switch.f
 29__92| ' >BODY  7777 SWAP ;
C:\ForthInc\SwiftForth\src\kernel\start.f
 34_100| | : ?ED ( -- flag )   ['] EDIT-START >BODY @ 0<> ;
C:\ForthInc\SwiftForth\src\ide\errmessages.f
 37_110| ['] (THROW) >BODY >LINK OVER , , ;
C:\ForthInc\SwiftForth\src\ide\encapsulate.f
 38__55| DUP >BODY CELL+ CELL+ @ ['] WORDLIST <> IOR_PACKAGENOT ?THROW
 38__56| >BODY CELL+ @ OPEN-PACKAGE  EXIT
C:\ForthInc\SwiftForth\src\ide\patterns.f
 43_1067| LASTLIT @ LASTCHILD @ >BODY @ LASTLIT 2!
 43_1079| LASTLIT @ LASTCHILD @ >BODY @ LASTLIT 2!
 43_1089| LASTCHILD @ >BODY @ [ESI] EBX LEA
 43_1096| LASTCHILD @ >BODY @ [ESI] EBX MOV
 43_1102| EBX LASTCHILD @ >BODY @ [ESI] MOV
 43_1109| LASTLIT @ # LASTCHILD @ >BODY @ [ESI] MOV
 43_1118| EBX LASTCHILD @ >BODY @ [ESI] MOV
 43_1127| LASTCHILD @ >BODY @ [ESI] EBX 0 RULEX
 43_1139| LASTCHILD @ >BODY @ [ESI] PUSH
 43_1143| LASTCHILD @ >BODY @ [ESI] POP
 43_1154| 0 # LASTCHILD @ >BODY @ [ESI] CMP
 43_1161| 0 # LASTCHILD @ >BODY @ [ESI] CMP
 43_1346| OPTIMIZE (LITERAL) >BODY WITH LIT->BODY
C:\ForthInc\SwiftForth\src\ide\aswoop.f
 49_210| CREATE DUP CELLS , 1+ DOES> @ SWAP >BODY + ;
 49_330| @ 'FLAVOR @ >BODY + ;
 49_1006| >BODY 2 CELLS + @+ SIZEOF >R ( n 'n)
 49_1154| THIS POSTPONE LITERAL  POSTPONE >BODY
 49_1155| THIS >BODY - CELL+ POSTPONE LITERAL  POSTPONE +  END-REFERENCE ;
C:\ForthInc\SwiftForth\src\ide\locate.f
 56__32| DUP LINK> >BODY @ THIRD = IF ( match)
 56__47| DUP LINK> >BODY @ 4 H.0 SPACE
C:\ForthInc\SwiftForth\src\ide\win32\imports.f
 62_128| DROP >BODY @ 0<> ;                   \ true if there's a handle
 62_132| >BODY @ FreeLibrary DROP ;           \ Get handle, close it
 62_152| >BODY 'LIB !REL  2DROP  EXIT  THEN
 62_243| CR DUP NAME> >BODY @+ 8 H.R  SPACE SPACE
C:\ForthInc\SwiftForth\src\ide\win32\winconstants.f
 63__53| ['] FindWin32Constant >BODY @ 0= ;
C:\ForthInc\SwiftForth\src\ide\win32\options.f
114__54| CR DUP H.8 SPACE DUP COUNT BRIGHT TYPE NORMAL SPACE NAME> >BODY COUNT TYPE ;
C:\ForthInc\SwiftForth\src\ide\win32\memtools.f
122_118| DUP (.') NAME> >BODY =
122_475| ['] DMPLINE >BODY @ CASE
122_483| ['] DMPLINE >BODY @ CASE
C:\ForthInc\SwiftForth\src\ide\win32\wordbrowser.f
123_225| HWND _VOCS CB_SETITEMDATA R> R> NAME> >BODY CELL+ @
123_230| ['] .ID >BODY @ >R  ok

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

#21048

On Friday, March 22, 2013 4:41:08 PM UTC+1, Brad Eckert wrote:
> On Thursday, March 21, 2013 11:20:01 AM UTC-7, Marcel Hendrix wrote: > "Elizabeth D. Rather" writes Re: Can i rely on >BODY for anything at all?
[..]
But that is all system source. 
(Most of) my examples are classic programs.

-marcel

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

#21056

On 3/22/13 6:03 AM, m.a.m.hendrix@tue.nl wrote:
> On Friday, March 22, 2013 4:41:08 PM UTC+1, Brad Eckert wrote:
>> On Thursday, March 21, 2013 11:20:01 AM UTC-7, Marcel Hendrix wrote: > "Elizabeth D. Rather" writes Re: Can i rely on >BODY for anything at all?
> [..]
> But that is all system source.
> (Most of) my examples are classic programs.

Yes. >BODY is useful in the context of a system, but then you know 
exactly how everything works, when it's appropriate, and what you expect 
to find in the referenced space.

The requirement for portability has to do with user application code. I 
have found very little need for it in application code. Maybe the 
difference is that Marcel is using it on his system where he knows how 
everything works and isn't trying to write portable code, or because 
he's using it with words defined by CREATE.

Remember, standards are all about portability. A rule such as requiring 
 >BODY to be used with CREATEd words is defining what a user can expect 
to be portable. You can do whatever works on your system of choice if 
you aren't attempting to write portable application code.

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]

#21059

Elizabeth D. Rather wrote:
> The requirement for portability has to do with user application code. I
> have found very little need for it in application code. Maybe the
> difference is that Marcel is using it on his system where he knows how
> everything works and isn't trying to write portable code, or because
> he's using it with words defined by CREATE.

We often don't have enough entitlements to write portable code.  >BODY is 
one of them.  I don't expect colon definitions to have something predictable 
on >BODY, because doing so would prevent too many optimizations.  But I 
don't think it's a major obstackle for system implementers to make >BODY 
work "right" on DEFERred words, VALUEs, and similar.

Such an entitlement should work on *data* associated with the word, not on 
code.  Looking at e.g. VFX shows that the half-done code-data separation 
spoils it, otherwise it works fine.  Variables and values have an additional 
indirection, DEFERs and CREATE work with >BODY.  As you can turn that off 
and on (the value IDATA? is true for separated data and code), >BODY 
probably needs some intelligence to do its job.  But as usual, options and 
inconsistencies make the code more complicated in other places, too.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#21081

Bernd Paysan <bernd.paysan@gmx.de> writes:
>But I 
>don't think it's a major obstackle for system implementers to make >BODY 
>work "right" on DEFERred words, VALUEs, and similar.

Concerning >BODY for DEFERred words, the X:deferred proposal
<http://www.forth200x.org/deferred.html> has a section on that:

| >BODY vs. DEFER@/DEFER!
| 
| Instead of having DEFER@ and DEFER!, one could also extend >BODY to be
| applicable to deferred words, and to use >BODY @ instead of DEFER@ and
| >BODY ! instead of DEFER!. This change would eliminate two words, but
| also eliminate a number of implementation options. Two systems have
| been named where >BODY @/! would not work for deferred words (as
| implemented on these systems).

So we considered that option.

- 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 2013: http://www.euroforth.org/ef13/

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

#21096

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>But I
>>don't think it's a major obstackle for system implementers to make >BODY
>>work "right" on DEFERred words, VALUEs, and similar.
> 
> Concerning >BODY for DEFERred words, the X:deferred proposal
> <http://www.forth200x.org/deferred.html> has a section on that:
> 
> | >BODY vs. DEFER@/DEFER!
> | 
> | Instead of having DEFER@ and DEFER!, one could also extend >BODY to be
> | applicable to deferred words, and to use >BODY @ instead of DEFER@ and
> | >BODY ! instead of DEFER!. This change would eliminate two words, but
> | also eliminate a number of implementation options. Two systems have
> | been named where >BODY @/! would not work for deferred words (as
> | implemented on these systems).
> 
> So we considered that option.

Well, we have considered that two systems would need to change their DEFER 
to make >BODY work.  And that a Defer proposal has less oppositon that way.  
But would that have been a major obstacle?  I doubt.  A minor nuisance for 
the maintainers of these two systems.

All the major high-quality Forths (like VFX, SwiftForth, Gforth) I've looked 
at have absolutely no problem with : DEFER! >BODY ! ; today.

If we are at counting words: IMHO, IS is another candidate for elimination.  
We already have TO as polymorph parsing method to assign words with values, 
with all its troubles (TO being either parsing or non-parsing is 
particularly troublesome).  If we have such troublesome words, we should at 
least reduce *them* to the bare minimum.

For legacy code, IS should be a synonym for TO.  It might also be 
implemented in a way tht works only on DEFER.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#21102

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>But I
>>>don't think it's a major obstackle for system implementers to make >BODY
>>>work "right" on DEFERred words, VALUEs, and similar.
>> 
>> Concerning >BODY for DEFERred words, the X:deferred proposal
>> <http://www.forth200x.org/deferred.html> has a section on that:
>> 
>> | >BODY vs. DEFER@/DEFER!
>> | 
>> | Instead of having DEFER@ and DEFER!, one could also extend >BODY to be
>> | applicable to deferred words, and to use >BODY @ instead of DEFER@ and
>> | >BODY ! instead of DEFER!. This change would eliminate two words, but
>> | also eliminate a number of implementation options. Two systems have
>> | been named where >BODY @/! would not work for deferred words (as
>> | implemented on these systems).
>> 
>> So we considered that option.
> 
> Well, we have considered that two systems would need to change their
> DEFER to make >BODY work.  And that a Defer proposal has less
> oppositon that way.  But would that have been a major obstacle?  I
> doubt.  A minor nuisance for the maintainers of these two systems.
> 
> All the major high-quality Forths (like VFX, SwiftForth, Gforth)
> I've looked at have absolutely no problem with : DEFER! >BODY ! ;
> today.

True enough.  One some types of processor architecture, though, an
indirect jump might be significantly more expensive than a direct one.
On ARM 64 you'd have

       ldr scratch, l
       br l
l:     <absolute address>

and with position-independent XTs you'd need more:

       ldr scratch, l
       add scratch, base, scratch
       br scratch
l:     <XT>

Does this really matter for  DEFER  ?  Probably not.

> If we are at counting words: IMHO, IS is another candidate for
> elimination.  We already have TO as polymorph parsing method to
> assign words with values, with all its troubles (TO being either
> parsing or non-parsing is particularly troublesome).  If we have
> such troublesome words, we should at least reduce *them* to the bare
> minimum.
> For legacy code, IS should be a synonym for TO.

Indeed.

Andrew.

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

#21103

On Sun, 24 Mar 2013 01:40:26 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>Well, we have considered that two systems would need to change their DEFER 
>to make >BODY work.  And that a Defer proposal has less oppositon that way.  
>But would that have been a major obstacle?  I doubt.  A minor nuisance for 
>the maintainers of these two systems.
>
>All the major high-quality Forths (like VFX, SwiftForth, Gforth) I've looked 
>at have absolutely no problem with : DEFER! >BODY ! ; today.

I have looked at a CPU architecture recently for which a sensible
implementation is:
: defer!  swap 8 um* rot >body 2!  ;
No problem with >BODY, but plenty with the single cell assumption.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#21106

On Mar 24, 12:18 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Sun, 24 Mar 2013 01:40:26 +0100, Bernd Paysan <bernd.pay...@gmx.de>
> wrote:
>
> >Well, we have considered that two systems would need to change their DEFER
> >to make >BODY work.  And that a Defer proposal has less oppositon that way.
> >But would that have been a major obstacle?  I doubt.  A minor nuisance for
> >the maintainers of these two systems.
>
> >All the major high-quality Forths (like VFX, SwiftForth, Gforth) I've looked
> >at have absolutely no problem with : DEFER! >BODY ! ; today.
>
> I have looked at a CPU architecture recently for which a sensible
> implementation is:
> : defer!  swap 8 um* rot >body 2!  ;
> No problem with >BODY, but plenty with the single cell assumption.

Windows 64 bit runs LLP64 (32 bit longs, 64 bit address), unlike other
*nix which are LP64 (64 bit longs). It's possible to write, and I have
considered, a 32 bit cell and a 32 bit PIC addressing scheme to ease
my way into a native 64 bit Windows Forth. But that still has issues,
since Windows system addresses are a full 64 bits.

>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads

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

#21109

Stephen Pelc wrote:
> I have looked at a CPU architecture recently for which a sensible
> implementation is:
> : defer!  swap 8 um* rot >body 2!  ;
> No problem with >BODY, but plenty with the single cell assumption.

How does your EXECUTE look like on that architecture?  The question here is: 
If you need some crazy transformation of an Xt to a jumpable address for 
DEFER, you might want it to speed up EXECUTE as well, and then, the extra 
effort in DEFER isn't really giving that much benefit.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#21069

In article <dLmdnRN9qoryANHMnZ2dnUVZ_uWdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 3/22/13 6:03 AM, m.a.m.hendrix@tue.nl wrote:
>> On Friday, March 22, 2013 4:41:08 PM UTC+1, Brad Eckert wrote:
>>> On Thursday, March 21, 2013 11:20:01 AM UTC-7, Marcel Hendrix wrote:
>> "Elizabeth D. Rather" writes Re: Can i rely on >BODY for anything at
>all?
>> [..]
>> But that is all system source.
>> (Most of) my examples are classic programs.
>
>Yes. >BODY is useful in the context of a system, but then you know
>exactly how everything works, when it's appropriate, and what you expect
>to find in the referenced space.
>
>The requirement for portability has to do with user application code. I
>have found very little need for it in application code. Maybe the
>difference is that Marcel is using it on his system where he knows how
>everything works and isn't trying to write portable code, or because
>he's using it with words defined by CREATE.
>
>Remember, standards are all about portability. A rule such as requiring
> >BODY to be used with CREATEd words is defining what a user can expect
>to be portable. You can do whatever works on your system of choice if
>you aren't attempting to write portable application code.

It makes sense that >BODY is used sparingly. The CREATE DOES> construction
is a kind of data hiding, OO type if you wish. Reaching through towards
the data goes against the spirit.

The exceptions are additions made by the implementor to the data type,
and of course test code.

>
>Cheers,
>Elizabeth

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#21070

On 3/22/13 4:26 PM, Albert van der Horst wrote:
> In article <dLmdnRN9qoryANHMnZ2dnUVZ_uWdnZ2d@supernews.com>,
> Elizabeth D. Rather <erather@forth.com> wrote:
>> On 3/22/13 6:03 AM, m.a.m.hendrix@tue.nl wrote:
>>> On Friday, March 22, 2013 4:41:08 PM UTC+1, Brad Eckert wrote:
>>>> On Thursday, March 21, 2013 11:20:01 AM UTC-7, Marcel Hendrix wrote:
>>> "Elizabeth D. Rather" writes Re: Can i rely on >BODY for anything at
>> all?
>>> [..]
>>> But that is all system source.
>>> (Most of) my examples are classic programs.
>>
>> Yes. >BODY is useful in the context of a system, but then you know
>> exactly how everything works, when it's appropriate, and what you expect
>> to find in the referenced space.
>>
>> The requirement for portability has to do with user application code. I
>> have found very little need for it in application code. Maybe the
>> difference is that Marcel is using it on his system where he knows how
>> everything works and isn't trying to write portable code, or because
>> he's using it with words defined by CREATE.
>>
>> Remember, standards are all about portability. A rule such as requiring
>>> BODY to be used with CREATEd words is defining what a user can expect
>> to be portable. You can do whatever works on your system of choice if
>> you aren't attempting to write portable application code.
>
> It makes sense that >BODY is used sparingly. The CREATE DOES> construction
> is a kind of data hiding, OO type if you wish. Reaching through towards
> the data goes against the spirit.
>
> The exceptions are additions made by the implementor to the data type,
> and of course test code.

Well, of course an object defined with CREATE DOES> *is* available for 
 >BODY access.

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]

#20924

Op Wed, 20 Mar 2013 10:27:21 +0000 (UTC) schreef Zbiggy:

> In comp.lang.forth, Rod Pemberton wrote:
> 
>> Basically, stick to using >BODY only on CREATEd words you created.
> 
> I recalled chapter 10 of "Starting Forth", where >BODY has been used for
> colon word's "innards" examination
> ( http://www.forth.com/starting-forth/sf10/sf10.html ).
> 
> Yes, SF has been written in pre-ANS days. Actually, in most of the present
> Forth implementations >BODY still shows, well, "something". At least it
> seems, that that "something" is taken from proper place.
> 
> The most strange behaviour I noticed in FPC, where DUMP-ing address returned
> by >BODY showed obviously something completely unrelated, like directories
> path/names. Most probably a bug(?).

The value stored at >BODY in F-PC and CHForth is a pointer to the start of
the colon definition in a different segment. In CHForth a colon definition
uses 4 (>BODY, aligned) + 2 (the pointer) bytes in the code segement. The
rest is in the list segment. The headers are in a third segment. This way,
there is a lot of memory left (40-50 Kb) for code and data in the
codesegment.
F-PC goes further, the list/colon segment can be larger than 64 K because
colon definions use a segmented address, thats why return addresses on the
return stack are 32 bits, two cells. Cells on the data stack are 16 bit.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#20981

In comp.lang.forth, Coos Haak wrote:

> The value stored at >BODY in F-PC and CHForth is a pointer to the start of
> the colon definition in a different segment. [..]

But I believe, this is enforced by 8086 ("real mode") architecture - and in
case of "linear address space" the things usually look out like on the
typical "Forth memory map" picture?
-- 
The consensus was, as usual in this community, that there is no consensus. (RA)

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

#21002

Op Thu, 21 Mar 2013 16:18:32 +0000 (UTC) schreef Zbiggy:

> In comp.lang.forth, Coos Haak wrote:
> 
>> The value stored at >BODY in F-PC and CHForth is a pointer to the start of
>> the colon definition in a different segment. [..]
> 
> But I believe, this is enforced by 8086 ("real mode") architecture - and in
> case of "linear address space" the things usually look out like on the
> typical "Forth memory map" picture?

Why would that be enforced? F83 (not Forth-83, which is a standard) has all
code, data and stacks in a single 64 Kb segment and has therefore a linear
address space.
Both F-PC and CHForth use more memory. CHForth needs about 210 Kb.
What would be a typical "Forth memory map" picture?

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web