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

[Rod Pemberton]

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


Rod Pemberton

[Mark Wills]

On May 22, 9:01 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:

I think you've unwittingly demonstrated why the words you cite aren't
included in the language: its trivial to define them yourself! This
isn't really possible in C but trivial in Forth. In forth you just
write what you need!


I personally know of no other language that is so malleable. I'm told
lisp has similar features but I've never tried it.

[Ed]

Rod Pemberton wrote:
> Is the use of VARIABLEs frequent or infrequent in Forth?

Less frequent than in other languages because Forth uses the stack
for passing parameters. That's not to say VARIABLE's are not required
or undesirable in Forth.

The downside is having to learn a new set of operators.

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.

[Paul Rubin]

"Ed" <inv...@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"). In fact it turns out the locals
can't really in general be weeded out. Part of the art of Forth
programming seems to be resolving (some of) the difficult cases by
high-level factoring that a compiler can't really do. The ability and
willingness to do that is one of the things I find impressive about
Forth programmers.

[Elizabeth D. Rather]

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

[Nomen Nescio]

I seem to remember one being available on MPE's site?

[Paul Rubin]

Nomen Nescio <nob...@dizum.com> writes:
> I seem to remember one being available on MPE's site?

Interesting. http://www.mpeforth.com/arena.htm :

These are for projects we think would be useful, are too busy or too
mean to do ourselves, or are outside our current skill set e.g. too
theoretical or academic. ...

C to Forth Compiler: This is a complete C to Forth compiler with
sources. It is an MPE research project which we believe will grow
better as a Forth community project. Download the ZIP file
c2forth110.zip which is about 510kb.

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> C to Forth Compiler: This is a complete C to Forth compiler with
> sources. It is an MPE research project which we believe will grow
> better as a Forth community project. Download the ZIP file
> c2forth110.zip which is about 510kb.

OK, I downloaded this and played with it. I had to fix a couple of
errors and clean up the makefile to get this to build, but yeah, it's a
quite compact C compiler that produces Forth code.

The output is nothing at all like idiomatic Forth, and relies heavily on
a "lv," time word that appears to mean something like PICK. That about
the same thing as locals, in my opinion. Still, it's nice work and it
would be cool if MPE were to dust it off a little and release it.

[Rod Pemberton]

"Paul Rubin" <no.e...@nospam.invalid> wrote in message
news:7xtxz7q...@ruckus.brouhaha.com...

> "Ed" <inv...@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

[Stephen Pelc]

It would be really cool if we got some feeback in the form of those
"dusted off" make files and bugs that you have fixed. The we might
even release v1.2.

Stephen

--
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

[Anton Ertl]

"Rod Pemberton" <do_no...@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/

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
> It would be really cool if we got some feeback in the form of those
> "dusted off" make files and bugs that you have fixed. The we might
> even release v1.2.

I just hacked the files enough to get it to compile. I didn't do any
real dusting. As I remember:

1) changed makefiles to use unix filenames instead of msdos. Changed
spaces to tabs which are syntactically significant in makefiles.
Changed "cl" (name of whatever C compiler you were using) to "cc".

2) There was some problem with "memmove" function so I chopped it out
since there is a library one.

3) symbols "emit" and "gen" were declared static in fthcode.c and
shadowed globals of the same name declared in a .h file that fthcode.c
also imported, so I patched that.

That was enough to get the files to compile so I could fool around with
them a little. There were still a lot of compile-time warning messages
that I didn't try to fix.

[Stephen Pelc]

On Thu, 24 May 2012 09:40:51 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>steph...@mpeforth.com (Stephen Pelc) writes:
>> It would be really cool if we got some feeback in the form of those
>> "dusted off" make files and bugs that you have fixed. The we might
>> even release v1.2.
>
>I just hacked the files enough to get it to compile. I didn't do any
>real dusting. As I remember:

...

I ask for feedback and get hand-waving ... grump, grump, grump.

It would be really cool if Open Source people could make proper
error reports. Or is that someone else's problem?

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
> I ask for feedback and get hand-waving ... grump, grump, grump.
>
> It would be really cool if Open Source people could make proper
> error reports. Or is that someone else's problem?

Well, do you have a bug tracker? A git repo that you can pull my
changes to? Anything like that?

Really, what I did wasn't rocket science. I unpacked the files, typed
"make" in the subdirs, got a bunch of error messages causing the build
to fail, so I poked stuff til the build was successful (though there
were still a lot of warning messages). That meant updating the
makefiles and making a couple of small hacks in the source files as I
said.

I can put up a tarball or a git repo of my hacked version if you want,
but I figured it was enough to just generally describe what I did, since
you can presumably do the same thing in a minute or two, if you have a
Un*x system. The patch I made to fix the gen/emit conflict was not
really an acceptable one for releasable code (I just #ifdef'd out the
global declaration for the file having the conflict), so you probably
want to handle that in a different way anyway.

[Elizabeth D. Rather]

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.

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:9dOdnS-FfKqwlyLS...@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

[Stephen Pelc]

On Thu, 24 May 2012 14:17:20 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>Really, what I did wasn't rocket science.

Just send me the changed files and I'll do the merge. One of the
peculiarities of MPE is that *all* code changes are reviewed by
human eyeballs and BeyondCompare *before* being let in.

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
> Just send me the changed files and I'll do the merge.

OK, I'll email them or post a tarball url in the next day or so.
Merging isn't appropriate since I basically changed the DOS-specific
makefiles turning them into unix-specific ones. Maybe you can include
both versions. The code changes I made probably also won't be
acceptable as-is, but they'll at least indicate what went wrong.

> One of the peculiarities of MPE is that *all* code changes are
> reviewed by human eyeballs and BeyondCompare *before* being let in.

Sure, though of course one normally does similar things with git (using
"git diff").

[Nomen Nescio]

> Just send me the changed files and I'll do the merge. One of the
> peculiarities of MPE is that *all* code changes are reviewed by
> human eyeballs and BeyondCompare *before* being let in.

man diff

[Stephen Pelc]

Oh, come on - get some real tools! Eyeballs are great!

Stephen
P.S. It's really hot here and I'm off to the garden for a
decent glass of wine. I may be some time ...

[Elizabeth D. Rather]

On 5/24/12 9:55 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<era...@forth.com> wrote in message
> news:9dOdnS-FfKqwlyLS...@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.

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message

news:Wu-dnalYGvM9XiLS...@supernews.com...

> On 5/24/12 9:55 PM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<era...@forth.com> wrote in message
> > news:9dOdnS-FfKqwlyLS...@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

[Elizabeth D. Rather]

On 5/25/12 9:17 AM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<era...@forth.com> wrote in message

> news:Wu-dnalYGvM9XiLS...@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.

[Albert van der Horst]

In article <4fbfb7c5....@192.168.0.50>,

Stephen Pelc <steph...@INVALID.mpeforth.com> wrote:
>On Fri, 25 May 2012 14:33:49 +0200 (CEST), Nomen Nescio
><nob...@dizum.com> wrote:
>
>>> Just send me the changed files and I'll do the merge. One of the
>>> peculiarities of MPE is that *all* code changes are reviewed by
>>> human eyeballs and BeyondCompare *before* being let in.
>>
>>man diff
>
>Oh, come on - get some real tools! Eyeballs are great!

What is he trying to imply? That it makes sense to run a diff or
use BeyondCompare, then have nobody look at the results?

>
>Stephen
>P.S. It's really hot here and I'm off to the garden for a
>decent glass of wine. I may be some time ...

It was over 30 degrees (303 K) last wednesday, here in the Netherlands.

>
>
>--
>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

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Fritz Wuehler]

Paul Rubin <no.e...@nospam.invalid> wrote:

> steph...@mpeforth.com (Stephen Pelc) writes:
> > Just send me the changed files and I'll do the merge.

Thank you Stephen, Paul, I see the most value in this as being able to
generate test cases by the zillions since there is so much C code
available.

> Sure, though of course one normally does similar things with git (using
> "git diff").

Git is not that great unless you're submitting Linux kernel patches. There
are quite a few source control systems around, you know.

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message

news:mLednTYtI8m0eyLS...@supernews.com...

> On 5/25/12 9:17 AM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<era...@forth.com> wrote in message
> > news:Wu-dnalYGvM9XiLS...@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

[Coos Haak]

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

[Doug Hoffman]

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

[BruceMcF]

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

[Elizabeth D. Rather]

On 5/26/12 2:02 AM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<era...@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.

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message

news:3NKdnYNbSeRRrFzS...@supernews.com...

> On 5/26/12 2:02 AM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<era...@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

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> steph...@mpeforth.com (Stephen Pelc) writes:
>> Just send me the changed files and I'll do the merge.
> OK, I'll email them or post a tarball url in the next day or so.

The changed files are here:

http://nightsong.com/phr/forth/c2fpatch.zip

Note that I unpacked your archive with "unzip -L -a" which
converted the filenames to lowercase and removed CR's from
ends of lines (DOS to Unix conversion) before making those changes.

[Elizabeth D. Rather]

On 5/26/12 1:52 PM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<era...@forth.com> wrote in message
> news:3NKdnYNbSeRRrFzS...@supernews.com...
>> On 5/26/12 2:02 AM, Rod Pemberton wrote:
>>> "Elizabeth D. Rather"<era...@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.

[Andrew Haley]

Rod Pemberton <do_no...@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.

[Harry Vaderchi]

On Sat, 26 May 2012 20:41:00 +0100, Elizabeth D. Rather
<era...@forth.com> wrote:

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

I though it was an accepted (maybe reluctantly!) americanism

! is pling in UK coding circles, and, it seems, shriek in US.
hashbang seems a common enough Unix usage.

Of course, the US calls a hash (#) a pound, to confuse things further.

--
[dash dash space newline 4line sig]

Albi CNU

[Elizabeth D. Rather]

It's also referred to as a "number sign", which is why it was chosen for
the output number conversion words.

[Alex McDonald]

On May 27, 11:54 am, "Harry Vaderchi" <ad...@127.0.0.1> wrote:
> On Sat, 26 May 2012 20:41:00 +0100, Elizabeth D. Rather
>

> <erat...@forth.com> wrote:
> > 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.
>
> I though it was an accepted (maybe reluctantly!) americanism
>
> ! is pling in UK coding circles, and, it seems, shriek in US.

My kids inform me that pling is a derogatory term, referring to cheap
shiny jewelry or "plastic bling".

> hashbang seems a common enough Unix usage.

shebang.

[Peter Knaggs]

It more like:

man kompare

--
Peter Knaggs

[hwf...@gmail.com]

On Friday, May 25, 2012 1:30:07 PM UTC-7, Albert van der Horst wrote:
> In article <4fbfb7c5....@192.168.0.50>,
> Stephen Pelc <steph...@INVALID.mpeforth.com> wrote:
> >On Fri, 25 May 2012 14:33:49 +0200 (CEST), Nomen Nescio
> ><nob...@dizum.com> wrote:
> >
> >>> Just send me the changed files and I'll do the merge. One of the
> >>> peculiarities of MPE is that *all* code changes are reviewed by
> >>> human eyeballs and BeyondCompare *before* being let in.
> >>
> >>man diff
> >
> >Oh, come on - get some real tools! Eyeballs are great!
>
> What is he trying to imply? That it makes sense to run a diff or
> use BeyondCompare, then have nobody look at the results?
>
> >
> >Stephen
> >P.S. It's really hot here and I'm off to the garden for a
> >decent glass of wine. I may be some time ...
>
> It was over 30 degrees (303 K) last wednesday, here in the Netherlands.
>

Sounds comfy. It gets up to 50C where I live (Phoenix), but not very often. That used to shut down the airport, until the FAA updated their calibration tables to cover the range beyond 120F.

[Ed]

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.

[Elizabeth D. Rather]

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.

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message

news:8dKdncVFodLPXVzS...@supernews.com...

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

[Andrew Haley]

Rod Pemberton <do_no...@notemailntt.cmm> wrote:
> "Elizabeth D. Rather" <era...@forth.com> wrote in message
> news:8dKdncVFodLPXVzS...@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.