Clarification on Forth System Variables BASE and STATE

[Krishna Myneni]

Both BASE and STATE are standard Forth system-supplied variables. I
believe the reading of the standard description for VARIABLE is that it
is associated with CREATE and, hence, named variables should have a data
or parameter field. Then, it should be possible to retrieve the value of
a variable with

VARIABLE V
' V >BODY @

However, this isn't always true for the system-supplied variables BASE
and STATE :

' STATE >BODY @

may or may not work, and may even seg fault. Should system variables be
on the same footing as regular variables with respect to being able to be
ticked and then being able to obtain their data field addresses with
>BODY ?

With BASE it is acceptable for the use to store a new value using, e.g.

8 BASE !

However, the same is not true for STATE -- the standard explicitly states
that the user should not write the value of state.

Krishna Myneni

[hughag...@gmail.com]

On Wednesday, August 21, 2019 at 6:47:52 PM UTC-7, Krishna Myneni wrote:
> I
> believe the reading of the standard description for VARIABLE is that it
> is associated with CREATE and, hence, named variables should have a data
> or parameter field.

Why do you believe that?
The ANS-Forth document (6.1.2410) doesn't say that VARIABLE
is necessarily defined with CREATE internally.

[Krishna Myneni]

On Thu, 22 Aug 2019 01:47:50 +0000, Krishna Myneni wrote:

> Both BASE and STATE are standard Forth system-supplied variables. I
> believe the reading of the standard description for VARIABLE is that it
> is associated with CREATE and, hence, named variables should have a data
> or parameter field. Then, it should be possible to retrieve the value of
> a variable with
>
> VARIABLE V ' V >BODY @
>
> However, this isn't always true for the system-supplied variables BASE
> and STATE :
>
> ' STATE >BODY @
>
> may or may not work, and may even seg fault. Should system variables be
> on the same footing as regular variables with respect to being able to
> be ticked and then being able to obtain their data field addresses with
>>BODY ?
>

...

Also, why is PRECISION (from the Floating-Point Extensions wordset) not a
system variable, in the same manner as BASE ? As a result of PRECISION
behaving more like a constant, it requires another word to set its value,
SET-PRECISION . This seems unnecessary if PRECISION had been implemented
as a system variable, for which the value could have been fetched and
stored. Perhaps there is a historical reason for doing the implementation
this way, but it is not clean from a design viewpoint.

KM

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:
> Both BASE and STATE are standard Forth system-supplied variables. I
> believe the reading of the standard description for VARIABLE is that it
> is associated with CREATE and, hence, named variables should have a data
> or parameter field. Then, it should be possible to retrieve the value of
> a variable with
>
> VARIABLE V
> ' V >BODY @

Why do you believe this to be true?

> However, this isn't always true for the system-supplied variables BASE
> and STATE :
>
> ' STATE >BODY @
>
> may or may not work, and may even seg fault.

On a multi-tasking system these are USER variables.

Andrew.

[Krishna Myneni]

On Thu, 22 Aug 2019 03:45:05 -0500, aph wrote:

> Krishna Myneni <krishna...@ccreweb.org> wrote:
>> Both BASE and STATE are standard Forth system-supplied variables. I
>> believe the reading of the standard description for VARIABLE is that it
>> is associated with CREATE and, hence, named variables should have a
>> data or parameter field. Then, it should be possible to retrieve the
>> value of a variable with
>>
>> VARIABLE V ' V >BODY @
>
> Why do you believe this to be true?
>

From Forth-2012 Standard's description of CREATE and VARIABLE:

----
6.1.1000
CREATE
CORE
( “hspacesiname” – – )
Skip leading space delimiters. Parse name delimited by a space. Create a
definition for name with the execution semantics defined below. If the
data-space pointer is not aligned, reserve enough data space to align it.
The new data-space pointer defines name’s data field. CREATE does not
allocate data space in name’s data field. ...

6.1.2410
VARIABLE
CORE
( “hspacesiname” – – )
Skip leading space delimiters. Parse name delimited by a space. Create a
definition for name with the execution semantics defined below. Reserve
one cell of data space at an aligned address. ...

----

The words "Create a definition for name" is explicitly in the description
of VARIABLE. A CREATEd word has a data-space pointer which can be
obtained from >BODY.

...

>
> On a multi-tasking system these are USER variables.
>

I don't understand why that's relevant.

KM

[none albert]

In article <qjlvbi$c74$2...@dont-email.me>,

By that interpretation >BODY would be applicable to colon definitions.

>
>...
>>
>> On a multi-tasking system these are USER variables.
>>
>
>I don't understand why that's relevant.
>
>KM

--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Krishna Myneni]

The 2012 standard's specification for colon ":"

----
6.1.0450
“colon”
:
CORE
( C: “hspacesiname” – – colon-sys )

Skip leading space delimiters. Parse name delimited by a space. Create a

definition for name, called a “colon definition”. Enter compilation state
and start the current definition, producing colon-sys. Append the
initiation semantics given below to the current definition. The execution
semantics of name will be determined by the words compiled into the body
of the definition. ...
----

The last statement refers to the "body of the definition". But, it is
clear from the context that the body refers to the address space of the
execution code rather than to a data field. However, the notion of a
valid >BODY address for words which do have a data field, such as for
variables, makes sense. For constants, some implementations simply inline
them with a colon definition. Even then, there is a valid body address
available in the inline definition, should the system implementor choose
to make it available in a word's header information.

If the (ANS/2012) standards do not guarantee a valid body address for
variables and constants, that's fine. But I don't see a fundamental
reason why body addresses cannot be made available for them. The reason
to do so might be to have a uniform interface for referencing the data
field, which may prove useful in source-level debuggers, e.g.

' wordname >body

would work not just for defining words which use CREATE , but also can be
guaranteed for xVARIABLEs and xCONSTANTs (x = {none, '2', 'F'}) and
system-variables such as BASE and STATE.

KM

[dxforth]

It depends on what you believe PRECISION represents/should control.
Is it is merely a display feature controlling the number of digits
output in a given application - or is it saying something about the
capabilities of the system? If the latter then you need SET-PRECISION
to limit values to something appropriate for the system since a
portable program won't know what that is.

[Krishna Myneni]

Well, the standard is pretty clear that it controls only the number of
significant digits for output words:

----
12.6.2.2035
FLOATING EXT
PRECISION
( –– u )
Return the number of significant digits currently used by F., FE., or FS.
as u.

12.6.2.2200
FLOATING EXT
SET-PRECISION
( u –– )
Set the number of significant digits currently used by F., FE., or FS. to
u.
----

I don't know of any Forth system which uses SET-PRECISION to set an
arbitrary number of significant digits for a floating-point calculation.
That would be hard to do. In kForth-64, I would like to provide for both
double precision and quad precision floating point calculations, and a
way to switch between them. Then, one might have the words, SET-FP-DOUBLE-
PRECISION and SET-FP-QUAD-PRECISION.

In any case, it seems to be that the functions of PRECISION and SET-
PRECISION to get and set the display precision in the Floating Point
Extensions wordset could have been more simply handled by providing a new
system variable to which one can fetch and store.

Krishna

[dxforth]

> ...

I didn't say that. I view the function of SET-PRECISION as setting the
maximum number of significant digits *displayable* up to the system's
internal maximum. How large a buffer do I need to assign for REPRESENT
in a portable application for any given system? I'd like to be able to
type: 10000 SET-PRECISION PRECISION . and have it tell me.

[peter....@gmail.com]

10000 SET-PRECISION PRECISION . 20 ok

is what my system gives me.

It is defined like this

user significant_digits

: precision ( -- u )
significant_digits @ dup 0= if drop 20 then ;

: set-precision ( u -- )
1 max 20 min significant_digits ! ;

BR
Peter

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>Both BASE and STATE are standard Forth system-supplied variables. I
>believe the reading of the standard description for VARIABLE is that it
>is associated with CREATE and, hence, named variables should have a data
>or parameter field. Then, it should be possible to retrieve the value of
>a variable with
>
>VARIABLE V
>' V >BODY @

No.

|>BODY ( xt -- a-addr )
|
|[...] An ambiguous condition exists if xt is not for a word defined
|via CREATE.

Even if the specification of VARIABLE, :, etc. uses the English word
"Create", there is nothing there that specifies that a word created
with VARIABLE is a word created with CREATE.

>However, this isn't always true for the system-supplied variables BASE
>and STATE :
>
>' STATE >BODY @
>
>may or may not work, and may even seg fault. Should system variables be
>on the same footing as regular variables with respect to being able to be
>ticked and then being able to obtain their data field addresses with
>>BODY ?

Nothing says that STATE or BASE are defined with VARIABLE, and on many
systems, they are not.

- 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 2019: http://euro.theforth.net/

[dxforth]

On Friday, 23 August 2019 17:00:49 UTC+10, peter...@gmail.com wrote:
> ...

> 10000 SET-PRECISION PRECISION . 20 ok
>
> is what my system gives me.
>
> It is defined like this
>
> user significant_digits
>
> : precision ( -- u )
> significant_digits @ dup 0= if drop 20 then ;
>
> : set-precision ( u -- )
> 1 max 20 min significant_digits ! ;

What is significant_digits=0 - a special mode?

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>Also, why is PRECISION (from the Floating-Point Extensions wordset) not a
>system variable, in the same manner as BASE ? As a result of PRECISION
>behaving more like a constant, it requires another word to set its value,
>SET-PRECISION . This seems unnecessary if PRECISION had been implemented
>as a system variable, for which the value could have been fetched and
>stored. Perhaps there is a historical reason for doing the implementation
>this way, but it is not clean from a design viewpoint.

It seems to me that the historical experience with STATE resulted in
preferring getters and setters over variable-flavoured interfaces in
Forth-94.

BASE is another case where a setter/getter pair would be better than
the current variable-flavoured interface: Division can be implemented
much more efficiently by multiplication with the reciprocal, but
computing the reciprocal is expensive, so this is only beneficial if
the same divisor is used for many divisions, *and* we know it. With
the variable-flavoured BASE interface, BASE can change between every
use of #, so (if we use this optimization), we have to check in #
(i.e., for every digit) if BASE has changed and recompute the
reciprocal if necessary. If instead we had SET-BASE and GET-BASE,
this check would be unnecessary.

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:

Yes, it has. But there's nothing to imply that a VARIABLE is a child
of CREATE and on many systems it isn't.

>> On a multi-tasking system these are USER variables.
>
> I don't understand why that's relevant.

In a USER variable, the data is not in the body of the variable's
definition but in the user area of a task.

Andrew.

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>On Thu, 22 Aug 2019 13:17:42 +0000, none) (albert wrote:
>
>> In article <qjlvbi$c74$2...@dont-email.me>,
>> Krishna Myneni <krishna...@ccreweb.org> wrote:
>If the (ANS/2012) standards do not guarantee a valid body address for
>variables and constants, that's fine. But I don't see a fundamental
>reason why body addresses cannot be made available for them.

Sure, if you want to do so, go ahead. But other systems make other
choices. We have seen that iForth implements constants as code that
pushes the constant. VFX puts the data cell of a variable elsewhere,
and apparently implements the variable as a constant pointing to that
cell.

Forth-94 defined >BODY to work only for CREATEd words, because one
needs >BODY in connection with certain CREATE...DOES>-defined words.
It is unnecessary for constants and variables, so >BODY is not
guaranteed to work for them. And obviously systems have made use of
that.

[peter....@gmail.com]

No, if I remember correctly it was to check for uninitialized user variable.
But this is old code.

Peter

[Krishna Myneni]

On Fri, 23 Aug 2019 07:53:49 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>On Thu, 22 Aug 2019 13:17:42 +0000, none) (albert wrote:
>>
>>> In article <qjlvbi$c74$2...@dont-email.me>,
>>> Krishna Myneni <krishna...@ccreweb.org> wrote:
>>If the (ANS/2012) standards do not guarantee a valid body address for
>>variables and constants, that's fine. But I don't see a fundamental
>>reason why body addresses cannot be made available for them.
>
> Sure, if you want to do so, go ahead. But other systems make other
> choices. We have seen that iForth implements constants as code that
> pushes the constant. VFX puts the data cell of a variable elsewhere,
> and apparently implements the variable as a constant pointing to that
> cell.
>

We have seen from recent discussions that >BODY is of limited use. Even
in the case of CREATEd words, unless memory is ALLOTted in the defining
word, >BODY simply points to an address which is not meaningful as a
pointer to a data field. In most other cases >BODY , as implemented in
several systems, appears to return an arbitrary address from which
fetching data may result in a seg fault.

In the wordlist information utility I was writing ( WL-INFO ), which
displays a formatted output of word names, xt's, precedence, and the
parameter field address ( the >BODY address or pfa), the last field was
mostly visual clutter. To make the output more useful to me, I have
changed how kForth-64 deals with setting up the pfa at compile time. In
the revised implementation, the following have valid pfa's and everything
else has null:

1) Words which are defined using CREATE and ALLOT

2) xVARIABLEs and xCONSTANTs

3) System variables: BASE and STATE

4) System words with an obvious data field: PRECISION

The output of "FORTH-WORDLIST WL-INFO" is now much more useful -- the
visual clutter is gone and it is easy to identify words which have
associated data. In effect, the new implementation of >BODY while
maintaining compatibility with the standard, really serves a new purpose
which might be called >DATA , the utility of which can now be tested in
practice.

> Forth-94 defined >BODY to work only for CREATEd words, because one needs
> >BODY in connection with certain CREATE...DOES>-defined words. It is
> unnecessary for constants and variables, so >BODY is not guaranteed to
> work for them. And obviously systems have made use of that.

A system can simply set the data field address in the word headers to
NULL by default until they are set by the action of a defining word. This
is simple system hygiene with very little overhead at compile time, and
none at run time. Perhaps this doesn't apply to embedded systems.

Krishna

[hughag...@gmail.com]

On Thursday, August 22, 2019 at 7:34:14 PM UTC-7, Krishna Myneni wrote:
> On Thu, 22 Aug 2019 18:22:43 -0700, dxforth wrote:
> > It depends on what you believe PRECISION represents/should control. Is
> > it is merely a display feature controlling the number of digits output
> > in a given application - or is it saying something about the
> > capabilities of the system? If the latter then you need SET-PRECISION
> > to limit values to something appropriate for the system since a portable
> > program won't know what that is.
>
> Well, the standard is pretty clear that it controls only the number of
> significant digits for output words:
>
> ----
> 12.6.2.2035
> FLOATING EXT
> PRECISION
> ( –– u )
> Return the number of significant digits currently used by F., FE., or FS.
> as u.
>
> 12.6.2.2200
> FLOATING EXT
> SET-PRECISION
> ( u –– )
> Set the number of significant digits currently used by F., FE., or FS. to
> u.
> ----

VFX has a bug in F. --- this is my code:
--------------------------------------------------------------------------
\ ******
\ ****** The following is for numeric output.
\ ******

: comma ( d -- d )
[char] , hold ;

: dot ( d -- d )
[char] . hold ;

: _# ( d -- d_less_digit ) \ digit if number is non-zero, else a blank
2dup d0= if bl hold else # then ;

: _comma ( d -- d ) \ comma if number is non-zero, else a blank
2dup d0= if bl hold else comma then ;

\ _# and _comma are used to blank-out the leftmost of the number if the digits are zero.

: book-sign ( d neg? -- d )
if [char] - else [char] + then hold ;

\ This is a bookkeeping-style sign. It prints a + for positive rather than print nothing.

item ?sgn \ used by ?# and ?COMMA

: ?# ( d -- new-d ) \ needs ?SGN set \ similar to _# except puts a - in there if ?SGN is set
2dup d0= if
?sgn if ?sgn sign then
false to ?sgn
else
# then ;

: ?comma ( d -- d ) \ needs ?SGN set \ similar to _comma except puts a - in there if ?SGN is set
2dup d0= if
?sgn if ?sgn sign then
false to ?sgn
else
comma then ;

: <big.> ( d -- adr cnt ) \ used for big numbers that need commas for clarity
2dup d0< to ?sgn dabs
<#
# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?#
#> ;

: big. ( d -- )
<big.> type ;

item ~#soft \ TRUE implies that ~# shouldn't output zeros

: ~# ( Da -- Db ) \ needs ~#SOFT set
~#soft if
2dup 10 um/mod drop if # false to ~#soft
else 1 10 m*/ then
else
# then ;

: ~. ( D -- D ) \ needs ~#SOFT set
~#soft not if [char] . hold then ;

\ ~# is used for the digits to the right of the decimal point.
\ ~. is used for the decimal point.

: round-off { prec -- } \ float: n -- new-n
prec 1 ?do 10.e f* loop fnear
prec 1 ?do 10.e f/ loop ;

: adjust-down ( adjustment -- new-adjustment ) \ float: n -- new-n
begin fdup 10.e f>= while
10.e f/ 1+ repeat ;

: adjust-up ( adjustment -- new-adjustment ) \ float: n -- new-n
begin fdup 1.e f< while
10.e f* 1- repeat ;

: exponent { prec | sgn -- adjustment } \ float: n -- new-n
0 \ -- adjustment
fdup f0= if exit then
fdup f0< to sgn fabs
adjust-up
adjust-down prec round-off adjust-down
sgn if fnegate then ;

: #exponent ( n -- ) \ must be called from within <# #>
?dup if
dup >r abs 0 \ -- d
#s r> sign [char] e hold \ -- d0
2drop then ;

: <scientific> { prec engineering? | sgn exp -- adr cnt } \ float: n --
prec 1 < abort" *** F>STRING needs a precision parameter >= 1 ***"
prec exponent to exp
engineering? if
begin exp 3 mod while 10.e f* -1 +to exp -1 +to prec repeat
fdup fabs prec round-off
1000.e f>= if 1000.e f/ 3 +to exp 3 +to prec then
then
prec 1 ?do 10.e f* loop
fnear f>d
dup to sgn dabs <# bl hold
exp #exponent
true to ~#soft prec 1 ?do ~# loop ~.
2dup or if #s
else ~#soft if #s then then
sgn sign #> ;

\ The e is optional, which prevents these numbers from being used in Forth source-code. >FLOAT still works though.

10 constant max-prec \ 11 works sometimes, but fails if the most significant digit is large. 10 always works.

: scientific ( -- adr cnt ) \ float: n --
precision false <scientific> ;

: max-scientific ( -- adr cnt ) \ float: n --
max-prec false <scientific> ;

: engineering ( -- adr cnt ) \ float: n --
precision true <scientific> ;

: max-engineering ( -- adr cnt ) \ float: n --
max-prec true <scientific> ;

2000000001 constant eng-lim \ must be a positive integer
\ In <ENG> any float >= the lim goes to ENGINEERING and otherwise is done without an 'e'

: <eng> ( -- adr cnt lim ) \ float: n --
fdup fabs s>d d>f f>= fdup fabs 1e f< or if engineering exit then
<cstr
fdup f0< if [char] - char+cstr then
fabs
fdup f>d 2dup <big.> <+cstr>
d>f f- \ float: integer-part
fdup f0= 0= if
[char] . char+cstr
precision 0 ?do 10.e f* loop
true to ~#soft
fround f>d <# precision 0 ?do ~# loop #> <+cstr>
then
cstr> count ;

: eng ( -- adr cnt ) \ float: n --
eng-lim <eng> ;

: HOLDS ( adr len -- ) \ HOLD a string
BEGIN DUP WHILE 1- 2DUP CHARS + C@ HOLD REPEAT 2DROP ;

\ HOLDS was written by HAA (he called it $HOLD though): https://groups.google.com/forum/#!topic/comp.lang.forth/ictps0w02yk
--------------------------------------------------------------------------

[Krishna Myneni]

The wording for VARIABLE is suggestive of using CREATE but I will concede
that it does not explicitly state that CREATE should be used. Even while
other implementations are allowed, unless the benefits of doing so are
compelling (possibly a minor bump in the execution speed for creating
variables, but it's highly questionable whether any such efficiency
improvement is significant to the overall application), I will argue that
using traditional Forth methods such as CREATE are better. For one, there
will be a valid >BODY address. Also, even when using other methods, the
data address is available and the system implementor can choose to make
it available. Whether the effort is warranted or not is another question,
though.

>>> On a multi-tasking system these are USER variables.
>>
>> I don't understand why that's relevant.
>
> In a USER variable, the data is not in the body of the variable's
> definition but in the user area of a task.
>

I can't find a requirement in the standard that the data be in contiguous
memory with the variable's definition. The only requirement is that
ALLOTed and ALLOCATEd memory be contiguous, not that the memory block be
adjacent to the code for a defining word. Therefore, an address in an
external block should be perfectly fine for a data field address accessed
through >BODY.

KM

[Krishna Myneni]

On Fri, 23 Aug 2019 07:32:58 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>Also, why is PRECISION (from the Floating-Point Extensions wordset) not
>>a system variable, in the same manner as BASE ? As a result of PRECISION
>>behaving more like a constant, it requires another word to set its
>>value,
>>SET-PRECISION . This seems unnecessary if PRECISION had been implemented
>>as a system variable, for which the value could have been fetched and
>>stored. Perhaps there is a historical reason for doing the
>>implementation this way, but it is not clean from a design viewpoint.
>
> It seems to me that the historical experience with STATE resulted in
> preferring getters and setters over variable-flavoured interfaces in
> Forth-94.
>

STATE is an unusual case where the standard discourages the practicing of
writing its value by the user.

> BASE is another case where a setter/getter pair would be better than the
> current variable-flavoured interface: Division can be implemented much
> more efficiently by multiplication with the reciprocal, but computing
> the reciprocal is expensive, so this is only beneficial if the same
> divisor is used for many divisions, *and* we know it. With the
> variable-flavoured BASE interface, BASE can change between every use of
> #, so (if we use this optimization), we have to check in # (i.e., for
> every digit) if BASE has changed and recompute the reciprocal if
> necessary. If instead we had SET-BASE and GET-BASE, this check would be
> unnecessary.
>

Do you mean something like

<# 16 BASE ! # 8 BASE ! # 2 BASE ! # DECIMAL #>

versus

<# 16 SET-BASE # 8 SET-BASE # 2 SET-BASE # DECIMAL #>

Are you taking the reciprocal of the base in floating point? In kForth,
"#" is implemented with a nonstandard triple integer division and
multiplication words:

UTM/ ( ut u -- ud ) divide unsigned triple by unsigned single
to give unsigned double quotient

UDM* ( ud u -- ut ) multiply unsigned double and unsigned single
to give unsigned triple product

Not sure how the procedure compares to doing the calculation with
floating point, using the reciprocal of the base. But, your point about #
not having to check BASE each time is true.

Krishna

[dxforth]

On Saturday, 24 August 2019 06:48:57 UTC+10, hughag...@gmail.com wrote:
> ...

> VFX has a bug in F.

Can you provide details?

[dxforth]

On Saturday, 24 August 2019 10:15:17 UTC+10, Krishna Myneni wrote:
> On Fri, 23 Aug 2019 07:32:58 +0000, Anton Ertl wrote:
>
> > Krishna Myneni <krishna...@ccreweb.org> writes:
> >>Also, why is PRECISION (from the Floating-Point Extensions wordset) not
> >>a system variable, in the same manner as BASE ? As a result of PRECISION
> >>behaving more like a constant, it requires another word to set its
> >>value,
> >>SET-PRECISION . This seems unnecessary if PRECISION had been implemented
> >>as a system variable, for which the value could have been fetched and
> >>stored. Perhaps there is a historical reason for doing the
> >>implementation this way, but it is not clean from a design viewpoint.
> >
> > It seems to me that the historical experience with STATE resulted in
> > preferring getters and setters over variable-flavoured interfaces in
> > Forth-94.
> >
>
> STATE is an unusual case where the standard discourages the practicing of
> writing its value by the user.

Agreed. One can make the same argument (special needs) for SET-PRECISION.
Note that it's SET-PRECISION that the end-user will typically be applying,
with PRECISION used in the internals of the f/p output function alongside REPRESENT.

This begs the question why PRECISION SET-PRECISION wasn't included with
REPRESENT but FLOAT-EXT. I believe ANS f/p output to be a 'paper design'.
It doesn't seem possible to me the gaps in the various specs would have
passed unnoticed had the TC access to an existing implementation before
publication.

[hughag...@gmail.com]

The bug in VFX seems to be in the input string>float function
used by the VFX outer interpreter. Also, >FLOAT has the same bug.

Of course, my code is bug-free. :-D
Also, I provide scientific and engineering output formats
that VFX fails to provide.

This is a demonstration:
----------------------------------------------------------------------------
2000000000.000123456789e f. 7751640. ok
s" 2000000000.000123456789" >float ok-1 F:-1
. -1 ok F:-1
f. 7751640. ok

s" 2000000000.000123456789" str>num ok-1 F:-1
. 3 ok F:-1
fdup f. 2000000000. ok F:-1
fdup eng type 2,000,000,000.00012346 ok F:-1
fdup scientific type 2e9 ok F:-1
----------------------------------------------------------------------------

This has already been discussed multiple times:

On Thursday, July 12, 2018 at 10:21:59 PM UTC-7, hughag...@gmail.com wrote:
> On Thursday, July 12, 2018 at 7:47:02 PM UTC-7, dxf...@gmail.com wrote:
> > On Thursday, July 12, 2018 at 3:58:32 PM UTC+10, hughag...@gmail.com wrote:
> > > Also, VFX has a bug.
> >
> > If the bug is in the VFX f/p output then I would
> > want to know about it.
>
> This has already been discussed here:
>
> https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B76-100%5D
>
> On Tuesday, December 20, 2016 at 6:13:25 AM UTC-7, Anton Ertl wrote:
> > ste...@mpeforth.com writes:
> > >> > 2000000000.000123456789e ok F:-1
> > >> > eng type 7,751,640.03949188 ok \ this is a bug in VFX --- F. doesn't work either
> > ...
> > >Hugh's 'bug' is actually a numeric overflow. The conversion routine converts to a 64 bit double number. Hugh's 22 digits require 73 bits for correct representation.
> >
> > vfxlin "include /usr/local/VfxLinEval/Lib/x86/Ndp387.fth"
> > VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> > Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
> > 2000000000.000123456789e f. 7751640. ok
> >
> > Here both the string->FP conversion and the FP->string conversion come
> > from Ndp387.fth. Looks like a bug in Ndp387.fth to me. Investigating
> > further, it looks like the bug is in the input conversion:
> >
> > 2000000000.e .000123456789e f+ f. 2000000000. ok
> >
> > If not all bits can be represented, that is ok and normal for FP. But
> > then you round to get rid of the least significant bits and get a
> > number that is close to the input number (just as you do for 0.1e,
> > which cannot be represented exactly in binary FP, either).

[hughag...@gmail.com]

On Friday, August 23, 2019 at 4:53:24 PM UTC-7, Krishna Myneni wrote:
> On Fri, 23 Aug 2019 02:56:00 -0500, aph wrote:
> >> 6.1.2410 VARIABLE CORE ( “hspacesiname” – – )
> >> Skip leading space delimiters. Parse name delimited by a space. Create
> >> a definition for name with the execution semantics defined below.
> >> Reserve one cell of data space at an aligned address. ...
> >>
> >> ----
> >>
> >> The words "Create a definition for name" is explicitly in the
> >> description of VARIABLE. A CREATEd word has a data-space pointer which
> >> can be obtained from >BODY.
> >
> > Yes, it has. But there's nothing to imply that a VARIABLE is a child of
> > CREATE and on many systems it isn't.
> >
>
> The wording for VARIABLE is suggestive of using CREATE but I will concede
> that it does not explicitly state that CREATE should be used.

ANS-Forth doesn't say that VARIABLE uses CREATE internally,
although some readers (APH) may believe that the use of the
phrase "create a definition for name" implies that it does.
More ambiguity in ANS-Forth!

Another stupidity in Elizabeth Rather's toy Forth is that
variables aren't initialized to zero. If the user forgets
to initialize a variable, when the user reads the variable
it will contain garbage data. The program will behave
differently from one compile to another --- the program
may work sometimes but not work other times (for example,
if the variable contains a flag that is supposed to be
initialized to true, the program will work most of the time
but will fail if the garbage value happens to be zero).
This is a very difficult bug to track down!

Elizabeth Rather's stupidity can be fixed easily.
I added the following to NOVICE.4TH just now:
------------------------------------------------------------
: variable ( -- ) \ stream: name
create 0 , does> ;

\ This definition of VARIABLE assures that >BODY will work on it, and that it is initialized to zero.
------------------------------------------------------------

So, my novice package has been improved,
thanks to information on comp.lang.forth from the ANS-Forth cult!

[hughag...@gmail.com]

On Friday, August 23, 2019 at 10:40:06 PM UTC-7, hughag...@gmail.com wrote:
> Elizabeth Rather's stupidity can be fixed easily.
> I added the following to NOVICE.4TH just now:
> ------------------------------------------------------------
> : variable ( -- ) \ stream: name
> create 0 , does> ;
>
> \ This definition of VARIABLE assures that >BODY will work on it, and that it is initialized to zero.
> ------------------------------------------------------------

Here is a slightly better definition:
--------------------------------------------------------------
: <variable> ( n -- ) \ stream: name
create , does> ;

: variable ( -- ) \ stream: name

0 <variable> ;

\ This definition of VARIABLE assures that >BODY will work on it, and that it is initialized to zero.

--------------------------------------------------------------

[dxforth]

On Saturday, 24 August 2019 15:15:25 UTC+10, hughag...@gmail.com wrote:
> On Friday, August 23, 2019 at 5:20:10 PM UTC-7, dxforth wrote:
> > On Saturday, 24 August 2019 06:48:57 UTC+10, hughag...@gmail.com wrote:
> > > ...
> > > VFX has a bug in F.
> >
> > Can you provide details?
>
> The bug in VFX seems to be in the input string>float function
> used by the VFX outer interpreter. Also, >FLOAT has the same bug.

Ok, so elsewhere and not in F.

> ...

> Also, I provide scientific and engineering output formats
> that VFX fails to provide.

VFX provides sci and eng functions along the lines of historic C
and Fortran functions, and more. Full documentation is here:

http://dxforth.mirrors.minimaltype.com/fpoutglo.html

Adding commas etc is easily done with post-processing as previously
described.

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:
> On Fri, 23 Aug 2019 07:32:58 +0000, Anton Ertl wrote:
>

>> BASE is another case where a setter/getter pair would be better
>> than the current variable-flavoured interface: Division can be
>> implemented much more efficiently by multiplication with the
>> reciprocal, but computing the reciprocal is expensive, so this is
>> only beneficial if the same divisor is used for many divisions,
>> *and* we know it. With the variable-flavoured BASE interface, BASE
>> can change between every use of #, so (if we use this
>> optimization), we have to check in # (i.e., for every digit) if
>> BASE has changed and recompute the reciprocal if necessary.

Would using reciprocals for arbitrary bases really be an optimization?
I can see that storing 1/10 might be useful, but other bases would be
so unusual that the effort to set all of this stuff up would be more
than the optimization would save.

> Are you taking the reciprocal of the base in floating point?

It's all integer. See

Torbjörn Granlund and Peter L. Montgomery, "Division by Invariant
Integers using Multiplication," ACM Conf on Prog Lang Dsgn and Impl,
(PLDI-1994):61-72.

Andrew.

[a...@littlepinkcloud.invalid]

This is how a USER variable might be defined:

: user ( offset) create , does> @ 'current-task + ;

The >BODY contains the offset of the USER variable, not its data.

Andrew.

[peter....@gmail.com]

In my systems VARIABLE and CREATE are defined using CONSTANT like this

: CREATE
align here constant ;

: VARIABLE
align here 0 , constant ;

This works as header code and data are separate. >BODY works on both
and also on CONSTANT but there produces just the constant not an address.
The reason can be seen below. The constant is store directly inline in
the code. It will expand as a macro when used in other code

123 constant t1 ok
see t1 macro 3 bytes starting at $00A0.93D8
$00A0.93D8 $0026 LIT1 $007B 123
$00A0.93DA $0025 RET
ok

>
> >>> On a multi-tasking system these are USER variables.
> >>
> >> I don't understand why that's relevant.
> >
> > In a USER variable, the data is not in the body of the variable's
> > definition but in the user area of a task.
> >
>
> I can't find a requirement in the standard that the data be in contiguous
> memory with the variable's definition. The only requirement is that
> ALLOTed and ALLOCATEd memory be contiguous, not that the memory block be
> adjacent to the code for a defining word. Therefore, an address in an
> external block should be perfectly fine for a data field address accessed
> through >BODY.

Just like my system does!

BR
Peter

>
> KM

[Mark William Humphries]

I wouldn't be surprised if many, if not most, Forths nowadays implement variables as constants.
My variables, like my constants, just inline a literal when compiled into a definition.

[Mark William Humphries]

Le samedi 24 août 2019 16:50:17 UTC+8, Mark William Humphries a écrit :
> I wouldn't be surprised if many, if not most, Forths nowadays implement variables as constants.
> My variables, like my constants, just inline a literal when compiled into a definition.

To be clearer, I should have said implement variables as *address* constants.

[Paul Rubin]

a...@littlepinkcloud.invalid writes:
> It's all integer. See
>
> Torbjörn Granlund and Peter L. Montgomery, "Division by Invariant
> Integers using Multiplication," ACM Conf on Prog Lang Dsgn and Impl,
> (PLDI-1994):61-72.

Nice, it's here: https://gmplib.org/~tege/divcnst-pldi94.pdf

[dxforth]

On Saturday, 24 August 2019 09:53:24 UTC+10, Krishna Myneni wrote:
> ...

> The wording for VARIABLE is suggestive of using CREATE but I will concede
> that it does not explicitly state that CREATE should be used. Even while
> other implementations are allowed, unless the benefits of doing so are
> compelling (possibly a minor bump in the execution speed for creating
> variables, but it's highly questionable whether any such efficiency
> improvement is significant to the overall application), I will argue that
> using traditional Forth methods such as CREATE are better. For one, there
> will be a valid >BODY address. Also, even when using other methods, the
> data address is available and the system implementor can choose to make
> it available. Whether the effort is warranted or not is another question,
> though.

While I find little practical need to apply ' name >BODY to a VARIABLE,
it's exactly what I use when it comes to DEFERed words. I'm not convinced
by the 'DEFERed words need to be fast' argument. Forthers above all know
there's a difference between deferred words and ones that aren't. Why
pretend otherwise when it comes to speed. Using DEFERed words at such a
low level that speed makes a difference, I'd consider poor programming.

[hughag...@gmail.com]

On Saturday, August 24, 2019 at 7:27:08 PM UTC-7, dxforth wrote:
> I'm not convinced
> by the 'DEFERed words need to be fast' argument. Forthers above all know
> there's a difference between deferred words and ones that aren't. Why
> pretend otherwise when it comes to speed. Using DEFERed words at such a
> low level that speed makes a difference, I'd consider poor programming.

My LowDraw.4th program used DEFERed words at a low level.
It does a recursive-descent traversal, so these get executed
many thousands of times.

Wil Baden's SORT used a DEFERed word for the comparer.
I pass the xt in as a parameter, store it in a local variable,
and EXECUTE it as needed.

[dxforth]

On Wednesday, 28 August 2019 11:25:16 UTC+10, hughag...@gmail.com wrote:
> On Saturday, August 24, 2019 at 7:27:08 PM UTC-7, dxforth wrote:
> > I'm not convinced
> > by the 'DEFERed words need to be fast' argument. Forthers above all know
> > there's a difference between deferred words and ones that aren't. Why
> > pretend otherwise when it comes to speed. Using DEFERed words at such a
> > low level that speed makes a difference, I'd consider poor programming.
>
> My LowDraw.4th program used DEFERed words at a low level.
> It does a recursive-descent traversal, so these get executed
> many thousands of times.

By low-level I mean @ EXECUTE would be deemed too slow. Is that what
you're saying because the Novice pack uses exactly that for its DEFER.

[Krishna Myneni]

>> efficiency improvement is significant to the overall application),...

> In my systems VARIABLE and CREATE are defined using CONSTANT like this
>
> : CREATE
> align here constant ;
>
> : VARIABLE
> align here 0 , constant ;
>
> This works as header code and data are separate. >BODY works on both and
> also on CONSTANT but there produces just the constant not an address.

If >BODY returns the value of the constant instead of an address, then it
breaks the consistent interface for using tick, followed by >BODY to get
the data field address. >BODY should return the address from where the
constant value may be retrieved.

Krishna

[Krishna Myneni]

On Sat, 24 Aug 2019 02:43:37 -0500, aph wrote:

...

> This is how a USER variable might be defined:
>
> : user ( offset) create , does> @ 'current-task + ;
>
> The >BODY contains the offset of the USER variable, not its data.
>

I have no experience with multi-tasking on a Forth system, other than
demonstrating the use of fork on my system to do a parallel computation.
In that case, an entire copy of the Forth environment is created, and the
parallel executing processes can communicate with each other through a
shared memory region. In the fork method, which is expensive but which
appears to be the recommended way of doing multi-tasking under Linux,
>BODY will work fine (return actual addresses) for the xt's of system
variables such as BASE and STATE.

KM

[Krishna Myneni]

On Sat, 24 Aug 2019 02:39:24 -0500, aph wrote:

> Krishna Myneni <krishna...@ccreweb.org> wrote:

...

>> Are you taking the reciprocal of the base in floating point?
>
> It's all integer. See
>
> Torbjörn Granlund and Peter L. Montgomery, "Division by Invariant
> Integers using Multiplication," ACM Conf on Prog Lang Dsgn and Impl,
> (PLDI-1994):61-72.
>

Interesting. Thanks for the reference.

KM

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:
> On Sat, 24 Aug 2019 02:43:37 -0500, aph wrote:
>
> ...
>> This is how a USER variable might be defined:
>>
>> : user ( offset) create , does> @ 'current-task + ;
>>
>> The >BODY contains the offset of the USER variable, not its data.
>
> I have no experience with multi-tasking on a Forth system, other
> than demonstrating the use of fork on my system to do a parallel
> computation. In that case, an entire copy of the Forth environment
> is created, and the parallel executing processes can communicate
> with each other through a shared memory region. In the fork method,
> which is expensive but which appears to be the recommended way of
> doing multi-tasking under Linux,

fork(2) hasn't really been the preferred way to do multi-tasking under
Linux for about twenty years. (Relatively) lightweight threads are
more practical in many cases.

>>BODY will work fine (return actual addresses) for the xt's of system
> variables such as BASE and STATE.

Fair point, if you clone the entire environment that will work.

Andrew.

[Rod Pemberton]

On Thu, 22 Aug 2019 11:46:58 -0000 (UTC)
Krishna Myneni <krishna...@ccreweb.org> wrote:

> On Thu, 22 Aug 2019 03:45:05 -0500, aph wrote:
> > Krishna Myneni <krishna...@ccreweb.org> wrote:

Both Anton and Andrew (aph) know that VARIABLE and CONSTANT was
historically implemented with CREATE like so:
https://groups.google.com/d/msg/comp.lang.forth/FLod-QnyTUI/wpmE4aeYIMoJ

With Google Books, you can find those /EXACT/ definitions in books
on Forth from 1981 to 2018, or with slight variations, e.g.,

: VARIABLE CREATE 2 ALLOT ;

So, since apparently every book on Forth ever written does it that way,
I'm really not sure what Anton and Andrew mean when they say **many**
Forths don't do it that way ...

Of course, I believe that historical behavior should be preserved, as
much as possible. So, let's look at fig-FORTH did for a moment.

fig-FORTH's BASE and STATE are created with USER. fig-FORTH's code
defines VARIABLE and USER in terms of CONSTANT. fig-FORTH's standard
states that CREATE is to be used to implement defining words, i.e.,
CONSTANT CODE USER VARIABLE VOCABULARY , specifically mentioning CODE
and CONSTANT .

So, we have: BASE & STATE -> USER -> CONSTANT -> CREATE

In fig-FORTH and Forth-79, ' (tick) returns the PFA. In Forth-83,
' (tick) returns the CFA. In Forth-94, ' (tick) returns an XT .
So, >BODY was introduced with Forth-83 to get from the CFA to PFA.
However, if fig-FORTH was modified to return the CFA or XT for ' (tick),
then >BODY would always work as every constant or variable in fig-FORTH
eventually calls CREATE . As you can see from excerpts from Forth-83,
there was no mention of an ambiguous condition for >BODY if the word
wasn't defined by CREATE, implying that CREATE was always used by
constants and variables for Forth-83. This disclaimer was added in
Forth-94 for >BODY with the introduction of XTs .

I've brought up this issue in the past, as have others over the years.
So, I'm not real sure why they're so strongly opposed to this i.e.,
having all variables and constants work with >BODY . That was clearly
historical behavior that should be preserved. It would also certainly
help with compatibility, consistency, and portability. Maybe, it has
something to do with compiled Forths? ...

In addition to the fig-FORTH code, I've posted excerpts from fig-FORTH,
Forth-79, Forth-83 for the definitions of CREATE CONSTANT VARIABLE for
your reference below, but nothing from Forth-94, Forth-2012 etc.


Rod Pemberton


fig-Forth:

CREATE
A defining word used in the form:
CREATE cccc
by such words as CODE and CONSTANT to create a
dictionary header for a Forth definition. The code field
contains the address of the word's parameter field. The
new word is created in the CURRENT vocabulary.

CONSTANT n --- L0
A defining word used in the form:
n CONSTANT cccc
to create word cccc, with its parameter field containing
n. When cccc is later executed, it will push the value
of n to the stack.

VARIABLE E,L0
A defining word used in the form:
n VARIABLE cccc
When VARIABLE is executed, it creates the definition
cccc with its parameter field initialised to n. When
cccc is later executed, the address of its parameter
field (containing n) is left on the stack, so that a
fetch or store may access this location.

2 : CREATE ( A SMUDGED CODE HEADER TO PARAM FIELD *)
3 ( WARNING IF DUPLICATING A CURRENT NAME *)
4 TIB HERE 0A0 + < 2 ?ERROR ( 6502 only )
5 -FIND ( CHECK IF UNIQUE IN CURRENT AND CONTEXT )
6 IF ( WARN USER ) DROP NFA ID.
7 4 MESSAGE SPACE ENDIF
8 HERE DUP C@ WIDTH @ MIN 1+ ALLOT
9 DP C@ 0FD = ALLOT ( 6502 only )
10 DUP A0 TOGGLE HERE 1 - 80 TOGGLE ( DELIMIT BITS )
11 LATEST , CURRENT @ !
12 HERE 2+ , ;

1 : CONSTANT ( WORD WHICH LATER CREATES CONSTANTS *)
2 CREATE SMUDGE , ;CODE
3 2 # LDY, W )Y LDA, PHA, INY, W )Y LDA, PUSH JMP,
4

5 : VARIABLE ( WORD WHICH LATER CREATES VARIABLES *)
6 CONSTANT ;CODE
7 CLC, W LDA, 2 # ADC, PHA, TYA, W 1+ ADC, PUSH JMP,

10 : USER ( CREATE USER VARIABLE *)
11 CONSTANT ;CODE
12 2 # LDY, CLC, W )Y LDA, UP ADC, PHA,
13 0 # LDA, UP 1+ ADC, PUSH JMP,


Forth-79:

CREATE 239
A defining word used in the form:
CREATE <name>
to create a dictionary entry for <name>, without allocating
any parameter field memory. When <name> is subsequently
executed, the address of the first byte of <name>'s parameter
field is left on the stack.

CONSTANT n -- 185
A defining word used in the form:
n CONSTANT <name>
to create a dictionary entry for <name>, leaving n in its
parameter field. When <name> is later executed, n will be
left on the stack.

VARIABLE 227
A defining word executed in the form:
VARIABLE <name>
to create a dictionary entry for <name> and allot two bytes
for storage in the parameter field. The application must
initialize the stored value. When <name> is later executed,
it will place the storage address on the stack.


Forth-83:

CREATE --
M,79 A defining word executed in the form:
CREATE <name>
Creates a dictionary entry for <name>. After <name> is
created, the next available dictionary location is the
first byte of <name>'s parameter field. When <name> is
subsequently executed, the address of the first byte of
<name>'s parameter field is left on the stack. CREATE
does not allocate space in <name>'s parameter field.

CONSTANT 16b --
M,83 A defining word executed in the form:
16b CONSTANT <name>
Creates a dictionary entry for <name> so that when
<name> is later executed, 16b will be left on the stack.

VARIABLE --
M,79 A defining word executed in the form:
VARIABLE <name>
____
A dictionary entry for <name> is created and two bytes
are ALLOTted in its parameter field. This parameter field is
to be used for contents of the variable. The application is
responsible for initializing the contents of the variable
which it creates. When <name> is later executed, the
address of its parameter field is placed on the stack.

>BODY addr1 -- addr2 83
"to-body" addr2 is the parameter field address corresponding
to the compilation address addr1. See: "9.2 Addressable
Memory"

' -- addr M,83
"tick" Used in the form:
' <name>
addr is the compilation address of <name>. An error
condition exists if <name> is not found in the currently
active search order.

--
Facebook privacy is like a leaky bucket of water.

[a...@littlepinkcloud.invalid]

Rod Pemberton <inv...@lkntrgzxc.com> wrote:

> Both Anton and Andrew (aph) know that VARIABLE and CONSTANT was
> historically implemented with CREATE like so:
> https://groups.google.com/d/msg/comp.lang.forth/FLod-QnyTUI/wpmE4aeYIMoJ

Sure, often still is.

> With Google Books, you can find those /EXACT/ definitions in books
> on Forth from 1981 to 2018, or with slight variations, e.g.,
>
> : VARIABLE CREATE 2 ALLOT ;
>
> So, since apparently every book on Forth ever written does it that way,
> I'm really not sure what Anton and Andrew mean when they say **many**
> Forths don't do it that way ...

Well, Forth was ROMable when I first used it circa 1980, so there
wasn't any guarantee, even back then. You could, of course, assume
that VARIABLE was defined as above, but then your programs wouldn't
work in ROM. And that's still true today, on all systems where code
and data are separate.

> Of course, I believe that historical behavior should be preserved, as
> much as possible.

WTF? Why do you believe that?

Andrew.

[Rod Pemberton]

On Fri, 30 Aug 2019 04:48:19 -0500
a...@littlepinkcloud.invalid wrote:

> Rod Pemberton <inv...@lkntrgzxc.com> wrote:

> > Of course, I believe that historical behavior should be preserved,
> > as much as possible.
>
> WTF? Why do you believe that?
>

My experience with C code.

a) C code doesn't compile correctly when things change and so must be
rewritten.
b) many historical behaviors of C that are required to this very day,
aren't included in the standards.

I'm believe the same is also true of Forth. E.g., much of my
Forth interpreter's vocabulary was based off of fig-Forth behaviors, but
also a few Forths that worked on Windows. What I've completed so far of
ANS CORE and CORE EXT also passes Hayes tests. However, some of that
behavior is not required as part of the current Forth standards. I.e.,
it's "undocumented," historical Forth behavior that is required to make
modern Forth work correctly. At least, that's the way I see it. Of
course, Hugh is also constantly arguing about the "ambiguity" in the
specifications, while others are always asking for clarifications and
interpretations of the standards. I'd say that is social proof which
feed my confirmation biases.


Rod Pemberton

[a...@littlepinkcloud.invalid]

Rod Pemberton <inv...@lkntrgzxc.com> wrote:
> On Fri, 30 Aug 2019 04:48:19 -0500
> a...@littlepinkcloud.invalid wrote:
>
>> Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>
>> > Of course, I believe that historical behavior should be preserved,
>> > as much as possible.
>>
>> WTF? Why do you believe that?
>
> My experience with C code.
>
> a) C code doesn't compile correctly when things change and so must be
> rewritten.
> b) many historical behaviors of C that are required to this very day,
> aren't included in the standards.

Well, yes, it's inconvenient when things change. It's also essential,
otherwise we'd be counting on abacuses.

> I'm believe the same is also true of Forth. E.g., much of my Forth
> interpreter's vocabulary was based off of fig-Forth behaviors, but
> also a few Forths that worked on Windows.

It's amazing that a snapshot of Forth has become sanctified in this
way. fig-FORTH was more or less a clone of microFORTH, which was
Forth, Inc's product at that time in the 1970s. It's purely an
accident.

Andrew.

[dxforth]

On Saturday, 31 August 2019 16:49:46 UTC+10, Rod Pemberton wrote:
> On Fri, 30 Aug 2019 04:48:19 -0500
> a...@littlepinkcloud.invalid wrote:
>
> > Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>
> > > Of course, I believe that historical behavior should be preserved,
> > > as much as possible.
> >
> > WTF? Why do you believe that?
> >
>
> My experience with C code.
>
> a) C code doesn't compile correctly when things change and so must be
> rewritten.
> b) many historical behaviors of C that are required to this very day,
> aren't included in the standards.
>
> I'm believe the same is also true of Forth.

> ...

Such considerations would matter had Forth a body of code such as
C that needed supporting. It doesn't. AFAIK there was no outcry
when Forth Inc stopped supporting polyForth. Forth users tend to
be adaptable knowing that vendors and standards have come and gone.

[Anton Ertl]

a...@littlepinkcloud.invalid writes:
>Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>> On Fri, 30 Aug 2019 04:48:19 -0500
>> a...@littlepinkcloud.invalid wrote:
>>
>>> Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>>
>>> > Of course, I believe that historical behavior should be preserved,
>>> > as much as possible.
>>>
>>> WTF? Why do you believe that?
>>
>> My experience with C code.
>>
>> a) C code doesn't compile correctly when things change and so must be
>> rewritten.
>> b) many historical behaviors of C that are required to this very day,
>> aren't included in the standards.
>
>Well, yes, it's inconvenient when things change. It's also essential,
>otherwise we'd be counting on abacuses.

But abacuses still continue to work as they always have. They were
not changed. Instead, we got additional tools. And most people these
days prefer the new tools, although I am sure that there are some that
prefer the abacus for its simplicity, and reject the new tools because
the abacus is good enough for the things they have been doing, and
introducing additional tools is needless complexity.

>It's amazing that a snapshot of Forth has become sanctified in this
>way. fig-FORTH was more or less a clone of microFORTH, which was
>Forth, Inc's product at that time in the 1970s. It's purely an
>accident.

So what? It's what started the Forth experience of a lot of people,
and some of them are nostalgic for it. Others (well, only one comes
to my mind) are nostalgic for polyForth, and a third group is
nostalgic for UR/Forth.

- 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 2019: http://euro.theforth.net/

[Anton Ertl]

Rod Pemberton <inv...@lkntrgzxc.com> writes:
>My experience with C code.
>
>a) C code doesn't compile correctly when things change and so must be
>rewritten.
>b) many historical behaviors of C that are required to this very day,
>aren't included in the standards.
>
>I'm believe the same is also true of Forth. E.g., much of my
>Forth interpreter's vocabulary was based off of fig-Forth behaviors, but
>also a few Forths that worked on Windows. What I've completed so far of
>ANS CORE and CORE EXT also passes Hayes tests. However, some of that
>behavior is not required as part of the current Forth standards. I.e.,
>it's "undocumented," historical Forth behavior that is required to make
>modern Forth work correctly.

What's with the scare quotes? If some things are not documented, they
are undocumented. Some things are explicitly undefined, maybe you
mean that. Anyway, for much of the stuff that used to work on Forth
systems of old, but was not standardized in Forth-94 or -2012, the
standard is quite explicit about it, most through "undefined" or
"ambiguous condition".

>At least, that's the way I see it. Of
>course, Hugh is also constantly arguing about the "ambiguity" in the
>specifications, while others are always asking for clarifications and
>interpretations of the standards.

Some of these questions are really just people who did not find the
right section in the document that answers their question. Others are
cases where people disagree with what the standard says. And others
really point out things where the standard document could do with a
clarification.

>I'd say that is social proof which
>feed my confirmation biases.

I think that there are such questions about any programming language
standard, so their existence proves nothing.

I think that there is a qualitative difference between what happens in
the C world and what happens in the Forth world.

In the C world, miscompilers have become widespread that miscompile by
propagating "knowledge" derived from the assumption that the program
does not perform undefined behaviour to other places that are not
obviously related. E.g., a bounded loop is "optimized" into an
endless loop, because of an array bounds violation.

In the Forth world, such shenanigans do not happen. At least as far
as the code is concerned, effects of ambiguous conditions are pretty
local to the code that implements the particular word; this is bad
enough, because at run-time any unexpected behaviour may become
apparent only much later, but it's still much better than what happens
in C.

[a...@littlepinkcloud.invalid]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> a...@littlepinkcloud.invalid writes:
>>Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>>> On Fri, 30 Aug 2019 04:48:19 -0500
>>> a...@littlepinkcloud.invalid wrote:
>>>
>>>> Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>>>
>>>> > Of course, I believe that historical behavior should be preserved,
>>>> > as much as possible.
>>>>
>>>> WTF? Why do you believe that?
>>>
>>> My experience with C code.
>>>
>>> a) C code doesn't compile correctly when things change and so must be
>>> rewritten.
>>> b) many historical behaviors of C that are required to this very day,
>>> aren't included in the standards.
>>
>>Well, yes, it's inconvenient when things change. It's also essential,
>>otherwise we'd be counting on abacuses.
>
> But abacuses still continue to work as they always have.

LOL! :-)

>>It's amazing that a snapshot of Forth has become sanctified in this
>>way. fig-FORTH was more or less a clone of microFORTH, which was
>>Forth, Inc's product at that time in the 1970s. It's purely an
>>accident.
>
> So what? It's what started the Forth experience of a lot of people,
> and some of them are nostalgic for it. Others (well, only one comes
> to my mind) are nostalgic for polyForth, and a third group is
> nostalgic for UR/Forth.

I'm not nostalgic for polyFORTH, whatever you think. I am nostalgic
for sensitive, intelligent language design that is based on actual
application usage.

Andrew.

[Krishna Myneni]

On Sun, 01 Sep 2019 15:29:19 +0000, Anton Ertl wrote:

> a...@littlepinkcloud.invalid writes:
>>Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>>> On Fri, 30 Aug 2019 04:48:19 -0500 a...@littlepinkcloud.invalid wrote:
>>>
>>>> Rod Pemberton <inv...@lkntrgzxc.com> wrote:
>>>
>>>> > Of course, I believe that historical behavior should be preserved,
>>>> > as much as possible.
>>>>
>>>> WTF? Why do you believe that?
>>>
>>> My experience with C code.
>>>
>>> a) C code doesn't compile correctly when things change and so must be
>>> rewritten.
>>> b) many historical behaviors of C that are required to this very day,
>>> aren't included in the standards.
>>
>>Well, yes, it's inconvenient when things change. It's also essential,
>>otherwise we'd be counting on abacuses.
>
> But abacuses still continue to work as they always have. They were not

> changed. Instead, we got additional tools. ...

But the abacus, in this case, the guaranteed behavior of >BODY for
variables and constants in Forth practices prior to ANS Forth, does not
continue to work. Worse than that, the abacus may have been broken for
not a particularly good reason: namely sacrificing a language feature in
favor of over-zealous optimization such as inlining constants. Inlining
constants and allowing >BODY to work on constants are not mutually
exclusive features.

KM

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:

> But the abacus, in this case, the guaranteed behavior of >BODY for
> variables and constants in Forth practices prior to ANS Forth,

It never was guaranteed behavior. Game over.

If you want it to be guaranteed behaviour on your system, you can do
that. No-one will stop you.

Andrew.

[none albert]

In article <y5ednUjNR8MHdvHA...@supernews.com>,

<a...@littlepinkcloud.invalid> wrote:
>Krishna Myneni <krishna...@ccreweb.org> wrote:
>
>> But the abacus, in this case, the guaranteed behavior of >BODY for
>> variables and constants in Forth practices prior to ANS Forth,
>
>It never was guaranteed behavior. Game over.

Especially not in the 80's where Forth was popular on affordable
computers and almost all implementations where based on fig,
which had PFA. >BODY became wide spread only after ANSI.

>
>If you want it to be guaranteed behaviour on your system, you can do
>that. No-one will stop you.

I certainly don't. Having DATA x that just leaves a pointer to HERE
(that can be filled afterwards) is a much better factor for other
words than CREATE with its does> pointer.
If one let ISO suggestions dictate what must be used internally
one is stifled regards simplification and I would say innovation.

DATA ( "name" ) create a definition "name"
Execution leaves HERE at the moment of creation.

: VARIABLE DATA 0 , ;
: 2VARIABLE DATA 0 , 0 , ;
: BUFFER ( n -- 0 ) DATA ALLOT ;
I throw in a non trivial data structure for good measure

: BAG ( n -- 0 ) DATA DUP HERE , CELLS ALLOT ;

>
>Andrew.

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Krishna Myneni]

On Mon, 02 Sep 2019 05:14:50 -0500, aph wrote:

> Krishna Myneni <krishna...@ccreweb.org> wrote:
>
>> But the abacus, in this case, the guaranteed behavior of >BODY for
>> variables and constants in Forth practices prior to ANS Forth,
>
> It never was guaranteed behavior. Game over.
>

It was bad wording that doesn't reflect accurately what I was trying to
convey. In an ealier message in this thread I conceded ANS Forth doesn't
guarantee that VARIABLEs and CONSTANTs use CREATE and therefore ">BODY"
cannot guarantee a valid address in ANS Forth. My statement was intended
to convey that the corresponding words to ">BODY" , e.g. ">PFA" in Forth
systems prior to ANS Forth often behaved like this with VARIABLEs and
CONSTANTs as Rod Pemberton pointed out earlier.

The rationale for doing away with such practice, based on comments from
system implementers, appears to be that

1) optimizations in the implementation of VARIABLEs and CONSTANTs prevent
allowing ">BODY" to work with them, at least for a convenient
implementation.

2) The use of ">BODY" to access data fields of such words is of
questionable value.

> If you want it to be guaranteed behaviour on your system, you can do
> that. No-one will stop you.

Of course I'm free to implement things in any way that I like in my
system. But this is a discussion of the meaning of words in the current
forth-2012 standard, meant to illuminate what coding techniques would be
portable across systems that used the standard, in whole or in part.
Obviously I'm interested in writing portable code and I'm not going to
detach my system from common practice except where I think it's needed
for my use. I like your discriminant of "intelligent, sensitive design",
which can never be 100%, either in my system or in standards such as ANS-
Forth or Forth-2012.

KM


> Andrew.

[none albert]

In article <qkjgap$pj8$1...@dont-email.me>,

Krishna Myneni <krishna...@ccreweb.org> wrote:
>On Mon, 02 Sep 2019 05:14:50 -0500, aph wrote:
>
>> Krishna Myneni <krishna...@ccreweb.org> wrote:
>>
>>> But the abacus, in this case, the guaranteed behavior of >BODY for
>>> variables and constants in Forth practices prior to ANS Forth,
>>
>> It never was guaranteed behavior. Game over.
>>
>
>It was bad wording that doesn't reflect accurately what I was trying to
>convey. In an ealier message in this thread I conceded ANS Forth doesn't
>guarantee that VARIABLEs and CONSTANTs use CREATE and therefore ">BODY"
>cannot guarantee a valid address in ANS Forth. My statement was intended
>to convey that the corresponding words to ">BODY" , e.g. ">PFA" in Forth
>systems prior to ANS Forth often behaved like this with VARIABLEs and
>CONSTANTs as Rod Pemberton pointed out earlier.
>
>The rationale for doing away with such practice, based on comments from
>system implementers, appears to be that
>
>1) optimizations in the implementation of VARIABLEs and CONSTANTs prevent
>allowing ">BODY" to work with them, at least for a convenient
>implementation.
>
>2) The use of ">BODY" to access data fields of such words is of
>questionable value.

3) The requirement that if a word is CREATE d there must be a DOES>
pointer to change it behaviour. Where almost al words can get by
with a code field and a data field, a CREATE d word must have a code field
and a data field that is a pointer to a struct with a field pointing
to high level code (DOES> pointer) and the actual data (body).

(This was the show stopper for me. I like my primitives simple and
small.)

[Paul Rubin]

albert@cherry.(none) (albert) writes:
> 3) The requirement that if a word is CREATE d there must be a DOES>
> pointer to change it behaviour.

There was a widely used Forth that required that? I had thought

CREATE bob 20 CELLS ALLOT

was idiomatic.

[dxforth]

Language design comes first. ANS reversed the order causing vested
interests to come first thereby making intelligent design impossible.

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:
> On Mon, 02 Sep 2019 05:14:50 -0500, aph wrote:
>
>> Krishna Myneni <krishna...@ccreweb.org> wrote:
>>
>>> But the abacus, in this case, the guaranteed behavior of >BODY for
>>> variables and constants in Forth practices prior to ANS Forth,
>>
>> It never was guaranteed behavior. Game over.
>
> It was bad wording that doesn't reflect accurately what I was trying to
> convey. In an ealier message in this thread I conceded ANS Forth doesn't
> guarantee that VARIABLEs and CONSTANTs use CREATE and therefore ">BODY"
> cannot guarantee a valid address in ANS Forth. My statement was intended
> to convey that the corresponding words to ">BODY" , e.g. ">PFA" in Forth
> systems prior to ANS Forth often behaved like this with VARIABLEs and
> CONSTANTs as Rod Pemberton pointed out earlier.

Sometimes did; it's never been any better than that. And prior to ANS
(in fact, prior to polyFORTH), >BODY (or PFA) didn't work on children
of DOES> either.

> The rationale for doing away with such practice,

It was not "done away with", IMO.

> based on comments from system implementers, appears to be that
>
> 1) optimizations in the implementation of VARIABLEs and CONSTANTs prevent
> allowing ">BODY" to work with them, at least for a convenient
> implementation.

Yes, especially if we're running in ROM.

> 2) The use of ">BODY" to access data fields of such words is of
> questionable value.

In the case of constants, especially so. And long as Forth programs
have been running in ROM -- which is a very long time -- constants
have been in ROM.

We have to distinguish features that are purely an artefact of a
particular implementation technique from properties of the
language. In fig-FORTH that is especially difficult, which is one of
the reasons that a language specification was useful.

>> If you want it to be guaranteed behaviour on your system, you can do
>> that. No-one will stop you.
>
> Of course I'm free to implement things in any way that I like in my
> system. But this is a discussion of the meaning of words in the
> current forth-2012 standard, meant to illuminate what coding
> techniques would be portable across systems that used the standard,
> in whole or in part.

Sure, fair enough.

Andrew.

[Alex McDonald]

I couldn't disagree more. Where there are extant systems (or as the IETF
likes to call it, "running code" https://www.ietf.org/how/runningcode/)
then standardization only works when vested interests are considered.
RFCs are rarely designed in advance (and right now I can't think of one).

--
Alex

[a...@littlepinkcloud.invalid]

Indeed, and in the case of ANS it was a fascinating exercise. Forth
had by that time diverged considerably, and to try to extract a useful
language from the various implementations was a challenge. One that was
successful to a remarkable extent, considering the scope of the
problem.

Andrew.

[Krishna Myneni]

On Tue, 03 Sep 2019 10:44:17 +0100, Alex McDonald wrote:

> On 03-Sep-19 02:50, dxforth wrote:

...

>> Language design comes first. ANS reversed the order causing vested
>> interests to come first thereby making intelligent design impossible.
>>
>>
> I couldn't disagree more. Where there are extant systems (or as the IETF
> likes to call it, "running code" https://www.ietf.org/how/runningcode/)
> then standardization only works when vested interests are considered.
> RFCs are rarely designed in advance (and right now I can't think of
> one).

Intelligent language design and the existence of systems in which the
consensus is that the design is flawed does not mean that the language
cannot be evolved to the desired point. There's a way to get from here to
there. Begin by reaching a consensus, declaring existing design features
and usage to be obsolescent, proposing new words which do not conflict
with obsolescent words, and eventually phasing them out of the standard
over a number of years. Where consensus can't be reached, common practice
will eventually solve the problem.

KM

[none albert]

In article <877e6qt...@nightsong.com>,

Not "widely used", it is an ANSI requirement.
You can follow the above with
DOES> 20 CELLS TYPE ;

[hughag...@gmail.com]

My MFX inlined constants using LIT internally.
It also created a constant that could be ticked and you would get an
xt that could be executed to push the value like any constant does.
This was trivial to accomplish. The immediate word in HOST generated
the LIT code in TARG words --- the word in TARG was the one that was
found with T' or ['T] providing a TARG cfa (I used the term cfa
in those days, as I didn't know the term xt at that time).

IIRC, I didn't have >BODY in MFX. I might of though; it is easy to provide.
I know I didn't have VALUE and TO in MFX.
With my locals, I generated various derivative words.
For example, if the local name was ABC I would also generate ABC! that
stored into it. I had a lot of derivative words! All of these
were "ghost" primitives, meaning that they didn't materialize unless
they were referenced at least once --- this allowed me to meta-compile
hundreds of ghosts without wasting code-memory in the usual case that
only a few of them actually got used.

If I did have >BODY I would have certainly made it illegal to use it
on a constant --- the idea of a mutable constant is very dumb!
The term "constant" implies that it is, you know, constant --- it doesn't
mean one value in some parts of the program and another value elsewhere.
I did have VARIABLE that is, you know, variable.

[Krishna Myneni]

On Tue, 03 Sep 2019 04:24:50 -0500, aph wrote:

> Krishna Myneni <krishna...@ccreweb.org> wrote:
>> On Mon, 02 Sep 2019 05:14:50 -0500, aph wrote:
>>
>>> Krishna Myneni <krishna...@ccreweb.org> wrote:

>> ... My statement was

>> intended to convey that the corresponding words to ">BODY" , e.g.
>> ">PFA" in Forth systems prior to ANS Forth often behaved like this with
>> VARIABLEs and CONSTANTs as Rod Pemberton pointed out earlier.
>
> Sometimes did; it's never been any better than that. And prior to ANS
> (in fact, prior to polyFORTH), >BODY (or PFA) didn't work on children of
> DOES> either.
>

I will have to check, but I'm pretty sure in UR/Forth >BODY did provide
the parameter field address of a word created by CREATE ... DOES>

>> The rationale for doing away with such practice,
>
> It was not "done away with", IMO.
>
>> based on comments from system implementers, appears to be that
>>
>> 1) optimizations in the implementation of VARIABLEs and CONSTANTs
>> prevent allowing ">BODY" to work with them, at least for a convenient
>> implementation.
>
> Yes, especially if we're running in ROM.

Well, VARIABLEs would certainly not be in ROM. Regarding CONSTANTs see
below.

>
>> 2) The use of ">BODY" to access data fields of such words is of
>> questionable value.
>
> In the case of constants, especially so. And long as Forth programs have
> been running in ROM -- which is a very long time -- constants have been
> in ROM.

Even if CONSTANTs were held in ROM, which is a good idea, they have a
valid address which can be returned by >BODY or equivalent. If there is
an overlapping address space between ROM and RAM then it would be
difficult to do.

Krishna

[Andy Valencia]

Alex McDonald <al...@rivadpm.com> writes:
> I couldn't disagree more. Where there are extant systems (or as the IETF
> likes to call it, "running code" https://www.ietf.org/how/runningcode/)
> then standardization only works when vested interests are considered.
> RFCs are rarely designed in advance (and right now I can't think of one).

In fact, the old IETF mantra was "rough consensus and running code".
All their strongest standards came from that philosophy, and it
was my experience during the years I worked standards at the IETF.

-----------------
Andy Valencia
Home page: https://vsta.org/andy/
Contact: https://vsta.org/contact/andy.html

[dxforth]

It's individuals - Backus, McCarthy, Wirth, K&R, Moore et al - that
create languages. The carpetbaggers came later.

[a...@littlepinkcloud.invalid]

Krishna Myneni <krishna...@ccreweb.org> wrote:
> On Tue, 03 Sep 2019 04:24:50 -0500, aph wrote:
>
>> Krishna Myneni <krishna...@ccreweb.org> wrote:
>>> On Mon, 02 Sep 2019 05:14:50 -0500, aph wrote:
>>>
>>>> Krishna Myneni <krishna...@ccreweb.org> wrote:
>>> ... My statement was
>>> intended to convey that the corresponding words to ">BODY" , e.g.
>>> ">PFA" in Forth systems prior to ANS Forth often behaved like this with
>>> VARIABLEs and CONSTANTs as Rod Pemberton pointed out earlier.
>>
>> Sometimes did; it's never been any better than that. And prior to ANS
>> (in fact, prior to polyFORTH), >BODY (or PFA) didn't work on children of
>> DOES> either.
>
> I will have to check, but I'm pretty sure in UR/Forth >BODY did provide
> the parameter field address of a word created by CREATE ... DOES>

So did fig-FORTH, but the DOES> pointer was there, not the data.

>>> The rationale for doing away with such practice,
>>
>> It was not "done away with", IMO.
>>
>>> based on comments from system implementers, appears to be that
>>>
>>> 1) optimizations in the implementation of VARIABLEs and CONSTANTs
>>> prevent allowing ">BODY" to work with them, at least for a convenient
>>> implementation.
>>
>> Yes, especially if we're running in ROM.
>
> Well, VARIABLEs would certainly not be in ROM.

Correct. The body would be a pointer to RAM.

> Regarding CONSTANTs see below.

>>> 2) The use of ">BODY" to access data fields of such words is of
>>> questionable value.
>>
>> In the case of constants, especially so. And long as Forth programs have
>> been running in ROM -- which is a very long time -- constants have been
>> in ROM.
>
> Even if CONSTANTs were held in ROM, which is a good idea, they have a
> valid address which can be returned by >BODY or equivalent.

So what? What are you going to do with data there?

Andrew.

[Krishna Myneni]

On Wed, 04 Sep 2019 03:25:20 -0500, aph wrote:

> Krishna Myneni <krishna...@ccreweb.org> wrote:
...

>>> In the case of constants, especially so. And long as Forth programs
>>> have been running in ROM -- which is a very long time -- constants
>>> have been in ROM.
>>
>> Even if CONSTANTs were held in ROM, which is a good idea, they have a
>> valid address which can be returned by >BODY or equivalent.
>
> So what? What are you going to do with data there?
>

For one, I can see in a comprehensive information list of words in a
wordlist, as generated by WL-INFO , that the word has data associated
with it. I don't have to inspect the source code to know this.

Second I can inspect it without having to know that the word is a
constant.

Suppose someone gives me source code that I load into my system, without
looking at it in detail. In my Forth system, where >BODY either returns a
zero or a valid data field address, WL-INFO shows me which words have
data fields. This indicates the word is associated with a CREATE ...
ALLOT sequence. It may be a variable, constant, or a buffer. This is
useful knowledge in understanding source code.

Krishna

[Krishna Myneni]

On Wed, 04 Sep 2019 22:55:33 +0000, Krishna Myneni wrote:

...

>
> Suppose someone gives me source code that I load into my system, without
> looking at it in detail. In my Forth system, where >BODY either returns
> a zero or a valid data field address, WL-INFO shows me which words have
> data fields. This indicates the word is associated with a CREATE ...
> ALLOT sequence. It may be a variable, constant, or a buffer. This is
> useful knowledge in understanding source code.

> ...

A more useful word than WL-INFO is WL-DATA-WORDS for the purpose of
showing which words have data fields is easy to write with TRAVERSE-
WORDLIST and assuming that the Forth system has a clean >BODY which works
with CREATE words properly:

----
\ Display name and data field address for a word only
\ if it has a non-zero body address and non-zero xt.
: data-word ( nt -- flag )
dup name>interpret
?dup IF
>body ?dup IF
swap name>string cr 32 $.R \ display the wordname
4 spaces 16 u.r \ display the data field address
ELSE drop
THEN
ELSE drop
THEN
true ;

: wl-data-words ( wid -- )
['] data-word swap traverse-wordlist cr ;
----

In kForth-32/64 (Google groups may mangle the formatting):

----
hex
forth-wordlist wl-data-words

PRECISION 8064E90
BASE 8064E88
STATE 8064E8C

ok
include system-test/core.4th \ the Hayes core tests
( ... output from core.4th ... )
ok
forth-wordlist wl-data-words

ABUF 99C1960
SBUF 99D9600
FBUF 99C16B8
GN-BUF 99D93F0
#BITS-UD 99D9350
MAX-BASE 99D92E0
V1 99D8E08
Y123 99D8D88
X123 99D45D8
GT2STRING 99D8798
GT1STRING 99D8738
2NDC 99D8548
1STC 99D84D8
2ND 99D84A8
1ST 99D8438
<TRUE> 99D81D8
<FALSE> 99D8188
MID-UINT+1 99D8138
MID-UINT 99D4248
MIN-INT 99D41F8
MAX-INT 99D41A8
MAX-UINT 99D4158
MSB 99D40A0
1S 99D4070
0S 99D54A0
VERBOSE 99D53E0
CELLS-PER-FP 99D5318
EXACT? 99D4F78
ABS-NEAR 99D4F28
REL-NEAR 99D4ED8
HAS-FLOATING-STACK 99D4E88
HAS-FLOATING 99D4E08
ERROR-XT 99D4DA8
XCURSOR 99D4D58
START-DEPTH 99D4D08
ACTUAL-RESULTS 99D4C40
ACTUAL-DEPTH 99D4BB8
HANDLER 99D48F8
PAD 99D42E0
PRECISION 8064E90
BASE 8064E88
STATE 8064E8C
ok
-----

The variables, constants, and named,ALLOTed buffers are shown along with
their data field addresses (body addresses) for the wordlist, FORTH-
WORDLIST .

I find this to be pretty useful output.

KM

[Krishna Myneni]

On Thu, 05 Sep 2019 01:59:47 +0000, Krishna Myneni wrote:

...

> A more useful word than WL-INFO is WL-DATA-WORDS for the purpose of
> showing which words have data fields is easy to write with TRAVERSE-
> WORDLIST and assuming that the Forth system has a clean >BODY which
> works with CREATE words properly:
>
> ----
> \ Display name and data field address for a word only \ if it has a
> non-zero body address and non-zero xt.
> : data-word ( nt -- flag )
> dup name>interpret ?dup IF
> >body ?dup IF
> swap name>string cr 32 $.R \ display the wordname 4 spaces 16
> u.r \ display the data field address
> ELSE drop THEN
> ELSE drop THEN true ;
>
> : wl-data-words ( wid -- )
> ['] data-word swap traverse-wordlist cr ;
> ----

> ...

In the context of the ANS/Forth-2012 standard, WL-DATA-WORDS could be WL-
CREATED-WORDS , i.e. serve the purpose of discovering named definitions
which are the children of CREATE . However, this would require removal of
the ambiguous condition in the standard for >BODY :

----
>BODY
( xt -- a-addr )

a-addr is the data-field address corresponding to xt. An ambiguous
condition exists if xt is not for a word defined via CREATE.

See:
3.3.3 Data space, A.6.1.0550 >BODY.

Rationale:
a-addr is the address that HERE would have returned had it been executed
immediately after the execution of the CREATE that defined xt.
Testing:
T{ CREATE CR0 -> }T
T{ ' CR0 >BODY -> HERE }T
----

If the standard required that >BODY return NULL (0) for the xt of a word
not defined by CREATE , then it is possible to have a portable WL-CREATED-
WORDS . Forth system implementers can make xCONSTANTS , xVARIABLES , and
named data buffers discoverable by using CREATE to implement them, if
they wish to do so.

KM

[none albert]

In article <qktj4v$15k$1...@dont-email.me>,
Krishna Myneni <krishna...@ccreweb.org> wrote:
<SNIP>

>
>If the standard required that >BODY return NULL (0) for the xt of a word
>not defined by CREATE , then it is possible to have a portable WL-CREATED-
>WORDS . Forth system implementers can make xCONSTANTS , xVARIABLES , and
>named data buffers discoverable by using CREATE to implement them, if
>they wish to do so.

Then we should also demand that #> returns an empty string if there
is not a preceeding <# etc. etc.
My system may crash if you run >BODY on a non-created word.
"Fixing" that requires a heap of pulleys and ropes that are in principle
superfluous.

You try to impose implementation details of your system on the standard.

>
>KM

[dxforth]

On Saturday, 7 September 2019 18:07:05 UTC+10, none albert wrote:
> In article <qktj4v$15k$1...@dont-email.me>,
> Krishna Myneni <krishna...@ccreweb.org> wrote:
> <SNIP>
> >
> >If the standard required that >BODY return NULL (0) for the xt of a word
> >not defined by CREATE , then it is possible to have a portable WL-CREATED-
> >WORDS . Forth system implementers can make xCONSTANTS , xVARIABLES , and
> >named data buffers discoverable by using CREATE to implement them, if
> >they wish to do so.
>
> Then we should also demand that #> returns an empty string if there
> is not a preceeding <# etc. etc.
> My system may crash if you run >BODY on a non-created word.
> "Fixing" that requires a heap of pulleys and ropes that are in principle
> superfluous.
>
> You try to impose implementation details of your system on the standard.

Too late. That's existed from the first standard - 'common practice' being
a euphemism for players whose implementations need to be accommodated
else there won't be a standard.

[Krishna Myneni]

On Sat, 07 Sep 2019 08:07:03 +0000, none) (albert wrote:

> In article <qktj4v$15k$1...@dont-email.me>,
> Krishna Myneni <krishna...@ccreweb.org> wrote:

...

>>If the standard required that >BODY return NULL (0) for the xt of a word
>>not defined by CREATE , then it is possible to have a portable

>>WL-CREATED-WORDS . ...

> My system may crash if you run >BODY on a non-created word.
> "Fixing" that requires a heap of pulleys and ropes that are in principle
> superfluous.
>
> You try to impose implementation details of your system on the standard.

My statement points out a potentially useful consequence of removing an
unambiguous condition in the standard. It is not imposing anything on
your system. However, if such a proposal is ever made then system
implementers can weigh in on whether or not it is practical to do so.

KM

[Krishna Myneni]

On Sun, 08 Sep 2019 13:44:42 +0000, Krishna Myneni wrote:

> On Sat, 07 Sep 2019 08:07:03 +0000, none) (albert wrote:
>
...
>> My system may crash if you run >BODY on a non-created word.
>> "Fixing" that requires a heap of pulleys and ropes that are in
>> principle superfluous.
>>
>> You try to impose implementation details of your system on the
>> standard.
>

> ... It is not imposing anything on your system. However, if such a

> proposal is ever made then system implementers can weigh in on
> whether or not it is practical to do so.

Actually, it is useful to know well in advance of developing a proposal
whether or not such a change will be supported by system implementers --
saves a lot of time to know if there is too little support to even
consider.

KM

[dxforth]

As with all the previous TC's those who you need to convince are
relatively few and the rest will follow.

[Krishna Myneni]

On Sun, 08 Sep 2019 18:54:01 -0700, dxforth wrote:

> On Monday, 9 September 2019 00:12:24 UTC+10, Krishna Myneni wrote:

...

>> Actually, it is useful to know well in advance of developing a proposal
>> whether or not such a change will be supported by system implementers
>> --
>> saves a lot of time to know if there is too little support to even
>> consider.
>
> As with all the previous TC's those who you need to convince are
> relatively few and the rest will follow.

My intent is not to convince anyone, in the sense of lobbying for a
change, whether I'm speaking to system implementers or to members of a
TC. If I feel there's a technical case to be made for some revision/
addition, I'll make an argument based on demonstrated or perceived
benefit. Once a sound technical argument is presented, the job is done
for me.

Standards for a computer language are useful for interoperability of code
and for capturing best practices. A wealth of experiential knowledge is
often encoded within a standard. While I am considerate of standards, a
standard itself is of secondary concern for me. The more important and
immediate concern is how to use my Forth system (or other systems) to
encode and solve a problem of interest to me. Standards make the original
investment of time in solving a problem pay interest over time.

Krishna

[dxforth]

On Monday, 9 September 2019 13:15:47 UTC+10, Krishna Myneni wrote:
> On Sun, 08 Sep 2019 18:54:01 -0700, dxforth wrote:
>
> > On Monday, 9 September 2019 00:12:24 UTC+10, Krishna Myneni wrote:
> ...
> >> Actually, it is useful to know well in advance of developing a proposal
> >> whether or not such a change will be supported by system implementers
> >> --
> >> saves a lot of time to know if there is too little support to even
> >> consider.
> >
> > As with all the previous TC's those who you need to convince are
> > relatively few and the rest will follow.
>
> My intent is not to convince anyone, in the sense of lobbying for a
> change, whether I'm speaking to system implementers or to members of a
> TC. If I feel there's a technical case to be made for some revision/
> addition, I'll make an argument based on demonstrated or perceived
> benefit. Once a sound technical argument is presented, the job is done
> for me.

Agreed but "it's useful to know" suggested a formal proposal. It
proved useful to me to know that a formal proposal to standardize
words to uppercase had insufficient TC support to proceed.