Re: acceptance of forth
- From: Elizabeth D Rather <erather@xxxxxxxxx>
- Date: Sat, 28 Nov 2009 22:27:47 -1000
Tinkerer Atlarge wrote:
Stephen Pelc <stephenXXX@xxxxxxxxxxxx> wrote:....
I'm one of those people who can only really learn a language by
having a job to do with it. I think it's a matter of focus.
Yes, without that, I find the incentive to grapple with a strange and
unfamiliar language simply isn't there. There is a large palette of
forth words to choose from. Initially, trying to winnow them down to a
small enough working set in order to set them in my mind without having
to look up their stack effects every time is the problem. With the
version of forth I was using, the documentation itself posed a similar
problem, being a cut'n'paste from various sources. As Elizabeth pointed
out in another post, Apple's version does not even comply wiith its
generic namesake and appears to have very little user documentation of
its own. (It has three interfaces, perhaps the client interface is
better serviced)
Indeed, you chose one of the most difficult paths for getting into Forth! You have done well to get so far. No useful documentation, no source, no one to talk to. You were very brave. In retrospect, you might have saved some time by learning on a friendlier system until you got the basics down, and then seeing how they apply in OF.
[ ... ]You have basically three choices as in any language:
1) test at the top
begin <test>
while
<action>
repeat
IMV the way that construct is often presented to forth beginners tends
to place too much emphasis on the test section. That can act as a red
herring which obscures the point you just made. Going by some text
descriptions I have read (I can't remember which ones) the test clause
can too easily be assumed to be the main purpose of the loop. You can do
that with C 'while' loops too of course, but their layout IMHO does a
better job of assigning the test clause its theoretical place outside
the body of the loop. At least it makes it easier to understand when
learning how to use it.
I have tried very hard to address this, mostly in Forth Application Techniques. I'd be most grateful for any suggestions as to how to improve my discussion of the loops in general.
2) test at the bottom
begin
<action>
<test>
until
Realizing its similarity to the "goto" loop was my breakthrough in
appreciating how simple 'begin:until' is beneath the surface.
3) counted
<limit> <start> do
<action>
loop
I suspect the best forth programmers are the ones who know how it fitsBecause Forth is extensible, understanding when things happen is
together under the hood. There is compile time and runtime and input
buffers all mixed in together. I expect a lot of newbies have no
rational basis for guessing which combinations of operations make sense
and which do not
very important for advanced Forth programming. You need to get
to the point where the basics feel natural first.
This broaches a subject which is difficult to put into words because it
is more a vague feeling than anything else. The feeling is that I was
being increasingly taken over and steered by forth into places I didn't
necessarily want to go.
Fascinating. Can you think of some examples?
In addition to their straight-forward nominal function, some forth words
also seem to possess a "role" or "purpose" within the forth "scheme of
things". That role is non-obvious and is never mentioned, but
experienced forth programmers are aware of it intuitively it seems, even
if they never have cause to view it in such terms.
That's very perceptive. Most of Forth works the way it does because it's used in the internal implementation of the system, and is *also* available to the application programmer.
One of my recurring frustrations when learning forth was repeatedly (and
I felt undeservedly) finding myself painted into a corner. The symptoms
were that the going kept getting unaccountably harder, the further I
proceeded along a certain path. It was like I had unwittingly taken a
wrong turn which I could only realize further down the track. The "wrong
turn" had no symptoms of its own. However, if I had made a mistake
anywhere, that is where it happened.
I will try to draw an analogy with something more concrete from the real
world. ...
A Forth example would be a lot more helpful than an analogy, here!
Back to forth. Let's start with the project-specific words you define
early in a project yourself. If your earlier ones turn out to be not
quite what they otherwise might have been (which at that point seemed
entirely a matter for your own judgment and discretion), they will still
perform the most immediate tasks you have for them. But, further down
the track, you try to coerce them against some seemingly innate
reluctance into doing things they can eventually be made to do, even if
not quite the way you would have preferred. What has happened is that
you are trying to employ them contrary to some originally conceived role
or purpose.
Chuck Moore used to write programs three times. The first time, he took a simple approach aiming to get the essence of the problem. Then he tried to accommodate all the special cases, options, and added facilities, and the program became a mess. Then he threw it all out and re-wrote the program from scratch, as he now fully understood it. Most of us have gone through most of those steps... but it's necessary to have the courage to do step three, rather than continue to try to muddle through. It usually saves time in the end.
Extrapolate that to the standard forth vocabulary. My suspicion is that
many common forth words do have an implicit 'role' within the forth
scheme of things which is "obvious" to those who have grown up with it,
but non-obvious and unexplained to anyone else unless how forth is
implemented is added to the start of their learning curve.
As I said above, most Forth words are used by the system at the lowest levels. That is their primary purpose, and why they work the way they do. This is one of the reasons that learning with OF is especially challenging, because although you can do SEE's to look at words, you don't really have any source. We supply the source with all our products. You can see lots of examples of how words are used.
I have tried to address much of this in my books, but would always appreciate any examples of something you find particularly opaque.
I am sure I could recollect plenty of examples of being steered off
course by seemingly role-conscious forth words just by going back over
the source code of my recent marathon. Jonah Thomas mentions one in his
separate followup. Let me know if you would like to see more.
Yes, I'd love that.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
.
- Follow-Ups:
- Re: acceptance of forth
- From: Dennis
- Re: acceptance of forth
- From: Anton Ertl
- Re: acceptance of forth
- References:
- continued fractions
- From: Hugh Aguilar
- Re: continued fractions
- From: Albert van der Horst
- Re: continued fractions
- From: Hugh Aguilar
- Re: continued fractions
- From: Coos Haak
- Re: continued fractions
- From: Hugh Aguilar
- Re: continued fractions
- From: Coos Haak
- Re: continued fractions
- From: Hugh Aguilar
- Re: continued fractions
- From: idknow
- Re: continued fractions
- From: Elizabeth D Rather
- acceptance of forth (was: Re: continued fractions)
- From: Uwe Kloß
- Re: acceptance of forth
- From: Tinkerer Atlarge
- Re: acceptance of forth
- From: Doug Hoffman
- Re: acceptance of forth
- From: Tinkerer Atlarge
- Re: acceptance of forth
- From: Stephen Pelc
- Re: acceptance of forth
- From: Tinkerer Atlarge
- continued fractions
- Prev by Date: Re: acceptance of forth
- Next by Date: Re: LC53 statistics
- Previous by thread: Re: acceptance of forth
- Next by thread: Re: acceptance of forth
- Index(es):
Relevant Pages
|