There is no guarantee that CONSTANT's are CREATEd.
Hence >BODY doesn't work.

E.g.
"

~$ lina

AMDX86 ciforth beta 2020Jun05
4 CONSTANT 4
4 : ISN'T UNIQUE
OK
BYE
~$ lina

AMDX86 ciforth beta 2020Jun05
4 CONSTANT four
OK
5 four >BODY !
Segmentation fault (core dumped)
"

Hope this helps.

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

On Fri, 11 Mar 2022 13:37:45 +0100
albert@cherry.(none) (albert) wrote:

> There is no guarantee that CONSTANT's are CREATEd.
> Hence >BODY doesn't work.
>

True. But, why wouldn't you ensure >BODY works?
This is for a Forth you coded (ciforth), correct?

--

On 4/04/2022 05:08, Rod Pemberton wrote:
> On Fri, 11 Mar 2022 13:37:45 +0100
> albert@cherry.(none) (albert) wrote:
>
>> There is no guarantee that CONSTANT's are CREATEd.
>> Hence >BODY doesn't work.
>>
>
> True. But, why wouldn't you ensure >BODY works?
> This is for a Forth you coded (ciforth), correct?

Perhaps it worked for ciforth in the past and he's informing it no longer does?
I won't ask why anyone needs such access as I'm too afraid of the answers :)

Rod Pemberton <noemail@basdxcqvbe.com> writes:
>On Fri, 11 Mar 2022 13:37:45 +0100
>albert@cherry.(none) (albert) wrote:
>
>> There is no guarantee that CONSTANT's are CREATEd.
>> Hence >BODY doesn't work.
>>
>
>True. But, why wouldn't you ensure >BODY works?

I can only speculate: More programming work? More run-time overhead?
Does not fit his aesthetic sensibilities?

- 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 2021: https://euro.theforth.net/2021

On Monday, April 4, 2022 at 8:08:30 AM UTC+2, dxforth wrote:
> Perhaps it worked for ciforth in the past and he's informing it no longer does?
> I won't ask why anyone needs such access as I'm too afraid of the answers :)
It doesn't work in 4tH either:

Addr| Opcode Operand Argument

0| literal 5
1| literal 4
2| environ 1
3| + 0
4| ! 0

Executing; Word 4: Bad variable

ALL constants are inlined in 4tH - and may be lina itself as well. It seems like a reasonable optimization.

So, what does the '94 standard have to say about this?
"6.1.0950: CONSTANT - Create a definition for name with the execution semantics defined below". I suppose lina does so.. Seems like a reasonable assumption.
"6.1.0550: >BODY - An ambiguous condition exists if xt is not for a word defined via CREATE". Which MIGHT explain why ">BODY" doesn't work in lina.

So, let's evaluate the facts:
- Nowhere in the standard is stated that CONSTANTS should be CREATEd;
- The standard states that >BODY only works on words that are CREATEd.

Therefore, it is a false assumption that ">BODY" doesn't work OR that lina shows "non-standard" behavior.

Hans Bezemer

On Monday, April 4, 2022 at 8:08:30 AM UTC+2, dxforth wrote:
Even MORE damning (I keep digging):

E.4.1 Definitions
Traditionally, Forth definitions have consisted of the name of the Forth word, a dictionary search link, data describing how to execute the definition, and parameters describing the definition itself. These components are called the name, link, code, and parameter fields. No method for accessing these fields has been found that works across all of the Forth implementations currently in use. Therefore, ANS Forth severely restricts how the fields may be used. Specifically, a portable ANS Forth program may not use the name, link, or code field in any way. Use of the parameter field (renamed to data field for clarity) is limited to the operations described below.

Only words defined with CREATE or with other defining words that call CREATE have data fields.

}}}
The other defining words in the Standard (VARIABLE, CONSTANT, :, etc.) might **NOT** be implemented with CREATE. Consequently, a Standard Program must assume that words defined by VARIABLE, CONSTANT, : , etc., may have no data fields. There is no way for a Standard Program to modify the value of a constant or to change the meaning of a colon definition. The DOES> part of a defining word operates on a data field. Since only CREATEd words have data fields, DOES> can only be paired with CREATE or words that call CREATE.
{{{

Hans Bezemer

On 6/04/2022 21:59, Hans Bezemer wrote:
>
> So, let's evaluate the facts:
> - Nowhere in the standard is stated that CONSTANTS should be CREATEd;
> - The standard states that >BODY only works on words that are CREATEd.
>
> Therefore, it is a false assumption that ">BODY" doesn't work OR that lina shows "non-standard" behavior.

Correct. Even when CONSTANTs are CREATEd and >BODY works on them, there's
no guarantee the data field is 1 CELL wide (especially in DX-Forth :)

AFAIK the >BODY restriction also applies to VALUEs. I'm not sure how an
assembler routine is supposed to access a VALUE if >BODY doesn't work
but that would be the implementer's problem - not ANS' :)

On Thursday, April 7, 2022 at 9:00:40 AM UTC+2, dxforth wrote:
> AFAIK the >BODY restriction also applies to VALUEs. I'm not sure how an
> assembler routine is supposed to access a VALUE if >BODY doesn't work
> but that would be the implementer's problem - not ANS' :)

Funny - in 4tH that works! Variables are 'floating', their true address dependent
on what the host program injects into the VM. When using VARIABLEs or VALUEs,
4tH "corrects" these address (offsets) before they are presented to ! or @.

However, if you tick those - you get the offset - not the address of the VARIABLE or
VALUE. That is what >BODY in 4tH does. So this works:

Scr # 0
0 10 value x
1 15 ' x >body !
2 x .
..

Compiled to:

4tH message: No errors at word 9
Object size: 9 words
String size: 0 chars
Variables : 1 cells
Strings : 0 chars
Symbols : 0 names
Reliable : Yes

Addr| Opcode Operand

0| literal 10
1| to 0
2| literal 15
3| literal 0
4| environ 1
5| + 0
6| ! 0
7| value 0
8| . 0

Execution:
15

It doesn't work on CONSTANT, CREATE or STRING - since those are NOT
located in the Integer Segment. It does work - of course - on ARRAY.

Yeah, I know - not quite ANS. But those here long enough know that - due to its
architecture, 4tH could never be an ANS compliant compiler:

"Yeah, I faked all my compilations - sue me!"

Hans Bezemer