RfD: N>R and NR> (v2)
Peter Knaggs
================
2010-03-16 PJK Revised after clf discussion
Added rational for N>R and test cases.
2009-02-04 SFP Original RfD
Rationale
=========
Problem
-------
Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
number of stack items. Interfacing with a host operating system
frequently requires a large number of stack items. To prevent
interference with other items, these items are then saved on the
return stack. Saving several items to the return stack is tedious,
especially where the number of items is unknown at compile time.
Current practise
----------------
At least SwiftForth, VFX Forth, spForth, and some versions of
Win32Forth provide the words N>R and NR> with the following
or similar specification.
N>R \ xn..x1 +n -- ; R: -- x1 .. xn +n
Transfer N items and count to the return stack.
NR> \ -- xn..x1 +n ; R: x1 .. xn +n --
\ *G Pull n items and count off the return stack.
These words cannot be written without an intimate knowledge of the
underlying Forth.
Approach
--------
At least one system stores items on the return stack in the format
R: -- xn .. x1 n
Because coding of this word is dependent on a number of CPU and Forth
design issues, we do not propose to mandate the order of x1..xn on
the return stack, only to specify that n itself is on the top of the
return stack.
A consequence of this is that N>R and NR> are used in pairs. I have
not yet seen any code that relies on the order of items on the return
stack, but it could be useful. It should also be noted that by
defining the order, the ambiguous condition in the proposal can be
removed.
Proposal
========
15.6.2.aaaa N>R n-to-r TOOLS EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( i*x +n -- ) ( R: -- j*x +n )
Remove n+1 items from the data stack and store them for later
retrieval by NR>. The return stack may be used to store the data.
Until this data has been retrieved by NR>:
* this date will not be overwritten by a subsequent invocation of
N>R and
* a program may not access data placed on the return stack before
the invocation of N>R.
Rational:
An implementation may store the stack items in any manner. It may
store them on the return stack, in any order. A stack constrained
system may prefer to use a buffer to store the items, and place the
location of that buffer on the return stack.
15.6.2.bbbb NR> n-r-from TOOLS EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( -- i*x +n ) ( R: j*x +n -- )
Retrieve the items previously stored by an invocation of N>R. n is
the number of items placed on the data stack.
Ambiguous condition:
It is an ambiguous condition if NR> is used with data not stored by
N>R.
Reference Implementation
========================
This implementation depends on the return address being on the
return stack.
: N>R \ xn .. x1 N -- ; R: -- x1 .. xn n
\ *G Transfer N items and count to the return stack.
dup \ xn .. x1 N N --
begin
dup
while
rot r> swap >r >r \ xn .. N N -- ; R: .. x1 --
1- \ xn .. N 'N -- ; R: .. x1 --
repeat
drop \ N -- ; R: x1 .. xn --
r> swap >r >r
;
: NR> \ -- xn .. x1 N ; R: x1 .. xn N --
\ *G Pull N items and count off the return stack.
r> r> swap >r dup
begin
dup
while
r> r> swap >r -rot
1-
repeat
drop
;
Tests
=====
: TNR1 N>R SWAP NR> ;
T{ 1 2 10 20 30 3 TNR1 -> 2 1 10 20 30 3 }T
: TNR2 N>R N>R SWAP NR> NR> ;
T{ 1 2 10 20 30 3 40 50 2 TNR2 -> 2 1 10 20 30 3 40 50 2 }T
Author
======
Stephen Pelc <steph...@mpeforth.com>
MicroProcessor Engineering
133 Hill Lane, Southampton SO15 5AF, England.
Peter Knaggs <p...@bcs.org.uk>
Engineering, Mathematics and Physical Sciences,
University of Exeter, Exeter, Devon EX4 7QF, England.
Bruce McFarling
QUOTE:
Until this data has been retrieved by NR>:
* this date will not be overwritten by a subsequent invocation of
N>R and
* a program may not access data placed on the return stack before
the invocation of N>R
Typo: "this date will not be overwritten" = this data will not be
overwritten
Jerry Avins
Not "these data"?
Jerry
--
Discovery consists of seeing what everybody has seen, and thinking what
nobody has thought. .. Albert Szent-Gyorgi
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Coos Haak
<snip>
>
> Not "these data"?
>
> Jerry
singular plural superplural?
datum datums or data data's
museum museums or musea musea's
IMO, data is definitely plural.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Bruce McFarling
> > Typo: "this date will not be overwritten" = this data will not be
> > overwritten
> Not "these data"?
Certaintly. "this" vs "these" is quite definitely not the typo.
Jerry Avins
OK. Please forgive my uptight soul.
�����������������������������������������������������������������������
Bruce McFarling
> Bruce McFarling wrote:
> > On Mar 17, 3:19 pm, Jerry Avins <j...@ieee.org> wrote:
> >>> Typo: "this date will not be overwritten" = this data will not be
> >>> overwritten
> >> Not "these data"?
> > Certaintly. "this" vs "these" is quite definitely not the typo.
> OK. Please forgive my uptight soul.
Whether "th**(*)" data should be this collection of data or these
items of data ... I dunno. Whatever people are happy with.
Jerry Avins
> On Mar 17, 8:00 pm, Jerry Avins <j...@ieee.org> wrote:
>> Bruce McFarling wrote:
>>> On Mar 17, 3:19 pm, Jerry Avins <j...@ieee.org> wrote:
>>>>> Typo: "this date will not be overwritten" = this data will not be
>>>>> overwritten
>
>>>> Not "these data"?
>
>>> Certaintly. "this" vs "these" is quite definitely not the typo.
>
>> OK. Please forgive my uptight soul.
>
> Whether "th**(*)" data should be this collection of data or these
> items of data ... I dunno. Whatever people are happy with.
What will we do with "datum"?
Jerry
--
Discovery consists of seeing what everybody has seen, and thinking what
nobody has thought. .. Albert Szent-Gyorgi
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Coos Haak
> Bruce McFarling wrote:
>> On Mar 17, 8:00 pm, Jerry Avins <j...@ieee.org> wrote:
>>> Bruce McFarling wrote:
>>>> On Mar 17, 3:19 pm, Jerry Avins <j...@ieee.org> wrote:
>>>>>> Typo: "this date will not be overwritten" = this data will not be
>>>>>> overwritten
>>
>>>>> Not "these data"?
>>
>>>> Certaintly. "this" vs "these" is quite definitely not the typo.
>>
>>> OK. Please forgive my uptight soul.
>>
>> Whether "th**(*)" data should be this collection of data or these
>> items of data ... I dunno. Whatever people are happy with.
>
> What will we do with "datum"?
>
I's like the weird feeling I had when I listened tot the BBC saying
'the police have'. In Dutch 'politie' is singular.
Andrew Haley
> Op Thu, 18 Mar 2010 04:12:51 -0400 schreef Jerry Avins:
>
>> Bruce McFarling wrote:
>>> On Mar 17, 8:00 pm, Jerry Avins <j...@ieee.org> wrote:
>>>> Bruce McFarling wrote:
>>>>> On Mar 17, 3:19 pm, Jerry Avins <j...@ieee.org> wrote:
>>>>>>> Typo: "this date will not be overwritten" = this data will not be
>>>>>>> overwritten
>>>
>>>>>> Not "these data"?
>>>
>>>>> Certaintly. "this" vs "these" is quite definitely not the typo.
>>>
>>>> OK. Please forgive my uptight soul.
>>>
>>> Whether "th**(*)" data should be this collection of data or these
>>> items of data ... I dunno. Whatever people are happy with.
>>
>> What will we do with "datum"?
>>
> I's like the weird feeling I had when I listened tot the BBC saying
> 'the police have'. In Dutch 'politie' is singular.
ISO standards tend to be quite formal. However, ISO C++ treats "data"
as singular ("the maintained data is presented") whereas ISO C treats
it as plural ("the mechanism by which input data are transformed") !
:-)
Andrew.
Bruce McFarling
> What will we do with "datum"?
A single bit? I'm with Anton on that one, I don't think there are any
bit-addressed Forths to worry about.
Bruce McFarling
wrote:
> ISO standards tend to be quite formal. However, ISO C++ treats "data"
> as singular ("the maintained data is presented") whereas ISO C treats
> it as plural ("the mechanism by which input data are transformed") !
There may be an American English usage versus Commonwealth English
usage thing creeping in there ... since I spent a decade in an Ozzie
department where a lot of my colleagues published in American
journals, I have no faith in my ear on those kinds of things.
Peter Knaggs
wrote:
According to my OED datum is "a piece of information" while data
represents "facts and statistics collected together for reference or
analysis". However, it also includes the following note on usage:
In Latin, data is the plural of datum and, historically and in
specialized scientific fields, it is also treated as a plural in
English, taking a plural verb, as in the data were collected and
classified. In modern non-scientific use, however, despite the
complaints of traditionalists, it is often not treated as a plural.
Instead, it is treated as a mass noun, similar to a word like
information, which cannot normally have a plural and which takes a
singular verb. Sentences such as data was (as well as data were)
collected over a number of years are now widely accepted in standard
English.
I put to you that the original intention "this date will not be
overwritten by a subsequent invocation of N>R" is valid. The whole
point of the word is for processing multiple stack items otherwise
people would use >r .
--
Peter Knaggs
Peter Knaggs
>
> I put to you that the original intention "this date will not be
> overwritten by a subsequent invocation of N>R" is valid. The whole
> point of the word is for processing multiple stack items otherwise
> people would use >r .
Obviously I meant "this data will not be overwritten by a subsequent
invocation of N>R". That what you get for copy and paste.
--
Peter Knaggs
Bruce McFarling
> I put to you that the original intention "this date will not be
> overwritten by a subsequent invocation of N>R" is valid. The whole
> point of the word is for processing multiple stack items otherwise
> people would use >r .
My only claim was that "date" was a type.
Jerry Avins raised the question of the number of the noun. As the
quote clarifies, in some specialized scientific fields, the usage is,
essentially, "these data" signifying "these data points", while the
more common usage, and the normal usage in statistics in the social
sciences in the US, is "this data", signifying this collection of data
(and sometimes really meaning "this data file").
For the application, since the point is to pick up the collection of
stack entries as a group and stash it away somewhere, there doesn't
seem to be anything wrong with the collective singular, as with "this
information".
Andrew Haley
> On Mar 18, 10:35?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> ISO standards tend to be quite formal. However, ISO C++ treats "data"
>> as singular ("the maintained data is presented") whereas ISO C treats
>> it as plural ("the mechanism by which input data are transformed") !
>
> There may be an American English usage versus Commonwealth English
> usage thing creeping in there
I don't think it's that. The convention regarding the plurality of
"data" is changing, and the difference in time between the C and C++
standards is probably the most important factor.
American academic editors tend to be rather more formal about their
writing style than British ones. However, American non-academic
editors tend to be rather less formal than their British counterparts.
As with many things, there seem to be more extreme variations
Stateside.
> ... since I spent a decade in an Ozzie department where a lot of my
> colleagues published in American journals, I have no faith in my ear
> on those kinds of things.
Indeed. My wife edits textbooks and academic papers, and she has a
different set of rules for each customer. These days everyone wants a
"transatlantic" style, but they don't quite agree what that means!
Andrew.
Jerry Avins
> Op Thu, 18 Mar 2010 04:12:51 -0400 schreef Jerry Avins:
>
>> Bruce McFarling wrote:
>>> On Mar 17, 8:00 pm, Jerry Avins <j...@ieee.org> wrote:
>>>> Bruce McFarling wrote:
>>>>> On Mar 17, 3:19 pm, Jerry Avins <j...@ieee.org> wrote:
>>>>>>> Typo: "this date will not be overwritten" = this data will not be
>>>>>>> overwritten
>>>>>> Not "these data"?
>>>>> Certaintly. "this" vs "these" is quite definitely not the typo.
>>>> OK. Please forgive my uptight soul.
>>> Whether "th**(*)" data should be this collection of data or these
>>> items of data ... I dunno. Whatever people are happy with.
>> What will we do with "datum"?
>>
> I's like the weird feeling I had when I listened tot the BBC saying
> 'the police have'. In Dutch 'politie' is singular.
Here in the US, we say "the company is ...." In Britain, they say "the
company are ...." They consider "company" to be a collective noun.
�����������������������������������������������������������������������