non destructive conditionals ?
Andreas Klimas
I have observed that many times I need the value
on TOS after comparing it (special while
iterating through pointers).
so, I'm about to use words like -if, or -while
which simply will not discard the TOS.
what do you think ?
thanks,
--
Andreas Klimas
Gary Chanson
"Andreas Klimas" <kli...@klimas-consulting.com> wrote in message
news:3E60BE23...@klimas-consulting.com...
> hello,
>
> I have observed that many times I need the value
> on TOS after comparing it (special while
> iterating through pointers).
>
> so, I'm about to use words like -if, or -while
> which simply will not discard the TOS.
>
>
> what do you think ?
I think it's not worth it to create functions which don't consume their
arguments. -IF would (I assume) be equivalent to DUP IF so it's really just
an optimization.
--
-Gary Chanson (MS MVP for Windows SDK)
-Software Consultant (Embedded systems and Real Time Controls)
-gcha...@mvps.org
-War is the last resort of the incompetent.
andr...@littlepinkcloud.invalid
> hello,
> I have observed that many times I need the value
> on TOS after comparing it (special while
> iterating through pointers).
> so, I'm about to use words like -if, or -while
> which simply will not discard the TOS.
> what do you think ?
What you're talking about is, I think, something equivalent to ?DUP IF.
This idea has come up before, and I think there's a lot to commend it.
However, I don't know if it has much extra notational clarity, and may
optimizing compilers handle this phrase anyway.
So, why do you want this? Efficency or better notation?
If it's just efficiency, you can make IF swallow a preceding ?DUP
so the compiler would do this automatically.
This would work on some threaded code systems:
: -?IF DUP HERE - IF
HERE CELL- @ ( ?? CELL-)
['] ?DUP = IF -1 CELLS ALLOT COMPILE -if EXIT THEN
THEN
COMPILE if ;
: IF -?IF HERE 0 , ; IMMEDIATE
Andrew.
Jeff Fox
>
> I have observed that many times I need the value
> on TOS after comparing it (special while
> iterating through pointers).
>
> so, I'm about to use words like -if, or -while
> which simply will not discard the TOS.
>
>
> what do you think ?
I think you are silly to ask such a question in c.l.f.
People here will not understand your logic. I would
say that I have the most experience with this. Second
might be Chuck Moore since he started using them back
just past the midpoint in Forth's history.
As he has said non-destructive conditionals save the
need to DUP before but often require an extra DROP
(or two) so regarding code size and clarity it is
a wash. There is no advantage in this regard to
this practice or to traditional practice. But
following traditions and standards is important
to certain people or in certain situations.
One reason for non-destructive conditionals is, as
Chuck says, hardware prefers to work this way. The
other reason is that it is not as wasteful as
DUPing something just to DROP it. People who have
no concerns about waste, or who prefer it for
whatever reasons, are not likely to understand
this. But it is very clear from Chuck's chain
of reasoning.
Chuck said that his MuP21 design was quite sufficient
for good Forth programming but the style of Forth
that it requires involves careful management of
resources. If you have only six cells in the parameter
stack it does not make much sense to let IF waste one
of them.
It is definately not equivalent to DUP IF although that
will be the first reaction of people unfamiliar with the
concept. It is most definately NOT the equivalent of
?DUP IF which is just a bad idea in the first place.
In the eleven year old tradition of MachineForth the
IF primitive is a non-destructive conditional that
compiles an opcode to branch if the TOS has no bits set.
The -IF primitive is a non-destructive conditional that
compiles an opcode to branch if the most significant bit
of T is not set. The real advantage of this is that it
obsoletes a great number of tradition Forth words that
test then leave a flag for other conditionals. It results
in less stack use, fewer needed words, and shorter code.
It is also very handy in bit-threaded Forth implementations.
The dash is meant to imply sign or carry related use.
I definately use -IF more often than IF.
Best wishes,
Jeff Fox
Andreas Klimas
>
> "Andreas Klimas" <kli...@klimas-consulting.com> wrote in message
> news:3E60BE23...@klimas-consulting.com...
> > hello,
> >
> > I have observed that many times I need the value
> > on TOS after comparing it (special while
> > iterating through pointers).
> >
> > so, I'm about to use words like -if, or -while
> > which simply will not discard the TOS.
> >
> >
> > what do you think ?
>
> I think it's not worth it to create functions which don't consume their
> arguments.
because of convention ?
> -IF would (I assume) be equivalent to DUP IF so it's really just
> an optimization.
yes, I see, thank you.
--
Andreas Klimas
Andreas Klimas
>
> Andreas Klimas <kli...@klimas-consulting.com> wrote:
> > hello,
>
> > I have observed that many times I need the value
> > on TOS after comparing it (special while
> > iterating through pointers).
>
> > so, I'm about to use words like -if, or -while
> > which simply will not discard the TOS.
>
> > what do you think ?
>
> What you're talking about is, I think, something equivalent to ?DUP IF.
> This idea has come up before, and I think there's a lot to commend it.
> However, I don't know if it has much extra notational clarity, and may
> optimizing compilers handle this phrase anyway.
>
> So, why do you want this? Efficency or better notation?
efficiency
--
Andreas Klimas
Coos Haak
wrote:
>It is definately not equivalent to DUP IF although that
>will be the first reaction of people unfamiliar with the
>concept. It is most definately NOT the equivalent of
>?DUP IF which is just a bad idea in the first place.
What else of these two would it be?
Can you give us a stack diagram?
Coos
Jeff Fox
> What else of these two would it be?
X is not A and X is not B. X is not A or B. Of
the two options incorrectly suggested, A and B,
neither is X. In the set of A or B there is nothing
else except the null set. Your question is nonsense.
> Can you give us a stack diagram?
The idea that a stack diagram would help shows
a problem with stack diagrams that I have tried
to illucidate in c.l.f before with little if any
success. A stack diagram would make it look
like DUP IF which is definately not the non-
destructive IF that Chuck started using at
about the midpoint in Forth history and that
I was talking about.
I thought I had explained it, but I forget just
how hard it is for people exposed to ANS Forth
to get ideas about Forth that are not from
common practice in the eighties.
Think of a stack rather than an array.
(stack: a finite last-in first-out memory structure)
(array: a finite indexed data structure in memory)
If you are still confused try to realize that
both DUP and a traditional IF are destructive.
Then read my previous post in this thread again
if still confused.
Best wishes,
Jeff Fox
Gary Chanson
> >
> > I think it's not worth it to create functions which don't consume
their
> > arguments.
>
> because of convention ?
No, because it's a lot easier to keep track of inputs and outputs of the
function and of what is on the stack.
Michael L.Gassanenko
such non-standard IF. But I do not remember which name it was
and what stack effect it had.
IIRC it was somehow related to colorforth.
andr...@littlepinkcloud.invalid
> Andreas Klimas <kli...@klimas-consulting.com> wrote in message news:<3E60BE23...@klimas-consulting.com>...
>> hello,
>>
>> I have observed that many times I need the value
>> on TOS after comparing it (special while
>> iterating through pointers).
>>
>> so, I'm about to use words like -if, or -while
>> which simply will not discard the TOS.
>>
>>
>> what do you think ?
> It is definately not equivalent to DUP IF although that
> will be the first reaction of people unfamiliar with the
> concept. It is most definately NOT the equivalent of
> ?DUP IF which is just a bad idea in the first place.
So what it is equiavalent to? DUP IF is bad because you have endless
IF DROPs.
> In the eleven year old tradition of MachineForth the
> IF primitive is a non-destructive conditional that
> compiles an opcode to branch if the TOS has no bits set.
> The -IF primitive is a non-destructive conditional that
> compiles an opcode to branch if the most significant bit
> of T is not set.
DUP 0< IF ?
Andrew.
Andreas Klimas
>
> "Andreas Klimas" <kli...@klimas-consulting.com> wrote in message
> news:3E628EBC...@klimas-consulting.com...
> > >
> > > I think it's not worth it to create functions which don't consume
> their
> > > arguments.
> >
> > because of convention ?
>
> No, because it's a lot easier to keep track of inputs and outputs of the
> function and of what is on the stack.
well, I don't talk about every function, I talk
about one or two cases where it seems to be better
not dropping the TOS.
dump for example. I think it's more convenient
(at least in the way I'm working with) to
left the next to last address on stack and to
put the number of bytes in a variable. so
I can use dump repetitive and doing any things
between.
the question of optimization is something which
could or could not happen. but why should I
left obvious things for an another layer (optimizer) ?
I can't agree with your argument because
I have to know which input and output parameters
are needed anyway.
--
Andreas Klimas
John Doty
<kli...@klimas-consulting.com> wrote:
> I have observed that many times I need the value on TOS after comparing
> it (special while iterating through pointers).
>
> so, I'm about to use words like -if, or -while which simply will not
> discard the TOS.
Back in the late 70's I used/programmed an editor ("Translex") whose "macro
language" was sort of a cross between TECO and Forth (one of its authors
had studied Forth). Instead of testing the TOS, there was a separate
"fail flag", not on the stack, for conditionals to check.
In the Translex context this made good sense. The language was
specialized for editing. Many primitives could "fail" (can't move the
cursor to the right at the end of the line), but often it made sense to
ignore the failure. With a separate flag no extra stack manipulation was
required either to check the flag or ignore it.
This worked very well in Translex, but I'm not convinced it would make
sense in a general purpose Forth.
--
| John Doty "You can't confuse me, that's my job."
| Home: j...@w-d.org
| Work: j...@space.mit.edu
Jeff Fox
I did say that it was probably silly to ask that kind of
question in c.l.f. and maybe it was silly of me to
answer it. As I expected people would edit out the
answer and repeat the question. I have seen it for a
dozen years, but more likely it has been going on for
thirty years.
> > It is definately not equivalent to DUP IF although that
> > will be the first reaction of people unfamiliar with the
> > concept.
>
> So what it is equiavalent to?
Let me try a third time.
A non-destructive IF does not destroy any stack items.
Not one like a conventional IF and not two like DUP IF.
I used MuP21 as an example because it first appeared
there in 1992. P21 has a real parameter stack and
a real return stack. These are stacks, not arrays
in addressable memory. But like addressable arrays
in memory they are finite. I suppose the problem is
that certain implications of the ANS Forth wordset,
like DEPTH and PICK leave people thinking that Forth
is a language which is designed to manipulate a
more or less infinite array in addressable memory
even though the standard does not explicitly state
this. But try to picture a stack.
DUP ( n -- n n )
What does that tell us? It tells you that DUP is going
to use another cell on the stack. There is one more item
on the stack. There is one less cell available on the
stack for future use than there was before. Before-after
style stack diagrams don't show what is really happening.
: X ( -- ) DUP DROP ;
What does that tell us? It tells us that the stack before
X and after X are the same. In fact they are not. They
are, more or less, if you are thinking of an array in memory
because the stack pointer will be at the same location after
X as it was before X.
But in fact there is no mention of a stack pointer even in
ANS Forth. That is because a stack pointer is an array
index mechanism.
Please don't say, but an optimizing compiler will ... That
is not the issue. Please don't say that a smart compiler
optimizing an array in memory and caching temporaries in
registers and optimize away bothersome stack use. That
also misses the entire issue.
The issue is that the DUP uses up one more stack cell. If the
hardware has a complicated stack in memory error detection
mechanism the DUP might cause an error trap. It might
cause an error because it is using a stack cell that might
not be available.
The stack diagram masks the internals of the word, where
the DUP is using up an extra stack cell. Yes, before and
after DUP DROP a pointer would be in the same location
but inside of the word the DUP is using up a stack cell.
If you are thinking of an array in memory and you think
of it as infinitely large this is not an issue, but
if you are thinking of a stack it should be a concern.
Remember that finite last-in first-out stack is just
that.
In the example that I sited, MuP21, where the non-destructive
conditionals first appeared DUP uses up one sixth of the stack.
Therefore if using a conventional IF which DROPs a flag
DUP IF uses one third of the stack and wastes one sixth of the
stack. This is not visible using a conventional stack diagram
which only shows the effect OUTSIDE of the definition, not
inside of the definition.
: X ( -- ) OVER OVER DUP DUP DROP DROP DROP DROP ;
appears to have no stack effect while in a real stack,
a finite last-in first-out buffer, it is using 6 stack
cells internally. If you were actually using an array
and you didn't have six cells available one would need
a complex error handling mechanism in hardware and
software. If you are using a real stack, a LIFO, then
the word overwrites four stack cells. Although the
classic stack diagram only shows before and after
and not internal stack effects.
The classic Forth phrase DUP IF has the same stack
diagram as DUP DROP. In order to DROP a stack cell
with DROP or a destructive IF an item is DUPed first.
It is therefore using up two stack cells instead of
one. DUP ( n -- n n ) means that you are using up
two stack cells instead of one.
DUP IF uses up two stack cells. A non-destructive
IF doesn't. It does not contain a DUP. It is not
the equivalent of DUP IF (unless one is only picturing
an infinite array in memory instead of a stack.)
It is definately NOT the equivalent of ?DUP IF.
It is definately not the equivalent of the long
ANS definitions that were posted as being the
equivalent of the non-destructive IF that Chuck
has used for almost half the history of Forth.
Chuck has explained this many many times in the
last dozen years. But like most of what he says
it seems to go right over people's heads. I think
all their stack cells are already filled with
X3J14. They may try to map these simple Forth
ideas to very complex Forths on very complex
chips designed to accomodate C. (and please,
no one complained when John Doty made the obvious
statement that C influenced those designs.)
But the ideas of real stacks don't map very well
to ANS as it leans heavily towards mixing up the
concept of stacks and arrays, just like in C
where indexed stack-frames are usually the result.
With people saying that their goal is to optimize
away actual stack access it is natural that
people new to ANS Forth would think that the
best way to optimize away the stack is just to
get rid of it in source and use global or
local variables.
> DUP IF is bad because you have endless
> IF DROPs.
Endless? ;-) No it is bad because it is wasteful
of the parameter stack. It is slower than a non-
destructive IF. It is bigger than a non-destructive
IF. It is more complex and harder to understand.
But the main thing, it is more wasteful of the stack.
You also edited out my previous comment on this
before making that assertion. As I said, it was
silly to start such a thread in c.l.f because
of this sort of easily predictable thing.
> DUP 0< IF ?
Yikes! You also edited out the section explaining
the advantages of the traditional (in MachineForth)
-IF such as how it obsoletes things like that. Also
that is longer, slower, and consumes more stack cells.
Trying to map simple things to ANS concepts can sure
them them complicated or just incomprehensible.
I hope this stuck on my third try (in this thread.)
Best wishes,
Jeff Fox
Michael L.Gassanenko
>
> andr...@littlepinkcloud.invalid wrote in message news:<v66dqbo...@news.supernews.com>...
>
> answer and repeat the question.
You want to say that you have an execution enviroment with
Restrictions on Functionality (a.k.a. RoF's,
see http://forth.sourceforge.net/Standard+/rof/index.html )
Namely, the data stack is 6 cells shallow.
And DUP DROP requires a significant amount of resources.
So the motivation behind non-destructive IF is shallow stack.
(Ok, shallow, but backed by philosofy that makes it enough deep.)
---
Ok, if that system had 1K cells on the data stack, what would you say
it is almost eqivalent to, "DUP IF" or "?DUP IF" ?
---
It is interesting that RoF seems to be the right term for describing
what happens on your platform.
I defined RoF for standard environments, but here we have
a non-standard environment with RoF's.
------
[snip the answer]
Maybe you'll find the following [stack?] notation more adequate:
> : X ( -- ) DUP DROP ;
>
X ( --1-- )
> : X ( -- ) OVER OVER DUP DUP DROP DROP DROP DROP ;
X ( --6-- )
: X ; ( --0-- )
----
DUP IF ( x --1-- x )
?DUP IF ( 0 --0-- ) ( x --1-- x )
andr...@littlepinkcloud.invalid
Maybe, and maybe not.
Where does ANS do that? PICK and ROLL?
> With people saying that their goal is to optimize
> away actual stack access it is natural that
> people new to ANS Forth would think that the
> best way to optimize away the stack is just to
> get rid of it in source and use global or
> local variables.
>> DUP IF is bad because you have endless
>> IF DROPs.
> Endless? ;-) No it is bad because it is wasteful
> of the parameter stack. It is slower than a non-
> destructive IF.
Sorry, what is "it"? Are you saying that with a nondestructive IF you
do not need IF DROP when you no longer care about the condition?
Surely you do.
The choice is destructive or not, and if you don't destroy implicitly
you'll sometimes have to destroy explicitly.
> It is bigger than a non-destructive IF. It is more complex and
> harder to understand. But the main thing, it is more wasteful of
> the stack.
> You also edited out my previous comment on this
> before making that assertion. As I said, it was
> silly to start such a thread in c.l.f because
> of this sort of easily predictable thing.
I try to keep postings short. I view posting without trimming as a
Great Evil. If I trim something inappropriately that's because I
didn't see its relevance.
All you seem to be saying is that the machine Forth primitive has the
same effect as some combination of words in trad Forth, but consumes
fewer resources internally. For example, -IF has the same external
effect as DUP IF but it doesn't use an extra cell on the stack while
doing its work.
Is that right now?
>> DUP 0< IF ?
> Yikes! You also edited out the section explaining
> the advantages of the traditional (in MachineForth)
> -IF such as how it obsoletes things like that. Also
> that is longer, slower, and consumes more stack cells.
Look, all I'm asking is "what does this word do?"
DUP 0< IF is the external view of an action. It does not say ANYTHING
about how the work was done.
DUP 0< IF does not imply that two stack cells are used. Maybe they
are, maybe not.
DUP 0< IF is a phrase that looks at TOS and branches if the top bit is
set. DUP 0< IF does not affect TOS in any way.
DUP 0< IF can be implemented as a single primitive in hardware that
does this job or it can be implemented as three separate instructions
or indeed three separate primitives. Or many other combinations.
> Trying to map simple things to ANS concepts can sure
> them them complicated or just incomprehensible.
> I hope this stuck on my third try (in this thread.)
Your objection seems to be based on a misunderstanding.
There is no rule in Forth implementation that DUP IF actually
duplicates the top of the stack before doing the test. Maybe it does,
and maybe it doesn't. And no, this doesn't miss the entire issue.
All I ever wanted to discover was the stack effect of -IF.
Andrew.
Gary Chanson
>
> well, I don't talk about every function, I talk
> about one or two cases where it seems to be better
> not dropping the TOS.
I have a few functions where it seemed to make sense to not consume input
parameters. They are typically functions which supply parameters for other
functions. One example is the LENGTH which returns the length of a null
terminated string. It's meant to be analogous to COUNT so it doesn't consume
the address pointer. Some day, I'll want only the length and find myself
writing "LENGTH NIP" (not very pretty). Even though this does make sense,
it's something which I have to be aware of when I use this function.
I've also been known on rare occasions to factor an application function,
creating a sub-function which doesn't consume its inputs.
In every case though, these functions are what we might call adjectives
which are used in the middle of a phrase to modify the parameters feed to what
we might call a verb which consumes them. What you're suggesting is to create
a verb which doesn't consume its inputs, not for the purpose of clarity, but
for the purpose of optimization.
If you want optimization, put it under the hood. Don't obfuscate your
code!
andr...@littlepinkcloud.invalid
> If you want optimization, put it under the hood. Don't obfuscate your
> code!
I really try not to write "me too" response, but in this case I'll
make an exception!
YES!!
Andrew.
Andreas Klimas
>
> andr...@littlepinkcloud.invalid wrote in message news:<v66dqbo...@news.supernews.com>...
>
> I did say that it was probably silly to ask that kind of
> question in c.l.f. and maybe it was silly of me to
> answer it.
not really, where else should one ask/answer such
questions ? I got your point after your first
post .
I also got Andrew's and Gery's point.
I'm appreciate for every answer.
Andreas
Julian V. Noble
Once when I wrote a fp library for the 8086/8087 assembler in a 16-bit
Forth I found it saved time sometimes to define things like F0>NP ;
NP meant "no pop" (everything was being done on the 8087 stack).
I can't see why an optimizing Forth would need no-pop or no-drop tests
or conditionals, since surely the drop would be optimized away. You
might want to have them occasionally in small, embedded programs running
on small cpu's.
--
Julian V. Noble
Professor of Physics
j...@virginia.edu
"Science knows only one commandment: contribute to science."
-- Bertolt Brecht, "Galileo".
jmdrake
> Chuck has explained this many many times in the
> last dozen years. But like most of what he says
> it seems to go right over people's heads. I think
> all their stack cells are already filled with
> X3J14. They may try to map these simple Forth
> ideas to very complex Forths on very complex
> chips designed to accomodate C. (and please,
> no one complained when John Doty made the obvious
> statement that C influenced those designs.)
Perhaps because people were too busy complaining
about his other assertions like Forth is inherently
unreadable (it isn't) or that C programs provides
"cues" to their source trees (they don't) or that
his example of Forth versus C code proved something
(it didn't because the code wasn't even equivilent)?
Anyway in the context of the destructive versus
non-destructive IF, wasn't it Chuck that first
came up with the destructive IF? And wasn't it on
hardware that PREDATED C? Regardless the feature
that is at question (stacks in memory versus
hardware stacks) certainly predates the dominance
of C. But that's a non-issue. Whether the machine
feature was originally designed for C or for
FORTRAN the effect is still the same.
Anyway I understand your point (I think). In the
standard IF word there is an implicit DROP
statement. When you have to use DUP IF you're
putting something on the stack just to have it
thrown away. Sure it can get optimized out by
the compiler, but each optimization that you put
off to the compiler causes it to become
unecessarily complex. And considering that some
Forth programs make use of the compiler at run
time translates this into extra run time cost.
Chuck might never have considered this if he
hadn't started designing his own hardware.
But this sort of change would have broken much
existing code. An alternative would be to
introduce new non destructive conditional
words so that people could migrate to the more
optimal approach while not completely breaking
old code.
Regards,
John M. Drake
John Doty
<jmdra...@yahoo.com> wrote:
> f...@ultratechnology.com (Jeff Fox) wrote in message
> news:<4fbeeb5a.03030...@posting.google.com>...
>> Chuck has explained this many many times in the last dozen years. But
>> like most of what he says it seems to go right over people's heads. I
>> think all their stack cells are already filled with X3J14. They may
>> try to map these simple Forth ideas to very complex Forths on very
>> complex chips designed to accomodate C. (and please, no one complained
>> when John Doty made the obvious statement that C influenced those
>> designs.)
>
> Perhaps because people were too busy complaining about his other
> assertions like Forth is inherently unreadable (it isn't)
You didn't pay attention to what I said. I can read Forth just fine (at
least the dialect I'm familiar with). The thing that's hard is coaxing
someone whose cognitive style doesn't match the True Forth Path to
continue attempting to read it after they've gotten themselves lost. C is
somewhat more forgiving here, as there are more ways into the logic of the
code. There are no universal solutions, and for some C is obscure while
Forth is clear (and some just like FORTRAN).
> or that C
> programs provides "cues" to their source trees (they don't).
C provides cues about the nature of the network of connections between
parts of the program (your "source tree" only covers a subset of these
connections). This helps readers focus on the sort of details that their
personal cognitive styles find illuminating. If execution trajectory
through the tree is your way of unscrewing the inscrutable, Forth is as
readable as anything, but that's not the only way to comprehend code.
> Anyway in the context of the destructive versus non-destructive IF,
> wasn't it Chuck that first came up with the destructive IF? And wasn't
> it on hardware that PREDATED C?
Isn't Chuck entitled to change his mind?
The stack frame in memory concept goes back to Algol 60 (at least), a
direct ancestor of C. It certainly predates Forth. It certainly did
influence hardware design.
Albert van der Horst
If you implemented such an editor in Forth you would use CATCH
THROW for that.
E.g. in ee all macro's are three letter words, with an optional
parameter.
((("" cle ))) cdo
((( ))) does looping. cle is cursor left and the empty argument
means infinite i.e. until an error occurs.
This macro would place the cursor at the start of the line
than one down.
))) would contain a catch, such that cdo (cursor down) is executed
too.
((("" cri )))
on the other hand would make your cursor land somewhere in
China. (At least "far east".)
(Actually ee has a line limit of 5001 . If you execute cri
at that position, you hear a beep and the status line displays
`` Have you tried walking to China too? ''
No kidding. I just tried it, because it is the editor I use
for everything, including writing this post. This message is there
since the beginning of the 80's. )
Read more about ee, and a project to rewrite it in Forth
on the page below.
>| John Doty "You can't confuse me, that's my job."
Groetjes Albert
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Q.: Where is Bin? A.: With his ma. Q.: That makes the Saudi's
terrorists, then? A.: No, George already owns their oil.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
jmdrake
> > programs provides "cues" to their source trees (they don't).
>
> C provides cues about the nature of the network of connections between
> parts of the program (your "source tree" only covers a subset of these
> connections). This helps readers focus on the sort of details that their
> personal cognitive styles find illuminating. If execution trajectory
> through the tree is your way of unscrewing the inscrutable, Forth is as
> readable as anything, but that's not the only way to comprehend code.
You were talking about a reviewer reading source code right? Finding
definitions in source code isn't hard if everthing's in the same file
regardless of whether or not you're talking C or Forth. Finding
definitions across multiple source files is what is difficult.
Java, Oberon, Modula ect have language constructs to help with
this. C and Forth don't.
> > Anyway in the context of the destructive versus non-destructive IF,
> > wasn't it Chuck that first came up with the destructive IF? And wasn't
> > it on hardware that PREDATED C?
>
> Isn't Chuck entitled to change his mind?
Where on earth did you get the strange idea that I think Chuck
doesn't have a right to change his mind? My point is that the
destructive IF was not invented by people trying to be compatible
with C (unless that was Chuck's goal).
> The stack frame in memory concept goes back to Algol 60 (at least), a
> direct ancestor of C. It certainly predates Forth. It certainly did
> influence hardware design.
Yeah. And your point is? My point is that this hardware feature
pre-dates C and you've just verified me. Thanks.
Regards,
John M. Drake
Len Zettel
"Darin Johnson" <da...@usa.net> wrote in message
news:cu165r0...@nokia.com...
> andr...@littlepinkcloud.invalid writes:
>
> > All I ever wanted to discover was the stack effect of -IF.
>
>
Legendary sixth grade book rpeort:
"This book tells me more than I want to know about rats" :-)
-LenZ-
> --
> Darin Johnson
> Where am I? In the village... What do you want? Information...
John Doty
jmdra...@yahoo.com wrote:
> You were talking about a reviewer reading source code right? Finding
> definitions in source code isn't hard if everthing's in the same file
> regardless of whether or not you're talking C or Forth. Finding
> definitions across multiple source files is what is difficult. Java,
> Oberon, Modula ect have language constructs to help with this. C and
> Forth don't.
*Finding* the definitions is always the easy part. Determining how they
relate is harder. Figuring out which ones illuminate the others is still
harder. Different people have different mental strategies for these
things.
Why do *you* think it's easier to teach Forth than C, but often harder to
get impatient people to read code in Forth than in C? It's a real problem.
andr...@littlepinkcloud.invalid
> You were talking about a reviewer reading source code right? Finding
> definitions in source code isn't hard if everthing's in the same file
> regardless of whether or not you're talking C or Forth. Finding
> definitions across multiple source files is what is difficult.
> Java, Oberon, Modula ect have language constructs to help with
> this. C and Forth don't.
A browser tools which allows one quickly to find definitions across
multiple source files is a basic tool. At its simplest, every Forth
system should have LOCATE or something equivalent that will instantly
bring up a definition and its accompanying documentation.
This is a quality of implementation issue.
Andrew.
Andreas Kochenburger
>You were talking about a reviewer reading source code right? Finding
>definitions in source code isn't hard if everthing's in the same file
>regardless of whether or not you're talking C or Forth. Finding
>definitions across multiple source files is what is difficult.
>Java, Oberon, Modula ect have language constructs to help with
>this. C and Forth don't.
That's NOT a language issue, but a feature of the development
environment.
Just for fun: start Win32Forth, type in VIEW WORDS, click the mouse on
any interesting word, hyperlink back with F10 ...
That's good, no?
Andreas
-------
MinForth: http://www.minforth.net.ms
John Doty
>> The stack frame in memory concept goes back to Algol 60 (at least), a
>> direct ancestor of C. It certainly predates Forth. It certainly did
>> influence hardware design.
>
> Yeah. And your point is? My point is that this hardware feature
> pre-dates C and you've just verified me. Thanks.
It is clear that when Jeff refers to "C", he means "the universe of
practices involving Algol-derived languages on CTSS-derived operating
systems".
Jeff Fox
>
> It is clear that when Jeff refers to "C", he means "the universe of
> practices involving Algol-derived languages on CTSS-derived operating
> systems".
Yes. That is what today's popular C based Operating Systems are
intended to support. This is quite different than your typical
Forth OS which is designed to support Forth.
I am glad that it was clear to you. I was not clear to many
other people. But some say that anything that I write is
nonsense and of course they always interpret it that way.
Best wishes,
Jeff Fox
Albert van der Horst
jmdrake <jmdra...@yahoo.com> wrote:
>"John Doty" <j...@space.mit.edu> wrote in message news:<3e650864$0$3926$b45e...@senator-bedfellow.mit.edu>...
>> In article <e20a4a47.03030...@posting.google.com>, "jmdrake"
>
>> > or that C
>> > programs provides "cues" to their source trees (they don't).
>>
>> C provides cues about the nature of the network of connections between
>> parts of the program (your "source tree" only covers a subset of these
>> connections). This helps readers focus on the sort of details that their
>> personal cognitive styles find illuminating. If execution trajectory
>> through the tree is your way of unscrewing the inscrutable, Forth is as
>> readable as anything, but that's not the only way to comprehend code.
>
>You were talking about a reviewer reading source code right? Finding
>definitions in source code isn't hard if everthing's in the same file
>regardless of whether or not you're talking C or Forth. Finding
>definitions across multiple source files is what is difficult.
>Java, Oberon, Modula ect have language constructs to help with
>this. C and Forth don't.
Regarding C this isn't fair. There is a tool that collects names
in a file. (ctags). Once I had configured my editor
with a tags function key. Hitting the function key if the cursor
was at a keyword, I got into the include file or whatever
where it was defined at the right place.
vi and emacs have similar things as standard.
Regarding Forth this isn't fair either.
Many systems have LOCATE . This may not count as a language construct,
but it is practical. Some systems (e.g. ciforth) have support for
this by having a field in the header to point to source.
Talking about C++. Making so called "class browsers" seem to be
a hobby.
So, not surprisingly, there seem to be a great many tools to
study source.
Why this must be a language construct is not clear to me.
>John M. Drake
John Doty
alb...@spenarnc.xs4all.nl wrote:
> So, not surprisingly, there seem to be a great many tools to study
> source. Why this must be a language construct is not clear to me.
Collecting the data is not the problem. Interpreting it is.
Anton Ertl
>You were talking about a reviewer reading source code right? Finding
>definitions in source code isn't hard if everthing's in the same file
>regardless of whether or not you're talking C or Forth. Finding
>definitions across multiple source files is what is difficult.
>Java, Oberon, Modula ect have language constructs to help with
>this. C and Forth don't.
How, then do C and Forth compilers do it? Black magic?
Actually, you can make a point that in C you would need the compiler
and linker command lines to find them all.
For Forth, the user could load the stuff piecewise on the command
line, but typically there is one central load block or a central file
that defines everything itself or that loads all other files.
Anyway, as others have pointed out, finding definitions in C works
nicely with etags or ctags. etags also supports Java, but not
Modula-2 or Oberon (nor Forth).
Gforth has a tool etags.fs that actually hooks into the Gforth
compiler to see exactly the definitions the Forth compiler sees
(including those from your own defining words), and you need to
specify only the central load file; in contrast, etags just uses some
heuristics based on lexical characteristics, and you have to specify
all files with definitions that you suspect. The disadvantage of the
etags.fs method is that you have to get the program to compile in
order to get TAGS.
- 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
jonah thomas
> Why do *you* think it's easier to teach Forth than C, but often harder to
> get impatient people to read code in Forth than in C? It's a real problem.
Because Forth code is denser.
If you can do something in 30 lines of Forth that would take 120 lines
of C, and you've accomplished basicly the same thing, the meaning is
packed 4 times as tight in the Forth code. So it's harder to read.
The various bits of boilerplate timewasters in the C code give people a
chance to relax. They can think about what it all means while they skim
over it. Without those things in Forth, you have to pace yourself.
Read too fast and you might blink and miss something vitally important.
Pacing is important. I have to make myself slow down when I read Forth
code because it's easy to read too fast. C code is easier to read
because it slows you down without you having to think about it.
jmdrake
> Why do *you* think it's easier to teach Forth than C, but often harder to
> get impatient people to read code in Forth than in C? It's a real problem.
I don't think it's easier to teach Forth than C. Why do *you* think
that *I* think that? Sure it's easier to teach C to people already
familair with another programming language since it's similair to
other programming languages but that's an entirely different issue.
Regards,
John M. Drake
John Doty
jmdra...@yahoo.com wrote:
I will rephrase:
It is my experience that it is easier to teach Forth than C. At the same
time, it is my experience that readers of Forth code give up in confusion
much more frequently than readers of C code. Why?
The latter is, for me, a huge disadvantage of Forth, because it has in
past projects meant that I've been the one who wound up maintaining and
extending all of the code, regardless of who wrote it.
With newer Forths looking much more complex (the LSE ROM had 50 words of
interest to application programmers), I worry that the reading problem is
likely to be worse.
Andreas Klimas
>
> In article <e20a4a47.03031...@posting.google.com>,
> jmdra...@yahoo.com wrote:
>
> > "John Doty" <j...@w-d.org> wrote in message
> > news:<7x6dndH37c5...@speakeasy.net>...
> >
> >> Why do *you* think it's easier to teach Forth than C, but often harder
> >> to get impatient people to read code in Forth than in C? It's a real
> >> problem.
> >
> > I don't think it's easier to teach Forth than C. Why do *you* think
> > that *I* think that? Sure it's easier to teach C to people already
> > familair with another programming language since it's similair to other
> > programming languages but that's an entirely different issue.
>
> I will rephrase:
>
> It is my experience that it is easier to teach Forth than C. At the same
> time, it is my experience that readers of Forth code give up in confusion
> much more frequently than readers of C code. Why?
because one has to rememeber the stack effekt
and keept track on what is on the stack.
in 15 years I even have to look for parameters
of fread. whereas in Forth I spent more energy
in remembering the stack effect because it is
critical.
so I think more brain power is needed for reading
(and writing) Forth code. on the other side, if
one has become familiar with brain stack tracking
and in remembering of stack effects, Forth become
a mega simple, mega effective tool.
>
> The latter is, for me, a huge disadvantage of Forth, because it has in
> past projects meant that I've been the one who wound up maintaining and
> extending all of the code, regardless of who wrote it.
>
> With newer Forths looking much more complex (the LSE ROM had 50 words of
> interest to application programmers), I worry that the reading problem is
> likely to be worse.
where are the people who likes to activate their brain ?
--
Andreas Klimas
Jeff Fox
There is no question that it is easier to teach Forth than
C. Some of the presentations at SVFIG about using different
computer languages for teaching high school students make
this very obvious.
But there are complications. C is not an oral tradition,
there are hundreds of textbooks to assist the teacher and
learner. Forth is at a great disadvantage this way as it
has primarily been an oral tradition where one learns the
language from a more senior mentor.
Like some other arts the distance down the chain from the
source makes a big difference. Those who learned from the
creator of Forth got excellent tutoring. Those who learned
from them got goodd tutoring. Third, fourth, fifth, and
sixth handed accounts each lost some of the original teaching
and replaced it with more of the personal color of the
teachers along the way. It is like the old children's game
telephone.
If your teacher in an art is a green belt it is harder to learn
than if your teacher is a black belt, it may be impossible. If
your teacher is a master teacher instead of just a black belt
chances are that it will be much easier to learn.
Also there is a rule that students will always learn the bad
habits of their teacher before they learn the good habits. So
students learning from beginners often are unable to make much
progress. We know that this is how Forth got most of its
reputation in the larger computer community. Some black belt
C programmer heard some newbie Forth programmer talking about
Forth like they had had some religous experience or something
and they dismissed Forth as some crackpot thing. Then they
describe Forth to others this way and before long most people
are predisposed to try to see Forth as some crackpot thing
or they try to map Forth to ideas they already have and Forth
just looks completely backwards to them.
> but often harder to
> get impatient people to read code in Forth than in C?
> It's a real problem.
J. Thomas has explained that Forth doesn't have to automatically
slow down a person to give them time to think slowly the way C does.
And impatient people don't make very good programmers. Not everyone
should be a programmer after all.
I recall Richard Stallman saying that we need to encourage some
children to be plumbers and some to be programmers, that if we
try to make them all programmers that our plumbing and our
computers will get all clogged up, and with the same stuff. ;-)
Best wishes,
Jeff Fox
John Doty
<kli...@klimas-consulting.com> wrote:
>> It is my experience that it is easier to teach Forth than C. At the
>> same time, it is my experience that readers of Forth code give up in
>> confusion much more frequently than readers of C code. Why?
>
> because one has to rememeber the stack effekt and keept track on what is
> on the stack.
>
> in 15 years I even have to look for parameters of fread. whereas in
> Forth I spent more energy in remembering the stack effect because it is
> critical.
>
> so I think more brain power is needed for reading
> (and writing) Forth code. on the other side, if
> one has become familiar with brain stack tracking and in remembering of
> stack effects, Forth become a mega simple, mega effective tool.
This doesn't explain the observed asymmetry: teaching Forth is easier than
teaching C, so the stack effect can't be a fundamental difficulty.
fread() is, however, a good example. I too need to look it up when
writing. However, if I see:
nread = fread( records, sizeof(records[0]), num, input );
when reading, I have a pretty good idea of what's going on without looking
up the definition of anything. On the other hand:
input num recordsize records fread nread !
at least requires you to look up the stack effect of fread to be sure
you've got it, and if you don't guess that the definition of fread is the
key here, you might just get lost for awhile. It's not the stack, it's the
lack of syntactic cues that is the trouble, I think. Note that *I* don't
have much trouble here, but I've seen smart people struggle.
> where are the people who likes to activate their brain ?
Plenty of people here like to activate their brains (I'm at MIT, after all
:-), but programming is only part of the job. It's a matter of cognitive
style, I think: C seems to be more forgiving of cognitive difference,
although I also know a few smart people who have a great deal of trouble
reading C.
I find if I write and maintain my own code in a familiar dialect of Forth
it is tremendously powerful. It's easy to get students to help, too. Done
that. But if my role is to start a project and then delegate further
development to students or maybe a new hire at an academic salary, it's
harder to see a good case for Forth, especially if I won't have time to do
maintenance myself. If I need to have a systems engineer review the code,
it gets tougher still.
John Doty
f...@ultratechnology.com wrote:
> J. Thomas has explained that Forth doesn't have to automatically slow
> down a person to give them time to think slowly the way C does.
I think that's completely backwards. It's Forth that slows you down,
making you jump from definition to definition.
> And impatient people don't make very good programmers. Not everyone
> should be a programmer after all.
The trouble is that in a big project, programming is only part of the job.
Specialists, including programmers, tend to be poor at seeing the whole
picture (although they sometimes insist that they see it clearly and
everone who doesn't agree with them is a fool :-).
The non-programmers who work on the project need to understand what the
programmers are doing. In some phases of my projects, code needs fixing
when there are no programmers on payroll. Systems engineering must be sure
that programs actually do what the system needs: programmers often do not
understand requirements written by non-programmers.
Documentation is helpful, but is often either incomprehensible or
erroneous. Programmers document what they *intended* to do in their *own*
terms, not what they actually did in terms others might understand. In
the end, people have to read the code.
In many cases, programmers should not be writing code at all: it's better
to have someone who understands the *application* than someone who
understands *technique*. A few years ago we had great success with a
project where a physicist wrote the code, with a programmer doing the
review and testing (I had intended it to be the other way around, but they
were doing so well that way that I encouraged it).
>
> I recall Richard Stallman saying that we need to encourage some children
> to be plumbers and some to be programmers, that if we try to make them
> all programmers that our plumbing and our computers will get all clogged
> up, and with the same stuff. ;-)
Stallman lives in his brave GNU world and produces marvelous stuff, but
he's clueless outside his limited domain. He sure isn't a Forth programmer
either :-)
Alex McDonald
"Jeff Fox" <f...@ultratechnology.com> wrote in message
news:4fbeeb5a.03031...@posting.google.com...
> There is no question that it is easier to teach Forth than
> C. Some of the presentations at SVFIG about using different
> computer languages for teaching high school students make
> this very obvious.
>
> But there are complications. C is not an oral tradition,
> there are hundreds of textbooks to assist the teacher and
> learner. Forth is at a great disadvantage this way as it
> has primarily been an oral tradition where one learns the
> language from a more senior mentor.
>
> Like some other arts the distance down the chain from the
> source makes a big difference. Those who learned from the
> creator of Forth got excellent tutoring. Those who learned
> from them got goodd tutoring. Third, fourth, fifth, and
> sixth handed accounts each lost some of the original teaching
> and replaced it with more of the personal color of the
> teachers along the way. It is like the old children's game
> telephone.
>
> If your teacher in an art is a green belt it is harder to learn
> than if your teacher is a black belt, it may be impossible. If
> your teacher is a master teacher instead of just a black belt
> chances are that it will be much easier to learn.
Oh, come on, this is simplistic nonsense. What exactly is this analogy
supposed to explain? That those at the feet of the master ... etc. You make
learning Forth sound like cabalistic ritual distorted by the untutored down
the ages.
>
> Also there is a rule that students will always learn the bad
> habits of their teacher before they learn the good habits.
Rule? Or your observation on a personal teaching/learning experience?
===snipped
>
> I recall Richard Stallman saying that we need to encourage some
> children to be plumbers and some to be programmers, that if we
> try to make them all programmers that our plumbing and our
> computers will get all clogged up, and with the same stuff. ;-)
The same is true of email.
>
> Best wishes,
> Jeff Fox
--
Regards
Alex McDonald
jonah thomas
>f...@ultratechnology.com wrote:
>> J. Thomas has explained that Forth doesn't have to automatically slow
>> down a person to give them time to think slowly the way C does.
> I think that's completely backwards. It's Forth that slows you down,
> making you jump from definition to definition.
Forth programmers like to think about examples where the Forth code is
factored well. So you can look at the big picture and then zero in on
whichever detail you prefer. But this is an art-form and there's no
guarantee that it will be done well in any particular case.
I've noticed that when I'm trying to deal with working code in other
languages, I find myself breaking it down into smaller pieces. I'll
start with a 500 line routine and try to turn 50 lines of it into a
separate routine and get it running with that separate, and then another
40 lines, etc. Sometimes I can see how to turn a line or two into a
small routine or macro that can replace lots of examples, but that's
likely to be harder and also riskier. Easier to do that after the giant
routines are divided into things that I can at least see.
I haven't noticed the mental overhead of looking at separate definitions
is worse than having them all smushed together with 8 levels of
indenting. But it's a personal thing. YMMV.
> The trouble is that in a big project, programming is only part of the
> job. Specialists, including programmers, tend to be poor at seeing the
> whole picture (although they sometimes insist that they see it clearly
> and everone who doesn't agree with them is a fool :-).
> In many cases, programmers should not be writing code at all: it's
> better to have someone who understands the *application* than someone
> who understands *technique*. A few years ago we had great success with
> a project where a physicist wrote the code, with a programmer doing
> the review and testing (I had intended it to be the other way around,
> but they were doing so well that way that I encouraged it).
In Forth I can imagine that the programmer should be making tools for
the others to use. The ideal is to make an application-specific
language that fits their needs so they can craft what they want in it.
I don't know how often that ideal works out in practice.
John Doty
<j2th...@cavtel.net> wrote:
> Forth programmers like to think about examples where the Forth code is
> factored well. So you can look at the big picture and then zero in on
> whichever detail you prefer. But this is an art-form and there's no
> guarantee that it will be done well in any particular case.
Factoring is a good idea in any language. It's not hard in C (although
many C programmers aren't very good at it). It's almost essential in
Forth, because poorly factored code becomes *very* hard to read. But C's
readabilty advantage doesn't depend on being unfactored. I like to write
highly factored C, rarely using more than a couple of dozen lines per
function (a result, no doubt, of playing around with languages like APL,
Forth, and Mathematica a lot). The other members of the team don't seem to
have any unusual trouble reading my code.
>
> I've noticed that when I'm trying to deal with working code in other
> languages, I find myself breaking it down into smaller pieces. I'll
> start with a 500 line routine and try to turn 50 lines of it into a
> separate routine and get it running with that separate, and then another
>
> 40 lines, etc. Sometimes I can see how to turn a line or two into a
> small routine or macro that can replace lots of examples, but that's
> likely to be harder and also riskier. Easier to do that after the giant
> routines are divided into things that I can at least see.
>
> I haven't noticed the mental overhead of looking at separate definitions
> is worse than having them all smushed together with 8 levels of
> indenting. But it's a personal thing. YMMV.
That's not the point. It isn't factoring that gets in the way. It's the
fact that you need to look at the definition of a word to understand the
"stack effect", while in other languages things like the distinction
between the function and its arguments are manifest.
It's not factoring but syntax that matters. Forth lacks syntax.
>
> > The trouble is that in a big project, programming is only part of the
> > job. Specialists, including programmers, tend to be poor at seeing
> > the whole picture (although they sometimes insist that they see it
> > clearly and everone who doesn't agree with them is a fool :-).
>
> > In many cases, programmers should not be writing code at all: it's
> > better to have someone who understands the *application* than someone
> > who understands *technique*. A few years ago we had great success
> > with a project where a physicist wrote the code, with a programmer
> > doing the review and testing (I had intended it to be the other way
> > around, but they were doing so well that way that I encouraged it).
>
> In Forth I can imagine that the programmer should be making tools for
> the others to use. The ideal is to make an application-specific
> language that fits their needs so they can craft what they want in it.
>
> I don't know how often that ideal works out in practice.
It works nicely until the requirements change. Having an
application-specific set of Forth definitions is great, especially since
Forth is a great scripting language. The trouble comes when somebody has
to pry the lid off the black box and change the contents.
jonah thomas
> "jonah thomas" <j2th...@cavtel.net> wrote:
>>Forth programmers like to think about examples where the Forth code is
>>factored well. So you can look at the big picture and then zero in on
>>whichever detail you prefer. But this is an art-form and there's no
>>guarantee that it will be done well in any particular case.
> Factoring is a good idea in any language. It's not hard in C (although
> many C programmers aren't very good at it). It's almost essential in
> Forth, because poorly factored code becomes *very* hard to read. But C's
> readabilty advantage doesn't depend on being unfactored.
That's what I figured. You pointed out the problem of having to look at
other definitions, but that isn't it.
> It isn't factoring that gets in the way. It's the
> fact that you need to look at the definition of a word to understand the
> "stack effect", while in other languages things like the distinction
> between the function and its arguments are manifest.
Why do you care? Are you debugging the code? Then you need the stack
effects. Are you using one of the words for something else? Then look
up the word and check its documented stack effect. If the stack diagram
is wrong then you have a completely legitimate beef against the author.
So we're approaching the crux. What's the purpose of reading the code.
What are people supposed to do with it. I'm figuring at this point
you want people to 'maintain' it, to change it to fit their own needs.
And for some reason they resist doing that with your code.
>>In Forth I can imagine that the programmer should be making tools for
>>the others to use. The ideal is to make an application-specific
>>language that fits their needs so they can craft what they want in it.
>>I don't know how often that ideal works out in practice.
> It works nicely until the requirements change. Having an
> application-specific set of Forth definitions is great, especially since
> Forth is a great scripting language. The trouble comes when somebody has
> to pry the lid off the black box and change the contents.
That makes sense. You get an expert to write the tools that everybody
else uses. Then the tools get obsolescent and you need another expert
to write new tools. You *could* get the people who're expert in the
problem domain to do it. Some of them are probably good enough at Forth
to do that. But they don't want to think on that level.
Am I on the right track or is your problem different?
Jeff Fox
> In article <4fbeeb5a.03031...@posting.google.com>,
> f...@ultratechnology.com wrote:
>
> > J. Thomas has explained that Forth doesn't have to automatically slow
> > down a person to give them time to think slowly the way C does.
>
> I think that's completely backwards. It's Forth that slows you down,
> making you jump from definition to definition.
That depends on how well written the Forth code is, how much you
understand about Forth and the problem, and on the documentation
present. Sure badly written Forth can be unreadable.
> > And impatient people don't make very good programmers. Not everyone
> > should be a programmer after all.
>
> The trouble is that in a big project, programming is only part of the job.
> Specialists, including programmers, tend to be poor at seeing the whole
> picture
That is for sure.
> (although they sometimes insist that they see it clearly and
> everone who doesn't agree with them is a fool :-).
Yes and sometimes they are right. ;-)
> The non-programmers who work on the project need to understand what the
> programmers are doing. In some phases of my projects, code needs fixing
> when there are no programmers on payroll. Systems engineering must be sure
> that programs actually do what the system needs: programmers often do not
> understand requirements written by non-programmers.
Yes, and conversely non-programmers often do not understand comments
written by programmers who assume they are writing for other programmers
not for non-programmers.
> Documentation is helpful, but is often either incomprehensible or
> erroneous. Programmers document what they *intended* to do in their *own*
> terms, not what they actually did in terms others might understand. In
> the end, people have to read the code.
That may be true in the general case. But some programmers write
extensive if not excessive documentation aimed at multiple audiences.
> In many cases, programmers should not be writing code at all: it's better
> to have someone who understands the *application* than someone who
> understands *technique*.
That is why a Forth programmer should really write the custom language
for the application so that the actual application can be written
by the expert in the application domain, not the Forth domain. Forth
is quite different than other languages in this way.
> A few years ago we had great success with a
> project where a physicist wrote the code, with a programmer doing the
> review and testing (I had intended it to be the other way around, but they
> were doing so well that way that I encouraged it).
If you were managing then the buck stopped with you.
> > I recall Richard Stallman saying that we need to encourage some children
> > to be plumbers and some to be programmers, that if we try to make them
> > all programmers that our plumbing and our computers will get all clogged
> > up, and with the same stuff. ;-)
>
> Stallman lives in his brave GNU world and produces marvelous stuff, but
> he's clueless outside his limited domain.
His comments about less talented programmers screwing things up
often anger the more average programmers. I was told that my
comments often have a similar effect and that I might find
what he said about the subject amusing. I did.
What I think is funny is that I have always felt that Forth was
designed for an exceptional person, that it got picked up by
other exceptional people and was most popular and effective
in the hand of exceptional people. More average people were
concerned that it wasn't more popular with more average
people who needed more training wheels, bumpers, and crutches for
lame programmers than Forth provided.
Stallman is clearly an exceptional person who laments lowering
of the bar to the level of the average. I loved the way he
put the concept and what it would lead to (led to).
> He sure isn't a Forth programmer either :-)
Nobody's perfect!
Best wishes,
Jeff Fox
John Doty
<j2th...@cavtel.net> wrote:
>> It isn't factoring that gets in the way. It's the fact that you need to
>> look at the definition of a word to understand the
>> "stack effect", while in other languages things like the distinction
>> between the function and its arguments are manifest.
>
> Why do you care?
Perhaps I'm asking someone to review the code to see if it meets the
requirements. Or I want to know what will happen if I try a novel
operational procedure with the system. Or the requirements have changed,
and I need to ask somebody to change something.
> Are you debugging the code? Then you need the stack
> effects. Are you using one of the words for something else? Then look
> up the word and check its documented stack effect. If the stack diagram
> is wrong then you have a completely legitimate beef against the author.
"The word". *Which* word? Looking them up in the sequence they appear in
a definition is tedious and unilluminating. Which word supplies the data?
Which word grinds it up? Which word supplies a control parameter? One
might suspect that the last word is the key, but some definitions are
"cliff hangers" (they set things up, but the resolution is in the next
one), and some do the work in the middle, with the tail mopping up the
results. The syntax in C gives you clues here that Forth does not.
Choosing a path into the logic of a definition is an art that seems
difficult to master in Forth, at least for some.
John Doty
>> In many cases, programmers should not be writing code at all: it's
>> better to have someone who understands the *application* than someone
>> who understands *technique*.
>
> That is why a Forth programmer should really write the custom language
> for the application so that the actual application can be written by the
> expert in the application domain, not the Forth domain. Forth is quite
> different than other languages in this way.
There are two problems here. The tool builder needs to understand the
application *better* than the application scripter does, so it should
actually be the application expert who writes the custom language while
the Forth programmer writes the application itself. It's often hard to
convince people to work that way (even assuming I have the right people
and an adequate budget to support such a division of labor).
The second is that when the application requirements change, it often
becomes necessary to change the custom language. Then, somebody has to
read the definitions. Since Forth readers are scarcer than Forth
programmers, this can be a problem.
Elizabeth D. Rather
> It is my experience that it is easier to teach Forth than C. At the same
> time, it is my experience that readers of Forth code give up in confusion
> much more frequently than readers of C code. Why?
Teaching to folks with what background? And being read by folks with
what background?
I do a lot of teaching of Forth. It is extremely easy to teach it to people
who
already know how to program in another language, and extremely difficult
to teach it to people who have never programmed, because first they
have to grasp the paradigm of what programming is.
The fact is that an awful lot of people already know C. If they are the
ones you're talking about, they probably learned C as a first language,
and it was very hard. Forth as a second language would be duck soup.
And if you're saying that folks who know some C can read C easier
than Forth (which they don't know) that's a no-brainer.
In my experience, engineers who know Forth (and I've worked with
a lot of them) can read Forth just fine, even "not very good" Forth.
I don't expect anyone to read a language they don't know. I can't
read C very well at all.
Cheers,
Elizabeth
andr...@littlepinkcloud.invalid
> In article <e20a4a47.03031...@posting.google.com>,
> jmdra...@yahoo.com wrote:
>> "John Doty" <j...@w-d.org> wrote in message
>> news:<7x6dndH37c5...@speakeasy.net>...
>>
>>> Why do *you* think it's easier to teach Forth than C, but often harder
>>> to get impatient people to read code in Forth than in C? It's a real
>>> problem.
>>
>> I don't think it's easier to teach Forth than C. Why do *you* think
>> that *I* think that? Sure it's easier to teach C to people already
>> familair with another programming language since it's similair to other
>> programming languages but that's an entirely different issue.
> I will rephrase:
> It is my experience that it is easier to teach Forth than C. At the
> same time, it is my experience that readers of Forth code give up in
> confusion much more frequently than readers of C code. Why?
Because they have less experiance reading Forth than reading C?
The problem with teaching C is not so much the things that programmers
think they know, but the things they think they know that are wrong.
There is quite a number of traps and pitfalls in the language that
even experianced programmers are caught by. So, when reading a
program as part of a review a program might appear to be correct but
in fact have subtle bugs caused by little understood parts of the
language. C might appear easy to read, but it isn't.
Andrew.
jmdrake
> I will rephrase:
>
> It is my experience that it is easier to teach Forth than C. At the same
> time, it is my experience that readers of Forth code give up in confusion
> much more frequently than readers of C code. Why?
Were you teaching to people who have programmed before or people who have
not? It would be interesting to take a group of people who have never
programmed, teach half C and half Forth, give them an assigment at
the end of the term and see which group does a better job completing
the assignment.
With each language paradigm there's something (or things) you have to
get past to truly understand the language. Coming from a GW-Basic
background it took me a while to get used to the idea that I didn't
need a goto.
Anyway while I don't know of any universities that use Forth as a
first teaching language, I recall that MIT used Lisp. Lisp can
be hard to learn/difficult to program for people used to the Algol
family of languages. Yet MIT has had good success with it.
> The latter is, for me, a huge disadvantage of Forth, because it has in
> past projects meant that I've been the one who wound up maintaining and
> extending all of the code, regardless of who wrote it.
Are you saying that the people who wrote the code couldn't read their
own code, or that they simply weren't around to maintain it?
> With newer Forths looking much more complex (the LSE ROM had 50 words of
> interest to application programmers), I worry that the reading problem is
> likely to be worse.
Good point. I remember long ago when it was feasible to type WORDS
from a Forth command line. *LOL* I suppose you could use eForth or
some other minimal Forth. Another idea is to use a Forth that has
a good help system where the words are logically grouped. TpForth
is like that (and it has a great scripted online tutorial). Also
HolonForth not only keeps its own words groups nicely, but allows
you to do the same as you extend the system.
Regards,
John M. Drake
jonah thomas
> f...@ultratechnology.com wrote:
>>That is why a Forth programmer should really write the custom language
>>for the application so that the actual application can be written by the
>>expert in the application domain, not the Forth domain. Forth is quite
>>different than other languages in this way.
> There are two problems here. The tool builder needs to understand the
> application *better* than the application scripter does, so it should
> actually be the application expert who writes the custom language while
> the Forth programmer writes the application itself.
That sounds like a dilemma. The toolbuilder needs to understand the
needs well enough to build the most useful tools, and he also needs to
understand toolbuilding well enough to actually do the work. Unless you
get somebody who's expert in both domains you're going to have a
communication problem to solve.
Maybe the extreme programming approach of having a 2-person team would
help. The domain expert says "Here's what I want to accomplish" and the
methods expert says "Here's how you can do it" and then the domain
expert says "No, that wasn't what I meant" and the methods expert says
"OK, we can do it this way" and the domain guy says "But what about this
other thing?" and the methods guy says "You never mentioned that before"
and so on.
> It's often hard to
> convince people to work that way (even assuming I have the right people
> and an adequate budget to support such a division of labor).
Understandable. Tell the numerical analyst "We're going to get an end
user to design the algorithms, you just use them". Tell the database
expert "An end user will do all the design work for the database, you
just do the application coding that uses it". But when you have enough
of the skills in one head or good enough commnication, it works.
It sounds a little like the traditional design problem. Design
everything top-down and if you make a mistake you can get a detailed
plan that can't be followed, that simply doesn't match up to the
low-level realities. Design bottom-up and if you make a mistake you can
get an elegant solution to the wrong problem. Somehow you have to meet
in the middle.
> The second is that when the application requirements change, it often
> becomes necessary to change the custom language. Then, somebody has to
> read the definitions. Since Forth readers are scarcer than Forth
> programmers, this can be a problem.
If you truly do have a bunch of people who can write Forth code easier
than they can read other people's code, you might try letting them
rewrite the custom language to fit the new needs. If they manage to
read the old code enough to get some good ideas from it, maybe even
re-use some code, that's a plus. But if they can code quicker than they
can read, you might as well let them code. 8-)
This would seem to point to a reason why you wind up maintaining
everything. You're the one who's expert in both domains. So you can do
it better than anybody else.
Gary Chanson
"jonah thomas" <j2th...@cavtel.net> wrote in message
news:3E790817...@cavtel.net...
>
>
> Understandable. Tell the numerical analyst "We're going to get an end
> user to design the algorithms, you just use them". Tell the database
> expert "An end user will do all the design work for the database, you
> just do the application coding that uses it". But when you have enough
> of the skills in one head or good enough commnication, it works.
>
> It sounds a little like the traditional design problem. Design
> everything top-down and if you make a mistake you can get a detailed
> plan that can't be followed, that simply doesn't match up to the
> low-level realities. Design bottom-up and if you make a mistake you can
> get an elegant solution to the wrong problem. Somehow you have to meet
> in the middle.
That's why I like to start in the middle. The upper levels will be
determined by how the user needs to interact with the machine. The lower
levels will be determined by the hardware. I start by designing that machine
in the middle.
--
-Gary Chanson (MS MVP for Windows SDK)
-Software Consultant (Embedded systems and Real Time Controls)
-gcha...@mvps.org
-War is the last resort of the incompetent.
Graham Smith
<gcha...@NOSPAM.TheWorld.com> writes
>
> That's why I like to start in the middle. The upper levels will be
>determined by how the user needs to interact with the machine. The lower
>levels will be determined by the hardware. I start by designing that machine
>in the middle.
>
Not only is forth "backwards", now it has become "inside-out" :-)
Graham Smith
Jerry Avins
So why not use Snobol instead?
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
jmdrake
> A browser tools which allows one quickly to find definitions across
> multiple source files is a basic tool. At its simplest, every Forth
> system should have LOCATE or something equivalent that will instantly
> bring up a definition and its accompanying documentation.
I'm quite aware of LOCATE, but that's not the point. Some languages
are explicit about what's imported from where and some are not.
C and Forth are not. Please note that I'm not knocking Forth, just
pointing out the fact that it's on the same level with C on this
one issue.
> This is a quality of implementation issue.
With some languages you have this information regardless of the
"implementation".
> Andrew.
Regards,
John M. Drake
jmdrake
> On 5 Mar 2003 09:13:56 -0800, jmdra...@yahoo.com (jmdrake) wrote:
> >You were talking about a reviewer reading source code right? Finding
> >definitions in source code isn't hard if everthing's in the same file
> >regardless of whether or not you're talking C or Forth. Finding
> >definitions across multiple source files is what is difficult.
> >Java, Oberon, Modula ect have language constructs to help with
> >this. C and Forth don't.
>
> environment.
You are missing the point. Badly I might add. John Doty was talking
about "language" cues, hence it's the LANGUAGE and NOT the
development enviornment that we were talking about.
> Just for fun: start Win32Forth, type in VIEW WORDS, click the mouse on
> any interesting word, hyperlink back with F10 ...
>
> That's good, no?
>
> Andreas
I'm not saying that it's good or bad. That's not the point.
I'm saying that neither C nor Forth have built into the language
cues about where a item came from. Other languages do.
If I see Files.Read in an Oberon program then I immediately
know where this was defined irregardless of the development
enviornment. And certainly I can have a development enviornment
for any language that does what you are describing for Forth.
But that wasn't the point.
Regards,
John M. Drake
andr...@littlepinkcloud.invalid
> andr...@littlepinkcloud.invalid wrote in message news:<v6ef7lt...@news.supernews.com>...
>> A browser tools which allows one quickly to find definitions across
>> multiple source files is a basic tool. At its simplest, every
>> Forth system should have LOCATE or something equivalent that will
>> instantly bring up a definition and its accompanying documentation.
> I'm quite aware of LOCATE, but that's not the point. Some languages
> are explicit about what's imported from where and some are not. C
> and Forth are not. Please note that I'm not knocking Forth, just
> pointing out the fact that it's on the same level with C on this one
> issue.
Your point was
> Finding definitions across multiple source files is what is
> difficult.
and my point addressed that particular issue. LOCATE *is* the point,
as it solves the problem of finding definitions across multiple source
files.
>> This is a quality of implementation issue.
> With some languages you have this information regardless of the
> "implementation".
Sure, but so what?
Andrew.
andr...@littlepinkcloud.invalid
> Andreas Kochenburger <kochen...@gmx.de> wrote in message news:<krfe6vg03310rncof...@4ax.com>...
>> On 5 Mar 2003 09:13:56 -0800, jmdra...@yahoo.com (jmdrake) wrote:
>> >You were talking about a reviewer reading source code right?
>> >Finding definitions in source code isn't hard if everthing's in
>> >the same file regardless of whether or not you're talking C or
>> >Forth. Finding definitions across multiple source files is what
>> >is difficult. Java, Oberon, Modula ect have language constructs
>> >to help with this. C and Forth don't.
>>
>> That's NOT a language issue, but a feature of the development
>> environment.
> You are missing the point. Badly I might add. John Doty was talking
> about "language" cues, hence it's the LANGUAGE and NOT the
> development enviornment that we were talking about.
So what? We already know that with LOCATE finding definitions across
multiple source files is not a problem.
It doesn't matter whether the cues are in the language or in the
environment as long as the job gets done.
Andrew.
jonah thomas
> You are missing the point. Badly I might add. John Doty was talking
> about "language" cues, hence it's the LANGUAGE and NOT the
> development enviornment that we were talking about.
>>Just for fun: start Win32Forth, type in VIEW WORDS, click the mouse on
>>any interesting word, hyperlink back with F10 ...
> I'm not saying that it's good or bad. That's not the point.
> I'm saying that neither C nor Forth have built into the language
> cues about where a item came from. Other languages do.
> If I see Files.Read in an Oberon program then I immediately
> know where this was defined irregardless of the development
> enviornment. And certainly I can have a development enviornment
> for any language that does what you are describing for Forth.
> But that wasn't the point.
So, Forth does things with development environment that some languages
do with syntax. Why is this important?
One result is that you do a lot better reading Forth when it's on a
system where you have the tools available. While languages that provide
the cues in the syntax are easier than Forth to read if you've, say,
taken paper copies on a backpacking trip and don't have an IDE handy.
Also once you learn the cues you can just know what they tell you, you
don't need even a single mouse click to find out. Many people put some
cues like that into their Forth code but there aren't any mechanics in
place that tells them they have to. Typically words that start with a .
will print something, words that start with ? consume a flag, etc. But
it isn't completely standardised and there's no penalty for not doing it
unless your boss wants you to.
jmdrake
> >definitions in source code isn't hard if everthing's in the same file
> >regardless of whether or not you're talking C or Forth. Finding
> >definitions across multiple source files is what is difficult.
> >Java, Oberon, Modula ect have language constructs to help with
> >this. C and Forth don't.
>
> in a file.
Sure it is. And what does "fairness" have to do with it? Why be
defensive about a languages? Sheesh.
> (ctags). Once I had configured my editor
> with a tags function key. Hitting the function key if the cursor
> was at a keyword, I got into the include file or whatever
> where it was defined at the right place.
> vi and emacs have similar things as standard.
That's nice. But it's not the point.
> Regarding Forth this isn't fair either.
> Many systems have LOCATE . This may not count as a language construct,
> but it is practical. Some systems (e.g. ciforth) have support for
> this by having a field in the header to point to source.
Again nice, but not at all the point.
> Talking about C++. Making so called "class browsers" seem to be
> a hobby.
>
> So, not surprisingly, there seem to be a great many tools to
> study source.
> Why this must be a language construct is not clear to me.
I never said that it HAD to be a language construct!!!!! I'm just
pointing out the fact that in some languages you don't need extra
tools to do this, and in some you do! I'm saying that Forth and
C are on the same level on this. Neither have it as a language
contruct, but both can use external tools to do this. Yes I
understand and have used LOCATE and VIEW for years! That's not
the point folks. A comment was made about C providing certain
"cues" for following a source tree that Forth lacks. I'm saying
that neither C nor Forth provide such "cues" although there are
other languages that do.
Regards,
John M. Drake
John Doty
jmdra...@yahoo.com wrote:
> A comment was made about C providing certain
> "cues" for following a source tree that Forth lacks. I'm saying
> that neither C nor Forth provide such "cues" although there are other
> languages that do.
When trying to understand a line of Forth code, how do you decide which
definition to look up first?
Jerry Avins
The first one you come to that you don't know. After a little use, it
will either be obscure or be part of the application code. (I just gave
a working definition of "obscure". It varies with the individual.)
Jerry
John Doty
wrote:
> John Doty wrote:
>> When trying to understand a line of Forth code, how do you decide which
>> definition to look up first?
> The first one you come to that you don't know. After a little use, it
> will either be obscure or be part of the application code. (I just gave
> a working definition of "obscure". It varies with the individual.)
That seems miserably inefficient to me. Some definitions are much more
illuminating than others. If I see "foo @", I'm not going to go look at
foo (although I might scan for "foo !" to see where its value comes
from). Of course, this strategy will occasionally confuse me (but I'm
used to that, and can cope :-).
John Doty
<era...@forth.com> wrote:
>> It is my experience that it is easier to teach Forth than C. At the
>> same time, it is my experience that readers of Forth code give up in
>> confusion much more frequently than readers of C code. Why?
>
> Teaching to folks with what background? And being read by folks with
> what background?
A mixture of students, engineers, and scientists. The usual riffraff that
hang around a physics lab :-). In the early days, none knew C (and we
weren't using it). The approach depended on the person: I'd show a
hardware engineer how to prod at his registers, a scientist how to invoke a
canned procedure. Work into programming from there. LSE only had 50 words
to start building applications from, so there wasn't so much to teach.
Jerry Avins
When you see foo @ , you know that foo is a variable. Often that's
enough. When it's not, look it up. It may give you misery, but what's
inefficient about it?
jonah thomas
>>>>When trying to understand a line of Forth code, how do you decide which
>>>>definition to look up first?
>>>The first one you come to that you don't know. After a little use, it
>>>will either be obscure or be part of the application code. (I just gave
>>>a working definition of "obscure". It varies with the individual.)
>>That seems miserably inefficient to me. Some definitions are much more
>>illuminating than others. If I see "foo @", I'm not going to go look at
>>foo (although I might scan for "foo !" to see where its value comes
>>from).
> When you see foo @ , you know that foo is a variable. Often that's
> enough. When it's not, look it up. It may give you misery, but what's
> inefficient about it?
I don't know that. All I know is that foo either returns a cell-aligned
address as the top item it returns, or it removes enough stack items to
reveal a cell-aligned address under them.
John Doty
<j2th...@cavtel.net> wrote:
>> When you see foo @ , you know that foo is a variable. Often that's
>> enough. When it's not, look it up. It may give you misery, but what's
>> inefficient about it?
>
> I don't know that. All I know is that foo either returns a cell-aligned
> address as the top item it returns, or it removes enough stack items to
> reveal a cell-aligned address under them.
Ah, now we're getting someplace. @ is a good cue for identifying variables
in Forth, but it isn't foolproof. In C, (foo) and (*foo()) have a very
different look: in the first case I'd probably not bother looking at the
definition, while the second would certainly give me the idea that foo's
definition might be very illuminating.
Of course it isn't foolproof in C, either. Macros can really foul up
readability, but seriously irresponsible use of macros is relatively rare
in actual C code. It seems to me that C's cues are more useful and
reliable than Forth's until the reader is familiar with the application's
specialized vocabulary. Getting the reader over that hump is the
difficulty.
Elizabeth D. Rather
> In article <3E7AC1A...@cavtel.net>, "jonah thomas"
> <j2th...@cavtel.net> wrote:
>
> >> When you see foo @ , you know that foo is a variable. Often that's
> >> enough. When it's not, look it up. It may give you misery, but what's
> >> inefficient about it?
> >
> > I don't know that. All I know is that foo either returns a cell-aligned
> > address as the top item it returns, or it removes enough stack items to
> > reveal a cell-aligned address under them.
>
> Ah, now we're getting someplace. @ is a good cue for identifying variables
> in Forth, but it isn't foolproof.
IMO it isn't important to know how something is defined, what's important
is to know what it _does_. Indeed, there are all kinds of ways of making
a word that returns an address; obviously in the above example foo is
one of them (Jonah's suggestion that it "removes enough stack items to
reveal" an address is pretty unlikely).
Ideally its name shouldn't be 'foo' but something indicative of its function,
such as #items. If you see #items @ you'll have a pretty clear idea of
what that phrase does and move on.
Cheers,
Elizabeth
jmdrake
> So what? We already know that with LOCATE finding definitions across
> multiple source files is not a problem.
>
> It doesn't matter whether the cues are in the language or in the
> environment as long as the job gets done.
>
> Andrew.
I never said that it mattered or that it didn't matter. I was addressing
a specific point that was brought up. Why you can't understand that
I don't know.
Regards,
John M. Drake
jmdrake
> So, Forth does things with development environment that some languages
> do with syntax. Why is this important?
I didn't say it was important. I was addressing a specific point.
Anyway you should change your wording to say "some Forth enviornments
do this" because some certainly do not.
What you and others seem to be missing is that I was addressing a
specific point that was brought up about language cues. My point
is that C is no better than Forth on this regard. The specific
illustration was what if you have source on paper as opposed to
in the computer? Let's say you're a program listing in a magazine
article? All of a sudden LOCATE and VIEW can't help you. Then
cues in the language can. And of course any language can do
what you're describing "in the enviornment" so that's really
not specific to Forth. But that's not my point anyway. I'm
saying that it's not in C either.
Regards,
John M. Drake
Ed Beroset
> In article <3E7AC1A...@cavtel.net>, "jonah thomas"
> <j2th...@cavtel.net> wrote:
>
>
>>>When you see foo @ , you know that foo is a variable. Often that's
>>>enough. When it's not, look it up. It may give you misery, but what's
>>>inefficient about it?
>>
>>I don't know that. All I know is that foo either returns a cell-aligned
>> address as the top item it returns, or it removes enough stack items to
>> reveal a cell-aligned address under them.
>
>
> Ah, now we're getting someplace. @ is a good cue for identifying variables
> in Forth, but it isn't foolproof. In C, (foo) and (*foo()) have a very
> different look: in the first case I'd probably not bother looking at the
> definition, while the second would certainly give me the idea that foo's
> definition might be very illuminating.
One of the interesting aspects to this difference is the relative
importance that different programmers attach to this ability (and I mean
here both the ability of the programmer to extract the information and
the ability of the language to support that). It relates, I think, to
what one is trying to do when looking at source code and also to how one
thinks. An article available from the ACM digital library
@inproceedings{801100,
author = {Raymond C. Hooker},
title = {APL programming: A psychological model},
booktitle = {Proceedings of the international conference on APL},
year = {1984},
isbn = {0-89791-137-7},
pages = {207--211},
location = {Finland},
}
examines the psychological aspects of APL programmming and APL
programmers (a scary place to explore for some of us! ;-) ) and makes
the observation that while there are "a preponderance of mathematical
degrees among APL'ers" there is little formal study on what
psychological factors make for the afinity and ability of programmers to
learn and successfully apply APL. I think the same lack of study is
true of Forth, and I think there is something to the notion that some
people just seem to "get" Forth (and then continue to use it) than
others. I think that while we have a lot of experience and a lot of
data regarding which problem domains are matched best with various
languages (although much is not very objective) we have very little on
the matching of programmers with languages.
> Of course it isn't foolproof in C, either. Macros can really foul up
> readability, but seriously irresponsible use of macros is relatively rare
> in actual C code. It seems to me that C's cues are more useful and
> reliable than Forth's until the reader is familiar with the application's
> specialized vocabulary. Getting the reader over that hump is the
> difficulty.
Interestingly, one of the objections I've read to C++ from some C
programmers is that it hides too much. Then if you visit alt.lang.asm,
you'll see that there are unrepentant C-haters who have the very same
objection to the C language. (There is even a small faction who claim
that macros in assembly language are objectionable for that reason!)
Clearly, then, different people look at things in different ways. I
wonder if the fact that Forth typically starts out as much more of a
"blank slate" compared with the environment of rich, standardized
libraries in which C++ programmers swim, might further highlight that
differences in the way individual programmers approach a problem. For
instance, there is a template class named "complex" which provides
various standard operators for complex numbers, including things like
polar to rectangular coordinate conversions and an experienced C++
programmer would likely use them, while an experienced Forth programmer
would likely write (or have already written) a word to do that. The
difference is that while the C++ version is commonly understood, the
Forth version is inherently personal and reflects how that programmer
saw the problem.
More concisely, can there be any doubt the Mac users really do "think
different?" (Not least in eschewing adverbs, for example...)
Just to be clear here, these are meant as observations to (possibly)
help us all understand the discussion better, rather than advocacy for
change to any of the programming languages I mentioned.
Ed
John Doty
<era...@forth.com> wrote:
> IMO it isn't important to know how something is defined, what's
> important is to know what it _does_.
That has multiple meaning. A word that estimates the offset of a blurred
point image from the center of a neighborhood might also be described as a
word that swallows a pointer to a 3x3 matrix of integers and yields a pair
of fixed point numbers.
To to the reader, "what it does" is often incomprehensible until one
understands "why it's there".
> Indeed, there are all kinds of
> ways of making a word that returns an address; obviously in the above
> example foo is one of them (Jonah's suggestion that it "removes enough
> stack items to reveal" an address is pretty unlikely).
But C distinguishes the more common simple cases (*foo) from the less
common complicated cases (*foo()) to the reader. If I was trying to
penetrate the logic of the code, the latter would definitely attract my
attention. Forth doesn't give a reader that kind of cue.
> Ideally its name shouldn't be 'foo' but something indicative of its
> function, such as #items. If you see #items @ you'll have a pretty
> clear idea of what that phrase does and move on.
Real code is often written by teams of people with variable skill levels
and different styles over a period of time to meet changing requirements.
Forth's protean flexibility tends to break any formal naming convention.
Informal conventions are understood and used differently by different
people, and also tend to change with time as the requirements and the
group culture change.
The other problem is that names carry a large burden of explaining the
code to a reader in any language (especially the "why it's there" part).
It is difficult under the best of circumstances to choose good names.
Asking the programmer to convey to the reader additional information about
"behavior" via the name increases the burden on both the programmer and
the reader.
So I'll ask you the same question I've been asking others: when reading a
line of Forth containing unknown words, how do *you* decide what to look
up first?
Pat LaVarre
> no-pop or no-drop tests or conditionals, since
> surely the drop would be optimized away.
Good to have notation for common idioms, yes? By the theory that
optimising compilers that produce human-readable output work better
i.e. making it easy for people to see stuff persuades them to bother
to look at more of it which then persuades them to fix some of it.
> You might want to have them occasionally in small,
> embedded programs running on small cpu's.
Yep.
> [option to test a flag
> vs. being required to test or drop the flag]
"Icon" followed "Snobol" and made it concise to say ignore failure
most of the time but catch failure when you care.
Recently I saw Jeff Fox mention Forth's that have "circular stacks"
that never overflow and do not track DEPTH. With those, you can
declare the stack empty at any time. So you can avoid dropping a flag
you chose not to test merely by again declaring the stack to be empty.
I follow that theory, but I don't get how it works in practice. Seems
to me you'd often want to create words known to leave some cells of
the stack undisturbed, so you can push context before you execute
them.
Pat LaVarre
John Doty
jmdra...@yahoo.com wrote:
> What you and others seem to be missing is that I was addressing a
> specific point that was brought up about language cues. My point is
> that C is no better than Forth on this regard. The specific
> illustration was what if you have source on paper as opposed to in the
> computer? Let's say you're a program listing in a magazine article?
> All of a sudden LOCATE and VIEW can't help you. Then cues in the
> language can. And of course any language can do what you're describing
> "in the enviornment" so that's really not specific to Forth. But that's
> not my point anyway. I'm saying that it's not in C either.
When reading Forth code containing unfamiliar words, how do you decide
which one to look up first?
jonah thomas
> Recently I saw Jeff Fox mention Forth's that have "circular stacks"
> that never overflow and do not track DEPTH. With those, you can
> declare the stack empty at any time. So you can avoid dropping a flag
> you chose not to test merely by again declaring the stack to be empty.
> I follow that theory, but I don't get how it works in practice. Seems
> to me you'd often want to create words known to leave some cells of
> the stack undisturbed, so you can push context before you execute
> them.
It's something you can do with your highest-level code. If nothing else
calls your routine, then you can know that you don't want to leave
anything on the stack.
Note also that the Forths in question tend to have rather shallow
on-chip stacks. There's a speed penalty for using literals and
variables but it has a big place with shallow stacks -- easier to repeat
the literal than DUP it and save it for later. After all there's also a
speed penalty for SWAP and ROT and PICK . If the stack is *very*
shallow then it's like a bank of registers that acts like a stack. You
get all the advantages of not having to name specific registers with all
the disadvantages of not being able to name specific registers.
Elizabeth D. Rather
> In article <3E7B26FE...@forth.com>, "Elizabeth D. Rather"
> <era...@forth.com> wrote:
>
> > IMO it isn't important to know how something is defined, what's
> > important is to know what it _does_.
>
> That has multiple meaning. A word that estimates the offset of a blurred
> point image from the center of a neighborhood might also be described as a
> word that swallows a pointer to a 3x3 matrix of integers and yields a pair
> of fixed point numbers.
>
> To to the reader, "what it does" is often incomprehensible until one
> understands "why it's there".
Well, yes, you need to know all these things.
> ...
>
> > Ideally its name shouldn't be 'foo' but something indicative of its
> > function, such as #items. If you see #items @ you'll have a pretty
> > clear idea of what that phrase does and move on.
>
> Real code is often written by teams of people with variable skill levels
> and different styles over a period of time to meet changing requirements.
> Forth's protean flexibility tends to break any formal naming convention.
> Informal conventions are understood and used differently by different
> people, and also tend to change with time as the requirements and the
> group culture change.
True, but having spent 30 years working with Forth programmers,
often in teams, I've not encountered problems with it. People in teams
usually do try to work together.
> The other problem is that names carry a large burden of explaining the
> code to a reader in any language (especially the "why it's there" part).
> It is difficult under the best of circumstances to choose good names.
> Asking the programmer to convey to the reader additional information about
> "behavior" via the name increases the burden on both the programmer and
> the reader.
>
> So I'll ask you the same question I've been asking others: when reading a
> line of Forth containing unknown words, how do *you* decide what to look
> up first?
It's usually possible to look at the structure of the definition and spot the
word or words that seem to be doing the critical parts, as opposed to
words that seem to be doing "set up" or "clean up" functions. Not
infallibly, to be sure, but well enough to be useful.
Cheers,
Elizabeth
Samuel Tardieu
Pat> Recently I saw Jeff Fox mention Forth's that have "circular
Pat> stacks" that never overflow and do not track DEPTH. With those,
Pat> you can declare the stack empty at any time. So you can avoid
Pat> dropping a flag you chose not to test merely by again declaring
Pat> the stack to be empty.
Not exactly: you don't declare the stack empty, you just consider it
is, the current state is of no importance since it is circular you
will be able to use the same deoth.
For example, the PIC microcontrollers do have a circular return
stack. At any point, you can jump to the beginning of your program and
not care about the current state of the return stack. As it is
circular, you will be able to use as many return stack cells as
available, whatever the current state is.
The size of the return stack is 8. If you are 6 levels deep (1 to 6
are used) and jump to main, the next call will use level 7, the one
after level 8, the one after level 1, 2, 3, ... From the application
point of view (main), you can go 8 levels deep and return cleanly.
Sam
--
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/sam
John Doty
<era...@forth.com> wrote:
Those who can read Forth can do this. Those who cannot read Forth cannot.
Neither group seems to understand what's going on here.
That it's possible I will not deny (since I can do it too). How it is
possible I cannot explain, and apparently you can't either. But this is
the crucial question.
Elizabeth D. Rather
> In article <3E7CC4D8...@forth.com>, "Elizabeth D. Rather"
> <era...@forth.com> wrote:
>
> > It's usually possible to look at the structure of the definition and
> > spot the word or words that seem to be doing the critical parts, as
> > opposed to words that seem to be doing "set up" or "clean up" functions.
> > Not infallibly, to be sure, but well enough to be useful.
>
> Those who can read Forth can do this. Those who cannot read Forth cannot.
> Neither group seems to understand what's going on here.
I'm perfectly willing to concede that you have to know something about
Forth to be able to read Forth. I think that's equally true of C (you have
to know something about it to be able to read it), or any language, for
that matter.
> That it's possible I will not deny (since I can do it too). How it is
> possible I cannot explain, and apparently you can't either. But this is
> the crucial question.
As I think I've mentioned, last week I was teaching Forth for Open
Firmware at Apple. The last day of the 5-day course, we read
several OF drivers, and even though they contained a lot of words
that were new to classmembers, they seemed to have no trouble
with it. Of course, they couldn't have done that before the course.
But 5 days doesn't seem like a huge learning curve to me.
As I was packing up to leave, one of the class mentioned to me
that he'd been assigned to write a driver, and although he'd
originally intended to do it in C, he now thought he'd do it
in Forth "because it's so much easier."
Cheers,
Elizabeth
John Doty
<era...@forth.com> wrote:
> I'm perfectly willing to concede that you have to know something about
> Forth to be able to read Forth. I think that's equally true of C (you
> have to know something about it to be able to read it), or any language,
> for that matter.
You keep ducking the issue. Many people who "know something about Forth"
get stuck reading it. Fewer who "know something about C" get stuck reading
it. It is possible to *describe* some elements of an effective C reading
strategy, where no such description exists for Forth (or at least nobody
here has been able to produce one).
Reading Forth seems to be a more holistic skill, while reading C is more
reductionistic, so perhaps a reductionist description of Forth reading is
impossible. But that makes it harder to teach.
> As I think I've mentioned, last week I was teaching Forth for Open
> Firmware at Apple. The last day of the 5-day course, we read several OF
> drivers, and even though they contained a lot of words that were new to
> classmembers, they seemed to have no trouble with it. Of course, they
> couldn't have done that before the course.
Stepping through an exercise in class is completely different from
decoding an unknown piece of code out in the real world.
How would it have gone if you had been teaching C instead?
> But 5 days doesn't seem like a huge learning curve to me.
It depends. For a full time programmer, no. For a part timer whose primary
duties are something other than programming, it's not trivial. And it
doesn't sound like you actually taught them to read.
> As I was packing up to leave, one of the class mentioned to me that he'd
> been assigned to write a driver, and although he'd originally intended
> to do it in C, he now thought he'd do it in Forth "because it's so much
> easier."
So what? If you know both, Forth is easier to write. For *some people*
it's also easier to read. For many it is not. I had hoped to get a
discussion going on making it easier to coach reading, but I'm obviously
not going to get it here.
Jeff Fox
> Pat LaVarre wrote:
>
> > Recently I saw Jeff Fox mention Forth's that have "circular stacks"
> > that never overflow and do not track DEPTH. With those, you can
> > declare the stack empty at any time. So you can avoid dropping a flag
> > you chose not to test merely by again declaring the stack to be empty.
>
> > I follow that theory, but I don't get how it works in practice. Seems
> > to me you'd often want to create words known to leave some cells of
> > the stack undisturbed, so you can push context before you execute
> > them.
In chips with stack depths less than 8 cells about 1% of the
code must manually spill/fill stacks. In chips with 16 or more
cells it is about 0%.
> It's something you can do with your highest-level code. If nothing else
> calls your routine, then you can know that you don't want to leave
> anything on the stack.
Stack diagraming helps the programmer track the use of stacks.
> Note also that the Forths in question tend to have rather shallow
> on-chip stacks. There's a speed penalty for using literals and
> variables but it has a big place with shallow stacks --
If you mean that literals and variables are always needed in any
Forth it is most certainly true. If you mean 0% to 1% of the
code dealing with stack spill/fill is a big deal then I don't
agree.
> easier to repeat
> the literal than DUP it and save it for later.
Sometimes. The speed variations have to do more with memory
interfaces and what kind of memory chips are being used than
anything else. With on chip memory the stacks are only
several times faster than memory, but going off chip can
be several to several hundred times slower.
> After all there's also a speed penalty for SWAP and ROT and PICK .
If they are not part of the single cycle opcodes, but not on the
designs where they are just as fast as DUP or DROP. But even with
support in the instruction set and automatic spill/fill hardware
like in the old ShBoom or newer Ignite even PICK can be very
fast if it doesn't require access to external memory.
> If the stack is *very*
> shallow then it's like a bank of registers that acts like a stack.
Those are two different things. Having stack registers and having
shallow or *very* shallow stacks are two completely separate concepts.
Even if stacks are just arrays in external memory with a stack
pointer if you only have three wires connected to the memory then
the stack will only have 8 cells. This has nothing to do with
whether the stacks are addressable memory cells, or actual stacks,
registers, or off chip memory.
> You
> get all the advantages of not having to name specific registers with all
> the disadvantages of not being able to name specific registers.
Once again this is mistaken. This is an instruction set and architecture
issue. If you want instructions to access a register stack as an
addressable register array in memory it is just a question of instruction
assignment and alternate register addressing hardware. Look at the
way Ignite provides internal stack address as an array. They added
that because it is almost essential for JAVA or C style programming.
Chuck did not put it into his later designs because his focus was
a language designed for stack access.
best wishes,
Jeff Fox
Jeff Fox
> I don't know that. All I know is that foo either returns a cell-aligned
> address as the top item it returns, or it removes enough stack items to
> reveal a cell-aligned address under them.
It doesn't have to be a cell-aligned address although it may
get much faster access with a cell-aligned address. @ normally
just requires an address. Of course @ could also check for
a cell-aligned address, or an address range, either at
compile or runtime.
Best Wishes,
Jeff Fox
John R. Strohm
news:YbKdnZzR3aN...@speakeasy.net...
> So what? If you know both, Forth is easier to write. For *some people*
> it's also easier to read. For many it is not. I had hoped to get a
> discussion going on making it easier to coach reading, but I'm obviously
> not going to get it here.
Some things must be learned experientially.
How did you learn to ride a bicycle?
To learn to read FORTH, you must read FORTH. Your first attempts will not
go well. Neither did your first attempts to ride a bicycle.
John Doty
<CF8105068D8FD7F6.C7E05090...@lp.airnews.net>, "John
R. Strohm" <str...@airmail.net> wrote:
> To learn to read FORTH, you must read FORTH. Your first attempts will
> not go well. Neither did your first attempts to ride a bicycle.
It only took me a few minutes to teach my kids to ride bicycles. Their
first attempts went very smoothly. If teaching EE's to read Forth was that
easy, I'd be using it a lot more. A computer language as easy to read as
riding a bicycle: *that* would be an innovation.
John R. Strohm
> In article
> <CF8105068D8FD7F6.C7E05090...@lp.airnews.net>, "John
> R. Strohm" <str...@airmail.net> wrote:
>
> > To learn to read FORTH, you must read FORTH. Your first attempts will
> > not go well. Neither did your first attempts to ride a bicycle.
>
> It only took me a few minutes to teach my kids to ride bicycles. Their
> first attempts went very smoothly. If teaching EE's to read Forth was that
> easy, I'd be using it a lot more. A computer language as easy to read as
> riding a bicycle: *that* would be an innovation.
Have you considered taking a week out of your busy schedule and going to one
of Forth Inc.'s classes?
Have you considered letting a couple of your EEs take a week out of their
busy schedules and sending THEM to one of Forth Inc.'s classes?
Jeff Fox
>
> When trying to understand a line of Forth code, how do you decide which
> definition to look up first?
Start with an understanding of Forth, then read the Forth code
that defines the application specific language from start to
finish. It should generally be read from start to finish. If
you start at the end, and pull a line out of context it will
be just like reading the last page of a novel first. You
won't know the story, the characters or their history. Then
you might ask, how far back in the novel should I jump to
make sense of the last page? Although Forth code is generally
more like a short story than a novel. But don't start at
the end. ;-)
A sign of one's understanding or ability to teach Forth is
how long it takes you to take someone who has never used
Forth to go off and use it on their own. If you teach them
that Forth is unreadable and show them how if you start at
the end of a program and pull a line out of context it will
be full of words with defintions that you have never seen
before they will have a hard time learning. Not a good idea.
I have trained people who have never used Forth before and
after two hours they went off and wrote usable programs
the next day. But the Forth was several times simpler than
Forths from twenty years ago. Chuck wants to refine and simplify
the language until he can teach it to someone in fifteen minutes.
Last year I took a C and BSD expert up to see Chuck. He
said that he could read Chuck's code quite easily and
without any training. He did ask a lot of questions about
the internals of the underlying Forth system implementation.
Well written Forth code should not be hard to read, but taking
a semantic language out of context will make it difficult or
impossible to read, because it is all about defining new semantics.
Syntactic languages have this problem to a lesser degree
for reasons already mentioned, they slow down the reader,
they provide lots of redundant cues in the rigid syntax.
But of course it takes a lot longer to teach them or learn
them, and a lot longer to code with them, and they require more
source and object code. Reading a short story is easier than
reading a long novel.
Speed reading generally does not work on code.
Best Wishes,
Jeff Fox
andr...@littlepinkcloud.invalid
> In article <3E7B26FE...@forth.com>, "Elizabeth D. Rather"
> <era...@forth.com> wrote:
>> IMO it isn't important to know how something is defined, what's
>> important is to know what it _does_.
> That has multiple meaning. A word that estimates the offset of a blurred
> point image from the center of a neighborhood might also be described as a
> word that swallows a pointer to a 3x3 matrix of integers and yields a pair
> of fixed point numbers.
> To to the reader, "what it does" is often incomprehensible until one
> understands "why it's there".
>> Indeed, there are all kinds of
>> ways of making a word that returns an address; obviously in the above
>> example foo is one of them (Jonah's suggestion that it "removes enough
>> stack items to reveal" an address is pretty unlikely).
> But C distinguishes the more common simple cases (*foo) from the less
> common complicated cases (*foo()) to the reader. If I was trying to
> penetrate the logic of the code, the latter would definitely attract my
> attention. Forth doesn't give a reader that kind of cue.
This is a _bug_ in C++ and Java. If an implementor wants to change
from a data member to a member function, every place an item is used
must be changed from
foo.bar
to
foo.bar()
and this is a major pain. This is in no way an advantage.
In Forth, a word that returns the address of a value might be a
variable or it might be a subroutine call. Forth doesn't distinguish
between the two because this is not something which client code needs
to know.
>> Ideally its name shouldn't be 'foo' but something indicative of its
>> function, such as #items. If you see #items @ you'll have a pretty
>> clear idea of what that phrase does and move on.
> Real code is often written by teams of people with variable skill
> levels and different styles over a period of time to meet changing
> requirements. Forth's protean flexibility tends to break any formal
> naming convention. Informal conventions are understood and used
> differently by different people, and also tend to change with time
> as the requirements and the group culture change.
So have formal conventions. Whatever. This is a management issue,
not a technical issue. Experienced Forth programmers soon come to
believe in naming conventions.
> The other problem is that names carry a large burden of explaining the
> code to a reader in any language (especially the "why it's there" part).
> It is difficult under the best of circumstances to choose good names.
> Asking the programmer to convey to the reader additional information about
> "behavior" via the name increases the burden on both the programmer and
> the reader.
> So I'll ask you the same question I've been asking others: when reading a
> line of Forth containing unknown words, how do *you* decide what to look
> up first?
I first look at the description of what the word does. I then read
the code "inside out", looking at the interesting words that seem to
be the core of the word. I do this when reading programs written in
any programming language.
Andrew.
andr...@littlepinkcloud.invalid
> In article <3E7CCCDB...@forth.com>, "Elizabeth D. Rather"
> <era...@forth.com> wrote:
>> I'm perfectly willing to concede that you have to know something about
>> Forth to be able to read Forth. I think that's equally true of C (you
>> have to know something about it to be able to read it), or any language,
>> for that matter.
> You keep ducking the issue. Many people who "know something about
> Forth" get stuck reading it. Fewer who "know something about C" get
> stuck reading it.
This is something that you assert.
Repeatedly asserting something don't make it true.
Given equivalent levels of experience, Forth is not -- IMO -- any
harder to read than C.
> So what? If you know both, Forth is easier to write. For *some
> people* it's also easier to read. For many it is not. I had hoped to
> get a discussion going on making it easier to coach reading, but I'm
> obviously not going to get it here.
Well, if you keep insisting on a premise that your interlocutors do
not accept you shouldn't expect to get a discussion going. Why not
agree to differ, and move along?
Andrew.
jonah thomas
> When reading Forth code containing unfamiliar words, how do you decide
> which one to look up first?
It depends on my purpose.
If it's code I'm going to be responsible for, I start at the
lowest-level words and study them carefully, and work my way up. I'm
going to have to understand it all, why put it off?
If it's code that I want to debug but I hope not to have to learn the
whole thing, I start with the known bug. I single-step through the
highest-level word until the bug shows up. If it's somewhere inside a
200-element loop then I grit my teeth and add a KEY I . DROP to the loop
and see if I can tell when it happens. If I can pretty easily get to
the code that shows me the bug, then I can see whether it's that code
that creates it. If not, I can at least get a look at the bad data it
got passed, and look for where that came from. If this approach doesn't
get quick results then I try something else.
If it's code I want to extend and I hope not to have to learn the whole
thing, I look for the spot in the code to add my extension. With luck
there will already be something kind of similar there, and I can copy it
with changes. With luck the interfaces are clean, there won't be a
whole lot of side effects and I can get my little extra result without
disturbing anything else. Of course this is for my personal use. Get a
few people using that approach on a shared project and it gets
continually harder to keep doing it. Things that should have been
re-used get rewritten, change them one place and they aren't changed
other places, the whole thing gets more and more unreadable....
If there's some documentation apart from the code then I look at that
first in case it says something interesting. I start with anything that
says README and go on from there.
I guess there are lots of different reasons to read code and the reading
will change with the purpose.
Reading to be responsible for the whole thing.
Reading to debug.
Reading to extend.
Reading to port.
Reading to mine for routines to use elsewhere.
Reading to document.
Reading to improve. (If the code isn't well-written and you write it
better, it will be easier to read, easier to document, easier to debug,
easier to extend, etc.
Reading for pleasure.
How you read will depend on what you're reading for.
I find writing Forth code is fun. Reading other people's Forth code is
not as much fun. If you have trouble getting employees to read Forth
code, maybe it's that they learned their C habits in school and they
learned to think of it as always drudgery, while they learned Forth from
you and don't have those habits.
Elizabeth D. Rather
> > As I think I've mentioned, last week I was teaching Forth for Open
> > Firmware at Apple. The last day of the 5-day course, we read several OF
> > drivers, and even though they contained a lot of words that were new to
> > classmembers, they seemed to have no trouble with it. Of course, they
> > couldn't have done that before the course.
>
> Stepping through an exercise in class is completely different from
> decoding an unknown piece of code out in the real world.
Although the class actually worked quite a few exercises in the course
of the week, this code was actually "real world" code, previously
unknown to them.
> How would it have gone if you had been teaching C instead?
Very badly, since I don't know C at all.
> > But 5 days doesn't seem like a huge learning curve to me.
>
> It depends. For a full time programmer, no. For a part timer whose primary
> duties are something other than programming, it's not trivial. And it
> doesn't sound like you actually taught them to read.
Our primary purpose was to teach them to write code, as well as to
read it. They'll obviously get better at both, with experience, but
they're off to a good start in both dimensions..
Cheers,
Elizabeth
John Doty
f...@ultratechnology.com wrote:
> "John Doty" <j...@w-d.org> wrote in message
> news:<ys2dnZXZu-y...@speakeasy.net>...
>>
>> When trying to understand a line of Forth code, how do you decide which
>> definition to look up first?
>
> Start with an understanding of Forth, then read the Forth code that
> defines the application specific language from start to finish. It
> should generally be read from start to finish. If you start at the end,
> and pull a line out of context it will be just like reading the last
> page of a novel first. You won't know the story, the characters or
> their history. Then you might ask, how far back in the novel should I
> jump to make sense of the last page? Although Forth code is generally
> more like a short story than a novel. But don't start at the end. ;-)
But Forth code isn't anything like a linear narrative (that's more classic
FORTRAN style).
Still, this is fairly illuminating. If a comprehensive, holistic approach
is required and facilitated by Forth that explains why Forth thrives in
small projects (and if they are mostly software, can keep them small).
Isolable parts of big projects that are otherwise small-project-like also
qualify here.
It also explains why Forth becomes a burden when the hardware and
conceptual parts of the project are complex and have complex connections
to the software: in this case a division of labor is required that breaks
the holistic approach. In the end, Forth is only software: it cannot
simplify everything.
It fits my experience. What a ahame. In my position, as architect of
projects that start simple but usually become complicated, Forth is a
trap. That's certainly what I experienced the last time around, and if
high level Forth skill is as holistic as you say, it's inevitable. Too
bad, I like Forth (but then again, I also like C, so don't cry too much
for me :-).
>
> A sign of one's understanding or ability to teach Forth is how long it
> takes you to take someone who has never used Forth to go off and use it
> on their own. If you teach them that Forth is unreadable and show them
> how if you start at the end of a program and pull a line out of context
> it will be full of words with defintions that you have never seen before
> they will have a hard time learning. Not a good idea.
Teaching people to write LSE was never hard. It was especially easy with a
student who'd just built a gadget that plugged into the bus: teach 'em how
to enter and print hex, @ and ! and maybe : and show 'em the 6 page doc on
the 50 app words and editor and show 'em example driver code and set 'em
loose. Bright kids around here, a few days later I'd have a driver (unless
the hardware debugging went badly). This process never produced anyone who
could maintain someone else's driver, though. I was the only one who
could do that (that's part of the trap).
>
> I have trained people who have never used Forth before and after two
> hours they went off and wrote usable programs the next day. But the
> Forth was several times simpler than Forths from twenty years ago. Chuck
> wants to refine and simplify the language until he can teach it to
> someone in fifteen minutes.
I don't think it would go so smoothly with ANS (but I know you agree with
me).
> Last year I took a C and BSD expert up to see Chuck. He said that he
> could read Chuck's code quite easily and without any training. He did
> ask a lot of questions about the internals of the underlying Forth
> system implementation.
Sure. I remember lo those many years ago when Jon Sachs introduced me to
Chuck's work. Code by a master is a joy to read. If you read Ritchie's
Unix V6 kernel, most of the C code is as clear as water. Unfortunately, I
usually have to make do with code written by mere mortals, and get mere
mortals to maintain it.
>
> Well written Forth code should not be hard to read, but taking a
> semantic language out of context will make it difficult or impossible
> to read, because it is all about defining new semantics. Syntactic
> languages have this problem to a lesser degree for reasons already
> mentioned, they slow down the reader, they provide lots of redundant
> cues in the rigid syntax. But of course it takes a lot longer to teach
> them or learn them, and a lot longer to code with them, and they require
> more source and object code. Reading a short story is easier than
> reading a long novel.
>
> Speed reading generally does not work on code.
But jumping around and following the cues often works well in math and
physics texts. They often do not read comprehensibly in order unless your
cognitive style matches the author's.
Elizabeth D. Rather
> "John Doty" <j...@w-d.org> wrote in message news:<ys2dnZXZu-y...@speakeasy.net>...
> >
> > When trying to understand a line of Forth code, how do you decide which
> > definition to look up first?
>
> Start with an understanding of Forth, then read the Forth code
> that defines the application specific language from start to
> finish. It should generally be read from start to finish. If
> you start at the end, and pull a line out of context it will
> be just like reading the last page of a novel first. You
> won't know the story, the characters or their history. Then
> you might ask, how far back in the novel should I jump to
> make sense of the last page? Although Forth code is generally
> more like a short story than a novel. But don't start at
> the end. ;-)
Nice theory, but complex applications aren't so easy. Open
Firmware, for example, has over 2000 "public" words plus
support definitions. The source is vast, and usually not
available for practical reasons. Fortunately there are
published glossaries and on-line assistance of various
kinds.
Coming to grips with a complex application is a big task,
involving not only language issues but understanding the
overall design and structure, requirements, etc. To me,
that's the place to start, then system documentation.
That should provide a lot of clues.
Forth actually helps here, because a complex application
in Forth will generally take a lot less source than the
same application written in a bulkier language like C.
And if you complain that this documentation isn't available,
then I say that's a management problem, not a language
problem.
> ...
> Well written Forth code should not be hard to read, but taking
> a semantic language out of context will make it difficult or
> impossible to read, because it is all about defining new semantics.
> Syntactic languages have this problem to a lesser degree
> for reasons already mentioned, they slow down the reader,
> they provide lots of redundant cues in the rigid syntax.
> But of course it takes a lot longer to teach them or learn
> them, and a lot longer to code with them, and they require more
> source and object code. Reading a short story is easier than
> reading a long novel.
>
> Speed reading generally does not work on code.
I agree with all this.
Cheers,
Elizabeth
Jeff Fox
> Still, this is fairly illuminating. If a comprehensive, holistic approach
> is required and facilitated by Forth that explains why Forth thrives in
> small projects (and if they are mostly software, can keep them small).
> Isolable parts of big projects that are otherwise small-project-like also
> qualify here.
Many Forth programmers claim an order of magnitude compression over
sources in more linear languages. Chuck claims, and rightfully so
from what I have seen, an order of magnitude more compression than
other Forth programmers. So when he says that Forth is like a
compression algorithm and that it should require about 1% of the
code required by say 'C' it upsets many people.
> It also explains why Forth becomes a burden when the hardware and
> conceptual parts of the project are complex and have complex connections
> to the software: in this case a division of labor is required that breaks
> the holistic approach.
Yes and no. I have heard of large projects in Forth that had to
deal with the same hardware and many layers of the same software
complexities as most people, but they still claim to achieve
more compressed code and do it faster.
> In the end, Forth is only software: it cannot simplify everything.
This was true more than twenty years ago, but it isn't any more.
Chuck said twenty years ago that the software problem was solved
(ie. Forth has proven itself at Forth Inc.) and the remaining
serious problem was hardware. So he set out just before the
middle of Forth's history to make Forth hardware, to apply
the concepts of Forth as a methodology to hardware design.
This then led to simpler Forth software for the greatly
simplifed Forth hardware. The process was slow when the
CAD was being done with conventional software, but then
again Forth software proved to be most useful for designing
Forth hardware.
Forth is not just software, or hardware, it is a way of
solving problems. You seem to have been looking at something
other than Forth for the last twenty years. In the end,
you are wrong about that.
> It fits my experience. What a ahame. In my position, as architect of
> projects that start simple but usually become complicated, Forth is a
> trap.
The trap is in your head, just like with most people. Forth was
designed to avoid traps. The hard part is that most people take
the traps in their head for granted.
> That's certainly what I experienced the last time around, and if
> high level Forth skill is as holistic as you say, it's inevitable. Too
> bad, I like Forth (but then again, I also like C, so don't cry too much
> for me :-).
I won't. I have no doubt that you have had limited sucess with such
limited and antiquated notions about Forth. But if C works for you
then have at it.
Laymen often picture things like spacecraft as using state of the
art hardware and software when it fact it is a very conservative
community. Like many academics that like things to be proven for a
long time before they accept them they are not in a position to
use or teach stuff that isn't fairly conservative. Laymen don't
appreciate that the manufacture and assembly quality of the
hardware for a space mission is state of the art, but the
components, software, and design methodologies tend to be
very conservative and pretty old fashion.
> Teaching people to write LSE was never hard. It was especially easy with a
> student who'd just built a gadget that plugged into the bus: teach 'em how
> to enter and print hex, @ and ! and maybe : and show 'em the 6 page doc on
> the 50 app words and editor and show 'em example driver code and set 'em
> loose. Bright kids around here, a few days later I'd have a driver (unless
> the hardware debugging went badly). This process never produced anyone who
> could maintain someone else's driver, though. I was the only one who
> could do that (that's part of the trap).
It doesn't sound like they had any training from professional Forth
software instructors. That is a fairly common description of what
happens when hardware engineers teach one-of engineering style Forth to
other hardware engineers. Some of the worst Forth code I have seen
was that type. It worked, but no-one would want to maintain such
poorly written Forth.
> I don't think it would go so smoothly with ANS (but I know you
> agree with me).
Yes, but I still think that having an expert teacher for Forth
is very important. Much of Forth's reputation came from clueless
Forth newbies teaching other people to be clueless Forth newbies
while thinking that they were Forth experts.
> Sure. I remember lo those many years ago when Jon Sachs introduced me to
> Chuck's work. Code by a master is a joy to read. If you read Ritchie's
> Unix V6 kernel, most of the C code is as clear as water. Unfortunately, I
> usually have to make do with code written by mere mortals, and get mere
> mortals to maintain it.
It has been suggested that you and your department might benefit
from some more modern Forth training. A little Forth is great for
an experimenter or an engineer to get a job done dirty and fast,
but without good training in writing good (readable and maintainable)
Forth it could be a nightmare. Forth code can certainly be worse
than more rigidly structured languages. Since Forth is like an
amplifier it can amplify good or bad ideas.
Best Wishes,
Jeff Fox
Albert van der Horst
John Doty <j...@w-d.org> wrote:
<SNIP>
>
>So I'll ask you the same question I've been asking others: when reading a
>line of Forth containing unknown words, how do *you* decide what to look
>up first?
I think alphabetically is best.
I handle Forth phrases like a phrase in any foreign language.
If I am reading a book, I gloss over a phrase with unknown words
as long as I don't loose track.
If there is a phrase I *must* understand, I look up *all* words
I don't understand. The order is utterly unimportant.
I think alphabetically is easiest on the dictionary.
The above gives a reason why Forth is hard to read. Glossing over
things in a Russian book is easier because there remains a clue.
Looking up Forth words often doesn't make sense because there
is no definition (specification), merely a stack diagram.
Russians are not in the habit of defining a new word each page
that you *must* understand in order to understand the remainder
of the book.
>| John Doty "You can't confuse me, that's my job."
Groetjes Albert
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Q.: Where is Bin? A.: With his ma. Q.: That makes the Saudi's
terrorists, then? A.: No, George already owns their oil.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
John Doty
> > This process never produced anyone who could maintain someone else's
> > driver, though. I was the only one who could do that (that's part of
> > the trap).
>
> It doesn't sound like they had any training from professional Forth
> software instructors. That is a fairly common description of what
> happens when hardware engineers teach one-of engineering style Forth to
> other hardware engineers. Some of the worst Forth code I have seen was
> that type. It worked, but no-one would want to maintain such poorly
> written Forth.
This is even more discouraging than your last theory. If this were true, a
loose collaboration of application experts and students would be unable to
employ Forth usefully. It's one thing to train a specialist or two, quite
another to train a whole bunch of part-timers.
This theory does not, however, match my experience. Between 25 and 10
years ago a very loose and shifting collaboration of people (not one of
whom was trained in Forth) produced, in my lab, a series of overlapping
Forth applications that were very successful. I found them very readable:
indeed I still look at them occasionally to refresh my memory about
particular ideas that worked well.
Your theory that Forth must be read holistically fits my experience much
better, since for much of this history I was the only one in a position to
do that easily.
Pat LaVarre
> > Date: 2003-03-22 15:26:02 PST
> >
> > In chips with stack depths less than 8 cells about
> > 1% of the code must manually spill/fill stacks. In
> > chips with 16 or more cells it is about 0%.
>
> Date: 2003-03-22 12:32:05 PST
>
> ... you don't declare the stack empty, you just
> consider it is, the current state is of no
This steps me forward, thanks, but no farther than the next brick
wall.
Supposing I have a shallow circular stack, I can readily imagine I
will sometimes want to page my stack out. I think by "spill" we mean
page out i.e. copy the content elsewhere. I think by "fill" we mean
page in i.e. copy the content back.
My question is, how do I know WHEN I want to page out the stack and
WHEN I want to page in the stack?
To me, this sounds like writing assembly code that does not preserve
and restore registers. When I change the called code to use another
register, I have to review all the calling code, to know that the
calling code didn't store context in a register that I didn't push.
Is that the idea here?
The development system for such a Forth should calculate the stack
depth apparently needed by each of my words, and tell me if ever I
appear to have overflowed the stack depth I have?
In the absence of such automatic help, I have to augment my stack
diagrams?
For example, in the Jvm, 2DUP and DROP are machine codes (x5C dup2 and
x57 pop), but OVER is not. So to say I use 4 cells to do OVER maybe I
write:
: OVER ( x1 x2 --4-- x1 x2 x1 ) 2DUP DROP ;
Is this what we mean?
This could be a nightmare in maintenance. To change whether OVER uses
4 cells or 3 or 5, I have to revisit ever word that calls OVER, every
word that calls one of those words, etc.
Is this what we mean?
Curiously, cluelessly, thankfully yours, Pat LaVarre
Jeff Fox
> This is even more discouraging than your last theory. If this were true, a
> loose collaboration of application experts and students would be unable to
> employ Forth usefully. It's one thing to train a specialist or two, quite
> another to train a whole bunch of part-timers.
Yes, but my point is that what is important is an expert trainer.
Like in many other non-trivial things doing and training are two
quite different things. Doing is somewhat natural and trying to
analyze what you are doing often gets in the way, so people tend
to do things in a way that is natural for them and without thinking
too much about what they are doing. They work around their problems
and go on. But teaching requires understanding the kinds of problems
that other people have, and often takes much more experience and
more reflection than just doing. This may not be true for things
like riding a bicycle but for some things training really requires
a master of the art. Some martial arts can be taught with some
success by one relative beginner to a complete newbie, but others
will never make much progress unless they have a master to learn
from.
> This theory does not, however, match my experience. Between 25 and 10
> years ago a very loose and shifting collaboration of people (not one of
> whom was trained in Forth) produced, in my lab, a series of overlapping
> Forth applications that were very successful. I found them very readable:
> indeed I still look at them occasionally to refresh my memory about
> particular ideas that worked well.
You found it readable but you lament that the problem with it was
that you could not teach newbies to read it and you ended up having
to do all the maintenance. This is a sign that your students only
made it so far.
I also pointed out that there are plenty of books written by masters
to assist in teaching languages like C and few in Forth. The last
time I visited the largest bookstore in the Western US I counted
over 300 books on C and C++ and not one book on Forth. So unless
you can provide a textbook written by a master the problem is
more difficult.
> Your theory that Forth must be read holistically fits my experience much
> better, since for much of this history I was the only one in a position to
> do that easily.
I recall that Dr. Tim Hendtlass of Swinbourne University taught a
class on computer hardware interfacing. But of course the students
also had to deal with the software side to get their assignments
working and debugged. He first taught the course using assembler
and a certain percentage of the students failed the course because
they just could not grasp assembler. The students had to deal with
timing, interrupts, ISR, ports, etc. and although some could deal
with the hardware concepts the software was just beyond them.
Then Tim changed the course to use Forth for the software rather
than assembler. This made the software so much easier that no
students ever failed the course after that. He made the text
that he used, Hardware Interfacing using Forth, available in
print and online.
I first met him at a FORML conference in 1991 when he presented
a paper on a project involving distributed expert systems with
learning neural nets in Forth for a project for the government.
He gave a very interesting presentation and had interesting
stories about his success in using Forth for teaching
engineering concepts at the university.
I also heard many stories from Dr. Montvelishsky about his use
of Forth for teaching various courses at the University in Saransk.
He taught parallel processing, expert systems, fuzzy logic, and
industrial CAD/CAM all in Forth with great success. He used
serious real applications used in industrial applications for
teaching. But they had an excellent Forth textbook to work
from.
But it is your problem and you will have to deal with it
in the way you see fit. It is not my problem if you have
had limited success in teaching students to be able to
read and write Forth and to maintain applications. So
if you end up having to do it all yourself then Forth
isn't working very well for you. Do whatever you need
to do to get the work done. If you have better luck
teaching something else then have at it.
I have seen plenty of people come into c.l.f and describe
their problem then argue with every person who offers them
advice. Take it or leave it. If it is of no value to you
then find something else that works for you.
Best wishes,
Jeff Fox
Jeff Fox
> This steps me forward, thanks, but no farther than the next brick
> wall.
I would recommend rereading Dr. Koopman's chapter on the issue
of stack spill/fill and the various stragies that had been
employed in hardware or software to deal with it. This will
give you a footing to approach the concepts and techniques
that have evolved since then.
> My question is, how do I know WHEN I want to page out the stack and
> WHEN I want to page in the stack?
You can manage that as the programmer, you can let the compiler
manage that for you, you can let the hardware manage that for
you. You can also learn to avoid the problem in many cases.
But as I say start with a review of the classic literature
on the subject.
I don't think there is only one way. I have not used automatic
stack spill/fill hardware and have only worked on systems where
the compiler or the programmer have to deal with it. But the
systems I have worked with also have a long list of techniques
which minimize the problem.
I prefer to let the programmer handle it rather than let the
compiler handle it. But in the last ten years I have had
zero instances where it was required. So I don't see it as
a big problem.
> In the absence of such automatic help, I have to augment my stack
> diagrams?
I think that helps. I have tried to discuss the subject before
in c.l.f but usually people have had so much trouble understanding
the environment that I was talking about that I spent most of the
time trying to bring the discussion back to reality instead of
people's wild misconceptions about what I was saying about stack
diagrams.
People would say, well that would be crazy with my ANS Forth
code, it wouldn't work, no one in their right mind would try
something like that. Of course I have to agree with that
because I understand what they are thinking. But it is not
what I talk about. Of course some ANS Forth programmers have
responded saying that 18 cells on the parameter stack and
17 cells on the return stack should be sufficient for any
reasonably coded Forth app whether it is ANS or some other
dialect. Others talk about needing 4KB or 64KB or 6MB of
stack space in their code.
> For example, in the Jvm, ...
I am talking about Forth not JAVA. Let's agree to talk
about this in a Forth context.
best wishes,
Jeff Fox
Pat LaVarre
> > than the next brick wall.
>
> I would recommend rereading Dr. Koopman's chapter
http://www.google.com/search?q=Koopman+stack+spill+fill
yields:
http://www.ultratechnology.com/ml0.htm
http://www.jwdt.com/~paysan/4stack.pdf
Irrelevant, yes?
http://groups.google.com/groups?q=Koopman+stack+spill+fill
yields:
http://groups.google.com/groups?as_umsgid=95shs1%249lv%241%40nnrp1.deja.com
http://www.cs.cmu.edu/People/koopman/stack_computers/index.html
Click thru to there redirects to:
http://www.ece.cmu.edu/~koopman/stack_computers/index.html
Stack Computers: the new wave
Philip J. Koopman, Jr.
Published in 1989
This is what we mean?
> > For example, in the Jvm, ...
>
> I am talking about Forth not JAVA. Let's agree to
> talk about this in a Forth context.
Sorry, I don't understand.
How does choosing an example target cpu move me out of a "Forth
context"?
Does c.l.f netiquette require that I just not name my target cpu?
That I can easily do:
[Suppose] 2DUP and DROP are machine codes ..., but OVER is not. So to
say I use 4 cells to do OVER maybe I write:
: OVER ( x1 x2 --4-- x1 x2 x1 ) 2DUP DROP ;
Does this example fall with"in a Forth context"?
Pat LaVarre
Jerry Avins
>
> ... my point is that what is important is an expert trainer.
> Like in many other non-trivial things doing and training are two
> quite different things. Doing is somewhat natural and trying to
> analyze what you are doing often gets in the way, so people tend
> to do things in a way that is natural for them and without thinking
> too much about what they are doing. They work around their problems
> and go on. But teaching requires understanding the kinds of problems
> that other people have, and often takes much more experience and
> more reflection than just doing.
It also needs an understanding of how a concept can be difficult. Once
the details of a subject become "obvious" to them -- math from long
division to differential equations provides plenty of examples -- many
people lose the ability to help others gain the same understanding. A
good teacher not only knows the subject, but retains an awareness of why
some parts of it aren't obvious to the as-yet untutored.
> This may not be true for things
> like riding a bicycle but for some things training really requires
> a master of the art. Some martial arts can be taught with some
> success by one relative beginner to a complete newbie, but others
> will never make much progress unless they have a master to learn
> from.
>
It may take a master to teach, but not every master can teach. Those who
merely say "Look! It's easy!" (or "It works!") should be barred from
teaching.
...
Sorry for the rant. You resonated with one of my pet peeves.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯