Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #12393 > unrolled thread

Use of VARIABLEs frequent or infrequent? And, C style operators.

Started by"Rod Pemberton" <do_not_have@notemailntt.cmm>
First post2012-05-22 16:01 -0400
Last post2012-05-27 11:13 -0700
Articles 20 on this page of 43 — 18 participants

Back to article view | Back to comp.lang.forth


Contents

  Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-22 16:01 -0400
    Re: Use of VARIABLEs frequent or infrequent? And, C style operators. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-22 14:58 -0700
    Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Ed" <invalid@nospam.com> - 2012-05-23 13:19 +1000
      Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-22 23:44 -0700
        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Nomen Nescio <nobody@dizum.com> - 2012-05-23 12:30 +0200
          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-23 08:37 -0700
            Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-23 23:32 -0700
              Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-24 13:24 +0000
                Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-24 09:40 -0700
                  Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-24 20:52 +0000
                    Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-24 14:17 -0700
                      Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-25 08:10 +0000
                        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-25 01:50 -0700
                          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Fritz Wuehler <fritz@spamexpire-201205.rodent.frell.theremailer.net> - 2012-05-25 22:39 +0200
                          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Paul Rubin <no.email@nospam.invalid> - 2012-05-26 22:02 -0700
                        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Nomen Nescio <nobody@dizum.com> - 2012-05-25 14:33 +0200
                          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-25 16:50 +0000
                            Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-25 20:30 +0000
                              Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. hwfwguy@gmail.com - 2012-05-30 11:23 -0700
                          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Peter Knaggs" <pjk@bcs.org.uk> - 2012-05-29 20:00 +0100
        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-24 07:39 -0400
          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-24 15:37 +0000
    Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-22 21:18 -1000
      Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-24 18:27 -1000
        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-25 03:55 -0400
          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-25 07:38 -1000
            Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-25 15:17 -0400
              Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-25 10:05 -1000
                Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-26 08:02 -0400
                  Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Coos Haak <chforth@hccnet.nl> - 2012-05-26 14:31 +0200
                  Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Doug Hoffman <glidedog@gmail.com> - 2012-05-26 09:55 -0400
                  Re: Use of VARIABLEs frequent or infrequent? And, C style operators. BruceMcF <agila61@netscape.net> - 2012-05-26 07:04 -0700
                  Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-26 09:41 -1000
                    Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-26 19:52 -0400
                      Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-26 19:49 -1000
                        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Ed" <invalid@nospam.com> - 2012-06-01 13:39 +1000
                          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-31 19:27 -1000
                        Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-01 18:24 -0400
                          Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-02 03:09 -0500
                      Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-27 02:23 -0500
                    Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Harry Vaderchi" <admin@127.0.0.1> - 2012-05-27 11:54 +0100
                      Re: Use of VARIABLEs frequent or infrequent?  And, C style operators. "Elizabeth D. Rather" <erather@forth.com> - 2012-05-27 07:25 -1000
                      Re: Use of VARIABLEs frequent or infrequent? And, C style operators. Alex McDonald <blog@rivadpm.com> - 2012-05-27 11:13 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →


#12418

From"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date2012-05-24 07:39 -0400
Message-ID<jpl6jb$bdl$1@speranza.aioe.org>
In reply to#12400
"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:7xtxz7qtuk.fsf@ruckus.brouhaha.com...
> "Ed" <invalid@nospam.com> writes:
> > IIRC there is or was a C-to-Forth translator available somewhere.  I
> > would imagine however most do it manually.  Having forth locals
> > can be handy for the preliminary stages after which they can be weeded
> > out.
>
> You might be thinking of Philip Koopman's GCC back end that produces
> Forth (see his book "Stack Machines").
>

More likely, he's thinking of Rob Chapman's Timbre "C-to-Forth" translation,
since it's been mentioned here quite a few times now...


Rod Pemberton


[toc] | [prev] | [next] | [standalone]


#12420

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2012-05-24 15:37 +0000
Message-ID<2012May24.173713@mips.complang.tuwien.ac.at>
In reply to#12418
"Rod Pemberton" <do_not_have@notemailntt.cmm> writes:
>More likely, he's thinking of Rob Chapman's Timbre "C-to-Forth" translation,
>since it's been mentioned here quite a few times now...

Timbre is a Forth-to-C thing.

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]


#12401

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-22 21:18 -1000
Message-ID<if-dnfnhuZ63EiHSnZ2dnUVZ_hmdnZ2d@supernews.com>
In reply to#12393
On 5/22/12 10:01 AM, Rod Pemberton wrote:
> Is the use of VARIABLEs frequent or infrequent in Forth?
>
> It just seems like if they were used much at all, that there would be some
> words that made using them a bit easier.  But, Forth seems to be devoid of
> most words that I'd guess would be available to use on VARIABLEs.  IMO, C's
> assignment operators would help.  Other than the ancient fig-Forth TOGGLE
> and SMUDGE, ISTM, that only +! (plus-store) is available.
>
> Perhaps, something like so, in Forth syntax, with C name as a comment:
>
> : AND! ( x addr -- ) DUP>R @ AND R>  ! ; \  C's&=
> : OR! ( x addr -- ) DUP>R @ OR R>  ! ; \  C's |=
> : XOR! ( x addr -- ) DUP>R @ XOR R>  ! ; \  C's ^=
>
> : +! ( x addr -- ) DUP>R @ + R>  ! ; \  C's +=
> : -! ( x addr -- ) DUP>R @ - R>  ! ; \  C's -=
> : *! ( x addr -- ) DUP>R @ * R>  ! ; \  C's *=
>
> : /! ( x addr -- ) SWAP OVER @ SWAP / SWAP ! ; \  C's /=
> : MOD! ( x addr -- ) SWAP OVER @ SWAP MOD SWAP ! \  C's %=
> : LSHIFT! ( x addr -- ) SWAP OVER @ SWAP LSHIFT SWAP ! ; \  C's<<=
> : RSHIFT! ( x addr -- ) SWAP OVER @ SWAP RSHIFT SWAP ! ; \  C's>>=
>
> I'd assume the "DUP>R @<op>  R>  !" and "SWAP OVER @ SWAP<op>  SWAP !"
> sequences could be implemented as generic wrapper words that could be passed
> an XT or ' (ticked) word which then get EXECUTEd.
>
> Well, at a minimum, they might help someone converting C to Forth ...

There isn't a perceived need for these things because that isn't how one 
uses variables in Forth. You fetch a value, pass it through whatever 
operations are appropriate, use it for something, and maybe store the 
result somewhere else. You don't work with things in place.  TOGGLE is 
one of the few exceptions.

I don't think I've ever actually encountered the factoring you propose.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12438

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-24 18:27 -1000
Message-ID<9dOdnS-FfKqwlyLSnZ2dnUVZ_r-dnZ2d@supernews.com>
In reply to#12401
On 5/22/12 9:18 PM, Elizabeth D. Rather wrote:
> On 5/22/12 10:01 AM, Rod Pemberton wrote:
>> Is the use of VARIABLEs frequent or infrequent in Forth?
>>
>> It just seems like if they were used much at all, that there would be
>> some
>> words that made using them a bit easier. But, Forth seems to be devoid of
>> most words that I'd guess would be available to use on VARIABLEs. IMO,
>> C's
>> assignment operators would help. Other than the ancient fig-Forth TOGGLE
>> and SMUDGE, ISTM, that only +! (plus-store) is available.
>>
>> Perhaps, something like so, in Forth syntax, with C name as a comment:
>>
>> : AND! ( x addr -- ) DUP>R @ AND R> ! ; \ C's&=
>> : OR! ( x addr -- ) DUP>R @ OR R> ! ; \ C's |=
>> : XOR! ( x addr -- ) DUP>R @ XOR R> ! ; \ C's ^=
>>
>> : +! ( x addr -- ) DUP>R @ + R> ! ; \ C's +=
>> : -! ( x addr -- ) DUP>R @ - R> ! ; \ C's -=
>> : *! ( x addr -- ) DUP>R @ * R> ! ; \ C's *=
>>
>> : /! ( x addr -- ) SWAP OVER @ SWAP / SWAP ! ; \ C's /=
>> : MOD! ( x addr -- ) SWAP OVER @ SWAP MOD SWAP ! \ C's %=
>> : LSHIFT! ( x addr -- ) SWAP OVER @ SWAP LSHIFT SWAP ! ; \ C's<<=
>> : RSHIFT! ( x addr -- ) SWAP OVER @ SWAP RSHIFT SWAP ! ; \ C's>>=
>>
>> I'd assume the "DUP>R @<op> R> !" and "SWAP OVER @ SWAP<op> SWAP !"
>> sequences could be implemented as generic wrapper words that could be
>> passed
>> an XT or ' (ticked) word which then get EXECUTEd.
>>
>> Well, at a minimum, they might help someone converting C to Forth ...
>
> There isn't a perceived need for these things because that isn't how one
> uses variables in Forth. You fetch a value, pass it through whatever
> operations are appropriate, use it for something, and maybe store the
> result somewhere else. You don't work with things in place. TOGGLE is
> one of the few exceptions.
>
> I don't think I've ever actually encountered the factoring you propose.

Ok, +! is common, I missed that one.  Add-to-memory and increment-memory 
are pretty common, because they're such simple operations that they're 
usually implemented as code primitives, or easily optimized.

And I meant to comment on DUP>R. I really don't see the point of 
defining that. It's just two words, so in an ITC system the overhead of 
the extra definition (in both time for the extra call and size of the 
definition) is more than any possible saving, and in a system with an 
optimizer it's taken care of easily.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12444

From"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date2012-05-25 03:55 -0400
Message-ID<jpndsd$jhj$1@speranza.aioe.org>
In reply to#12438
"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:9dOdnS-FfKqwlyLSnZ2dnUVZ_r-dnZ2d@supernews.com...

> > [snip RP's C style words in Forth syntax ...]
>
> And I meant to comment on DUP>R. I really don't see the point of
> defining that. It's just two words, so in an ITC system the overhead of
> the extra definition (in both time for the extra call and size of the
> definition) is more than any possible saving, and in a system with an
> optimizer it's taken care of easily.

Um...

Firstly, in my original post, DUP>R was two words:

  DUP <space> >R

It seems you or your newsreader software removed a space (?) ...
(That's not important to me, but you might check.)

Secondly, the sequences I suggested defining are pre- and post-operation,
so DUP >R has a @ too:

 DUP >R @

That's what preceeds the + - * words in my examples.

But, yes, that sequence is not that significant spacewise.  It just seems
that Forth inserts words or operations directly into the middle of various
common sequences.  So, I'm wanting to create "wrappers" for everything at
this point, i.e., a word before and a word after.  Or, I'm wanting to create
a single word that inserts the difference, e.g., passed an XT and using
EXECUTE.  I've not tried that yet.  It shouldn't be too difficult.  I
wouldn't know if it was ANS compliant...  Although, perhaps more "generic,"
I can "see" that definition becoming a bit larger ...


Rod Pemberton


[toc] | [prev] | [next] | [standalone]


#12455

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-25 07:38 -1000
Message-ID<Wu-dnalYGvM9XiLSnZ2dnUVZ_radnZ2d@supernews.com>
In reply to#12444
On 5/24/12 9:55 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> news:9dOdnS-FfKqwlyLSnZ2dnUVZ_r-dnZ2d@supernews.com...
>
>>> [snip RP's C style words in Forth syntax ...]
>>
>> And I meant to comment on DUP>R. I really don't see the point of
>> defining that. It's just two words, so in an ITC system the overhead of
>> the extra definition (in both time for the extra call and size of the
>> definition) is more than any possible saving, and in a system with an
>> optimizer it's taken care of easily.
>
> Um...
>
> Firstly, in my original post, DUP>R was two words:
>
>    DUP<space>  >R
>
> It seems you or your newsreader software removed a space (?) ...
> (That's not important to me, but you might check.)

Dunno. I use Thunderbird, which has never been known to alter spacing.

> Secondly, the sequences I suggested defining are pre- and post-operation,
> so DUP>R has a @ too:
>
>   DUP>R @
>
> That's what preceeds the + - * words in my examples.
>
> But, yes, that sequence is not that significant spacewise.  It just seems
> that Forth inserts words or operations directly into the middle of various
> common sequences.

??? News to me! What version of Forth are you accusing of doing this?

> So, I'm wanting to create "wrappers" for everything at
> this point, i.e., a word before and a word after.  Or, I'm wanting to create
> a single word that inserts the difference, e.g., passed an XT and using
> EXECUTE.  I've not tried that yet.  It shouldn't be too difficult.  I
> wouldn't know if it was ANS compliant...  Although, perhaps more "generic,"
> I can "see" that definition becoming a bit larger ...

Why would you want to do any of these things?

This sounds like a lot of unnecessary machinery, to me. It's as though 
you are wanting to take Forth, which is a very simple language, and make 
it as complicated as others you're more familiar with.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12457

From"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date2012-05-25 15:17 -0400
Message-ID<jpolqg$t03$1@speranza.aioe.org>
In reply to#12455
"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:Wu-dnalYGvM9XiLSnZ2dnUVZ_radnZ2d@supernews.com...
> On 5/24/12 9:55 PM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> > news:9dOdnS-FfKqwlyLSnZ2dnUVZ_r-dnZ2d@supernews.com...
> >
> >>> [snip RP's C style words in Forth syntax ...]
> >>
> >> And I meant to comment on DUP>R. I really don't see the point of
> >> defining that. It's just two words, so in an ITC system the overhead of
> >> the extra definition (in both time for the extra call and size of the
> >> definition) is more than any possible saving, and in a system with an
> >> optimizer it's taken care of easily.
> >
> > Um...
> >
> > Firstly, in my original post, DUP>R was two words:
> >
> >    DUP<space>  >R
> >
> > It seems you or your newsreader software removed a space (?) ...
> > (That's not important to me, but you might check.)
>
> Dunno. I use Thunderbird, which has never been known to alter spacing.
>

Well, it did it again above.

That was posted as:

2 spaces
DUP
1 space
<space>
1 space
>R

That came through, in reply, as:

>
4 spaces
DUP
0 spaces
<space>
2 spaces
>R

If you're not reformatting (as I do), it seems to be something with '<' and
'>' or indenting.  Perhaps, those characters are causing shifting or
trimming of spaces.  I'd report a bug.  That is, if ... , you're not running
messages through a Forth beautifier.  ;-)  Although, I'm sure other people
are using Thunderbird too.  However, I've not noticed anything like that
before.  It seems strange.

You can view the original thread here:
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/ef3bdff829165fa6#

> > It just seems that Forth inserts words or operations directly
> > into the middle of various common sequences.
>
> ??? News to me!
> What version of Forth are you accusing of doing this?
>

That would be most of everything I attempt to code in my Forth ... :)  No,
it's not that bad.  The issue of wrappers to come up every now and then.
The less specific issue of repeated sequence seems to comes up more
frequently.  Is OVER + SWAP in loop words common enough to define another
word for it?  Anyone for O+S ?

> > So, I'm wanting to create "wrappers" for everything at
> > this point, i.e., a word before and a word after.  Or, I'm wanting to
> > create a single word that inserts the difference, e.g., passed an XT
> > and using EXECUTE.  I've not tried that yet.  It shouldn't be too
> > difficult.  I wouldn't know if it was ANS compliant...  Although,
> > perhaps more "generic," I can "see" that definition becoming a bit
> > larger ...
>
> Why would you want to do any of these things?
>

It seems ... useful?

> This sounds like a lot of unnecessary machinery, to me. It's as though
> you are wanting to take Forth, which is a very simple language, and make
> it as complicated as others you're more familiar with.

Ok.


Rod Pemberton



[toc] | [prev] | [next] | [standalone]


#12458

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-25 10:05 -1000
Message-ID<mLednTYtI8m0eyLSnZ2dnUVZ_qmdnZ2d@supernews.com>
In reply to#12457
On 5/25/12 9:17 AM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> news:Wu-dnalYGvM9XiLSnZ2dnUVZ_radnZ2d@supernews.com...
...
>>>
>>> Firstly, in my original post, DUP>R was two words:
>>>
>>>     DUP<space>   >R
>>>
>>> It seems you or your newsreader software removed a space (?) ...
>>> (That's not important to me, but you might check.)
>>
>> Dunno. I use Thunderbird, which has never been known to alter spacing.
>>
>
> Well, it did it again above.

I suspect what's going on is a difference between html and text. I use 
text only for these emails, and if you're working in a browser you're 
doing html.  Anyway, not important.

...
>>> It just seems that Forth inserts words or operations directly
>>> into the middle of various common sequences.
>>
>> ??? News to me!
>> What version of Forth are you accusing of doing this?
>>
>
> That would be most of everything I attempt to code in my Forth ... :)  No,
> it's not that bad.  The issue of wrappers to come up every now and then.
> The less specific issue of repeated sequence seems to comes up more
> frequently.  Is OVER + SWAP in loop words common enough to define another
> word for it?  Anyone for O+S ?

The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes 
vary as to whether this improves or impedes readability.

A good clue as to whether a sequence is worth naming is whether it makes 
logical sense that could be captured in an English name, as opposed to 
some functional jargon such as O+S. This one is marginal :-)

>>> So, I'm wanting to create "wrappers" for everything at
>>> this point, i.e., a word before and a word after.  Or, I'm wanting to
>>> create a single word that inserts the difference, e.g., passed an XT
>>> and using EXECUTE.  I've not tried that yet.  It shouldn't be too
>>> difficult.  I wouldn't know if it was ANS compliant...  Although,
>>> perhaps more "generic," I can "see" that definition becoming a bit
>>> larger ...
>>
>> Why would you want to do any of these things?
>>
>
> It seems ... useful?

Well, looking at the code you originally posted (putting the spaces back 
in):

: AND! ( x addr -- ) DUP >R @ AND R>  ! ; \  C's&=
: OR! ( x addr -- ) DUP >R @ OR R>  ! ; \  C's |=
: XOR! ( x addr -- ) DUP >R @ XOR R>  ! ; \  C's ^=

: +! ( x addr -- ) DUP >R @ + R>  ! ; \  C's +=
: -! ( x addr -- ) DUP >R @ - R>  ! ; \  C's -=
: *! ( x addr -- ) DUP >R @ * R>  ! ; \  C's *=

: /! ( x addr -- ) SWAP OVER @ SWAP / SWAP ! ; \  C's /=
: MOD! ( x addr -- ) SWAP OVER @ SWAP MOD SWAP ! \  C's %=
: LSHIFT! ( x addr -- ) SWAP OVER @ SWAP LSHIFT SWAP ! ; \  C's<<=
: RSHIFT! ( x addr -- ) SWAP OVER @ SWAP RSHIFT SWAP ! ; \  C's>>=

...I do see a lot of what you're calling "wrappers". But I'm disagreeing 
with the style of programming that would use *any* of these words, with 
the exception of +! (which is normally defined as a code sequence, both 
shorter and simpler than the high-level mess above).

>> This sounds like a lot of unnecessary machinery, to me. It's as though
>> you are wanting to take Forth, which is a very simple language, and make
>> it as complicated as others you're more familiar with.
>
> Ok.

If you want to program in C, that's fine. If you want to program in 
Forth, you should accept that Forth is a very different language from C, 
both in ideomatic style and in economics (what's efficient both for the 
programmer and for runtime). Trying to make equivalences to functions 
you're accustomed to in C and then using them to write programs will 
lead to code which is tortuously inefficient to run and very much more 
difficult to maintain.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12466

From"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date2012-05-26 08:02 -0400
Message-ID<jpqgnf$qt3$1@speranza.aioe.org>
In reply to#12458
"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:mLednTYtI8m0eyLSnZ2dnUVZ_qmdnZ2d@supernews.com...
> On 5/25/12 9:17 AM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> > news:Wu-dnalYGvM9XiLSnZ2dnUVZ_radnZ2d@supernews.com...
> ...
> >>>
> >>> Firstly, in my original post, DUP>R was two words:
> >>>
> >>>     DUP<space>   >R
> >>>
> >>> It seems you or your newsreader software removed a space (?) ...
> >>> (That's not important to me, but you might check.)
> >>
> >> Dunno. I use Thunderbird, which has never been known to alter spacing.
> >
> > Well, it did it again above.
>
> I suspect what's going on is a difference between html and text. I use
> text only for these emails, and if you're working in a browser you're
> doing html.

No, I read as text and post as text via Usenet.

I just linked to Google to show the correct content.

> Anyway, not important.

That's what I said.

But, I'd claim it's clearly a bug related to something on your end.  E.g.,
it might be your Usenet provider or company server instead of Thunderbird,
but most likely Thunderbird...

> > Is OVER + SWAP in loop words common enough to define another
> > word for it?  Anyone for O+S ?
>
> The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes
> vary as to whether this improves or impedes readability.
>
> A good clue as to whether a sequence is worth naming is whether it makes
> logical sense that could be captured in an English name, as opposed to
> some functional jargon such as O+S. This one is marginal :-)
>

What ... ?

So, for the OVER + SWAP sequence, you're  _seriously_  telling me BOUNDS
makes more "logical sense" of what "could be captured in an English name"
than O+S?

C'mon now ...

Coming from an EE background, I know that abbreviations are by far the best
for that.  There is a myriad of abbreviations in English used by
engineering, chemistry, mathematics, or text messaging that everyone knows
and remembers.  I can recite complex chemical names, from their
abbreviations, which I learned decades ago. Next, that'd be followed by
short numbers, like upto 7 digits since they match telephone numbers.
That's followed by symbols which can be converted easily remembered in terms
of words after slight memorization, e.g., + for arithmetic in mathematics or
! for memory store in Forth or != for not-equal in C.

You brought up an interesting point with the "captured by an English name"
concept.  I agree that it seems Forth transitioned to a syntax that almost
always uses English names.  But, even you must admit Forth started out with
symbolicly named words.  I don't see anyone doing the following to Forth to
bring it inline with this concept:

: STORE ! ;
: FETCH @ ;
: TICK ' ;
: MULTIPLY * ;
: .GT. > ;

Yes, that last one was a "poke" at Fortran.  Who liked typing that?  No
one...  Ditto for Forth.  No one wants to type MULTIPLY for * .  If they do
like extra typing, they'd probably program in COBOL.  Terseness is a factor
in C's success IMO.  So, why aren't more symbolic names defined for Forth?
Forth has no required syntax to speak of.  Some syntax, e.g., < <= >= > ,
has been standardized across a number of languages: Pascal, C, C++, Ada,
Python, and even Forth, etc.

However, I do sometimes see Forth programmers defining new symbolic words.
E.g. ` for POSTPONE or [[ ]] for POSTPONEd sequences.  So, I don't
understand why Forthers wouldn't embrace the compact or symbolic
representations of mathematics or C.  E.g., isn't  << much better notation
and syntax than LSHIFT?  Think ".GT." vs. ">" ...  E.g., isn't % better for
MOD and & better for AND?

I.e., I'm not buying into your argument here.

> >>> So, I'm wanting to create "wrappers" for everything at
> >>> this point, i.e., a word before and a word after.  Or, I'm wanting to
> >>> create a single word that inserts the difference, e.g., passed an XT
> >>> and using EXECUTE.  I've not tried that yet.  It shouldn't be too
> >>> difficult.  I wouldn't know if it was ANS compliant...  Although,
> >>> perhaps more "generic," I can "see" that definition becoming a bit
> >>> larger ...
> >>
> >> Why would you want to do any of these things?
> >
> > It seems ... useful?
>
> Well, looking at the code you originally posted (putting the spaces back
> in):
>
> [...]
>
> ...I do see a lot of what you're calling "wrappers". But I'm disagreeing
> with the style of programming that would use *any* of these words, with
> the exception of +! (which is normally defined as a code sequence, both
> shorter and simpler than the high-level mess above).

Ah.

So, if Forth mostly doesn't have words to manipulate VARIABLEs stored in
memory, where/how do Forthers use VARIABLEs?

Do Forthers always copy a variable's value to the stack, manipulate,
re-store?  Isn't that a waste?  (time, re-typing, cut-n-paste, etc)  What
happened to "factoring"?  If you know you're going to  be multiplying values
held by a few variables, wouldn't  *! be useful?  E.g., what if you have a
handful of counter variables, each with different initial values, and all of
them get multiplied by three at the end of a loop?  Do you code a word for
each variable that multiplies it by 3? Then, code another word that groups
all the multiply-by-3 words together?

I.e., not defining *! -! LSHIFT! etc to help with variables seems to violate
the Forth "factoring" concept.  No?  Why not?  I even gave them "Forthy"
names...


Rod Pemberton






[toc] | [prev] | [next] | [standalone]


#12467

FromCoos Haak <chforth@hccnet.nl>
Date2012-05-26 14:31 +0200
Message-ID<1e2cvqmiapf7w.zrzsl6ql89t9$.dlg@40tude.net>
In reply to#12466
Op Sat, 26 May 2012 08:02:38 -0400 schreef Rod Pemberton:

<snip>
> So, for the OVER + SWAP sequence, you're  _seriously_  telling me BOUNDS
> makes more "logical sense" of what "could be captured in an English name"
> than O+S?

Yes

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]


#12471

FromDoug Hoffman <glidedog@gmail.com>
Date2012-05-26 09:55 -0400
Message-ID<4fc0e0b6$0$284$14726298@news.sunsite.dk>
In reply to#12466
On 5/26/12 8:02 AM, Rod Pemberton wrote:

> I.e., not defining *! -! LSHIFT! etc to help with variables seems to violate
> the Forth "factoring" concept.

It took me awhile to realize that the Forth standard, by its own 
explicit declaration, is constructed to minimize the word set.  Also, in 
order for a word(s) to be added to the standard generally one must show 
that the word, or something like it, has already been in common use.

 From the Forth standard  29 Feb 2012
(these are selected snippets):

"A.1.2 Scope
The result of the effort to satisfy all of these objectives is a 
Standard arranged so that the required word set remains small.  Thus ANS 
Forth can be provided for resource-constrained embedded systems."

"Cost of compliance - This goal includes such issues as common practice,..."

"Utility - Be judged to have sufficiently essential functionality and 
frequency of use to be deemed suitable for inclusion."

"A.1.3.1 Word sets
 From the beginning, the Technical Committee faced not only conflicting 
ideas as to what “real” Forth is, but also conflicting needs of the 
various groups within the Forth community. At one extreme were those who 
pressed for a “bare” Forth. At the other extreme were those who wanted a 
“fat” Forth. Many were somewhere in between. All were convinced of the 
rightness of their own position and of the wrongness of at least one of 
the two extremes. The committee’s composition reflected this full range 
of interests."

Btw, ">=" and "<=" are not standard words.

Also, if you feel strongly enough you could always write an RfD:
http://www.forth200x.org/rfd-guide.html
http://www.forth200x.org/rfds.html

-Doug


[toc] | [prev] | [next] | [standalone]


#12472 — Re: Use of VARIABLEs frequent or infrequent? And, C style operators.

FromBruceMcF <agila61@netscape.net>
Date2012-05-26 07:04 -0700
SubjectRe: Use of VARIABLEs frequent or infrequent? And, C style operators.
Message-ID<cc2111ef-9c9f-4a8e-9904-ffca682258ec@v24g2000vbx.googlegroups.com>
In reply to#12466
On May 26, 8:02 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
>>> Is OVER + SWAP in loop words common enough to define another
>>> word for it?  Anyone for O+S ?

>> The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes
>> vary as to whether this improves or impedes readability.

> What ... ?

> So, for the OVER + SWAP sequence, you're  _seriously_  telling me BOUNDS
> makes more "logical sense" of what "could be captured in an English name"
> than O+S?

Yes. Words should be named for what they accomplish, not for how they
are implemented. The word "converts a base and count to bounds for a
do-loop."

[toc] | [prev] | [next] | [standalone]


#12477

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-26 09:41 -1000
Message-ID<3NKdnYNbSeRRrFzSnZ2dnUVZ_h6dnZ2d@supernews.com>
In reply to#12466
On 5/26/12 2:02 AM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
...
>> The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes
>> vary as to whether this improves or impedes readability.
>>
>> A good clue as to whether a sequence is worth naming is whether it makes
>> logical sense that could be captured in an English name, as opposed to
>> some functional jargon such as O+S. This one is marginal :-)
>>
>
> What ... ?
>
> So, for the OVER + SWAP sequence, you're  _seriously_  telling me BOUNDS
> makes more "logical sense" of what "could be captured in an English name"
> than O+S?
>
> C'mon now ...

As others have pointed out, BOUNDS conveys the *purpose* of the action. 
Good names reflect purpose and intent, not just a summary of details.

> Coming from an EE background, I know that abbreviations are by far the best
> for that.  There is a myriad of abbreviations in English used by
> engineering, chemistry, mathematics, or text messaging that everyone knows
> and remembers.  I can recite complex chemical names, from their
> abbreviations, which I learned decades ago. Next, that'd be followed by
> short numbers, like upto 7 digits since they match telephone numbers.
> That's followed by symbols which can be converted easily remembered in terms
> of words after slight memorization, e.g., + for arithmetic in mathematics or
> ! for memory store in Forth or != for not-equal in C.

Good abbreviations capture the *conceptual essence* of the thing being 
abbreviated, not an abstract shortening.

> You brought up an interesting point with the "captured by an English name"
> concept.  I agree that it seems Forth transitioned to a syntax that almost
> always uses English names.  But, even you must admit Forth started out with
> symbolicly named words.  I don't see anyone doing the following to Forth to
> bring it inline with this concept:
>
> : STORE ! ;
> : FETCH @ ;
> : TICK ' ;
> : MULTIPLY * ;
> : .GT.>  ;

A story about FETCH as pronunciation of '@': Originally that was 
pronounced "at" (i.e., that character is an "at sign"). At an early 
standards meeting a group of FIG members insisted on changing the 
pronunciation to "fetch" (for reasons I never understood), and outvoted 
the others present. I still think "at" would be better.

And I distinctly remember teaching a Forth class in England in the 80's. 
I had a lot of examples on the board, when someone (who had evidently 
not been paying attention and suddenly woke up) asked, "What are all 
those bangs?" What? Where? Eventually, someone explained that ! is 
pronounced "bang" in England.

> Yes, that last one was a "poke" at Fortran.  Who liked typing that?  No
> one...  Ditto for Forth.  No one wants to type MULTIPLY for * .  If they do
> like extra typing, they'd probably program in COBOL.  Terseness is a factor
> in C's success IMO.  So, why aren't more symbolic names defined for Forth?
> Forth has no required syntax to speak of.  Some syntax, e.g.,<  <=>=>  ,
> has been standardized across a number of languages: Pascal, C, C++, Ada,
> Python, and even Forth, etc.

A lot of it was personal decisions made by Chuck, compromises between 
clarity and conciseness for frequently-used operations such as @, !, . 
etc. Once things are in common use they're hard to change.

> However, I do sometimes see Forth programmers defining new symbolic words.
> E.g. ` for POSTPONE or [[ ]] for POSTPONEd sequences.  So, I don't
> understand why Forthers wouldn't embrace the compact or symbolic
> representations of mathematics or C.  E.g., isn't<<  much better notation
> and syntax than LSHIFT?  Think ".GT." vs. ">" ...  E.g., isn't % better for
> MOD and&  better for AND?
>
> I.e., I'm not buying into your argument here.

On the contrary, you're presenting it well.  < and > are commonly 
understood symbols, and hence better than .LT. and .GT. On the other 
hand, LSHIFT conveys the action better than << which could be 
interpreted as, for example, "much less than" or a beginning of a string 
<< ... >> or a variety of other purposes.

And, for Pete's sake, % clearly means "per cent" not MOD!

...
>>
>> ...I do see a lot of what you're calling "wrappers". But I'm disagreeing
>> with the style of programming that would use *any* of these words, with
>> the exception of +! (which is normally defined as a code sequence, both
>> shorter and simpler than the high-level mess above).
>
> Ah.
>
> So, if Forth mostly doesn't have words to manipulate VARIABLEs stored in
> memory, where/how do Forthers use VARIABLEs?
>
> Do Forthers always copy a variable's value to the stack, manipulate,
> re-store?  Isn't that a waste?  (time, re-typing, cut-n-paste, etc)  What
> happened to "factoring"?  If you know you're going to  be multiplying values
> held by a few variables, wouldn't  *! be useful?  E.g., what if you have a
> handful of counter variables, each with different initial values, and all of
> them get multiplied by three at the end of a loop?  Do you code a word for
> each variable that multiplies it by 3? Then, code another word that groups
> all the multiply-by-3 words together?

The whole point is that a value 'lives' on the stack, not in memory. If 
you are performing a sequence of operations on a value, it will be 
passed on the stack through the words that act on it, and not stored in 
a variable between each of those actions.

Your example sounds a little forced to me... I have trouble imagining 
such a situation. My experience is much more like: read a value from a 
device; scale it; display it on the screen; store it in the next 
location in an array. Only the last action involves storing in data 
space, and then it isn't a "variable" per se. All of the other steps 
would be performed on the value on the stack. And even the index into 
the array is likely to be a loop counter, rather than a variable.

> I.e., not defining *! -! LSHIFT! etc to help with variables seems to violate
> the Forth "factoring" concept.  No?  Why not?  I even gave them "Forthy"
> names...

In most languages you can't operate on a value unless you give it a 
name. So, one naturally learns to think about values as named variables. 
This is an example of the different thinking that's required to use 
Forth effectively. Forth encourages you to approach processes differently.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12482

From"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date2012-05-26 19:52 -0400
Message-ID<jprq9v$u7c$1@speranza.aioe.org>
In reply to#12477
"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:3NKdnYNbSeRRrFzSnZ2dnUVZ_h6dnZ2d@supernews.com...
> On 5/26/12 2:02 AM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<erather@forth.com>  wrote in message
...

> >> The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes
> >> vary as to whether this improves or impedes readability.
> >>
> >> A good clue as to whether a sequence is worth naming is whether it
> >> makes logical sense that could be captured in an English name, as
> >> opposed to some functional jargon such as O+S. This one is marginal :-)
> >
> > What ... ?
> >
> > So, for the OVER + SWAP sequence, you're  _seriously_  telling me BOUNDS
> > makes more "logical sense" of what "could be captured in an English
> > name" than O+S?
> >
> > C'mon now ...
>
> As others have pointed out, BOUNDS conveys the *purpose* of the action.
> Good names reflect purpose and intent, not just a summary of details.

There is nothing in BOUNDS to convey that it is OVER + SWAP.  One must
either know, look it up, or display it's definition.  There is zero
information content as to what BOUNDS means when one reads "BOUNDS".
Good abbreviations convey the *meaning* of the abbreviation:

 H2O - two hydrogen and one oxygen - water
 ROFL - rolling on the floor laughing
 HCl - hydrochloride
 USD - U.S. dollar
 TCE - tri-chloro-ethylene
 Turducken - turkey, duck, chicken
 TSP - tri-sodium-phosphate
 Bennifer - Ben + Jennifer

> > Coming from an EE background, I know that abbreviations are by far the
> > best for that.
>
> Good abbreviations capture the *conceptual essence* of the thing being
> abbreviated, not an abstract shortening.

See above.
Look at the letters of the abbreviations.
Look at the letters of their meanings.

> A story about FETCH as pronunciation of '@': Originally that was
> pronounced "at" (i.e., that character is an "at sign"). At an early
> standards meeting a group of FIG members insisted on changing the
> pronunciation to "fetch" (for reasons I never understood), and outvoted
> the others present. I still think "at" would be better.

Um, "fetch" in the sense of "to retrieve" or "return with" being an antonym
to "store" in the sense of "to place" or "put away" was not something you
understood or considered ...  Really?  Their pairing is clearly a mnemonic
device.  Abbreviations are too.  Although, I think "load" and "store" were
more prevalent names in the 8-bit assembly era.  Perhaps, he/she had
issues with the word: "load".

> And I distinctly remember teaching a Forth class in England in the 80's.
> I had a lot of examples on the board, when someone (who had evidently
> not been paying attention and suddenly woke up) asked, "What are all
> those bangs?" What? Where? Eventually, someone explained that ! is
> pronounced "bang" in England.

"at" for @, apparently meaning an address pointer in this context, seems to
be contradictory to your statements above.  "at" doesn't convey the
"*purpose* of the action" nor the "*conceptual essence*".  But, "fetch"
does...  "at" just conveys an address, but doesn't convey the operation of
retrieving what is "at" that address.

It's called a "bang" for Unix shell scripts too, Fido-net email routing,
etc.  Perhaps, he/she also had issues with the word: "bang".

> > I.e., I'm not buying into your argument here.
>
> On the contrary, you're presenting it well.  < and > are commonly
> understood symbols, and hence better than .LT. and .GT. On the other
> hand, LSHIFT conveys the action better than << which could be
> interpreted as, for example, "much less than" or a beginning of a string
> << ... >> or a variety of other purposes.
>

... just as @ being interpreted as meaning "at" ...  ;-)

Someone must define a meaning for symbols.

> >> ...I do see a lot of what you're calling "wrappers". But I'm
> >> disagreeing with the style of programming that would use *any* of
> >> these words, with the exception of +! (which is normally defined as
> >> a code sequence, both shorter and simpler than the high-level mess
> >> above).
> >
> > Ah.
> >
> > So, if Forth mostly doesn't have words to manipulate VARIABLEs
> > stored in memory, where/how do Forthers use VARIABLEs?
> >
> > Do Forthers always copy a variable's value to the stack, manipulate,
> > re-store?  Isn't that a waste?  (time, re-typing, cut-n-paste, etc)
>
> The whole point is that a value 'lives' on the stack, not in memory. If
> you are performing a sequence of operations on a value, it will be
> passed on the stack through the words that act on it, and not stored in
> a variable between each of those actions.
>
> Your example sounds a little forced to me...

If the words I posted were implemented as primitives (or low-level words),
then they need not use the data stack at all.  So, I see the use of the
stack as contrived when one wants to manipulate memory data.  It's an
unecessary intermediate step that prevents proper optimization of assembly.

You are aware that most microprocessor's since 1974 can directly manipulate
memory locations with arithmetic operations, yes?

> In most languages you can't operate on a value unless you give it a
> name.

True.  Most are derived from C, or ALGOL, ...

> So, one naturally learns to think about values as named variables.

AIR, I learned mathematics before programming, where values were manipulated
without naming at first (basic math), then with naming them later (algebra).
I learned 6502 assembly immediately after BASIC.  So, I don't see that
naming variables as logical outcome of thinking about values.  In a language
with variables, the compiler can place data where most appropriate: stack,
memory, or register.  The compiler can keep track of it's location without
programmer intervention.  That's a good thing.  The assembly can be made
more efficient.  The programmer can't make mistakes about where the data is
located.

> This is an example of the different thinking that's required to use
> Forth effectively. Forth encourages you to approach processes differently.

That's called being devoid of a type system.  That is usually considered to
be a security risk.  I.e., someone retrieves a variable's value onto the
data stack, mistakes where it is, and stores it back to the variable in the
wrong location.  The control-flow stack is another security issue.
Normally, "safe" high-level languages don't allow users to directly
manipulate control-flow data.  When they can, they cause crashes and
breaches, e.g., see numerous buffer-overflow exploits for C.  R> and >R etc
would have to be removed from Forth or use a 3rd stack.


In regards to Forth and my questions about it, what I'm seeing is a language
which has no self-imposed ideology, because it has no required language
syntax.  However, I'm also seeing a language which has programmers who are
imposing currently or have imposed specific ideologies over time on the
language, thereby limiting the way it's used and it's potential.  Some of
those ideologies, I would list as:

 "factor words, but only when it doesn't conflict with other goals"
 "use the stack, not variables"
 "use words, not symbols or abbreviations"
 "avoid state-aware words"


Rod Pemberton



[toc] | [prev] | [next] | [standalone]


#12490

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-26 19:49 -1000
Message-ID<8dKdncVFodLPXVzSnZ2dnUVZ_hudnZ2d@supernews.com>
In reply to#12482
On 5/26/12 1:52 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> news:3NKdnYNbSeRRrFzSnZ2dnUVZ_h6dnZ2d@supernews.com...
>> On 5/26/12 2:02 AM, Rod Pemberton wrote:
>>> "Elizabeth D. Rather"<erather@forth.com>   wrote in message
> ...
>
>>>> The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes
>>>> vary as to whether this improves or impedes readability.
>>>>
>>>> A good clue as to whether a sequence is worth naming is whether it
>>>> makes logical sense that could be captured in an English name, as
>>>> opposed to some functional jargon such as O+S. This one is marginal :-)
>>>
>>> What ... ?
>>>
>>> So, for the OVER + SWAP sequence, you're  _seriously_  telling me BOUNDS
>>> makes more "logical sense" of what "could be captured in an English
>>> name" than O+S?
>>>
>>> C'mon now ...
>>
>> As others have pointed out, BOUNDS conveys the *purpose* of the action.
>> Good names reflect purpose and intent, not just a summary of details.
>
> There is nothing in BOUNDS to convey that it is OVER + SWAP.  One must
> either know, look it up, or display it's definition.  There is zero
> information content as to what BOUNDS means when one reads "BOUNDS".

The important thing is that its stack arguments are ( sv n -- sv+n sv ) 
which are appropriate DO...LOOP parameters to run a loop with indices sv 
through sv+n-1. There may be a number of ways to do this other than OVER 
+ SWAP. The focus should be on what words do, not how they do them.

> Good abbreviations convey the *meaning* of the abbreviation:
>
>   H2O - two hydrogen and one oxygen - water
>   ROFL - rolling on the floor laughing
>   HCl - hydrochloride
>   USD - U.S. dollar
>   TCE - tri-chloro-ethylene
>   Turducken - turkey, duck, chicken
>   TSP - tri-sodium-phosphate
>   Bennifer - Ben + Jennifer

I doubt seriously that you knew what all these were the first time you 
saw them. All Forth words have to be learned, including their stack 
effects and semantics, and new words need to be documented regardless of 
how they're named.

...
>> A story about FETCH as pronunciation of '@': Originally that was
>> pronounced "at" (i.e., that character is an "at sign"). At an early
>> standards meeting a group of FIG members insisted on changing the
>> pronunciation to "fetch" (for reasons I never understood), and outvoted
>> the others present. I still think "at" would be better.
>
> Um, "fetch" in the sense of "to retrieve" or "return with" being an antonym
> to "store" in the sense of "to place" or "put away" was not something you
> understood or considered ...  Really?  Their pairing is clearly a mnemonic
> device.  Abbreviations are too.  Although, I think "load" and "store" were
> more prevalent names in the 8-bit assembly era.  Perhaps, he/she had
> issues with the word: "load".

Well, LOAD was the word used to interpret a block of source, so that was 
taken :-)  The point is not that "fetch" is inappropriate, it's that 
when one is accustomed to something, its mnemonic value seems obvious, 
and it's normal to be resistant to change.

...
>
> "at" for @, apparently meaning an address pointer in this context, seems to
> be contradictory to your statements above.  "at" doesn't convey the
> "*purpose* of the action" nor the "*conceptual essence*".  But, "fetch"
> does...  "at" just conveys an address, but doesn't convey the operation of
> retrieving what is "at" that address.

Of course it does: you just said it. X @ returns the value 'at' the 
address X.

> It's called a "bang" for Unix shell scripts too, Fido-net email routing,
> etc.  Perhaps, he/she also had issues with the word: "bang".
>
>>> I.e., I'm not buying into your argument here.

Ok. I don't care whether you "buy" it, I just want you to know what it is.

...
> Someone must define a meaning for symbols.

Of course.

...
>>> Do Forthers always copy a variable's value to the stack, manipulate,
>>> re-store?  Isn't that a waste?  (time, re-typing, cut-n-paste, etc)
>>
>> The whole point is that a value 'lives' on the stack, not in memory. If
>> you are performing a sequence of operations on a value, it will be
>> passed on the stack through the words that act on it, and not stored in
>> a variable between each of those actions.
>>
>> Your example sounds a little forced to me...
>
> If the words I posted were implemented as primitives (or low-level words),
> then they need not use the data stack at all.  So, I see the use of the
> stack as contrived when one wants to manipulate memory data.  It's an
> unecessary intermediate step that prevents proper optimization of assembly.
>
> You are aware that most microprocessor's since 1974 can directly manipulate
> memory locations with arithmetic operations, yes?

Yes. I am also aware that in many Forth implementations the top stack 
item is kept in a register -- often the top two items, so an actual 
memory access may not be necessary.

But the important concept is that Forth is a stack-oriented language. If 
you are going to use Forth effectively, you need to accept this. If you 
don't want to use a stack-oriented language, nobody is forcing you to 
use Forth. If you want to twist Forth into being other than a 
stack-oriented language, you will end up with something that will 
probably be very unsatisfactory.

>> In most languages you can't operate on a value unless you give it a
>> name.
>
> True.  Most are derived from C, or ALGOL, ...

Right. Forth doesn't share that heritage.

>> So, one naturally learns to think about values as named variables.
>
> AIR, I learned mathematics before programming, where values were manipulated
> without naming at first (basic math), then with naming them later (algebra).
> I learned 6502 assembly immediately after BASIC.  So, I don't see that
> naming variables as logical outcome of thinking about values.  In a language
> with variables, the compiler can place data where most appropriate: stack,
> memory, or register.  The compiler can keep track of it's location without
> programmer intervention.  That's a good thing.  The assembly can be made
> more efficient.  The programmer can't make mistakes about where the data is
> located.

Yes, that's the "smart compiler, dumb programmer" theory of computing. 
Forth follows a "simple compiler, powerful programmer" theory. It's not 
for everyone, I'm the first to admit.

>> This is an example of the different thinking that's required to use
>> Forth effectively. Forth encourages you to approach processes differently.
>
> That's called being devoid of a type system.  That is usually considered to
> be a security risk.  I.e., someone retrieves a variable's value onto the
> data stack, mistakes where it is, and stores it back to the variable in the
> wrong location.  The control-flow stack is another security issue.
> Normally, "safe" high-level languages don't allow users to directly
> manipulate control-flow data.  When they can, they cause crashes and
> breaches, e.g., see numerous buffer-overflow exploits for C.  R> and >R etc
> would have to be removed from Forth or use a 3rd stack.

Being weakly typed isn't the only way Forth is different. Being 
stack-oriented and programmer-controlled are also important elements. 
Forth is not the language for programmers who don't want to accept 
responsibility for their code, but prefer a powerful compiler to save 
themselves from their mistakes. It may not be the language for you. But 
for programmers willing to accept that responsibility, it makes them 
incredibly powerful.

> In regards to Forth and my questions about it, what I'm seeing is a language
> which has no self-imposed ideology, because it has no required language
> syntax.

It has the characteristics I listed above. These are fundamental to the 
language. I'm not sure what you mean by "ideology" in this context.

> However, I'm also seeing a language which has programmers who are
> imposing currently or have imposed specific ideologies over time on the
> language, thereby limiting the way it's used and it's potential.  Some of
> those ideologies, I would list as:
>
>   "factor words, but only when it doesn't conflict with other goals"

Not sure what that means. There are positive guidelines for when 
factoring is a good thing.

>   "use the stack, not variables"

I never heard that one before. Forth is a stack-oriented language, so 
one uses fewer variables than in other languages, but they have a 
definite utility. "Use variables when they're appropriate" is more like it.

>   "use words, not symbols or abbreviations"

I have no idea what the distinction between these three words is!

>   "avoid state-aware words"

That's a recommendation from experience, I wouldn't call it an 
"ideology". Every discipline has recommended and discouraged practices.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12648

From"Ed" <invalid@nospam.com>
Date2012-06-01 13:39 +1000
Message-ID<jq9dip$d7v$1@speranza.aioe.org>
In reply to#12490
Elizabeth D. Rather wrote:
> ...
> But the important concept is that Forth is a stack-oriented language. If
> you are going to use Forth effectively, you need to accept this. If you
> don't want to use a stack-oriented language, nobody is forcing you to
> use Forth. If you want to twist Forth into being other than a
> stack-oriented language, you will end up with something that will
> probably be very unsatisfactory.

Insofar as locals are present in "Standard Forth" and the intent/effect
of locals is to *minimize use of the stack* by assigning variables to
hold intermediate results, "Standard Forth" can no longer claim to be
a purely stack-oriented language.

If Forth today is confused/confusing, it's only a reflection of the users
who use it.


[toc] | [prev] | [next] | [standalone]


#12649

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-05-31 19:27 -1000
Message-ID<nZGdnf9xH9dUz1XSnZ2dnUVZ_gqdnZ2d@supernews.com>
In reply to#12648
On 5/31/12 5:39 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> ...
>> But the important concept is that Forth is a stack-oriented language. If
>> you are going to use Forth effectively, you need to accept this. If you
>> don't want to use a stack-oriented language, nobody is forcing you to
>> use Forth. If you want to twist Forth into being other than a
>> stack-oriented language, you will end up with something that will
>> probably be very unsatisfactory.
>
> Insofar as locals are present in "Standard Forth" and the intent/effect
> of locals is to *minimize use of the stack* by assigning variables to
> hold intermediate results, "Standard Forth" can no longer claim to be
> a purely stack-oriented language.
>
> If Forth today is confused/confusing, it's only a reflection of the users
> who use it.

Locals were added to Standard Forth, but as I recall the primary intent 
was to have them available to solve particularly hairy problems, not to 
"minimize the use of the stack" in general. They're an optional wordset, 
and thus not available in all Standard Systems. Stephen has presented 
compelling evidence that, even with an advanced optimizing compiler, 
programs are shorter and faster without locals, so I won't back off 
asserting that Forth is a stack-oriented language.

People who insist on using locals as a crutch to avoid learning stack 
management skills will end up with an inferior product, at least 
technically.

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."
==================================================

[toc] | [prev] | [next] | [standalone]


#12658

From"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date2012-06-01 18:24 -0400
Message-ID<jqbfdo$ssh$1@speranza.aioe.org>
In reply to#12490
"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:8dKdncVFodLPXVzSnZ2dnUVZ_hudnZ2d@supernews.com...
> On 5/26/12 1:52 PM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> > news:3NKdnYNbSeRRrFzSnZ2dnUVZ_h6dnZ2d@supernews.com...
> >> On 5/26/12 2:02 AM, Rod Pemberton wrote:
> >>> "Elizabeth D. Rather"<erather@forth.com>   wrote in message
...

> >>>> The sequence OVER + SWAP is often defined as the word BOUNDS. Tastes
> >>>> vary as to whether this improves or impedes readability.
> >>>>
> >>>> A good clue as to whether a sequence is worth naming is whether it
> >>>> makes logical sense that could be captured in an English name, as
> >>>> opposed to some functional jargon such as O+S. This one is marginal
> >>>> :-)
> >>>
> >>> What ... ?
> >>>
> >>> So, for the OVER + SWAP sequence, you're  _seriously_  telling me
> >>> BOUNDS makes more "logical sense" of what "could be captured in
> >>> an English name" than O+S?
> >>>
> >>> C'mon now ...
> >>
> >> As others have pointed out, BOUNDS conveys the *purpose* of the action.
> >> Good names reflect purpose and intent, not just a summary of details.
> >
> > There is nothing in BOUNDS to convey that it is OVER + SWAP.  One must
> > either know, look it up, or display it's definition.  There is zero
> > information content as to what BOUNDS means when one reads "BOUNDS".
>
> The important thing is that its stack arguments are ( sv n -- sv+n sv )
> which are appropriate DO...LOOP parameters to run a loop with indices sv
> through sv+n-1. There may be a number of ways to do this other than OVER
> + SWAP. The focus should be on what words do, not how they do them.
>

Well, I'm not finding BOUNDS officially defined ... anywhere.  ;-)

Where is/was BOUNDS defined?  Or, where did it come into usage?


BOUNDS is not defined for fig-Forth.
BOUNDS is not defined for Forth-79.
BOUNDS is not defined for Forth-83.
BOUNDS is not defined for ANS-94 (ANSI X3.215-1994).
BOUNDS is not defined in Forth200x draft 9.
BOUNDS is not defined in Forth200x draft 10.
BOUNDS is not defined in "Starting Forth" by Leo Brodie.
BOUNDS is not defined in "Thinking Forth" by Leo Brodie.
BOUNDS is not defined in "Forth - The Early Years" by Chuck Moore.

BOUNDS is defined for Open Firmware FCODE (IEEE Std. 1275-1994).
BOUNDS is defined as an example in Forth200x draft 11.
BOUNDS is defined in Bill Muench's eForth.
BOUNDS is defined in Tom Zimmer's TCOM.
BOUNDS is defined in GNU Forth
BOUNDS is defined in Laxen and Perry's 8086Forth.
BOUNDS is defined in Wil Baden's various wordsets.


FYI, the BOUNDS example in Forth200x draft 11 seems to be the same
example as that in "Programming Forth" by Stephen Pelc ...

The Open Firmware FCODE specification defines two wordsets.  The first is a
selection of Forth words which the specification says are _all_ from ANS-94.
That list includes a few words which are *not* in ANS-94 such as BOUNDS
and -ROT ...

Why did the Open Firmware creators believe BOUNDS was in ANS-94?

The earliest use of BOUNDS in what I have are Laxen & Perry's 8086Forth '84
and Wil Baden FORML '87.


Rod Pemberton
BTW, are the FORML Conferences (Forth Modification Laboratory) available
online somewhere?  I'm not finding them ...

[toc] | [prev] | [next] | [standalone]


#12662

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2012-06-02 03:09 -0500
Message-ID<Z-2dnUqhxJbLV1TSnZ2dnUVZ_vSdnZ2d@supernews.com>
In reply to#12658
Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote in message
> news:8dKdncVFodLPXVzSnZ2dnUVZ_hudnZ2d@supernews.com...
>> On 5/26/12 1:52 PM, Rod Pemberton wrote:
>> > There is nothing in BOUNDS to convey that it is OVER + SWAP.  One must
>> > either know, look it up, or display it's definition.  There is zero
>> > information content as to what BOUNDS means when one reads "BOUNDS".
>>
>> The important thing is that its stack arguments are ( sv n -- sv+n sv )
>> which are appropriate DO...LOOP parameters to run a loop with indices sv
>> through sv+n-1. There may be a number of ways to do this other than OVER
>> + SWAP. The focus should be on what words do, not how they do them.
>>
> 
> Well, I'm not finding BOUNDS officially defined ... anywhere.  ;-)
> 
> Where is/was BOUNDS defined?  Or, where did it come into usage?

It's been around for at least twenty-five years, to my knowledge.
It's always been a bit marginal: some people used it, some didn't.
It's worth standardizing because it's common enough and you don't want
people using it with other meanings, but IMO not worth using.

Andrew.

[toc] | [prev] | [next] | [standalone]


#12492

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2012-05-27 02:23 -0500
Message-ID<yvidnQXXCtfpS1zSnZ2dnUVZ_tidnZ2d@supernews.com>
In reply to#12482
Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
> 
> You are aware that most microprocessor's since 1974 can directly
> manipulate memory locations with arithmetic operations, yes?

Quite the reverse, in fact.  The dominant trend in computer design
since MIPS in 1981 has been the load/store architecture, which only
allows memory to be accessed by load and store.

>> This is an example of the different thinking that's required to use
>> Forth effectively. Forth encourages you to approach processes
>> differently.
> 
> That's called being devoid of a type system.

No, it's not.  It's got nothing to do with types.  The same would
apply to a strongly-typed Forth variant.

> In regards to Forth and my questions about it, what I'm seeing is a
> language which has no self-imposed ideology, because it has no
> required language syntax.

Oh, this is nonsense.  How can a language impose an ideology on
itself?

> However, I'm also seeing a language which has programmers who are
> imposing currently or have imposed specific ideologies over time on
> the language, thereby limiting the way it's used and it's potential.
> Some of those ideologies, I would list as:
> 
> "factor words, but only when it doesn't conflict with other goals"
> "use the stack, not variables"
> "use words, not symbols or abbreviations"
> "avoid state-aware words"

These aren't ideologies, they are advice from people who are
experienced.  Such advice is no more ideological than "always clean
your tools before you put them away."  You can ignore that advice if
you want, but it'll cost you.

Andrew.

[toc] | [prev] | [next] | [standalone]


Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth


csiph-web