RfD - FVALUE
Marcel Hendrix
Marcel Hendrix, August 25, 2006
* First draft *
Rationale
=========
Problem
-------
The word VALUE was considered useful enough to be included in ANS94.
A search through 4827 source files shows 532 occurences of VARIABLE
versus 4241 uses of VALUE. It would be obviously useful to have a
variant of VALUE that works for floating-point values.
The main idea behind FVALUE is that fetching a variable is more
frequent than changing it. Therefore both readibility of source code
and efficiency of execution can be achieved by making 'F@' the default
action of FVALUE.
Current practice
----------------
The proposed form of FVALUE has been in use in tForth, iForth, and their
predecessors since 1985. FVALUE (with TO) is also in use for Mops and
MacForth. The systems mentioned define more TO-like words that work on
values, e.g. +TO -TO CLEAR, with obvious meanings.
This proposal does not propose to standardize on these extensions.
Solution
--------
Although many people have objected to parsing words, parsing
permits the host system the most flexibility in implementation
and is thus the preferred solution (see also TO).
The syntax is:
123e0 FVALUE fdata
to define <fdata> as a floating-point value initialized to <123e0>.
To access the value of fdata:
fdata 2e0 F+ F. <cr> 125.000000 ok
To change fdata:
fdata 2e0 F+ TO fdata fdata F. <cr> 125.000000 ok
Proposal
========
12.6.1.xxxx FVALUE "f-value" FLOATING
( F: x -- ) ( "<spaces>name" -- )
Skip leading space delimiters. Parse name delimited by a space. Create
a definition for name with the execution semantics defined below, with
an initial value equal to x.
name is referred to as an "f-value".
name Execution: ( F: -- x )
Place x on the FP stack. The value of x is that given when name was
created, until the phrase x TO name is executed, causing a new value of
x to be associated with name.
See: 3.4.1 Parsing.
6.2.2295 TO CORE EXT
Interpretation: ( x "<spaces>name" -- ) or ( F: x -- ) ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Store x in
name. An ambiguous condition exists if name was not defined by VALUE or FVALUE.
Compilation: ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Append the
run-time semantics given below to the current definition. An ambiguous
condition exists if name was not defined by VALUE or FVALUE.
Run-time: ( x -- ) or ( F: x -- )
Store x in name.
Note: An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO.
See: 6.2.2405 VALUE, 12.6.1.xxxx FVALUE, 13.6.1.2295 TO.
13.6.1.2295 TO LOCAL
Extend the semantics of 6.2.2295 TO to be:
Interpretation: ( x "<spaces>name" -- ) or ( F: x -- ) ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Store x in
name. An ambiguous condition exists if name was not defined by VALUE or FVALUE.
Compilation: ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Append the
run-time semantics given below to the current definition. An ambiguous
condition exists if name was not defined by either VALUE, FVALUE or (LOCAL).
Run-time: ( x -- ) or ( F: x -- )
Store x in name.
Note:
An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO.
See: 3.4.1 Parsing, 6.2.2295 TO, 6.2.2405 VALUE, 12.6.1.xxxx FVALUE, 13.6.1.0086 (LOCAL).
Labelling
=========
TBD
Reference Implementation
========================
The implementation of FVALUE requires carnal knowledge of the host
implementation, which is the main reason why it should be standardized.
The implementation below disregards the issue that TO should also
work for integer VALUEs and locals.
: FVALUE CREATE F, ( F: r -- ) DOES> F@ ; ( F: -- r )
: TO ( F: r -- ) ( "<spaces>name" -- )
' >BODY
STATE @ IF POSTPONE LITERAL POSTPONE F!
ELSE F!
THEN ; IMMEDIATE
Test Cases
==========
123e FVALUE fdata
2 VALUE idata
: foo ( -- )
idata LOCALS| ldata |
ldata . idata 2* TO ldata ldata .
idata 1 D>F TO fdata fdata F.
fdata 33e F+ F>D D>S TO idata idata .
ldata idata + fdata F>D D>S + . ;
foo <cr> 2 4 4.294967e9 35 41 ok
Marcel Hendrix
Marcel Hendrix, August 25, 2006
* First draft *
* First spell-checked draft *
Rationale
=========
Problem
-------
The word VALUE was considered useful enough to be included in ANS94.
A search through 4827 source files shows 532 occurrences of VARIABLE
versus 4241 uses of VALUE. It would be obviously useful to have a
variant of VALUE that works for floating-point values.
The main idea behind FVALUE is that fetching a variable is more
frequent than changing it. Therefore both readability of source code
Labeling
Anton Ertl
>RfD - FVALUE
>Marcel Hendrix, August 25, 2006
>
>* First draft *
>* First spell-checked draft *
How about a draft that can be read even on 80-char-wide terminals?
- 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 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
ward mcfarland
> RfD - FVALUE
I have no trouble supporting this, since as you mentioned, MacForth
supports FLOCAL and TO +TO both work fine with FLOCAL's.
-- w
Julian V. Noble
What is wrong with FTO vs TO for FVALUEs? Why do you want
to make TO smart enough to tell the difference between an
integer and a floating point VALUE ? If you're going to do
that why not make VALUE smart enough to tell the difference?
--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
werty
I dont see any value in this discussion of an ambiguios cmd called
Value ha ha hahhahhha
Certainly you can figure a more intuitive cmd than that !!
What kind of Value ? Where used ?!!
You better switch from the old obsolete Forth to NewForth ....
Doug Hoffman
Marcel Hendrix wrote:
> RfD - FVALUE
> Marcel Hendrix, August 25, 2006
>
> * First draft *
Bravo Marcel! My enthusiasm for Forth is getting re-energized with
(even if overdue) standards proposals such as this and those by Stephen
Pelc.
Regards,
-Doug
Doug Hoffman
You wrote:
> What is wrong with FTO vs TO for FVALUEs? Why do you want
> to make TO smart enough to tell the difference between an
> integer and a floating point VALUE ?
I think the idea here is to help reduce the "name explosion" problem.
> If you're going to do that why not make VALUE smart enough
> to tell the difference?
Because one can quickly check the "type" of the (F)VALUE, integer or
float, simply by checking its declaration. Otherwise things could get
pretty confusing. I think I understand your point. But a balance must
be struck between polymorphic words and type declaration. Also, I
believe most existing code will not be broken by sticking to Marcel's
proposal.
You could always use SYNONYM for your own code if you prefer FTO. :-)
Regards,
-Doug
Marcel Hendrix
> Marcel Hendrix wrote:
>> RfD - FVALUE
> What is wrong with FTO vs TO for FVALUEs?
It has no history. I think FTO was implemented by Jos Ven for
Win32F because he wanted to quickly port some iForth stuff and
didn't find the internals of TO quickly enough.
Defining FTO would be against Paul Bartholdi's initial vision.
(Check the on-line FD annals for the TO concept).
Programmers really wanting FTO can use a SYNONYM, as others
have suggested.
> Why do you want
> to make TO smart enough to tell the difference between an
> integer and a floating point VALUE ?
In the context of standardization it only matters that I have
done so, and a sizeable number of other implementations found
it a good idea too.
> If you're going to do
> that why not make VALUE smart enough to tell the difference?
The difference in what? Do you mean:
55 VALUE a
66e-12 VALUE b
0 VALUE c
a b + TO c
As you can see, a smart VALUE wouldn't help.
But I don't think you are serious :-)
BTW: I see that VFX 3.9 also supports FVALUE, with TO.
-marcel
Charles Melice
"Julian V. Noble" <j...@virginia.edu> a écrit dans le message de news:
ecnpnj$3pn$1...@murdoch.acc.Virginia.EDU...
> Marcel Hendrix wrote:
>> RfD - FVALUE
>> Marcel Hendrix, August 25, 2006
>>
>> * First draft *
>> * First spell-checked draft *
>>
[...]
>> : foo ( -- )
>> idata LOCALS| ldata |
>> ldata . idata 2* TO ldata ldata .
>> idata 1 D>F TO fdata fdata F.
>> fdata 33e F+ F>D D>S TO idata idata . ldata idata + fdata F>D
>> D>S + . ;
>>
>> foo <cr> 2 4 4.294967e9 35 41 ok
>>
>
> What is wrong with FTO vs TO for FVALUEs? Why do you want
> to make TO smart enough to tell the difference between an
> integer and a floating point VALUE ? If you're going to do
> that why not make VALUE smart enough to tell the difference?
>
I agree.
Also in that spirit, 'IS' should be replaced by 'TO' too.
I think 'FTO' is better because it indicates the usage of
the floats stack (if exists).
- 'IS', 'TO' and 'FTO' can check the target but not the source.
- 'FTO' is more in the Forth tradition (no type)
- 'FTO' is more easy to implement.
Finally, I think it's better to improve 'TO', 'FTO' and 'IS'
to check the right target:
0 value L
0e fvalue X.
defer Compute
10 to X. ( error )
5e fto L ( error )
' sin to Compute ( error )
Charles Melice
GerryJ
Marcel Hendrix wrote:
> RfD - FVALUE
> Marcel Hendrix, August 25, 2006
>
> * First draft *
> * First spell-checked draft *
>
> Rationale
> =========
> Problem
> -------
> The word VALUE was considered useful enough to be included in ANS94.
> A search through 4827 source files shows 532 occurrences of VARIABLE
> versus 4241 uses of VALUE. It would be obviously useful to have a
> variant of VALUE that works for floating-point values.
If we're going to have FVALUE why not include 2VALUE to complete the
set? 2VALUE would be useful for holding the (caddr u) pair for strings.
>
> 13.6.1.2295 TO LOCAL
> Extend the semantics of 6.2.2295 TO to be:
> Interpretation: ( x "<spaces>name" -- ) or ( F: x -- ) ( "<spaces>name" -- )
The use of F: in the floating point stack comment clashes with the
proposed reserved use of F: for declaring
local floating point values. No real problem apart from a bit of
confusion.
Gerry
Coos Haak
12.2.2.2 Stack notation
Floating-point stack notation when the floating-point stack is separate
from the data stack is:
( F: before -- after )
(And systems that hold them on the data stack, F: is omitted or given as S:
)
And to Marcel: Floating point numbers are notated with the letter r,
integers with x ;-)
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Marcel Hendrix
> Marcel Hendrix wrote:
> If we're going to have FVALUE why not include 2VALUE to complete the
> set? 2VALUE would be useful for holding the (caddr u) pair for strings.
And ZVALUE ( complex) and DDVALUE ( double-double) and ... :-)
Are people using this already, so is there a need for standardizing?
In iForth I use DDVALUE (double-double), ZVALUE (complex), DVALUE (2value),
VALUE and FVALUE, and there are LOCALS|, DLOCALS|, FLOCALS| and ZLOCALS|.
No DDLOCALS| yet, I can use ZLOCALS| in a pinch.
If you want to use 2VALUE for strings I would suggest another name, like
$VALUE . The idea is that a TO-message like CLEAR should do something different
for a string than for an arbitrary set of numbers.
>
> 13.6.1.2295 TO LOCAL
> Extend the semantics of 6.2.2295 TO to be:
> Interpretation: ( x "<spaces>name" -- ) or ( F: x -- ) ( "<spaces>name" -- )
> The use of F: in the floating point stack comment clashes with the
> proposed reserved use of F: for declaring local floating point values.
> No real problem apart from a bit of confusion.
Confusion only if you need glasses and can't distinguish ( from { :-)
From ANS94:
12.6.1.1420 F+ "f-plus" FLOATING
( F: r1 r2 -- r3 ) or ( r1 r2 -- r3 )
Add r1 to r2 giving the sum r3.
As you can see there is widespread and undisputed practice for my notation.
-marcel
GerryJ
> "GerryJ" <ge...@jackson9000.fsnet.co.uk> writes Re: RfD - FVALUE
>
> > Marcel Hendrix wrote:
>
> > If we're going to have FVALUE why not include 2VALUE to complete the
> > set? 2VALUE would be useful for holding the (caddr u) pair for strings.
>
> And ZVALUE ( complex) and DDVALUE ( double-double) and ... :-)
>
> Are people using this already, so is there a need for standardizing?
>
> In iForth I use DDVALUE (double-double), ZVALUE (complex), DVALUE (2value),
> VALUE and FVALUE, and there are LOCALS|, DLOCALS|, FLOCALS| and ZLOCALS|.
> No DDLOCALS| yet, I can use ZLOCALS| in a pinch.
>
> If you want to use 2VALUE for strings I would suggest another name, like
> $VALUE . The idea is that a TO-message like CLEAR should do something different
> for a string than for an arbitrary set of numbers.
>
> >
I am merely pointing out that ANS Forth already contains:
VARIABLE 2VARIABLE FVARIABLE and
CONSTANT 2CONSTANT FCONSTANT and
LITERAL 2LITERAL FLITERAL and
DROP 2DROP FDROP and
etc
but only VALUE
You and others are proposing to add FVALUE which I agree with, and it
seems sensible to me for the sake of consistency to also add 2VALUE
Of course the above pattern breaks for things like + D+ and F+ and
other operators but that doesn't seem to me, at least, a good enough
reason to exclude 2VALUE
I don't particularly want it for strings as it would have as many uses
as 2VARIABLE etc. I was merely giving an example of its possible
utility.
Gerry
George Hubert
GerryJ wrote:
>
> I am merely pointing out that ANS Forth already contains:
>
> VARIABLE 2VARIABLE FVARIABLE and
> CONSTANT 2CONSTANT FCONSTANT and
> LITERAL 2LITERAL FLITERAL and
> DROP 2DROP FDROP and
> etc
>
> but only VALUE
>
> You and others are proposing to add FVALUE which I agree with, and it
> seems sensible to me for the sake of consistency to also add 2VALUE
>
> Of course the above pattern breaks for things like + D+ and F+ and
> other operators
Operators use D (or both D and UD where separate signed and unsigned
versions are needed) to indicate specifically double numbers, whereas
2@ 2! etc work equally well
with pairs of single numbers and doubles.
> but that doesn't seem to me, at least, a good enough
> reason to exclude 2VALUE
>
The RfD is about FVALUE. You could always have a separate one for
2VALUE if you want.
George Hubert
Marcel Hendrix
[..]
> Operators use D (or both D and UD where separate signed and unsigned
> versions are needed) to indicate specifically double numbers, whereas
> 2@ 2! etc work equally well with pairs of single numbers and doubles.
No, 2@ and 2! specify a stack picture that is incompatible with hardware
details of some CPUs (and thus OSs). This means for some uses a SWAP
is necessary. I think dpANS tried to solve that, but the proposal got
shot down.
-marcel
J Thomas
I think his point is that double math operators work only on double
numbers -- if you use them on pairs of single numbers you might get
carries and such contaminating the results. (I have occasionally
looked at doing things like pairs of additions of small numbers with
doubles. It avoids explicit stack operations and on some hardware it's
more efficient. But usually it turned out there was some circumstance
where it would fail, and it wasn't worth the trickiness.) While 2@ and
2! do work on either double numbers or pairs of single-cell values of
any kind.
The committee looked at the problem you point out. They specified that
2@ and 2! both put the high-order data in the first cell and the
low-order data in the second. For some systems that makes every use of
2@ and 2! with double numbers use an implicit SWAP . But unless the
order is specified you can't portably use 2@ and 2! for anything but
double numbers. They talked about also defining D@ D! which would
efficiently store the numbers however it worked best for that system.
But it was late in the standards process, everybody was running out of
energy, double integers aren't very important to 32-bit or larger
systems, and it would be a source of confusion. So they just dropped
the issue.
When I think about it, a D@ D! which was guaranteed to use the
opposite order would have some use. Then when you collected two cells
from a data structure you could get them in whichever order you
preferred. Presumably both might be done efficiently and you could
avoid an explicit SWAP . I don't know how often that would be useful,
but it might be useful more often than saving double numbers. Maybe
optimising compilers could figure out which version to use, but it
would be a struggle unless they were told or figured out which uses
were actually double numbers and which were random data structures.
Albert van der Horst
Julian V. Noble <j...@virginia.edu> wrote:
>Marcel Hendrix wrote:
>> RfD - FVALUE
>> Marcel Hendrix, August 25, 2006
>>
>
>What is wrong with FTO vs TO for FVALUEs? Why do you want
>to make TO smart enough to tell the difference between an
>integer and a floating point VALUE ? If you're going to do
>that why not make VALUE smart enough to tell the difference?
TO is by definition overloaded. It is statesmart (most of the
implementations) and is used by LOCAL 's and VALUE 's already.
I think of it as a message that is accepted by different kind
of objects. mhx also likes extensions as +TO 0TO.
I don't like this too much, but if you are consequent you would
arrive at
TO [TO] LTO [LTO] DTO [DTO] FTO [FTO]
+TO [+TO] L+TO [L+TO] D+TO [D+TO] F+TO [F+TO]
0+TO [0+TO] L0+TO [L0+TO] D0+TO [D0+TO] F0+TO [F0+TO]
which is even more horrific.
^^^^^^^^ 1)
>
>--
>Julian V. Noble
>Professor Emeritus of Physics
>University of Virginia
1) My spelling checker doesn't know this word.
I hope you know what I mean.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
>"George Hubert" <george...@yahoo.co.uk> writes Re: RfD - FVALUE
>[..]
>> Operators use D (or both D and UD where separate signed and unsigned
>> versions are needed) to indicate specifically double numbers, whereas
>> 2@ 2! etc work equally well with pairs of single numbers and doubles.
>
>No,
Yes.
>2@ and 2! specify a stack picture that is incompatible with hardware
>details of some CPUs (and thus OSs).
Nonsense. You can implement 2@ and 2! on any hardware.
I think you mean this: the standard specifies the order of the cells
of a double number in a way that may be suboptimal on some
architectures for a given stack growth direction; this happens in
3.1.4.1, i.e. independent of 2@ and 2!.
If you choose to let your stack grow upwards, 2! and 2@ store the two
stack items in a different order on the stack and in memory. But
that's rarely a reason for a slowdown because single-cell only hardware
or alignment problems require dividing the memory accesses anyway.
And if there is a slowdown in these words, it does not matter much,
because they are not very frequent.
Peter Fälth
Marcel Hendrix wrote:
> RfD - FVALUE
> Marcel Hendrix, August 25, 2006
>
> * First draft *
>
> : FVALUE CREATE F, ( F: r -- ) DOES> F@ ; ( F: -- r )
>
> : TO ( F: r -- ) ( "<spaces>name" -- )
> ' >BODY
> STATE @ IF POSTPONE LITERAL POSTPONE F!
> ELSE F!
> THEN ; IMMEDIATE
>
This is a definition of FTO not of TO it will fail if applied to VALUES
or LOCALS.
The Test Cases below can not have been run with it.
regards
peter
Marcel Hendrix
> Marcel Hendrix wrote:
>> RfD - FVALUE
[..]
>> : FVALUE CREATE F, ( F: r -- ) DOES> F@ ; ( F: -- r )
[..]
> This is a definition of FTO not of TO it will fail if applied to VALUES
> or LOCALS.
> The Test Cases below can not have been run with it.
True, that was explained in the part that you snipped:
| The implementation of FVALUE requires carnal knowledge of the host
| implementation, which is the main reason why it should be standardized.
| The implementation below disregards the issue that TO should also
| work for integer VALUEs and locals.
I don't see the need for a reference implementation. (ANS94 does not
show one for VALUE.)
The testcases were run on two of the mentioned systems.
-marcel