RfD - N>R and NR>
Stephen Pelc
4 February 2009, Stephen Pelc
Rationale
=========
Problem
-------
Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
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 practice
----------------
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 carnal 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
========
6.2.aaaa N>R
n-to-r CORE EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( x1..xn +n -- ) ( R: -- xn..x1 +n )
Move n+1 items to the return to the return stack such that n is the
top item on the return stack. The order of the items x1..xn on the
return stack is implementation defined.
6.2.bbbb NR>
n-r-from CORE EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( -- xn..x1 n ) ( R: x1..xn n -- )
Move n+1 items from the return stack to the data stack, leaving n on
the
top of the data stack. The order of the items x1..xn on the
return stack is implementation defined.
Ambiguous condition
NR> is used with data not placed on the return stack 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
=====
TBD
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Helmar
> RfD: N>R and NR>
I think it's nice. The 4p implementation (-A switch) is:
-------------------
: n>r [ -OPT ] dup begin ?dup while
rot >rr 1-
repeat >rr ;
: nr> [ -OPT ] rr> dup
: (nr>) ?dup and: rr> -rot 1- recurse ;
-------------------
Regards,
-Helmar
Bernd Paysan
> 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 carnal knowledge of the
> underlying Forth.
Ah, simply make them immediate and let them postpone the loops ;-).
Otherwise I support this proposal, though I must say that I don't like
juggling with a variable number of stack items. In my Audio GUI, I've
created two words to deal with them more easily: [[ and ]]. You can do
something like
[[ get-order ]] ( -- addr )
which packs the complete stack spillout of whatever is between the two
delimiters into memory, returning just one address. This hasn't been well
factored yet (there is only one buffer for it), but that idea could be
improved.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marcel Hendrix
> Problem
> -------
> Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
> 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.
Is this a problem that mandates endless debates and two new
words? What's the frequency of occurance of these N>R NR>
factors?
GET-ORDER and SAVE-INPUT are ANS already, so don't count as examples.
I can find many examples where a large number of items is put on
the return stack ( N>R would help ) but where NR> is not used.
Flabbergasted,
-marcel
Helmar
> Stephen Pelc wrote:
> > 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 carnal knowledge of the
> > underlying Forth.
>
> Ah, simply make them immediate and let them postpone the loops ;-).
>
> Otherwise I support this proposal, though I must say that I don't like
> juggling with a variable number of stack items. In my Audio GUI, I've
> created two words to deal with them more easily: [[ and ]]. You can do
> something like
>
> [[ get-order ]] ( -- addr )
>
> which packs the complete stack spillout of whatever is between the two
> delimiters into memory, returning just one address. This hasn't been well
> factored yet (there is only one buffer for it), but that idea could be
> improved.
What's the word to restore the thing on stack? You need a third word.
Regards,
-Helmar
Andrew Haley
> > Problem
> > -------
> > Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
> > 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.
> Is this a problem that mandates endless debates and two new
> words? What's the frequency of occurance of these N>R NR>
> factors?
> GET-ORDER and SAVE-INPUT are ANS already, so don't count as examples.
Why not? Surely
SAVE-INPUT N>R
... stuff ...
NR> RESTORE-INPUT
is an obvious use for these, isn't it?
Andrew.
Coos Haak
I have had this construct for years in INCLUDE-FILE LOAD and EVALUATE ;-)
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Jonah Thomas
> 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 carnal knowledge of the
> underlying Forth.
: N>R
DUP BEGIN
DUP 0 - WHILE
>R 1-
REPEAT
>R
;
This would work if you were using a dummy return stack, that the system
didn't use for anything else. But in general it doesn't work. So:
: N>R
]] DUP BEGIN
DUP 0 - WHILE
ROT >R 1-
REPEAT
DROP >R [[
; IMMEDIATE
: R>N
]] R> DUP BEGIN
DUP 0 - WHILE
R> -ROT 1-
REPEAT
DROP [[
; IMMEDIATE
I believe this ought to work anywhere. But it isn't good. A 13-word
macro (bigger if 0 is a literal) every time you use either one.
Still it could provide a quick patch for a system that doesn't yet have
N>R and R>N .
]] parses the input and postponse everything, providing literals for
numbers. It quits when it finds [[ . You could get about the same result
by potting POSTPONE in front of every word between ]] and [[ . It would
look worse then. The 0 might need to become 0 POSTPONE LITERAL .
Coos Haak
> steph...@mpeforth.com (Stephen Pelc) wrote:
>
>> 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 carnal knowledge of the
>> underlying Forth.
>
>: N>R
> DUP BEGIN
> DUP 0 - WHILE
Why the '0 -' construct? You might do '0<>' but I would skip it ;-)
Andrew Haley
> > 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 carnal knowledge of the
> > underlying Forth.
> : N>R
> DUP BEGIN
> DUP 0 - WHILE
> >R 1-
> REPEAT
> >R
> ;
> This would work if you were using a dummy return stack, that the system
> didn't use for anything else. But in general it doesn't work. So:
> : N>R
> ]] DUP BEGIN
> DUP 0 - WHILE
> ROT >R 1-
> REPEAT
> DROP >R [[
> ; IMMEDIATE
Surely it's just
]] begin ?dup while swap >r 1- repeat [[
Andrew.
Bernd Paysan
>> [[ get-order ]] ( -- addr )
>>
>> which packs the complete stack spillout of whatever is between the two
>> delimiters into memory, returning just one address. This hasn't been well
>> factored yet (there is only one buffer for it), but that idea could be
>> improved.
>
> What's the word to restore the thing on stack? You need a third word.
Yes, the word is @s (could also be "unpack" if something more readable is
necessary). I've several *s words which all do the same as the non-s words
but with these packed arrays. MAP is not a good solution, because these *s
words make use of the knowledge that this is a regular structure.
Jonah Thomas
> Jonah Thomas <jeth...@gmail.com> wrote:
> > : N>R \ xn..x1 +n -- ; R: -- x1 .. xn +n
> > ]] DUP BEGIN
> > DUP 0 - WHILE
> > ROT >R 1-
> > REPEAT
> > DROP >R [[
> > ; IMMEDIATE
>
> Surely it's just
>
> ]] begin ?dup while swap >r 1- repeat [[
The complications come because we need to save the count at the top of
the return stack.
Jonah Thomas
> schreef Jonah Thomas:
> >: N>R
> > DUP BEGIN
> > DUP 0 - WHILE
> Why the '0 -' construct? You might do '0<>' but I would skip it ;-)
You're right. I simply missed that for no obvious reason.
Marcel Hendrix
> Marcel Hendrix <m...@iae.nl> wrote:
>> steph...@mpeforth.com (Stephen Pelc) Re: RfD - N>R and NR>
>> > Problem
>> > -------
>> > Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
>> > number of stack items.
[..]
>> GET-ORDER and SAVE-INPUT are ANS already, so don't count as examples.
> Why not?
[..]
Sorry, I overlooked the crucial "variable number of". I can't find
a variable number of args in my sources, nor a reason why that should
be portable, but I have a sudden insight where this is going :-)
Splendid idea!
-marcel
Alex McDonald
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads
Seconded (if that's the right thing to do). Later versions of
Win32Forth have both N>R and NR> as you note, and although
infrequently used, very useful.
--
Regards
Alex McDonald
Andrew Haley
Oh duh, I didn't read the rfd properly. Sorry.
Andrew.
Bee
> RfD: N>R and NR>
> 4 February 2009, Stephen Pelc
>
> Rationale
> =========
>
> Problem
> -------
> Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
> 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.
Search order can be modified without the need for the words N>R and
NR>. Please note: I am not saying anything about the usefulness of N>R
and NR>.
The following work with Swiftforth and gforth.
: _-ORDER ( w wid*n n -- wid*n w n ) ( internal word )
DUP IF 1- SWAP >R ( >>> ) RECURSE ( <<< ) ( wid*n w n )
OVER R@ XOR IF 1+ R> -ROT ( >>> ) EXIT ( <<< )
THEN R> DROP THEN ;
I would like propose these words as reserved:
: -ORDER ( wid -- ) ( remove wid from search order )
GET-ORDER _-ORDER NIP SET-ORDER ;
: +ORDER ( wid -- ) ( add wid to search order, only one instance )
DUP >R -ORDER GET-ORDER R> SWAP 1+ SET-ORDER ;
--
Bill Muench
Santa Cruz, California
Helmar
I guess you missed the point. The +ORDER -ORDER things are worth an
own RfD imho and they should be in a standard.
The point here is to preserve such an arbitrary state as the search
order on stack and for needs of application move that runtime-known
number of items to the return stack and move it back later. That is
just for convenience - you do not always know (bad design btw.), how
many items should be preserved before something like GET-ORDER - eg:
: FOO ... >R >R GET-ORDER R> R> ... SET-ORDER ... ;
So I guess the words are very useful - beside other possibilities to
set the search order.
Regards,
-Helmar
Stephen Pelc
wrote:
>The point here is to preserve such an arbitrary state as the search
>order on stack and for needs of application move that runtime-known
>number of items to the return stack and move it back later. That is
>just for convenience - you do not always know (bad design btw.),
For words like SAVE-INPUT, you know the number of items on *your*
system, but you don't know on how many on other systems. N>R
eases portability in these cases.
On some systems, SAVE-INPUT is entitled to vary the number of
items according to the conditions, e.g. terminal or file. N>R
and NR> cope with this situation.
Stephen
Bernd Paysan
> For words like SAVE-INPUT, you know the number of items on *your*
> system, but you don't know on how many on other systems. N>R
> eases portability in these cases.
Indeed. However, last time we redesigned the source input system of Gforth,
we just went the route to have an object oriented input buffer, which
contains all necessary variables plus the buffer space, so it ends up as a
single pointer, whatever the current input is. This takes the insanity of
variable length stack effects out of the equation.
Jonah Thomas
> However, last time we redesigned the source input system of Gforth,
> we just went the route to have an object oriented input buffer, which
> contains all necessary variables plus the buffer space, so it ends up
> as a single pointer, whatever the current input is. This takes the
> insanity of variable length stack effects out of the equation.
So for source inputs it makes sense to keep the data in data structures.
You don't have a large number of input specifications and they're
reasonably stable. Not like you were dealing with many thousands of
types with variable length data, that were created and destroyed
quickly. Even in that case you could put them in allocated memory and
remember to free the memory at the correct times.
Are there times when it makes sense to use the ( xn ... x1 n -- )
( -- xn ... x1 n ) form?
If so you might sometimes want to move things onto the return stack and
sometimes elsewhere. It might be good to arrange that flexibly.
Would it be easier to have the length at both ends? ( n xn ... x1 n -- )
I just recently saw a Forth word that started with ( xn ... x1 n ) and
it bubbled the n through a whole stack so the n would be available at
the end. It could have been saved in a variable or a local ... but if
it's already sitting at both ends then everything turns simple while you
move it around on stacks. Like a railroad train with engines facing
opposite directions at either end.
You'd have to drop it when the data was consumed, but it's easier to
DROP something you don't need than to juggle something you do.
: N->R' ( n xn ... x1 n -- ) ( R: -- n x1 ... xn n )
]] DUP 1+ 1+ BEGIN ?DUP WHILE SWAP >R 1- REPEAT [[ ; IMMEDIATE
: R->N' ( -- n x1 ... xn n ) ( R: n xn ... x1 n -- )
]] R@ 1+ 1+ BEGIN ?DUP WHILE R> SWAP 1- REPEAT [[ ; IMMEDIATE
It's half-baked. I haven't used variable-length stack trains enough to
guess whether the simplicity you get this way is worth the complexity of
removing the extra item when you no longer want it.
And it's no help for the guy who writes it in C or assembly, who can
just move the return stack pointer by n+1 cells, move the nest-sys to
its new spot, move the n just under the nest-sys, move the data just
under that, and reset the data stack pointer to delete the data there.
m_l_g3
> On Feb 4, 5:05 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> > RfD: N>R and NR>
> > 4 February 2009, Stephen Pelc
>
> > Rationale
> > =========
>
> > Problem
> > -------
> > Several ANS words, e.g. GET-ORDER and SAVE-INPUT, return a variable
> > 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 practice
> > ----------------
> > 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 carnal knowledge of the
> > underlying Forth.
>
> > Stephen Pelc, stephen...@mpeforth.com
>
> Seconded (if that's the right thing to do). Later versions of
> Win32Forth have both N>R and NR> as you note, and although
> infrequently used, very useful.
>
> --
> Regards
> Alex McDonald
Me too.
This word is very useful if you write a compiler or some compiler
extension(s).
In application code these words are not needed provided that the
programmer
avoids the use of ( xn .. x1 n ) arrays on the stack.
I would also prefer to have NDROP in addition to these words,
but that's definitely a different proposal.
I never used N>R like ( x y z ) 3 N>R R> DROP or 3 >R NR> DROP ( x y
z ).
Michael L Gassanenko
m_l_g3
> On Thu, 5 Feb 2009 09:04:00 -0800 (PST), Helmar <hel...@gmail.com>
> wrote:
>
> >The point here is to preserve such an arbitrary state as the search
> >order on stack and for needs of application move that runtime-known
> >number of items to the return stack and move it back later. That is
> >just for convenience - you do not always know (bad design btw.),
>
> For words like SAVE-INPUT, you know the number of items on *your*
> system, but you don't know on how many on other systems. N>R
> eases portability in these cases.
>
That number of items is known only up to the moment that someone
decides to *change* the number of items. At that moment everybody
involved will find out that N>R and NR> either _are_ or _would_be_
very useful.
Jonah Thomas
> stephen...@mpeforth.com (Stephen Pelc) wrote:
> > Helmar <hel...@gmail.com> wrote:
> >
> > >The point here is to preserve such an arbitrary state as the search
> > >order on stack and for needs of application move that runtime-known
> > >number of items to the return stack and move it back later. That is
> > >just for convenience - you do not always know (bad design btw.),
> >
> > For words like SAVE-INPUT, you know the number of items on *your*
> > system, but you don't know on how many on other systems. N>R
> > eases portability in these cases.
>
> That number of items is known only up to the moment that someone
> decides to *change* the number of items. At that moment everybody
> involved will find out that N>R and NR> either _are_ or _would_be_
> very useful.
The return stack is good because you can do re-entrant code etc, and
whatever else you do, when you get back to the code that did N>R the
data will be waiting on the return stack for NR> . But on some systems
the return stack is shallow, and sometimes you might want to access that
data from other code.
How about a word to move the top n datastack items to a location in
memory in reverse order?
Would that be useful too?
If you could do that simply, you could move to an existing buffer, or
create a new buffer on the spot with ALLOT or ALLOCATE .
Maybe call the words N! and N@? Or are those taken in common use, I
don't remember....
You could define them in high-level Forth but they'd be much more
elegant under-the-hood.
N@ ( addr -- xn ... x1 n )
N! ( xn ... x1 addr n -- )
Under-the-hood, you might do something like
: N@ ( addr -- xn ... x1 )
DUP @ CELLS DUP >R
SP -ROT MOVE
R> SP +! ;
: N! ( xn ... x1 addr n -- )
TUCK 1+ CELLS SP OVER +
SP SWAP MOVE ;
\ does SP point to the lowest in-use cell of the data stack?
But you'd want to do it in CODE or a different atomic task or something
so you wouldn't clobber the data stack while you were changing it. If
your system lets MOVE move data faster than a do loop with repeated @ or
! then this approach should be better.
> > On some systems, SAVE-INPUT is entitled to vary the number of
> > items according to the conditions, e.g. terminal or file. N>R
> > and NR> cope with this situation.
A lot of times it might be simpler to just save space for the maximum
size plus the count. You lose a little space but you save complexity.
But if you sometimes have a *whole lot* of items then it costs too much.
Coos Haak
<snip>
> This word is very useful if you write a compiler or some compiler
> extension(s).
> In application code these words are not needed provided that the
> programmer
> avoids the use of ( xn .. x1 n ) arrays on the stack.
>
> I would also prefer to have NDROP in addition to these words,
> but that's definitely a different proposal.
>
> I never used N>R like ( x y z ) 3 N>R R> DROP or 3 >R NR> DROP ( x y
> z ).
>
As a matter of fact, the names N>R and NR> I use for them,
I saw first in a posting from you in c.l.f. in about 1998 ;-)
Before that I used weird names like PUSH-DATA and POP-DATA.
The Beez'
Just for the record, I have no objection whatsoever concerning with
this RfD. If it is chosen to be adopted, I will provide the reference
implementation as an include file.
Hans Bezemer
rickman
>
> These words cannot be written without carnal knowledge of the
> underlying Forth.
I'm pretty far from a prude, but is this really an appropriate use of
the above term? I thought maybe it had a definition other than
sexual, but I can't find one. Did I not look far enough?
I do believe I understand what you meant, but I think I would have
found another term myself.
Rick
PS This reminds me of a female technician who objected to the use of
the terms "male" and "female" for connectors. I guess I can
understand that one though. Those terms actually derive from the
images of... well you know... 8^o Good thing she didn't have to
work with plumbing where they have "nipples" on pipes.
Elizabeth D Rather
> On Feb 4, 12:05 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
>> These words cannot be written without carnal knowledge of the
>> underlying Forth.
>
> I'm pretty far from a prude, but is this really an appropriate use of
> the above term? I thought maybe it had a definition other than
> sexual, but I can't find one. Did I not look far enough?
>
> I do believe I understand what you meant, but I think I would have
> found another term myself.
>
> Rick
AFAIK the term (as far as Forth relevance is concerned) developed during
discussions in the Forth94 process. We needed a term to designate
functions that couldn't be implemented without knowledge of and
dependence on implementation details such as dictionary structure, head
geography, etc. Someone started saying "kernel knowledge", and since
the movie "Carnal Knowledge" had recently been popular it was an obvious
pun which stuck. I don't know if it's used in any other
computer-related context.
I'm sorry if it offends you, and hope this explanation helps.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Coos Haak
<snip>
> Maybe call the words N! and N@? Or are those taken in common use, I
> don't remember....
>
> You could define them in high-level Forth but they'd be much more
> elegant under-the-hood.
>
> N@ ( addr -- xn ... x1 n )
> N! ( xn ... x1 addr n -- )
Why not ( xn .. x1 n addr -- ) to make it analogous to ! and 2!
that have addr on top of the stack.
rickman
> rickman wrote:
> > On Feb 4, 12:05 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> >> These words cannot be written without carnal knowledge of the
> >> underlying Forth.
>
> > I'm pretty far from a prude, but is this really an appropriate use of
> > the above term? I thought maybe it had a definition other than
> > sexual, but I can't find one. Did I not look far enough?
>
> > I do believe I understand what you meant, but I think I would have
> > found another term myself.
>
> > Rick
>
> AFAIK the term (as far as Forth relevance is concerned) developed during
> discussions in the Forth94 process. We needed a term to designate
> functions that couldn't be implemented without knowledge of and
> dependence on implementation details such as dictionary structure, head
> geography, etc. Someone started saying "kernel knowledge", and since
> the movie "Carnal Knowledge" had recently been popular it was an obvious
> pun which stuck. I don't know if it's used in any other
> computer-related context.
>
> I'm sorry if it offends you, and hope this explanation helps.
I's not that it offends me... I am not offended easily at all. But I
work and live by the mores of the community. I am sure that 99% of
the people I know would not blink an eye about this. But in case that
1% includes a customer, I can't take a chance of offending. This is a
term I will be avoiding.
It reminds me of a job I had where we were teamed with General
Dynamics. They even referred to themselves as GD. But you *had* to
keep a straight face when you said that, although there were plenty of
times when people wanted to use the term differently.
Rick
Alex McDonald
>
> - Show quoted text -
GD?
I know it helps not to be offensive where possible, but honestly; this
is taking things too far. GD? What's wrong with that?
"He cocked his weapon and shot at the tits at the bottom of the black
bush". There; pick the rude ones out of that. Six? Possible 7 if using
"he" might be considered sexist? 8 with a racist reference?
Language has a context, and anyone who objects to language that might
have the slightest sexist, racist or other-ist overtones *in some
other context* has more on their minds than just the job in hand. O
bother, there I go again...
--
Regards
Alex McDonald
rickman
Exactly, context is what it is all about. That is why it was
important to not let any other context show when saying GD, TO GD.
That was the problem. We used GD in totally different context when
they weren't there to hear it.
That reminds me of the Chevy Chase Family Vacation movie where they
visited Hoover Dam and got the tour of the Dam gift shop and the Dam
this and the Dam that...
My original point is that unless you are in bed with the Forth
community, you could easily not understand the context of "carnal
knowledge", especially since there is no formal meaning other than the
sexual one, (pun intended). I just think this is a poor choice of
term. I have any number of contacts with whom I would not use that
term. You never know about Colonels and Generals. They can dislike
one thing you say and you are off the project without ever knowing
why.
Rick
Jerry Avins
Someone not accustomed to "carnal knowledge" in its Forth use would
likely need to have it explained anyway, so it's best avoided with your
clients anyway. "Deeply intimate knowledge if the internals"?
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
rickman
That's a good rationalization. "If you need to ask, you shouldn't
know anyway."
Rick
Alex McDonald
I still don't get this GD thing. Can you explain it for me (without
upsetting the regulars here, of course).
--
Regards in mystification
Alex McDonald