Forth Frustrations
George Peter Staplin
I was working on an interface to my new window system in Ficl. I found
it extremely frustrating to juggle around data on the stack, such as 2
RGBA color components when building a gradient. 8 items or more.
So, I asked in #Forth and was told not to do that, because I shouldn't
have more than 3 or 4 items on the stack at once. My code was horrible
apparently. So, I used allocate, and then I had to call free. I grew
tired of that interface. Then it occured to me that people building
large matrices in Forth would of course have more items on the stack
than that, so the Charles Moore dogma doesn't apply, and it's a bad
dogfood. I suppose people may not even do that with Forth though. The
constraints imposed by the community and Charles Moore have limited
Forth.
So, I came upon another solution. I added a concept that I call a "super
local," to Ficl's C code. A super local works like this:
: quad 4 parse-word (superLocal) ; immediate compile-only
: some-word quad color1 ( pops 4 items ) quad color2
color1 ( pushes 4 items ) ;
Only then did I discover that doesn't really help me in most cases to
reduce complexity. I talked about my (superLocal) in #Forth and was of
course criticized. The Forth community I'm getting the impression likes
to criticize. I've been accused of programming C in Forth, as if that's
somehow terrible, but I digress... I realized that I need a way to get
the cells in an individual super local. That's where I stopped. I was
thinking that indexed keyed arrays might be an approach, or a completely
different language.
Now unmotivated and realizing that the structure really sucks in my Ficl
code by some standards, I wrote some C code and felt much better. I
think C is much easier, because it comes with rich structure abilities
out of the box. As Rob Pike once said in his notes on C:
"Rule 5. Data dominates. If you've chosen the right data structures
and organized things well, the algorithms will almost always be
selfevident. Data structures, not algorithms, are central to
programming. (See Brooks p. 102.)"
I believe page 102 is from the Mythical Man Month, and the subsection of
that reads "Representation is the essence of programming."
I feel sad, because my Forth books have mostly gone to waste. I ordered
them from Forth Inc. years ago, and have read them off-and-on since.
Since I left the Tcl community last year, I've tried to turn to Forth,
but now I find it's just not there. I hate being criticized for using
features of the language, and I see it happen in this newsgroup too.
I'll add my own too; I think that using the return stack words for
temporaries is dirtier than using a local.
So, I expect you all to tell me how wrong I am, and what an awful person
I am for posting this. Tell me how I should use a different language
(again). Go right ahead. You can write me off as a troll if that makes
you feel better. :(
Sincerely,
-George
Andrew Haley
> So, I expect you all to tell me how wrong I am, and what an awful
> person I am for posting this. Tell me how I should use a different
> language (again). Go right ahead. You can write me off as a troll
> if that makes you feel better. :(
Not at all; you're just not very good at writing Forth. If you think
in C while writing Forth, your code will be very bad. The same would
be true if you thought in C while writing LISP or Haskell.
Andrew.
pablo reda
not let the arm down !!
try RGBA in one number (not separate the component) and then you
reduce the 4 numbers to 1
when calc (one component at time...or two (some trick can be made;) )
separate..calc..and acumulate.
this is my code for mix 2 color with alpha chanel
ink is the color1 and the second is in the stack
>> is shr
:mix | alpha color -- ncolor
dup $ff00ff and ink $ff00ff and
over - pick3 * 8 >> + $ff00ff and >r
$ff00 and ink $ff00 and
over - rot * 8 >> + $ff00 and r> or ;
you can see, I use pick3 (3 pick for some other forth).
I have a GUI interface and need a gradient too ;)
if you like, try my lang
good luck
Brad Eckert
<georgepsSPAMME...@xmission.com> wrote:
>
> So, I expect you all to tell me how wrong I am, and what an awful person
> I am for posting this. Tell me how I should use a different language
> (again). Go right ahead. You can write me off as a troll if that makes
> you feel better. :(
>
How do we know you're not Marvin the Android?
Post the algorithm here so we can code it. One of the best ways to
learn Forth is to study good Forth code such as the stuff that comes
with the commercial Forths. You can find good Forth online too but you
can also find bad Forth. Getting started programming in Forth was a
struggle for me too, even though I had written a Forth.
Brad
John Passaniti
> Not at all; you're just not very good at writing Forth. If you think
> in C while writing Forth, your code will be very bad. The same would
> be true if you thought in C while writing LISP or Haskell.
Then show him a "good" solution in Forth. Your response provides no
guidance other than the generic "hey, think in Forth." How is that
useful to him or anyone else?
John Passaniti
> Hi George,
>
> not let the arm down !!
>
> try RGBA in one number (not separate the component) and then you
> reduce the 4 numbers to 1
> when calc (one component at time...or two (some trick can be made;) )
> separate..calc..and acumulate.
This assumes that the width of each RGBA component sums to less than or
equal to the number of bits in a cell. This is (very) common, but he
didn't state that. There are currently video displays that can show
more than eight bits for each color and there are other kinds of output
devices (like printers) where each color component could be more than 8
bits.
Chances are that yes, he can represented his RGBA quad as a packed array
of bits and reduce the number of stack items. But let's assume that
wasn't the case. What would a decent solution be?
Bruce McFarling
<georgepsSPAMME...@xmission.com> wrote:
> So, I expect you all to tell me how wrong I am, and what an awful person
> I am for posting this. Tell me how I should use a different language
> (again). Go right ahead. You can write me off as a troll if that makes
> you feel better. :(
Post the code ... descriptions tend to get analytic answers, code
with problems tends to get code solutions.
The allocate/free thing with local structures is one reason I
suggested a local buffer allocating word, only to find that
two full-featured forths had something along the same lines.
However, in general, to simplify allocate/free problems with
structured data:
* define structures that you will be working with in groups
with a "next-item" cell at the front of the structure;
* allocate a set of structures you will be working with
together as a linked list;
* write a de-allocator that frees every structure in the list
Then to localize it, the same word creates the structures,
fills them with data, calls the code that works on the
structures, and frees them at the end. That means that
you can hang the linked list off a first structure
address that is tucked out of the way on the R-stack
until the end of the word.
Oh, and dereference the structure as late as possible
and get data from the stack into the structure as
early as possible. That allows you the greatest
freedom to change the definition of the structure
at some later time with the minimum of re-writing.
Its not the "having" eight or 16 items on the stack
that is the "don't do that", its the retaining them
on the stack. If you happen to have 16 cells on
the stack, pack them into a structure and now they
are one item on the stack.
J Thomas
>
> I was working on an interface to my new window system in Ficl. I found
> it extremely frustrating to juggle around data on the stack, such as 2
> RGBA color components when building a gradient. 8 items or more.
>
> So, I asked in #Forth and was told not to do that, because I shouldn't
> have more than 3 or 4 items on the stack at once.
But it sounds like you're saying you *need* 8 items on the stack at
once so you can give an OS routine what it needs. So that advice is no
good for you.
Either find a way to do it with only a few items on the stack, or look
for some innovative solution.
For example, you might possibly put your data into a data structure,
and then point your stack pointer at your data to make the OS call.
This is not something that Forth programmers would do very often, but
if your problem needs it maybe you can make it work. If you can't move
your data to the stack, move your stack to the data.
Or possibly you can leave the data in your data structure and still
use it.
Or perhaps there's a way to get the first item completely settled, and
then work on the second item and get it completely settled, etc. It
isn't hard to put 8 items on the stack if you only have to play with
the top couple at any time. Then you make your call and it all goes
away.
Forth is supposed to encourage you to find a simple way to deal with
it. If there just *isn't* any simple way then you could spin your
wheels looking for it.
> I think C is much easier, because it comes with rich structure abilities
> out of the box.
If you still want to try Forth, and you feel like you need data
structures, you might find out how to make what you want easily. Forth
doesn't come with much in the way of data structures, but if it turns
out that you can make what you need about as easily as you can
describe what you want in another language, then you haven't lost
much.
There's a proposal to make standard data structures for Forth, and if
you like those then you or someone else might make them for FICL.
Anyway, I think the steps are:
1. Look for a simple way to get the result you want.
2. Failing that, look for a way to simplify the problem and then
repeat step 1.
3. Failing that, gut it out with locals or whatever looks like it will
help.
John Doty
Forth is great when data flow can easily be made LIFO (and it often
can). Forth stumbles when the data flow is not naturally LIFO,
especially if you worry too much about conformance to dogma.
One technique that often helps is to use variables. There, I'm a Forth
heretic. But everybody knows that ;-)
>
> Now unmotivated and realizing that the structure really sucks in my Ficl
> code by some standards, I wrote some C code and felt much better. I
> think C is much easier, because it comes with rich structure abilities
> out of the box.
The problem isn't that Forth needs structure abilities out of the box.
What it needs is real portability, a usable library mechanism, and a
collection of published libraries, including structures.
I'm user of a C-based Forth, LSE64. When C's the right thing, I'll drop
into C. Forth makes a fine scripting language (and much more) for C.
> As Rob Pike once said in his notes on C:
> "Rule 5. Data dominates. If you've chosen the right data structures
> and organized things well, the algorithms will almost always be
> selfevident. Data structures, not algorithms, are central to
> programming. (See Brooks p. 102.)"
>
> I believe page 102 is from the Mythical Man Month, and the subsection of
> that reads "Representation is the essence of programming."
It's a good way to think about programming, at least until it stops
working. Then try another way.
>
> I feel sad, because my Forth books have mostly gone to waste. I ordered
> them from Forth Inc. years ago, and have read them off-and-on since.
> Since I left the Tcl community last year, I've tried to turn to Forth,
> but now I find it's just not there. I hate being criticized for using
> features of the language, and I see it happen in this newsgroup too.
> I'll add my own too; I think that using the return stack words for
> temporaries is dirtier than using a local.
Indeed. Too many Forthers delight in write-only code.
>
> So, I expect you all to tell me how wrong I am, and what an awful person
> I am for posting this.
Nope. I'm going to tell you how right you are. But don't give up on
Forth: like most things it's like the girl with the curl ("When she was
good, she was very, very, good, but when she was bad she was horrid.").
Use the good, avoid the horrid.
> Tell me how I should use a different language
> (again). Go right ahead. You can write me off as a troll if that makes
> you feel better. :(
Humans are prone to idolatry. But programming is a practical activity:
just be practical.
>
> Sincerely,
>
> -George
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Andrew Haley
> Andrew Haley wrote:
>> Not at all; you're just not very good at writing Forth. If you think
>> in C while writing Forth, your code will be very bad. The same would
>> be true if you thought in C while writing LISP or Haskell.
> Then show him a "good" solution in Forth. Your response provides no
> guidance other than the generic "hey, think in Forth."
If his posting had been phrased in the form of a "how can I do this"
question rather than a long whine, my reply would have been different.
It was a direct response to the part I quoted, and which you trimmed,
perhaps in order to make my reply look like a non sequitur. Happily,
the whole of that post is still available.
If we had a bit more information about the actual problem it might be
possible to reply in a way that might help someone who wants to solve
it in Forth. However, I do not believe the OP falls into that
category.
Andrew.
Charlie Springer
(in article <1175526892.2...@e65g2000hsc.googlegroups.com>):
>> I'm extremely frustrated by Forth lately.
>>
>> I was working on an interface to my new window system in Ficl. I found
>> it extremely frustrating to juggle around data on the stack, such as 2
>> RGBA color components when building a gradient. 8 items or more.
>>
>> So, I asked in #Forth and was told not to do that, because I shouldn't
>> have more than 3 or 4 items on the stack at once.
Sounds like you might like an OOForth like Win32Forth. The Yerk/Neon object
model is much better than C++. I agree about the return stack. I never liked
moving data to an "address" stack. It is a notorious source for errors. On
the ARM or any RISC with loads of registers I have a bunch of stacks; a loop
stack, an FP stack, etc. I have never added a locals stack, but might give it
a try.
I never use pick or roll. I find it generally faster and easier (and a lot
more readable) to pluck the items from a data structure. Besides, I am mired
in the simplicity of the Fig-Forth past - no roll, pick, nip, tuck, trim,
etc. - and avoid standard forth except as the basis for Win32Forth or Mops.
-- Charlie Springer
John Doty
> I never use pick or roll. I find it generally faster and easier (and a lot
> more readable) to pluck the items from a data structure. Besides, I am mired
> in the simplicity of the Fig-Forth past - no roll, pick, nip, tuck, trim,
> etc. - and avoid standard forth except as the basis for Win32Forth or Mops.
Sounds like you're *liberated* by the simplicity of the Fig-Forth past!
Andreas Kochenburger
<depressive eruption snipped>
Obviously
a) when you get lost in stack juggling, use locals
b) when you need structures, use a structures package for Forth
Apparently
a) you had complete data sets on the stack and that blocked the rest
b) if you don't want to use pointers to allocated memory, consider
abstraction. The simplest way:
- create a new data stack for quads (that's easy)
- define some operators that work on the stack QPUSH, QPOP, QTRANSFORM
et cetera whatever
- define a global storage word e.g. QVARIABLE along with Q@ and Q! (or
QVALUE and QTO)
c) if you are familiar with OO, why not use it? You use FICL, don't you?
I guess that b) might be sufficient -> you're code readability will
improve, your mistakes will become less, and the sun will shine again ;-)
--
Andreas
-------
MinForth: http://minforth.net.ms/
John Doty
> a) when you get lost in stack juggling, use locals
That usually doesn't help because if the problem is complicated enough
to need stack juggling it's almost always too complicated for a single
word of sane length. Words using locals are often just as "write-only"
as words using fancy stack gymnastics.
Bruce McFarling
> But it sounds like you're saying you *need* 8 items on the stack at
> once so you can give an OS routine what it needs. So that advice is no
> good for you.
Yes it is ... write a word that takes a structure pointer
and pulls the data onto the stack for the OS routine.
IOW, encapsulate the deep use of the stack so that the Forth
code does not have to worry about it.
Andreas Kochenburger
> Andreas Kochenburger wrote:
>
>> a) when you get lost in stack juggling, use locals
>
> That usually doesn't help because if the problem is complicated enough
> to need stack juggling it's almost always too complicated for a single
> word of sane length. Words using locals are often just as "write-only"
> as words using fancy stack gymnastics.
>
Factoring is one thing. But some algorithms or formulae do not allow it.
Giving operands names makes life simpler for the human mind, which
usually works with associations. You don't read sequentially by the
letter, your brain does a pattern matching of the "gestalt" of a word.
The other thing is that Forth locals "lift weight" from the data stack,
it gets "disencrowded" (ha! I like this one ;-)
Elizabeth D Rather
> I'm extremely frustrated by Forth lately.
>
> I was working on an interface to my new window system in Ficl. I found
> it extremely frustrating to juggle around data on the stack, such as 2
> RGBA color components when building a gradient. 8 items or more.
>
> So, I asked in #Forth and was told not to do that, because I shouldn't
> have more than 3 or 4 items on the stack at once. My code was horrible
> apparently. So, I used allocate, and then I had to call free. I grew
> tired of that interface. Then it occured to me that people building
> large matrices in Forth would of course have more items on the stack
> than that, so the Charles Moore dogma doesn't apply, and it's a bad
> dogfood. I suppose people may not even do that with Forth though. The
> constraints imposed by the community and Charles Moore have limited
> Forth.
>
> Now unmotivated and realizing that the structure really sucks in my Ficl
> code by some standards, I wrote some C code and felt much better. I
> think C is much easier, because it comes with rich structure abilities
> out of the box. As Rob Pike once said in his notes on C:
> "Rule 5. Data dominates. If you've chosen the right data structures
> and organized things well, the algorithms will almost always be
> selfevident. Data structures, not algorithms, are central to
> programming. (See Brooks p. 102.)"
>
> I believe page 102 is from the Mythical Man Month, and the subsection of
> that reads "Representation is the essence of programming."
Rule 5 is essentially correct in Forth as well as any other language.
And Forth offers exceptionally flexible ways to organize data
structures. It's just that they aren't necessarily the *same* as the
way you'd do it in other languages.
I have the impression you're looking at a set of choices that is
restricted to largish stacks, temporary memory allocations, and (some of
the suggestions in this thread) locals. Perhaps this is because some
other schools of programming regard global data structures as abhorrant,
but I certainly don't find that to be the case in Forth. On the
contrary, static data structures are the best way to communicate data
between a number of definitions in an application.
Many years ago I worked on some 2D and 3D graphics and image processing
applications. We designed appropriate data structures: for the
graphics, 2vectors and 3vectors. They were structures 2 or 3 cells in
size, automatically indexed by the words X, Y, and Z which set a
variable used as an index. There was a set of vectors for the current
cursor position, and if you wanted to move you just had to specify the
desired deltas. There were also special vector arithmetic words to add
vectors, multiply a vector by a ratio of scalars, etc. For image
processing, we had a much more elaborate structure called an "image"
which had a number of attributes as well as methods for reading and
writing rows. Nowadays this would be described in OOP terms, but this
was the 1970's, before such terminology was developed.
To me, one of the essential steps in attacking a new application is
understanding its data, and designing an appropriate data structure for
it. The stack is appropriate for handling temporary data (being
operated on at the moment or passed to other words), but not for large
assemblages of data, arrays, or strings. You make suitable structures
in memory and pass their address and length, or address and selector,
etc., whatever is convenient.
In the Windows environment, you often have to put together immense lists
of parameters for an OS call. However, those are assembled specifically
for the call, and not a working environment. Windows Forths, such as
SwiftForth, have OOP extensions to facilitate working with these things.
I'm not at all familiar with Ficl, but the products from FORTH, Inc. as
well as other modern Forths I'm familiar with have excellent facilities
for setting up application-specific data structures.
I agree with the other suggestions here: pose a specific challenge or
show us some code and we can offer more concrete suggestions.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
J Thomas
> John Doty wrote:
> > Andreas Kochenburger wrote:
>
> >> a) when you get lost in stack juggling, use locals
>
> > That usually doesn't help because if the problem is complicated enough
> > to need stack juggling it's almost always too complicated for a single
> > word of sane length. Words using locals are often just as "write-only"
> > as words using fancy stack gymnastics.
>
> Factoring is one thing. But some algorithms or formulae do not allow it.
If it can work to use an algorithm that does allow factoring, that
algorithm will usually be easier to write and debug, and it might be
simpler and also more efficient. But sometimes that isn't possible.
And sometimes there isn't time to spare to find out whether it's
possible or not.
> Giving operands names makes life simpler for the human mind, which
> usually works with associations. You don't read sequentially by the
> letter, your brain does a pattern matching of the "gestalt" of a word.
>
> The other thing is that Forth locals "lift weight" from the data stack,
> it gets "disencrowded" (ha! I like this one ;-)
The hope is that if you can keep it simple at the bottom layers, then
it can stay simple as you build on them. But when those are overly
complex and have an overly-complex interface, then the layers above
them will be complex too.
I like that philosophy. The problem is that sometimes you just need to
get it done. And if you gamble that you can make it simple and get it
done quickly that way, there's the chance you'll fail and end up with
no simple solution and insufficient time to do it the hard way.
So to follow that philosophy consistently you need not only the faith
that you can always make it work, and you need to actually be able to
make it work every time, quickly enough. Far easier to make that
gamble on amateur projects where there's no money or reputation riding
on it.
John Passaniti
Elizabeth D Rather wrote:
> Nowadays this would be described in OOP terms, but this
> was the 1970's, before such terminology was developed.
Smalltalk was concurrent with Forth; the terminology existed then.
Smalltalk also had it's antecedents (such as Simula) which also had
objects in the mid to late 60's.
John Doty
> John Doty wrote:
>> Andreas Kochenburger wrote:
>>
>>> a) when you get lost in stack juggling, use locals
>>
>> That usually doesn't help because if the problem is complicated enough
>> to need stack juggling it's almost always too complicated for a single
>> word of sane length. Words using locals are often just as "write-only"
>> as words using fancy stack gymnastics.
>>
>
> Factoring is one thing. But some algorithms or formulae do not allow it.
Only if you refuse to use variables or objects.
>
> Giving operands names makes life simpler for the human mind,
Indeed. That's what variables are for.
> which
> usually works with associations. You don't read sequentially by the
> letter, your brain does a pattern matching of the "gestalt" of a word.
>
> The other thing is that Forth locals "lift weight" from the data stack,
> it gets "disencrowded" (ha! I like this one ;-)
Use variables or an object instead. Then you can factor, too.
Gerry
> Andreas Kochenburger wrote:
> > a) when you get lost in stack juggling, use locals
>
> That usually doesn't help because if the problem is complicated enough
> to need stack juggling it's almost always too complicated for a single
> word of sane length.
Not so e.g. what about the example in a recent thread to re-order the
stack from ( a b c d -- d c b a ). I don't recall anyone suggesting
the local solution (using the F200X notation) which is simple and
clear.
: x { a b c d } d c b a ;
While this is covered by your 'almost always' cop-out, I don't believe
this is an isolated example.
> Words using locals are often just as "write-only"
> as words using fancy stack gymnastics.
As in Forth in general, only if the programmer makes it write only
e.g. by using meaningless local names.
Gerry
John Doty
> On 2 Apr, 18:07, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> Andreas Kochenburger wrote:
>>> a) when you get lost in stack juggling, use locals
>> That usually doesn't help because if the problem is complicated enough
>> to need stack juggling it's almost always too complicated for a single
>> word of sane length.
>
> Not so e.g. what about the example in a recent thread to re-order the
> stack from ( a b c d -- d c b a ). I don't recall anyone suggesting
> the local solution (using the F200X notation) which is simple and
> clear.
>
> : x { a b c d } d c b a ;
>
> While this is covered by your 'almost always' cop-out, I don't believe
> this is an isolated example.
I think it is. Even that one stretches the 7+-2 rule. Most uses of
locals are *much* longer.
>
>> Words using locals are often just as "write-only"
>> as words using fancy stack gymnastics.
>
> As in Forth in general, only if the programmer makes it write only
> e.g. by using meaningless local names.
No. A Forth definition should do one *simple* thing. Long, complex
definitions are generally hard to understand. But locals prevent
factoring of definitions into simple pieces.
J Thomas
> On 2 Apr, 18:07, John Doty <j...@whispertel.LoseTheH.net> wrote:
>
> > Andreas Kochenburger wrote:
> > > a) when you get lost in stack juggling, use locals
>
> > That usually doesn't help because if the problem is complicated enough
> > to need stack juggling it's almost always too complicated for a single
> > word of sane length.
>
> Not so e.g. what about the example in a recent thread to re-order the
> stack from ( a b c d -- d c b a ). I don't recall anyone suggesting
> the local solution (using the F200X notation) which is simple and
> clear.
>
> : x { a b c d } d c b a ;
>
> While this is covered by your 'almost always' cop-out, I don't believe
> this is an isolated example.
In this example, the problem was precisely to do stack juggling. It
wasn't particularly complex in itself. For example,
: x ( a b c d -- d c b a )
SWAP 2SWAP SWAP ;
But of course most solutions would use a little stack juggling, since
stack juggling is what the word is supposed to do.
If we had a problem that appeared to require this particular stack
juggling to get a solution, we might have found a way to solve it
without much stack juggling at all.
> > Words using locals are often just as "write-only"
> > as words using fancy stack gymnastics.
>
> As in Forth in general, only if the programmer makes it write only
> e.g. by using meaningless local names.
This is potentially testable. Find a body of code that uses locals,
and a similar body of code that doesn't. Get some people to judge how
write-only they both ard. If both sets come out, say, 30% write-only,
then he's right that words with locals are on average just as write-
only. Or we could grade each word, say on a scale of 1 to 5 for how
write-only it is, and if 30% of the regular words come out very write-
only (4 or 5) while 10% of the words with local reach that level, then
he might be right that words with locals are "very often" as write-
only as words without.
I'm not sure it's worth testing it, though we might find some other
interesting things if we tried. But if it isn't worth testing, is it
worth arguing about?
sl...@jedit.org
>
> I was working on an interface to my new window system in Ficl. I found
> it extremely frustrating to juggle around data on the stack, such as 2
> RGBA color components when building a gradient. 8 items or more.
Local variables are the wrong approach for this. If you are
programming in C, it might be good practice to write code like
int r,g,b,a;
Then have lots of rather arbitrary scalar expressions in r,g,b,a.
However this is a poor way of abstracting a color value because you
always have to deal with those four values as a group. The same is
true in C as well as in Forth.
When you realize that a color component is in fact a single entity --
or "object", if you will, you'll see that stack juggling is not a
problem at all. Computing something like a gradient becomes trivial:
you write some words to perform arithmetic on colors, then put
together a loop.
One way to define 'colors' as an entity in the language is to use OOP.
But on the other hand, if your color is really just a quadruple of
numbers -- integers or floats, depending on your window system, you
can get by with array processing words instead. If you can add
vectors, scale vectors and build a list of vectors, you can compute a
smooth gradient in a line of code. Take a look at APL and Lisp and
borrow the concepts.
The stack is incidental, by the way. Forth uses a stack because this
happens to be the simplest way to glue functions together -- you put
whitespace between them! When you're programming in Forth, you're not
programming with a stack, you're programming Forth. You get a stack
for free -- but it doesn't mean you have to store everything there.
Object systems, array processing and so on are really just examples of
data structures together with a library of supporting idioms. You can
build these in Forth -- this is Forth's strength.
I've found that in almost every case where I had to juggle a lot of
values on the stack, it meant that I was simply missing a higher
level, more declarative approach, one that would also give me a more
reusable abstraction for solving similar problems in the future.
Slava
John Doty
The important thing is jury selection. You need to find people who know
Forth, but aren't ideological about it. Not many of those around any more.
> write-only they both ard. If both sets come out, say, 30% write-only,
> then he's right that words with locals are on average just as write-
> only. Or we could grade each word, say on a scale of 1 to 5 for how
> write-only it is, and if 30% of the regular words come out very write-
> only (4 or 5) while 10% of the words with local reach that level, then
> he might be right that words with locals are "very often" as write-
> only as words without.
>
> I'm not sure it's worth testing it, though we might find some other
> interesting things if we tried. But if it isn't worth testing, is it
> worth arguing about?
>
sl...@jedit.org
take a look at the code George posted in the #forth channel:
http://forth.pastebin.ca/374026
It is more complex than it needs to be because it deals with the R/G/B/
A components as distinct stack values.
Here is a solution using an array processing library I came up with in
about 10 seconds -- this one is for Factor, but it isn't hard to
implement in any Forth:
: gradify-line ( color delta width -- seq )
dup [ / ] map-with [ v*n ] map-with [ v+ ] map-with ;
You turn width (which is an integer) into an array of scalars from 0
to 1. Then you multiply each scalar by the delta vector. Finally, you
add each scaled delta vector to the original color. The result is an
array of 'width' colors, smoothly transitioning from 'color' to 'color
+delta'.'.
The above is the first implementation I came up with but not the most
efficient; it creates multiple intermediate arrays. Here is another
one.
: gradify-line ( color delta width -- seq )
dup [ >r 3dup r> / v*n v+ ] map >r 3drop r> ;
This does not create any intermediate arrays, however now you have
some ugly stack shuffling. But we can introduce another abstraction.
There's a Factor library which defines versions of the array iterators
which preserve values on the stack. It is not loaded by default but it
is useful sometimes.
We can define a version that keeps 3 parameters;
: map-with3 3 map-withn ; inline
Now, we get something worthy of being called a one-liner:
: gradify-line ( color delta width -- seq ) dup [ / v*n v+ ] map-
with3 ;
All of this could be done in Forth with relatively little effort.
You'd need a reference counting memory allocator to manage your arrays
(if you don't want a full GC...).
Slava
J Thomas
> Just to show that my post wasn't completely incoherent babbling, let's
> take a look at the code George posted in the #forth channel:
>
> http://forth.pastebin.ca/374026
Thank you for pointing to his code.
: 4rot { a b c d }
b c d a ;
: 4swap { a b c d e f g h }
e f g h a b c d ;
: 4dup { a b c d }
a b c d a b c d ;
: 4drop
2drop 2drop ;
: 4over { a b c d e f g h }
a b c d e f g h a b c d ;
: 8dup
4over 4over ;
: gradify-rgba-deltas { r1 g1 b1 a1 r2 g2 b2 a2 }
r2 r1 -
g2 g1 -
b2 b1 -
a2 a1 - ;
: gradify-rgba ( rgba-addr -- r g b a )
dup c@ swap ( r addr )
1 + dup c@ swap ( r g addr )
1 + dup c@ swap ( r g b addr )
1 + c@ ;
: gradify-line ( r1 g1 b1 a1 ) { addr width rdelta gdelta bdelta
adelta }
width 0 ?do
4dup
\ red
4rot ( g b a r )
i rdelta width */ + addr c!
addr 1 + to addr
rot ( b a g )
i gdelta width */ + addr c!
addr 1 + to addr
swap ( a b )
i bdelta width */ + addr c!
addr 1 + to addr
( a )
i adelta width */ + addr c!
addr 1 + to addr
loop
4drop ;
OK, you want to wind up with data in a 4-byte structure. that looks
easy.
: +C! ( u c-addr -- )
TUCK C@ + SWAP C! ;
\ start with colors at c-addr in order r g b a
: +colors ( r g b a c-addr -- )
3 OVER + DO
I +C!
LOOP ;
Maybe better not to put all those values on the stack at once.
\ deltas between -128 and 127? If not, make delta a cell array
: sc@ ( c-addr -- n ) \ signed c@
C@ DUP 128 0 WITHIN IF NEGATE THEN ;
: +deltas ( delta-addr color-addr -- )
4 0 DO
OVER I + sc@
OVER I + +C!
LOOP 2DROP ;
gradify-line is hard to handle because at each step you need to have
1. the i-value
2. The width
3. the delta
4. the color-address
and to do it again you have to preserve all but the delta, as well as
the delta-address.
At least 4 items going in and at least 4 items coming out.
: grad-one-color-pixel ( i width delta-addr addr -- )
>R sc@ SWAP */
R> +C! ;
: grad-four-color-pixel ( i width delta-addr addr -- i width delta-
addr' addr' )
4 0 DO
2OVER 2OVER grad-one-color-pixel
1 1 D+ \ address buffer will never overflow
LOOP ;
: gradify-line ( delta-addr addr width -- )
>R 0 R@ 2SWAP R> \ 0 width delta-addr addr width
0 DO
grad-4-color-pixel SWAP 4 - SWAP
2SWAP NIP I SWAP 2SWAP
LOOP 2DROP 2DROP ;
The things that change the least should be at the bottom, but then we
have to stack-juggle when we do have to change them. width could go on
the bottom since it never changes, and then it's simpler
: gradify-line ( delta-addr addr width -- )
DUP >R 0 2SWAP R> \ width 0 delta-addr addr width
0 DO
grad-4-color-pixel
ROT 1+ -ROT
LOOP 2DROP 2DROP ;
but grad-one-color-pixel needs a ROT in place of its SWAP .
Probably better to use a variable or two.
2VARIABLE progress
: grad-one-color-pixel ( addr delta-addr -- )
sc@ progress 2@ SWAP */
SWAP +C! ;
: grad-four-color-pixel ( addr delta-addr -- addr' )
4 0 DO
2DUP grad-one-color-pixel
1 1 D+ \ address buffer will never overflow
LOOP DROP ;
: gradify-line ( delta-addr addr width -- )
DUP progress !
0 DO
I progress CELL+ !
OVER grad-4-color-pixel
LOOP 2DROP ;
This isn't tested. It could have trouble from deltas out of range, and
maybe byte-size colors could overflow and change sign. It requires
that the data be in buffers. I doubt it would be optimal even if you
got it cleaned up. You didn't like having to free ALLOCATEd buffers.
What if you have just one permanet buffer for deltas, You can load
that buffer whenever you want and then gradify things, as long as your
routines aren't re-entrant.
Where the original went wrong was, lots of things on the stack at once
and then they had to be juggled to get the right one on top. But if
you have an address, you can get just the one you want and all you
have to juggle is the ddress.
It's natural starting out to figure that everything should stay on the
stack. When I started out at one point I had 17 items on the stack and
I had a complicated paper diagram showing what happened, and I
couldn't understand how anybody could think it was easy.
The central trick is, when it seems like you're climbing up a hill of
glue, stop and look at what's making it hard. And then find some
easier way. Don't assume it's supposed to be hard.
ken...@cix.compulink.co.uk
jeth...@gmail.com (J Thomas) wrote:
> This is not something that Forth programmers would do very often,
Unless they were using Windows' calls. Given the number off parameters
that most of these use that is the recommended method with every
language I have used. It was recommended for just about any multi
parameter call. set up the parameter block and pass a pointer.
Ken Young
Gerry
> Gerry wrote:
> > On 2 Apr, 18:07, John Doty <j...@whispertel.LoseTheH.net> wrote:
> >> Andreas Kochenburger wrote:
> >>> a) when you get lost in stack juggling, use locals
> >> That usually doesn't help because if the problem is complicated enough
> >> to need stack juggling it's almost always too complicated for a single
> >> word of sane length.
>
> > Not so e.g. what about the example in a recent thread to re-order the
> > stack from ( a b c d -- d c b a ). I don't recall anyone suggesting
> > the local solution (using the F200X notation) which is simple and
> > clear.
>
> > : x { a b c d } d c b a ;
>
> > While this is covered by your 'almost always' cop-out, I don't believe
> > this is an isolated example.
>
> I think it is. Even that one stretches the 7+-2 rule. Most uses of
> locals are *much* longer.
I only count 4 items being handled - how does that stretch the rule?
(Incidentally I only gave this is as an example not as a
recommendation)
> >> Words using locals are often just as "write-only"
> >> as words using fancy stack gymnastics.
>
> > As in Forth in general, only if the programmer makes it write only
> > e.g. by using meaningless local names.
>
> No. A Forth definition should do one *simple* thing. Long, complex
> definitions are generally hard to understand.
Not necessarily, a sequence of simple operations making a more complex
definition can be easier to understand if well presented. Taken to
extreme your statement can lead to over-factoring
> But locals prevent factoring of definitions into simple pieces.
>
Not always. As Andreas stated earlier, locals can be useful - use them
when beneficial not as routine or for the sake of it. If you don't
want to use locals that's fine, who cares, but the trouble with
dogmatic statements like yours is that they get taken as fact by those
who know no better, like Forth newbies.
Gerry
rickman
wrote:
> John Passaniti <put-my-first-name-h...@japanisshinto.com> wrote:
> > Andrew Haley wrote:
> >> Not at all; you're just not very good at writing Forth. If you think
> >> in C while writing Forth, your code will be very bad. The same would
> >> be true if you thought in C while writing LISP or Haskell.
> > Then show him a "good" solution in Forth. Your response provides no
> > guidance other than the generic "hey, think in Forth."
>
> If his posting had been phrased in the form of a "how can I do this"
> question rather than a long whine, my reply would have been different.
> It was a direct response to the part I quoted, and which you trimmed,
> perhaps in order to make my reply look like a non sequitur. Happily,
> the whole of that post is still available.
But that does not make your reply any better. I find it funny that he
was "expecting" to be "accused of programming C in Forth" and then you
do exactly that!
I agree with George that some things seem difficult to do in Forth if
they involve a significant number of data items that need to be
manipulated. But I think he has the key to his own answer. He refers
to the "right" data structures which may not be on the stack. Perhaps
he needs to put the data in words to hold the structure he is using
and then define words that will pull the data out and perform the
various operations on that data. I seriously doubt that this will be
any less efficient than using C. I have seen C code do some very
lenghtly computations just to get to the data being used.
> If we had a bit more information about the actual problem it might be
> possible to reply in a way that might help someone who wants to solve
> it in Forth. However, I do not believe the OP falls into that
> category.
But then perhaps it would have been better to not post at all? Was
your post intended to help anyone in some way?
Andrew Haley
Perhaps, but newbies are precisely the people who will most benefit
from the advice not to use locals. Seasoned users will use their own
judgement anyway.
Andrew.
Andrew Haley
> On Apr 2, 11:20 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> John Passaniti <put-my-first-name-h...@japanisshinto.com> wrote:
>> > Andrew Haley wrote:
>> >> Not at all; you're just not very good at writing Forth. If you
>> >> think in C while writing Forth, your code will be very bad. The
>> >> same would be true if you thought in C while writing LISP or
>> >> Haskell.
>> > Then show him a "good" solution in Forth. Your response provides no
>> > guidance other than the generic "hey, think in Forth."
>>
>> If his posting had been phrased in the form of a "how can I do this"
>> question rather than a long whine, my reply would have been different.
>> It was a direct response to the part I quoted, and which you trimmed,
>> perhaps in order to make my reply look like a non sequitur. Happily,
>> the whole of that post is still available.
> But that does not make your reply any better. I find it funny that
> he was "expecting" to be "accused of programming C in Forth"
This is an example of what goes wrong if you snip quotes and then try
to paraphrase people. Actually, he said
"I've been accused of programming C in Forth, as if that's somehow
terrible ... I expect you all to tell me how wrong I am, and what an
awful person I am for posting this. Tell me how I should use a
different language (again). Go right ahead. You can write me off as
a troll if that makes you feel better"
which was the part I was responding to.
> and then you do exactly that!
I told him the truth.
>> If we had a bit more information about the actual problem it might be
>> possible to reply in a way that might help someone who wants to solve
>> it in Forth. However, I do not believe the OP falls into that
>> category.
> But then perhaps it would have been better to not post at all?
That's possible.
> Was your post intended to help anyone in some way?
You seem to be confused about the purpose of this group. It is not a
helpdesk: it is a forum for the exchange of information and opinions
on the subject of Forth programming.
However, yes, I think my message was helpful: rather than getting into
a big digression about technical matters, it focussed on the very core
of the problem, which was the OP's approach. From what he said, it
seems like he had already received some good advice on the #forth
channel.
Andrew.
J Thomas
> On 2 Apr, 22:52, John Doty <j...@whispertel.LoseTheH.net> wrote:
> > Gerry wrote:
> > >> Words using locals are often just as "write-only"
> > >> as words using fancy stack gymnastics.
>
> > > As in Forth in general, only if the programmer makes it write only
> > > e.g. by using meaningless local names.
>
> > No. A Forth definition should do one *simple* thing. Long, complex
> > definitions are generally hard to understand.
>
> Not necessarily, a sequence of simple operations making a more complex
> definition can be easier to understand if well presented. Taken to
> extreme your statement can lead to over-factoring
Easy to understand is kind of subjective. I've seen examples that fit
your claim for me.
Taken to extremes, practically any advice will be wrong.
> > But locals prevent factoring of definitions into simple pieces.
>
> Not always. As Andreas stated earlier, locals can be useful - use them
> when beneficial not as routine or for the sake of it. If you don't
> want to use locals that's fine, who cares, but the trouble with
> dogmatic statements like yours is that they get taken as fact by those
> who know no better, like Forth newbies.
The way newbies find out what works for them is to try stuff and
notice what isn't working well. I don't know any better way,
unfortunately.
My problem with locals is like the others -- by the time you need
locals to handle things like stack thrashing, your routine is already
too complicated and should be factored. And the locals then prevent
factoring. But locals might make the code more readable by providing
names. (Stack comments with those names might do just about as well,
if the factoring works.)
But on the other hand, locals don't do any particular harm. They don't
make the code badly inefficient. They don't make it unreadable. They
add a little complexity to the compiler but not much. So they aren't
harmful unless they're taken to extremes.
George got in trouble by trying to follow the Forth advice to do
everything on the data stack and not use data structures. That's good
advice if you don't take it to extremes.
There's no substitute for experience. And the trouble with learning by
trial and error is that you have to make errors to learn from. I'd
like to hope that the books put out by Forth, Inc. and MPE might at
least give lots of hints for good practice, so that Forth newbies can
follow good examples and get lots of early success and do their trial
and error slower.
rickman
> On Apr 2, 1:37 pm, Andreas Kochenburger <a...@nospam.org> wrote:
> > Factoring is one thing. But some algorithms or formulae do not allow it.
>
> If it can work to use an algorithm that does allow factoring, that
> algorithm will usually be easier to write and debug, and it might be
> simpler and also more efficient. But sometimes that isn't possible.
> And sometimes there isn't time to spare to find out whether it's
> possible or not.
I don't buy into the idea that an algorithm can't be factored. If it
can't be factored, then it must be so small that it is not needed.
The only time I could not factor a function to make it simpler to code
in Forth was when it had for loops with relatively little code inside
the loop other than stack juggling. Moving the inner code to another
function did not make anything more clear and actually would make it
worse since all references to the loop variable more difficult. If
there was much code inside the loop then it could easily be worth the
effort of making another function.
rickman
wrote:
What is your point? Your post said, "If you think in C while writing
Forth, your code will be very bad." That is the part I was reponding
to! You clearly told him exactly what he was afraid someone was going
to say.
> > and then you do exactly that!
>
> I told him the truth.
To what end? Your post had little value for anyone reading in this
group.
> >> If we had a bit more information about the actual problem it might be
> >> possible to reply in a way that might help someone who wants to solve
> >> it in Forth. However, I do not believe the OP falls into that
> >> category.
> > But then perhaps it would have been better to not post at all?
>
> That's possible.
>
> > Was your post intended to help anyone in some way?
>
> You seem to be confused about the purpose of this group. It is not a
> helpdesk: it is a forum for the exchange of information and opinions
> on the subject of Forth programming.
>
> However, yes, I think my message was helpful: rather than getting into
> a big digression about technical matters, it focussed on the very core
> of the problem, which was the OP's approach. From what he said, it
> seems like he had already received some good advice on the #forth
> channel.
If this group is not to provide help, when what do you see as its
purpose? "Exchanging information" sounds a lot like "help" to me.
The bottom line is that I see a lot of crap in this group and few
people chalenge it. A lot of it is people having petty arguments
among themselves to no visible purpose. There are also the
personality clashes. None of this is needed, but it happens. But
there is no reason to be short with someone asking for help, even if
their way of asking is to say, "I'm extremely frustrated by Forth
lately." Sounds like a cry for help to me!
John Passaniti
> I don't buy into the idea that an algorithm can't be factored. If it
> can't be factored, then it must be so small that it is not needed.
That's silly. An algorithm's ability to be factored has no relationship
on if the application needs that algorithm.
John Doty
>> No. A Forth definition should do one *simple* thing. Long, complex
>> definitions are generally hard to understand.
>
>
> Not necessarily, a sequence of simple operations making a more complex
> definition can be easier to understand if well presented.
Hardly ever happens.
> Taken to
> extreme your statement can lead to over-factoring
Over-factoring? So rare I've *never* seen it. Highly factored Forth is
invariably the most readable kind.
>
>
>> But locals prevent factoring of definitions into simple pieces.
>>
>
> Not always. As Andreas stated earlier, locals can be useful - use them
> when beneficial not as routine or for the sake of it. If you don't
> want to use locals that's fine, who cares, but the trouble with
> dogmatic statements like yours is that they get taken as fact by those
> who know no better, like Forth newbies.
Every *real* definition I've ever seen that used locals was too long to
be easily understandable by anyone but a Forth expert (by "real" I mean
something intended to be used, not just an example).
Charlie Springer
(in article <1175635813....@y80g2000hsf.googlegroups.com>):
> don't buy into the idea that an algorithm can't be factored. If it
> can't be factored, then it must be so small that it is not needed.
> The only time I could not factor a function to make it simpler to code
> in Forth was when it had for loops with relatively little code inside
> the loop other than stack juggling. Moving the inner code to another
> function did not make anything more clear and actually would make it
> worse since all references to the loop variable more difficult. If
> there was much code inside the loop then it could easily be worth the
> effort of making another function.
I'm not sure about factorability in an abstract sense but I can picture
situations where it can't be factored in a practical sense, such as in
handling an interrupt that is time sensitive or an interrupt that shares the
stacks and pointers in some way.
-- Charlie Springer
rickman
I didn't mean the algorithm is not needed, I mean the factoring is not
needed.
John Doty
Only if you don't care that the code is write-only.
rickman
> On Tue, 3 Apr 2007 14:30:13 -0700, rickman wrote
Why can an interrupt not be factored? Why can't the stacks be shared
in an interrupt? Interrupts depend on the stack so they can store a
return address. Anything stored on the stack is removed before
returning. Any other data the interrupt needs has to be staticly
allocated variables.
If you feel the time penalty of a call to a word is too expensive in
terms of time, then that may preclude factoring, but that is an issue
with the code being time critical and not an issue with factoring per-
se. There are any number of other shortcuts you are likely to take in
time critical code which defy general rules. This has nothing to do
with whether an algorithm is factorable or not.
Elizabeth D Rather
> On Apr 3, 4:19 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> The bottom line is that I see a lot of crap in this group and few
> people chalenge it. A lot of it is people having petty arguments
> among themselves to no visible purpose. There are also the
> personality clashes. None of this is needed, but it happens.
This exchange looks like a prime example, to me.
J Thomas
> I don't buy into the idea that an algorithm can't be factored. If it
> can't be factored, then it must be so small that it is not needed.
I'm an agnostic on this topic. Even when an algorithm looks hard to
factor usefully, it might be I just haven't seen how.
I vaguely remember one example. Years ago there was a competition to
find good sort algorithms coded in Forth. Some of them factored
nicely. Some factored recursively. But I vaguely remember that one of
them was just hard to do. It involved keeping track of a whole lot of
different things. First you'd fiddle with 4 or 5 of them, and then
you'd use that result to fiddle with a different 4 or 5 things, and so
on. You could break it into pieces but there was a lot of stack
juggling or else a lot of variables, and the factored pieces didn't
seem to make a lot of sense or yield good descriptive names.
It's quite possible that somebody who understood the algorithm better
could have factored it well. But the guy who presented it didn't find
a good factoring, and on a quick look I didn't either. So there might
be an example there, or maybe not.
You gave the example of looping code. That can be hard to factor in
Forth.
DO ... DO ... DO
K I Foo J I Bar K J Fubar I K Bam ...
You could factor it if you had a separate loop stack. And you could
test the code separately, you'd load test values onto the loop stack
and then run the code. But in portable standard Forth it isn't worth
factoring. Maybe if you didn't have DO you wouldn't think in ways that
create the problem.
I've had code with other complicated control structures that didn't
factor.
BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
I don't find this very readable, but it doesn't factor. Maybe there's
a better way to write it.
BEGIN
test1 0= IF result1 EXIT THEN action1
test2 0= IF result2 result1 EXIT THEN action2
test3 0= IF result3 result2 result1 EXIT THEN action3
test4 UNTIL result4 result2 result1 ;
This factors some, and it looks clearer to me.
: result2
result2 result1 ;
: result3
result3 result2 ;
: result4
result4 result2 ;
And this allows factoring if you don't mind passing a flag!
: part3
test3 IF action3 true ELSE result3 false THEN ;
: part2
test2 IF action2 part3 else result2 false THEN ;
: part1
test1 IF action1 part2 ELSE result1 false THEN ;
.... BEGIN part1 WHILE test4 UNTIL result4 THEN ....
So I was wrong, it does factor. You just have to be willing to pass
flags.
I got prejudiced against passing flags for that sort of thing because
of an experience when I was first learning Forth. Naturally I wanted
to factor my loops. So I was looking for something and I wanted to
quit when I found it.
: STREET?
... DO ... found? IF LEAVE true THEN LOOP false ;
: CITY?
... DO ... STREET? IF LEAVE true THEN LOOP false ;
: COUNTY?
... DO ... CITY? IF LEAVE true THEN LOOP false ;
: STATE?
... DO ... COUNTY? IF LEAVE true THEN LOOP false ;
It was just so tedious passing flags over and over to repeat a
decision that's already made.
We didn't have UNLOOP then. Now you can do it without factoring.
DO ... DO ... DO ... DO ... found? IF UNLOOP UNLOOP UNLOOP UNLOOP EXIT
THEN LOOP LOOP LOOP LOOP ;
Can you do it factored? Looks hard.
Somebody suggested using THROW and we all jumped on him. But it could
work.
: STREET?
... DO ... found? IF save-location 12 THROW THEN LOOP ;
['] STATE? CATCH 12 = IF get-location ELSE ." no match" THEN
It ought to work if you save your results. The cleanest solution I
see, everything else looks bad.
DO LOOP is an easy tool to use for simple tasks, but when you use it
for harder things it breaks in your hand.
hel...@gmail.com
experiences (I'm used to it very well).
FORTH is about building your own language that solves the problem. Tcl
is about using that minimal language applying the best tricks. (BTW:
You can use Tcl perfectly the same way as FORTH - but usually you dont
do so.)
You referred to RGBA-color components. If I see two of such color
definitions, there is no need for more than 2 values on the stack. You
could make this being pointers to the actual color definition.
So when you refer to FORTH missing something in language, you've not
implemented it. Dont complain about things you did not implement until
now. Go ahead, implement it and use your own idiomatic solution.
-Helmar
rickman
> rickman wrote:
> > On Apr 3, 7:10 pm, John Passaniti <n...@JapanIsShinto.com> wrote:
> >> rickman wrote:
> >>> I don't buy into the idea that an algorithm can't be factored. If it
> >>> can't be factored, then it must be so small that it is not needed.
> >> That's silly. An algorithm's ability to be factored has no relationship
> >> on if the application needs that algorithm.
>
> > I didn't mean the algorithm is not needed, I mean the factoring is not
> > needed.
>
> Only if you don't care that the code is write-only.
First, I will say your comment is a non-sequitur. I don't know what
you are saying makes the code write-only. When I see comments like
this, often repeated in this group like a mantra, I realize that no
real thought went into the comment. Can you explain what you mean?
My point is that if the code is small enough that it is hard to
factor, then factoring likely will not improve the code in any way and
the code is adequately clear. Otherwise, I maintain that the code can
be factored. It may take a bit of reorganization of the code, but
that does not have to hide the essential functioning of the code.
Factoring can be used to clarify the functioning of the code by
reducing or simplifying the stack manipulations. Factoring may even
increase the number of words used to adjust the stack, but if they are
separated into the ones needed to set up the word call and the ones
that are an essential part of the function, that can be much more
clear.
Like I said before, if you have a loop with little content other than
stack movements, then you likely will muddy the waters by pulling out
the little content into a factor. Taking the stack movements with it
can make it even worse since a word is much more clear if you provide
it with a well orgainized stack for it's purpose. If the stack
manipulations are complex, then factoring them into their own word can
simplify. But there is a point where factoring does not make sense
and nested loops provide many examples.
If your function is large enough that it is hard to understand you can
either factor out sections that make sense and simplify the problem,
reorganize the code to allow factoring or if you can't find good
factors even with reorganization the idea that the function is hard to
understand is likely inccorect.
If you want to discuss this, then lets work with real issues and not
dogma.
Charlie Springer
(in article <1175646524.1...@y80g2000hsf.googlegroups.com>):
> If you feel the time penalty of a call to a word is too expensive in
> terms of time, then that may preclude factoring, but that is an issue
> with the code being time critical and not an issue with factoring per-
> se. There are any number of other shortcuts you are likely to take in
> time critical code which defy general rules. This has nothing to do
> with whether an algorithm is factorable or not.
Thanks for explaining what I meant by "factorability in an abstract sense." I
needed that. I'll take a paragraph over simple phrase any time.
-- Charlie Springer
rickman
> On Apr 3, 5:30 pm, "rickman" <gnu...@gmail.com> wrote:
>
> > I don't buy into the idea that an algorithm can't be factored. If it
> > can't be factored, then it must be so small that it is not needed.
>
> I'm an agnostic on this topic. Even when an algorithm looks hard to
> factor usefully, it might be I just haven't seen how.
>
> I vaguely remember one example. Years ago there was a competition to
> find good sort algorithms coded in Forth. Some of them factored
> nicely. Some factored recursively. But I vaguely remember that one of
> them was just hard to do. It involved keeping track of a whole lot of
> different things. First you'd fiddle with 4 or 5 of them, and then
> you'd use that result to fiddle with a different 4 or 5 things, and so
> on. You could break it into pieces but there was a lot of stack
> juggling or else a lot of variables, and the factored pieces didn't
> seem to make a lot of sense or yield good descriptive names.
>
> It's quite possible that somebody who understood the algorithm better
> could have factored it well. But the guy who presented it didn't find
> a good factoring, and on a quick look I didn't either. So there might
> be an example there, or maybe not.
>
> You gave the example of looping code. That can be hard to factor in
> Forth.
>
> DO ... DO ... DO
> K I Foo J I Bar K J Fubar I K Bam ...
Interesting, your example is already factored! Foo, Bar, Fubar and
Bam are all factors! If each of these is just a word or two then it
does not make sense to factor them, but then the code is not hard to
understand. Just because a piece of code is not brief does not make
it complex.
Even if you did factor the entire loop internal it would not be hard
to manipulate the three loop variables on the stack. I have had to do
this before and I did not find it overly complex.
> You could factor it if you had a separate loop stack. And you could
> test the code separately, you'd load test values onto the loop stack
> and then run the code. But in portable standard Forth it isn't worth
> factoring. Maybe if you didn't have DO you wouldn't think in ways that
> create the problem.
>
> I've had code with other complicated control structures that didn't
> factor.
>
> BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
> test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
Yes, this is a very complex control structure and I would say it is
also a poor decomposition of the problem. I'm not even sure what the
code above does. It looks to me like leaving the loop by the UNTIL
executes result4 as well as result2 and result1. I think that it will
be hard to come up with examples that require such a complex control
structure. Beside, this does not preclude factoring, each of your
lowercase words above are factors! Then the higher level code is just
the control structure which then is as simple as you have coded it
with all the detail in the factors.
BTW, I don't agree that factored words have to be obvious functions
that are ripe for reuse. I believe that a factor is whatever makes
sense in the context of the problem. It can be used in exactly one
place and still be a significant benefit.
I don't agree that your initial code is well written. I don't like
the use of EXIT unless it is absolutely required which I don't think
it is. In fact, your example does not even work since you forgot to
use UNLOOP.
> BEGIN
> test1 0= IF result1 EXIT THEN action1
> test2 0= IF result2 result1 EXIT THEN action2
> test3 0= IF result3 result2 result1 EXIT THEN action3
> test4 UNTIL result4 result2 result1 ;
This is how I would write your code with the UNLOOPs added.
BEGIN
test1 0= IF
result1 UNLOOP EXIT THEN
action1
test2 0= IF
result2 result1 UNLOOP EXIT THEN
action2
test3 0= IF
result3 result2 result1 UNLOOP EXIT THEN
action3
test4 UNTIL
result4 result2 result1 ;
Now I would change it to get rid of the EXITs.
BEGIN
test1 0= IF
result1
ELSE
action1
test2 0= IF
result2 result1
ELSE
action2
test3 0= IF
result3 result2 result1
ELSE
action3
THEN
THEN
THEN
test1 test2 OR test3 OR test4 OR UNTIL
result4 result2 result1 ;
Unless the tests are modified by the result words, this is equivalent
to your orignial code and can be factored senquentially...
: check3
test3 0= IF
result3 result2 result1
ELSE
action3
THEN
;
: check2
test2 0= IF
result2 result1
ELSE
action2
check3
THEN
;
BEGIN
test1 0= IF
result1
ELSE
action1
check2
THEN
test1 test2 OR test3 OR test4 OR UNTIL
result4 result2 result1 ;
This may seem verbose, but it is much more clear I think. Of course,
you can orgainize the IF ELSE THEN structures to your liking. They
are very spread out in my example because I am much more used to C
style code formating.
> different things. First you'd fiddle with 4 or 5 of them, and then
> you'd use that result to fiddle with a different 4 or 5 things, and so
> on. You could break it into pieces but there was a lot of stack
> juggling or else a lot of variables, and the factored pieces didn't
> seem to make a lot of sense or yield good descriptive names.
>
> It's quite possible that somebody who understood the algorithm better
> could have factored it well. But the guy who presented it didn't find
> a good factoring, and on a quick look I didn't either. So there might
> be an example there, or maybe not.
>
> You gave the example of looping code. That can be hard to factor in
> Forth.
>
> DO ... DO ... DO
> K I Foo J I Bar K J Fubar I K Bam ...
Interesting, your example is already factored! Foo, Bar, Fubar and
Bam are all factors! If each of these is just a word or two then it
does not make sense to factor them, but then the code is not hard to
understand. Just because a piece of code is not brief does not make
it complex.
Even if you did factor the entire loop internal it would not be hard
to manipulate the three loop variables on the stack. I have had to do
this before and I did not find it overly complex.
> You could factor it if you had a separate loop stack. And you could
> test the code separately, you'd load test values onto the loop stack
> and then run the code. But in portable standard Forth it isn't worth
> factoring. Maybe if you didn't have DO you wouldn't think in ways that
> create the problem.
>
> I've had code with other complicated control structures that didn't
> factor.
>
> BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
> test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
Yes, this is a very complex control structure and I would say it is
also a poor decomposition of the problem. I'm not even sure what the
code above does. It looks to me like leaving the loop by the UNTIL
executes result4 as well as result2 and result1. I think that it will
be hard to come up with examples that require such a complex control
structure. Beside, this does not preclude factoring, each of your
lowercase words above are factors! Then the higher level code is just
the control structure which then is as simple as you have coded it
with all the detail in the factors.
BTW, I don't agree that factored words have to be obvious functions
that are ripe for reuse. I believe that a factor is whatever makes
sense in the context of the problem. It can be used in exactly one
place and still be a significant benefit.
I don't agree that your initial code is well written. I don't like
the use of EXIT unless it is absolutely required which I don't think
it is. In fact, your example does not even work since you forgot to
use UNLOOP.
> BEGIN
> test1 0= IF result1 EXIT THEN action1
> test2 0= IF result2 result1 EXIT THEN action2
> test3 0= IF result3 result2 result1 EXIT THEN action3
> test4 UNTIL result4 result2 result1 ;
This is how I would write your code with the UNLOOPs added.
BEGIN
test1 0= IF
result1 UNLOOP EXIT THEN
action1
test2 0= IF
result2 result1 UNLOOP EXIT THEN
action2
test3 0= IF
result3 result2 result1 UNLOOP EXIT THEN
action3
test4 UNTIL
result4 result2 result1 ;
Now I would change it to get rid of the EXITs.
BEGIN
test1 0= IF
result1
ELSE
action1
test2 0= IF
result2 result1
ELSE
action2
test3 0= IF
result3 result2 result1
ELSE
action3
THEN
THEN
THEN
test1 test2 OR test3 OR test4 OR UNTIL
result4 result2 result1 ;
Unless the tests are modified by the result words, this is equivalent
to your orignial code and can be factored senquentially...
: check3
test3 0= IF result3 result2 result1
ELSE action3
THEN
;
: check2
test2 0= IF result2 result1
ELSE action2 check3
THEN
;
BEGIN
test1 0= IF result1
ELSE action1 check2
THEN test1 test2 OR test3 OR test4 OR UNTIL
result4 result2 result1 ;
Is this better?
Elizabeth D Rather
> I don't agree that your initial code is well written. I don't like
> the use of EXIT unless it is absolutely required which I don't think
> it is. In fact, your example does not even work since you forgot to
> use UNLOOP.
>
>> BEGIN
>> test1 0= IF result1 EXIT THEN action1
>> test2 0= IF result2 result1 EXIT THEN action2
>> test3 0= IF result3 result2 result1 EXIT THEN action3
>> test4 UNTIL result4 result2 result1 ;
>
> This is how I would write your code with the UNLOOPs added.
>
> BEGIN
> test1 0= IF
> result1 UNLOOP EXIT THEN
> action1
> test2 0= IF
> result2 result1 UNLOOP EXIT THEN
> action2
> test3 0= IF
> result3 result2 result1 UNLOOP EXIT THEN
> action3
> test4 UNTIL
> result4 result2 result1 ;
UNLOOP is only appropriate with DO ... LOOP structures (as indicated by
the requirement for "loop-sys" on the return stack). BEGIN loops don't
use the return stack.
IMO all these definitions are too long and complex. They're also all
hypothetical. Given a real-world problem, there's probably a simpler
solution.
J Thomas
> On Apr 4, 2:59 am, "J Thomas" <jethom...@gmail.com> wrote:
> > You gave the example of looping code. That can be hard to factor in
> > Forth.
>
> > DO ... DO ... DO
> > K I Foo J I Bar K J Fubar I K Bam ...
>
> Interesting, your example is already factored! Foo, Bar, Fubar and
> Bam are all factors! If each of these is just a word or two then it
> does not make sense to factor them, but then the code is not hard to
> understand. Just because a piece of code is not brief does not make
> it complex.
Notice the ... at the end of Bam ...
It could be something very complex, that would do better to be somehow
factored. But hard to do.
> Even if you did factor the entire loop internal it would not be hard
> to manipulate the three loop variables on the stack. I have had to do
> this before and I did not find it overly complex.
I sometimes find it overly complex. Remember in my example I didn't
give stack diagrams for Foo, Bar, Fubar, Bam, etc. They could pick up
and use other items under the loop parameters. It could turn into some
serious stack juggling, maybe best handled with
: factor ( 2nd 1st i j k -- )
DUP >R -ROT >R DUP >R Foo
2R@ Bar
R> 2R@ ROT >R Fubar ...
> > I've had code with other complicated control structures that didn't
> > factor.
>
> > BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
> > test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
>
> Yes, this is a very complex control structure and I would say it is
> also a poor decomposition of the problem. I'm not even sure what the
> code above does. It looks to me like leaving the loop by the UNTIL
> executes result4 as well as result2 and result1. I think that it will
> be hard to come up with examples that require such a complex control
> structure.
It's pretty easy to find examples that fit such a control structure.
But there could be a better way to do it.
> Beside, this does not preclude factoring, each of your
> lowercase words above are factors! Then the higher level code is just
> the control structure which then is as simple as you have coded it
> with all the detail in the factors.
Suppose there's a subtle error in that control structure. What sort of
testing would find it?
> BTW, I don't agree that factored words have to be obvious functions
> that are ripe for reuse. I believe that a factor is whatever makes
> sense in the context of the problem. It can be used in exactly one
> place and still be a significant benefit.
I agree. It's *better* when factored words are obvious functions that
are ripe for reuse. That makes the code more readable, and easier to
test the factors, and so on. Factoring into smaller pieces can help
even without that, though.
Why would I need UNLOOP when I do THROW ?
> > BEGIN
> > test1 0= IF result1 EXIT THEN action1
> > test2 0= IF result2 result1 EXIT THEN action2
> > test3 0= IF result3 result2 result1 EXIT THEN action3
> > test4 UNTIL result4 result2 result1 ;
>
> This is how I would write your code with the UNLOOPs added.
>
> BEGIN
> test1 0= IF
> result1 UNLOOP EXIT THEN
> action1
> test2 0= IF
> result2 result1 UNLOOP EXIT THEN
> action2
> test3 0= IF
> result3 result2 result1 UNLOOP EXIT THEN
> action3
> test4 UNTIL
> result4 result2 result1 ;
This is what I get for supplying examples of complex unreadable code.
My BEGIN example didn't need any UNLOOPs. I wrote complex unreadable
code and it got you confused. Not your fault. ;)
> Now I would change it to get rid of the EXITs.
>
> BEGIN
> test1 0= IF
> result1
> ELSE
> action1
> test2 0= IF
> result2 result1
> ELSE
> action2
> test3 0= IF
> result3 result2 result1
> ELSE
> action3
> THEN
> THEN
> THEN
> test1 test2 OR test3 OR test4 OR UNTIL
> result4 result2 result1 ;
Is it thus you console me? To me that looks awful. But it's probably
correct. It's so complicated that I don't want to check it to see.
> Unless the tests are modified by the result words, this is equivalent
> to your orignial code and can be factored senquentially...
Why would you suppose the tests weren't modified by the result
words? ;)
> : check3
> test3 0= IF
> result3 result2 result1
> ELSE
> action3
> THEN
> ;
I had result3 call result2 and result2 call result1 on the assumption
that they were never used otherwise, so why make multiple calls. But
that assumption doesn't have to be right, maybe somewhere else you'd
use result2 without result1.
> : check2
> test2 0= IF
> result2 result1
> ELSE
> action2
> check3
> THEN
> ;
>
> BEGIN
> test1 0= IF
> result1
> ELSE
> action1
> check2
> THEN
> test1 test2 OR test3 OR test4 OR UNTIL
> result4 result2 result1 ;
That looks good on the assumption the test results don't get changed
by any of the actions. You get to do the tests over instead of saving
flags. Nice!
> This may seem verbose, but it is much more clear I think. Of course,
> you can orgainize the IF ELSE THEN structures to your liking. They
> are very spread out in my example because I am much more used to C
> style code formating.
There ought to be a way to lay it out in simple easy-to-understand
pieces. My original version was a structured almost-spaghetti-code
mess. Your if-else version is hard on the eyes. Both us us came up
with ways to factor it like an onion -- OK if the inner layers are
completely understood and debugged before you look at the outer
layers, but hard to understand what the outer parts are doing unless
you understand the inside first.
I've seen a CASE version that would probably work.
CASE
BEGIN
test1 0 OF result1 ENDOF
DROP action1
test2 0 OF result2 ENDOF
DROP action2
test3 0 OF result3 ENDOF
DROP action3
test4 UNTIL
result4
ENDCASE
I'm not sure this is clear either, but at least it isn't hidden. And
it won't work with every CASE. It isn't standard.
It's hard to write readable complex control structures. I tend to
think that if it's going to be hard to read regardless, maybe it would
be better to simplify the structures themselves. We've seen proposals
to make the only loop be a tail-recursion, and various simple
branches. That might be enough.
J Thomas
> > BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
> > test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
>
> Yes, this is a very complex control structure and I would say it is
> also a poor decomposition of the problem. I'm not even sure what the
> code above does. It looks to me like leaving the loop by the UNTIL
> executes result4 as well as result2 and result1. I think that it will
> be hard to come up with examples that require such a complex control
> structure.
You can always find another way to do it. Let's see....
Is this a valid debit card?
Is this the correct PIN for this debit card?
Is this an allowed request for this card?
Did the request process correctly?
In this particular case it makes sense to use THROW codes because the
failure case is simple.
: PROCESS
BEGIN
check-card THROW
get-PIN THROW
get-request THROW
service-request THROW
AGAIN ;
BEGIN
['] PROCESS CATCH
?DUP IF
CASE CR
5 OF ." Sorry, this is not a valid card." ENDOF
6 OF ." Sorry, that is not your PIN." ENDOF
7 OF ." I'm sorry, Dave, I can't do that." ENDOF
8 OF ." This terminal is out of service." ENDOF
ENDCASE
EJECT-CARD
CR CR ." Have a nice day!" EXIT
ELSE
CR ." Would you like to make another transaction?"
THEN
AGAIN
It certainly isn't unusual to have a sequence of 4 sequential tests,
each of which gives a different outcome where one combination results
in a retry.
Or where all but one combination results in a retry.
Is there another wordlist to check?
Is this word in this wordlist?
Is this word a number?
Is it a double number?
Is it a float?
If yes to any of those, check the next word.
Surely this sort of thing isn't uncommon.
It isn't even unusual to have a cascade of tests.
Gerry
> Gerry wrote:
> > On 2 Apr, 22:52, John Doty <j...@whispertel.LoseTheH.net> wrote:
> > ...
> >> No. A Forth definition should do one *simple* thing. Long, complex
> >> definitions are generally hard to understand.
>
> > Not necessarily, a sequence of simple operations making a more complex
> > definition can be easier to understand if well presented.
>
> Hardly ever happens.
>
> > Taken to
> > extreme your statement can lead to over-factoring
>
> Over-factoring? So rare I've *never* seen it. Highly factored Forth is
> invariably the most readable kind.
>
You didn't read the FizzBuzz thread then
http://groups.google.co.uk/group/comp.lang.forth/tree/browse_frm/thread/b4b64b09cd368269/15a7429fa98b48da?rnum=1&_done=%2Fgroup%2Fcomp.lang.forth%2Fbrowse_frm%2Fthread%2Fb4b64b09cd368269%2F%3F#doc_e648ef37a9ac24c9
Gerry
Gerry
> On 4 Apr, 00:19, John Doty <j...@whispertel.LoseTheH.net> wrote:
>
>
>
>
>
> > Gerry wrote:
> > > On 2 Apr, 22:52, John Doty <j...@whispertel.LoseTheH.net> wrote:
> > > ...
> > >> No. A Forth definition should do one *simple* thing. Long, complex
> > >> definitions are generally hard to understand.
>
> > > Not necessarily, a sequence of simple operations making a more complex
> > > definition can be easier to understand if well presented.
>
> > Hardly ever happens.
>
> > > Taken to
> > > extreme your statement can lead to over-factoring
>
> > Over-factoring? So rare I've *never* seen it. Highly factored Forth is
> > invariably the most readable kind.
>
>
> Gerry- Hide quoted text -
>
> - Show quoted text -
Whoops, sorry, I copied the wrong link
http://groups.google.co.uk/group/comp.lang.forth/tree/browse_frm/thread/b4b64b09cd368269/15a7429fa98b48da?rnum=1&_done=%2Fgroup%2Fcomp.lang.forth%2Fbrowse_frm%2Fthread%2Fb4b64b09cd368269%2F%3F#doc_918c626394195848
Gerry
John Doty
> On Apr 3, 8:28 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> rickman wrote:
>>> On Apr 3, 7:10 pm, John Passaniti <n...@JapanIsShinto.com> wrote:
>>>> rickman wrote:
>>>>> I don't buy into the idea that an algorithm can't be factored. If it
>>>>> can't be factored, then it must be so small that it is not needed.
>>>> That's silly. An algorithm's ability to be factored has no relationship
>>>> on if the application needs that algorithm.
>>> I didn't mean the algorithm is not needed, I mean the factoring is not
>>> needed.
>> Only if you don't care that the code is write-only.
>
> First, I will say your comment is a non-sequitur.
No it isn't, since factoring is fundamentally a tool to make the code
comprehensible.
> I don't know what
> you are saying makes the code write-only.
Because when you don't factor adequately, it places an unnecessary
burden on the reader.
> When I see comments like
> this, often repeated in this group like a mantra, I realize that no
> real thought went into the comment. Can you explain what you mean?
I have, repeatedly. But unless you consider the psychological aspects of
programming to be fundamental, you won't understand.
>
> My point is that if the code is small enough that it is hard to
> factor,
Factoring is always a burden on the coder. It's easier just to keep
writing. But it's the price of readability and maintainability.
> then factoring likely will not improve the code in any way and
> the code is adequately clear.
No. Clarity depends on the number of concepts that you make the reader
mentally juggle at one time. Too many make the code unreadable. Too many
also make the code hard to factor. Therefore, it is most important to
factor the code that is most difficult to factor!
> Otherwise, I maintain that the code can
> be factored. It may take a bit of reorganization of the code, but
> that does not have to hide the essential functioning of the code.
The purpose of factoring is to *reveal* the essential functioning of the
code to the reader at the level of detail the reader needs.
> Factoring can be used to clarify the functioning of the code by
> reducing or simplifying the stack manipulations.
Yes, but that's not primary. Factoring is about breaking down concepts
into simpler concepts. Simplification of stack manipulations is a likely
by-product, but it's not the only goal.
> Factoring may even
> increase the number of words used to adjust the stack, but if they are
> separated into the ones needed to set up the word call and the ones
> that are an essential part of the function, that can be much more
> clear.
True.
>
> Like I said before, if you have a loop with little content other than
> stack movements, then you likely will muddy the waters by pulling out
> the little content into a factor.
Why? The content has some purpose: give it a descriptive name. Then the
reader of the loop can easily skip over the details of the machinations
if they want, or see them easily isolated as a definition if they want.
> Taking the stack movements with it
> can make it even worse since a word is much more clear if you provide
> it with a well orgainized stack for it's purpose. If the stack
> manipulations are complex, then factoring them into their own word can
> simplify. But there is a point where factoring does not make sense
> and nested loops provide many examples.
Nested loops in Forth are a bad idea, period. I put them into the old
LSE around 1982, and I'm sorry I did. Even I find my own nested loop
code difficult to read, while the simpler code others wrote without them
is much clearer. They made the code easier to *write*, but writing code
is already the easiest part of software engineering. There's no point in
making that easier at the expense of the rest of it.
>
> If your function is large enough that it is hard to understand you can
> either factor out sections that make sense and simplify the problem,
> reorganize the code to allow factoring or if you can't find good
> factors even with reorganization the idea that the function is hard to
> understand is likely inccorect.
No, it is likely correct. But you have to select "good factors" for
*human* reasons, not machine reasons.
>
> If you want to discuss this, then lets work with real issues and not
> dogma.
>
If you want to discuss this, keep in mind that Forth is nearly extinct.
One major reason I've heard for not using it any more is that it is
"write-only". This is not dogma, this is simply what users with real
problems to solve report. But the same sorts of users once used Forth.
John Doty
Silly attempts at obfuscated solutions to toy problems don't count.
rickman
> On Apr 4, 12:39 pm, "rickman" <gnu...@gmail.com> wrote:
>
> > On Apr 4, 2:59 am, "J Thomas" <jethom...@gmail.com> wrote:
> > > You gave the example of looping code. That can be hard to factor in
> > > Forth.
>
> > > DO ... DO ... DO
> > > K I Foo J I Bar K J Fubar I K Bam ...
>
> > Interesting, your example is already factored! Foo, Bar, Fubar and
> > Bam are all factors! If each of these is just a word or two then it
> > does not make sense to factor them, but then the code is not hard to
> > understand. Just because a piece of code is not brief does not make
> > it complex.
>
> Notice the ... at the end of Bam ...
>
> It could be something very complex, that would do better to be somehow
> factored. But hard to do.
It could be anything, but that does not automatically make it hard to
factor. That is my point. The fact that you can summarize it the way
you did says to me that it is inherently simple.
> > Even if you did factor the entire loop internal it would not be hard
> > to manipulate the three loop variables on the stack. I have had to do
> > this before and I did not find it overly complex.
>
> I sometimes find it overly complex. Remember in my example I didn't
> give stack diagrams for Foo, Bar, Fubar, Bam, etc. They could pick up
> and use other items under the loop parameters. It could turn into some
> serious stack juggling, maybe best handled with
Did you even try to make this simpler?
> : factor ( 2nd 1st i j k -- )
> DUP >R -ROT >R DUP >R Foo
The stack before Foo is called is ( D: 2nd 1st k i R: k j i ) How
about...
-ROT 2DUP ( 2nd 1st j k i k i )
Foo ( 2nd 1st j k i )
> 2R@ Bar
-ROT SWAP 2DUP Bar
> R> 2R@ ROT >R Fubar ...
You have written a lot of complex stuff, but it is all hypothetical
and looks to me like it can be greatly simplified. Like Elizabeth
said, use a real world example and drop the hypo stuff.
> > > I've had code with other complicated control structures that didn't
> > > factor.
>
> > > BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
> > > test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
>
> > Yes, this is a very complex control structure and I would say it is
> > also a poor decomposition of the problem. I'm not even sure what the
> > code above does. It looks to me like leaving the loop by the UNTIL
> > executes result4 as well as result2 and result1. I think that it will
> > be hard to come up with examples that require such a complex control
> > structure.
>
> It's pretty easy to find examples that fit such a control structure.
> But there could be a better way to do it.
>
> > Beside, this does not preclude factoring, each of your
> > lowercase words above are factors! Then the higher level code is just
> > the control structure which then is as simple as you have coded it
> > with all the detail in the factors.
>
> Suppose there's a subtle error in that control structure. What sort of
> testing would find it?
I don't follow your question. What control structure are you
referring to? I would never use the control structure you gave above,
so I don't need to figure out how to test it. Testing and
verification of the code is exactly why you should not use complex
control structures.
Actually you don't need unloop at all in the example I was referring
to. My mistake confusing DO and UNTIL.
I don't agree that it is complex. There are three nested IFs. That
is not inherently complex. Because it is such a simple control
structure nesting IFs in this way is inherently simple. The problem
is symmetrical so the next IF is in the ELSE of the previous IF. So
the structure is condition IF do this ELSE more condtional... THEN.
This is the IF equivalent of a case statement.
> > Unless the tests are modified by the result words, this is equivalent
> > to your orignial code and can be factored senquentially...
>
> Why would you suppose the tests weren't modified by the result
> words? ;)
Because we are working with a hypothetical, not a real problem. One
of the things I have noticed that you are constructing a lot of
complexity that can be eliminated by a number of means. For example,
the stack juggling above can be eased by how you write the words being
called. But since this is not a real problem we don't know which
techniques will work and which won't.
Again it all depends on the problem. You can evaluate the tests and
save them in a variable. If the inputs to the tests are being
modified, this is starting to sound like a state machine and there are
very, very simple ways to code a state machine.
Yes, a case is a good way to go. I am assuming that this case
statement evaluates each test separately rather than the way a case
works in C where it only allows multiple values of the same
expression.
> It's hard to write readable complex control structures. I tend to
> think that if it's going to be hard to read regardless, maybe it would
> be better to simplify the structures themselves. We've seen proposals
> to make the only loop be a tail-recursion, and various simple
> branches. That might be enough.
I don't think that is the issue. If you have a complex problem, any
implementation needs to break the problem down into multiple, simpler
problems. Then you can use simple control structures in simple
ways.
J Thomas
> > > Over-factoring? So rare I've *never* seen it. Highly factored Forth is
> > > invariably the most readable kind.
>
> > You didn't read the FizzBuzz thread then linkhttp://groups.google.co.uk/group/comp.lang.forth/tree/browse_frm/thre...
Did we ever get a consensus that any of the solutions were
overfactored?
Some of us found uses for the factors. I felt like all the solutions
(except maybe some of mine, where I explored some ideas to confirm
that they weren't useful) were good.
J Thomas
> rickman wrote:
> > First, I will say your comment is a non-sequitur.
>
> No it isn't, since factoring is fundamentally a tool to make the code
> comprehensible.
Factoring has other uses than readability. And readability is to some
extent an esthetic issue, and to some extent even by objective tests
it will depend on what you get used to.
However, you point out below that Forth gets criticised for being
write-only, and your claim that this is one of the main reasons that
Forth has not been more successful may be right.
So if you're right about that, readability is one of the most
important things to fix, and careful factoring can help with that.
On the other hand, thoughtless factoring can make it harder to read.
> > I don't know what
> > you are saying makes the code write-only.
>
> Because when you don't factor adequately, it places an unnecessary
> burden on the reader.
>
> > When I see comments like
> > this, often repeated in this group like a mantra, I realize that no
> > real thought went into the comment. Can you explain what you mean?
>
> I have, repeatedly. But unless you consider the psychological aspects of
> programming to be fundamental, you won't understand.
The trouble with putting the psychology first is that it's hard to
tell when you're doing it right.
> > My point is that if the code is small enough that it is hard to
> > factor,
>
> Factoring is always a burden on the coder. It's easier just to keep
> writing. But it's the price of readability and maintainability.
I disagree that factoring is always a burden. Sometimes it makes it
easier to write working code.
And that's potentially a problem, because -- speaking for myself --
when I factor badly for *writing* I get immediate feedback. It starts
getting hard to do. I notice that it's turned hard and I look for my
mistakes. But I don't find out what's readable until somebody tells me
what they don't like from trying to read my code, and I don't find out
what's maintainable until I've forgotten what I did and then go back
and try to maintain it.
> > then factoring likely will not improve the code in any way and
> > the code is adequately clear.
>
> No. Clarity depends on the number of concepts that you make the reader
> mentally juggle at one time. Too many make the code unreadable. Too many
> also make the code hard to factor. Therefore, it is most important to
> factor the code that is most difficult to factor!
That makes sense.
> Nested loops in Forth are a bad idea, period. I put them into the old
> LSE around 1982, and I'm sorry I did. Even I find my own nested loop
> code difficult to read, while the simpler code others wrote without them
> is much clearer. They made the code easier to *write*, but writing code
> is already the easiest part of software engineering. There's no point in
> making that easier at the expense of the rest of it.
That's an interesting point.
> > If your function is large enough that it is hard to understand you can
> > either factor out sections that make sense and simplify the problem,
> > reorganize the code to allow factoring or if you can't find good
> > factors even with reorganization the idea that the function is hard to
> > understand is likely inccorect.
>
> No, it is likely correct. But you have to select "good factors" for
> *human* reasons, not machine reasons.
If you can find good factors they're likely to be good for both.
Still, if readability is the limiting factor, then the human reasons
are more important.
> > If you want to discuss this, then lets work with real issues and not
> > dogma.
>
> If you want to discuss this, keep in mind that Forth is nearly extinct.
> One major reason I've heard for not using it any more is that it is
> "write-only". This is not dogma, this is simply what users with real
> problems to solve report. But the same sorts of users once used Forth.
What are the other major reasons?
Andreas Kochenburger
> One major reason I've heard for not using it any more is that it is
> "write-only". This is not dogma, this is simply what users with real
> problems to solve report. But the same sorts of users once used Forth.
IMO it is pretty readable when Forth is used for controls, i.e. as
sequential command language.
However to compare algebraic infix formulations with Forth's postfix or
Lisp's prefix way can be frustrating. However the late Julian Noble's
little formula translation program can help you there.
--
Andreas
-------
MinForth: http://minforth.net.ms/
John Doty
> John Doty wrote:
>> One major reason I've heard for not using it any more is that it is
>> "write-only". This is not dogma, this is simply what users with real
>> problems to solve report. But the same sorts of users once used Forth.
>
> IMO it is pretty readable when Forth is used for controls, i.e. as
> sequential command language.
I agree, especially if you keep the definitions short. I've been
experimenting with "short-circuit" flow control in LSE64. That's much
more sequential than traditional Algol-style block structure, and I
think it fits Forth better.
>
> However to compare algebraic infix formulations with Forth's postfix or
> Lisp's prefix way can be frustrating. However the late Julian Noble's
> little formula translation program can help you there.
Mathematica is fundamentally Lisp-like in syntax, but provides a variety
of "forms" for expressions that allow the user to find the best balance
between the program's needs and human needs. I really like this: with
care Mathematica code can be radically readable, even by people who
can't write it. Could a Forth have this? I don't see why not. Julian's
work is a step on the path (and then there was MAGIC/L).
Duke Normandin
>
>>
>> If you want to discuss this, then lets work with real issues and not
>> dogma.
>>
>
> If you want to discuss this, keep in mind that Forth is nearly extinct.
You're joking! right? Have I started on a long walk down a dead-end road
in deciding to learn Forth? I was fixing to ramp-up my efforts - maybe it
would truely be a waste of time? Is the Forth niche _that_ skinny?
> One major reason I've heard for not using it any more is that it is
> "write-only". This is not dogma, this is simply what users with real
> problems to solve report. But the same sorts of users once used Forth.
Thanks for the heads-up!
--
duke | A: Yes. |
| >Q: Are you sure? |
| >>A: Because it reverses the logical flow of conversation. |
| >>>Q: Why is top posting frowned upon? |
macoln
> On 2007-04-04, John Doty <j...@whispertel.LoseTheH.net> wrote:
>
> >> If you want to discuss this, then lets work with real issues and not
> >> dogma.
>
> > If you want to discuss this, keep in mind that Forth is nearly extinct.
>
> ^^^^^^^^^^^^^^^^^^^^^^^
> You're joking! right? Have I started on a long walk down a dead-end road
> in deciding to learn Forth? I was fixing to ramp-up my efforts - maybe it
> would truely be a waste of time? Is the Forth niche _that_ skinny?
There's been lots of other posts describing all the interesting
applications Forth is used for, but as a newcomer and a hobbyist I can
say that this language is just darn fun to work with. So if you're
looking to get a job, don't waste your time, but if you like fun, keep
going! One more thing: programming philosophy and people's opinions
about it are an interesting read but it really interferes with coding
time. There, I said it. Rotten c.l.f :)
John Passaniti
>> If you want to discuss this, keep in mind that Forth is nearly extinct.
> ^^^^^^^^^^^^^^^^^^^^^^^
> You're joking! right? Have I started on a long walk down a dead-end road
> in deciding to learn Forth? I was fixing to ramp-up my efforts - maybe it
> would truely be a waste of time? Is the Forth niche _that_ skinny?
Forth's primary domain is embedded systems. As Forth is a
general-purpose programming language, it could be used anywhere. But
just because something *can* be used doesn't mean it *should*.
You've brought up web applications as one domain you're interested in.
That's a domain where I think Forth is especially poor. You got excited
when you saw that a web server (but not really-- look closer) was
written in Forth, and this to you said that Forth was applicable to web
applications. But when you compare what Forth offers "out of the box"
to other languages, you see that Forth offers *nothing* unique or
special for that domain.
So the question is if you're comfortable building up from scratch all
the infrastructure you're going to need to write those Forth-based web
applications, or if it would be more efficient and worthwhile to look at
languages, tools, libraries, and frameworks that are *designed* for that
domain.
As far as if there is any value to learning Forth, I say there certainly
is. But I'm of the belief that every programmer should understand as
many languages as they can possibly handle. Every language you learn
presents a different way to solve problems and becomes a new tool in
your toolbox.
Learn Forth. Then learn Smalltalk. Then learn Lisp. Then learn
Prolog. Then start diving into "variations on a theme" languages to see
the various kinds of tradeoffs and design decisions they made-- and why.
Gerry
> On Apr 4, 4:04 pm, "Gerry" <g...@jackson9000.fsnet.co.uk> wrote:
>
> > > > Over-factoring? So rare I've *never* seen it. Highly factored Forth is
> > > > invariably the most readable kind.
>
> > > You didn't read the FizzBuzz thread then linkhttp://groups.google.co.uk/group/comp.lang.forth/tree/browse_frm/thre...
>
> Did we ever get a consensus that any of the solutions were
> overfactored?
No I don't think so. I was simply pointing to a post that said some
code was over-factored.
Gerry
John Doty
> Duke Normandin wrote:
>>> If you want to discuss this, keep in mind that Forth is nearly extinct.
>> ^^^^^^^^^^^^^^^^^^^^^^^
>> You're joking! right? Have I started on a long walk down a dead-end road
>> in deciding to learn Forth? I was fixing to ramp-up my efforts - maybe it
>> would truely be a waste of time? Is the Forth niche _that_ skinny?
>
> Forth's primary domain is embedded systems.
Even in this niche, C dominates. And for stuff that isn't technically
challenging, one even sees a lot of code in languages like Python and
even Visual Basic, not normally considered "embedded" languages.
Where Forth *used* to shine was embedded systems where there wasn't a
distinction between developers and users. "Want to point the telescope?
Here are the Forth words to do that...". Forth was the language of
choice for those more comfortable with telescopes than with programs.
But at the SPIE astronomical convention last year, there was a whole
conference devoted to software. Hundreds of papers. No Forth.
> ...
> Learn Forth. Then learn Smalltalk. Then learn Lisp. Then learn
> Prolog. Then start diving into "variations on a theme" languages to see
> the various kinds of tradeoffs and design decisions they made-- and why.
Good advice.
J Thomas
On Apr 4, 1:46 pm, "J Thomas" <jethom...@gmail.com> wrote:
> On Apr 4, 12:39 pm, "rickman" <gnu...@gmail.com> wrote:
>
> > On Apr 4, 2:59 am, "J Thomas" <jethom...@gmail.com> wrote:
> > > BEGIN test1 WHILE action1 test2 WHILE action2 test3 WHILE action3
> > > test4 UNTIL result4 ELSE result3 THEN result2 THEN result1 ....
A complex control structure. Can't be factored.
> > BEGIN
> > test1 0= IF
> > result1
> > ELSE
> > action1
> > test2 0= IF
> > result2 result1
> > ELSE
> > action2
> > test3 0= IF
> > result3 result2 result1
> > ELSE
> > action3
> > THEN
> > THEN
> > THEN
> > test1 test2 OR test3 OR test4 OR UNTIL
> > result4 result2 result1 ;
Just as complex, but it can be easily factored.
The first way, if there's anything wrong you can check the flags that
each routine produces and look at the code to see if it looks right.
The second way you can actually factor the code and test parts of it
in isolation.
Until Forth 94 multiple WHILEs weren't standard, and I never missed
them. When I first saw them used they looked like a neat idea. Now I
think, use them sparingly.
John Passaniti
>> Forth's primary domain is embedded systems.
>
> Even in this niche, C dominates. And for stuff that isn't technically
> challenging, one even sees a lot of code in languages like Python and
> even Visual Basic, not normally considered "embedded" languages.
Yes. I wasn't commenting on how dominate Forth was, just where Forth's
niche is.
> Where Forth *used* to shine was embedded systems where there wasn't a
> distinction between developers and users. "Want to point the telescope?
> Here are the Forth words to do that...". Forth was the language of
> choice for those more comfortable with telescopes than with programs.
> But at the SPIE astronomical convention last year, there was a whole
> conference devoted to software. Hundreds of papers. No Forth.
So what. Spring comes, time passes, people marry and die, Pinkerton
does not return. I'm sure there are people who lament that slide rules
are largely forgotten, manual typewriters are no longer used or that we
don't build homes by hand-shaving logs.
Is your repetitive and tedious lament really a long-winded indirect way
of saying Forth hasn't significantly grown over the years? If so, I
agree. But even with languages that have grown, there are still
converts to newer and sometimes better ways of working. So even if the
Forth community had done everything right and even if Forth had turned
toward your ideals, there is no guarantee that the early adopters would
still be using Forth.
Ultimately, I don't care-- and I don't think anyone else should. The
value of a language is how well it helps you solve *your* problems. The
trials and tribulations of anonymous astronomers really doesn't bother
me because it doesn't affect me. I know my needs, and I know when Forth
makes sense. That's all I care about.
I guess if I was a Forth vendor or someone who had some irrational
emotional investment in Forth I might care. So maybe Elizabeth Rather
regrets the loss of a dozen more users, or Charles Moore is standing in
a cubicle somewhere, shedding a tear like that Native American in those
old commercials begging people not to litter.
Elizabeth D Rather
> John Doty wrote:
....
> I guess if I was a Forth vendor or someone who had some irrational
> emotional investment in Forth I might care. So maybe Elizabeth Rather
> regrets the loss of a dozen more users, or Charles Moore is standing in
> a cubicle somewhere, shedding a tear like that Native American in those
> old commercials begging people not to litter.
Elizabeth regrets nothing. FORTH, Inc. is doing fine, and I gather MPE
is, as well. Yes, Forth is a niche language, but it continues to get
new users in that niche, and many of our old customers are doing well
with it. It's too bad John Doty doesn't personally know any, or that
Forth isn't mentioned in the papers he reads or hears, or that Michael
Coughlin can't find Starting Forth in his bookstore, but I'm afraid
those are not very reliable indicators.
As for Chuck, he has his hands (as well as his pockets) full, and I
seriously doubt he's shedding many tears right now.
werty
> Then show him a "good" solution in Forth. Your response provides no
> guidance other than the generic "hey, think in Forth." How is that
> useful to him or anyone else?
_____________________________________
It has allready been shown , millions
of times , yet we get slapped down
for it each time ...
Forth , is to simplify , yet all here ,
using the handy Luddite text tool ,
to obtuse and then defame Forth ..
Forth is to eliminate the "overhead"
like ASCII text , yet those here , insist
on defining and redefining , definitions ...
in ASCII !
I hope this will uncover , the insincerity
of those "complainers" , here ...
K.I.S.S.
When we use NON-text Forth , we can
temp use redefined ASCII chars to
bridge us over to totally GUI , posts here
in the NG .
I find it easy to do ..
Andreas Kochenburger
> I'm sure there are people who lament that slide rules
> are largely forgotten
Count me in. I've seen my sons making calculation mistakes that were not
possible if they had learnt some better gut-feeling about physical
dimensions.
And the power consumption is phenomenally low. However slide rules are
hard to use at night :-(
Jerry Avins
> John Passaniti wrote:
>> I'm sure there are people who lament that slide rules are largely
>> forgotten
>
> Count me in. I've seen my sons making calculation mistakes that were not
> possible if they had learnt some better gut-feeling about physical
> dimensions.
>
> And the power consumption is phenomenally low. However slide rules are
> hard to use at night :-(
I keep mine handy, but I have to admit that it's poor at addition.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
John Doty
> John Passaniti wrote:
>> John Doty wrote:
>> I guess if I was a Forth vendor or someone who had some irrational
>> emotional investment in Forth I might care. So maybe Elizabeth Rather
>> regrets the loss of a dozen more users, or Charles Moore is standing
>> in a cubicle somewhere, shedding a tear like that Native American in
>> those old commercials begging people not to litter.
>
> Elizabeth regrets nothing. FORTH, Inc. is doing fine, and I gather MPE
> is, as well. Yes, Forth is a niche language, but it continues to get
> new users in that niche, and many of our old customers are doing well
> with it.
But nearly all users who were using Forth 25-30 years ago have abandoned
it. That a significant fraction of the few remaining come to you doesn't
change that fact.
> It's too bad John Doty doesn't personally know any, or that
> Forth isn't mentioned in the papers he reads or hears, or that Michael
> Coughlin can't find Starting Forth in his bookstore, but I'm afraid
> those are not very reliable indicators.
They're *far* more reliable out here in the Forth desert than anything
you pay attention to.
I'm reminded of an interview I once heard with a member of the old 50's
folk group, the Kingston Trio. Speaking of the group's great popular and
commercial success, he said "when it was over, we were the last to know".
John Doty
> John Doty wrote:
>>> Forth's primary domain is embedded systems.
>>
>> Even in this niche, C dominates. And for stuff that isn't technically
>> challenging, one even sees a lot of code in languages like Python and
>> even Visual Basic, not normally considered "embedded" languages.
>
> Yes. I wasn't commenting on how dominate Forth was, just where Forth's
> niche is.
>
>> Where Forth *used* to shine was embedded systems where there wasn't a
>> distinction between developers and users. "Want to point the
>> telescope? Here are the Forth words to do that...". Forth was the
>> language of choice for those more comfortable with telescopes than
>> with programs. But at the SPIE astronomical convention last year,
>> there was a whole conference devoted to software. Hundreds of papers.
>> No Forth.
>
> So what. Spring comes, time passes, people marry and die, Pinkerton
> does not return. I'm sure there are people who lament that slide rules
> are largely forgotten,
At least my Deci-lon still works. Can't say that of many computers that
old ;-)
> manual typewriters are no longer used or that we
> don't build homes by hand-shaving logs.
>
> Is your repetitive and tedious lament really a long-winded indirect way
> of saying Forth hasn't significantly grown over the years? If so, I
> agree. But even with languages that have grown, there are still
> converts to newer and sometimes better ways of working. So even if the
> Forth community had done everything right and even if Forth had turned
> toward your ideals, there is no guarantee that the early adopters would
> still be using Forth.
>
> Ultimately, I don't care-- and I don't think anyone else should. The
> value of a language is how well it helps you solve *your* problems. The
> trials and tribulations of anonymous astronomers really doesn't bother
> me because it doesn't affect me. I know my needs, and I know when Forth
> makes sense. That's all I care about.
That's the viewpoint of the hermit programmer. But many of my projects
are orders of magnitude bigger than I can do by myself: I absolutely
must have teamwork and community leverage.
>
> I guess if I was a Forth vendor or someone who had some irrational
> emotional investment in Forth I might care.
I don't think I'm irrational about it. Recently I spent a day
characterizing a piece of hardware using one-liners in LSE64 to make
test stimuli. Then I'd pick up a scope probe. The programming part was a
tiny part of the work, and that's what I like: a programming system that
doesn't complicate my life. But once I pass the stuff on to others, it
does complicate my life because Forth is an unfamiliar technique. Of
course it helps that LSE64 is relatively simple: Standard Forth would be
a nightmare here.
> So maybe Elizabeth Rather
> regrets the loss of a dozen more users, or Charles Moore is standing in
> a cubicle somewhere, shedding a tear like that Native American in those
> old commercials begging people not to litter.
Elizabeth closes her eyes tightly to anything that doesn't match her
world view.
John Passaniti
>> Ultimately, I don't care-- and I don't think anyone else should. The
>> value of a language is how well it helps you solve *your* problems.
>> The trials and tribulations of anonymous astronomers really doesn't
>> bother me because it doesn't affect me. I know my needs, and I know
>> when Forth makes sense. That's all I care about.
>
> That's the viewpoint of the hermit programmer. But many of my projects
> are orders of magnitude bigger than I can do by myself: I absolutely
> must have teamwork and community leverage.
I'm not sure how my statement that a programming language should match
the needs of the application programmer is mangled in your mind to be a
statement that I'm a "hermit programmer."
>> I guess if I was a Forth vendor or someone who had some irrational
>> emotional investment in Forth I might care.
>
> I don't think I'm irrational about it. Recently I spent a day
> characterizing a piece of hardware using one-liners in LSE64 to make
> test stimuli. Then I'd pick up a scope probe. The programming part was a
> tiny part of the work, and that's what I like: a programming system that
> doesn't complicate my life. But once I pass the stuff on to others, it
> does complicate my life because Forth is an unfamiliar technique. Of
> course it helps that LSE64 is relatively simple: Standard Forth would be
> a nightmare here.
Regarding irrational emotional investment: When it comes to LSE64,
you're like the annoying father with an average kid who believes that
everything that Junior or Missy does is special, unique, and so much
better than everyone else's kids.
> Elizabeth closes her eyes tightly to anything that doesn't match her
> world view.
Pot to kettle. Do you really think your various rationalizations about
LSE64 demonstrate to comp.lang.forth that your eyes are any more open?
John Passaniti
> Elizabeth regrets nothing. FORTH, Inc. is doing fine, and I gather MPE
> is, as well. Yes, Forth is a niche language, but it continues to get
> new users in that niche, and many of our old customers are doing well
> with it. It's too bad John Doty doesn't personally know any, or that
> Forth isn't mentioned in the papers he reads or hears, or that Michael
> Coughlin can't find Starting Forth in his bookstore, but I'm afraid
> those are not very reliable indicators.
In case it wasn't clear, I don't have a problem with Forth being a niche
language. I do believe that there is no reason why Forth couldn't move
beyond that niche if the community cared. But everything I see suggests
that the major players in the Forth world simply don't care.
> As for Chuck, he has his hands (as well as his pockets) full, and I
> seriously doubt he's shedding many tears right now.
The best I can figure out is that John Doty suffers from some form of
techno sentimentalized nostalgia regarding the first adopters of Forth.
Whatever it is, he seems incapable of expressing his concern
rationally. Any such defense seems to quickly degenerate into a
one-sentence snarky comment.
John Doty
> John Doty wrote:
>>> Ultimately, I don't care-- and I don't think anyone else should. The
>>> value of a language is how well it helps you solve *your* problems.
>>> The trials and tribulations of anonymous astronomers really doesn't
>>> bother me because it doesn't affect me. I know my needs, and I know
>>> when Forth makes sense. That's all I care about.
>>
>> That's the viewpoint of the hermit programmer. But many of my projects
>> are orders of magnitude bigger than I can do by myself: I absolutely
>> must have teamwork and community leverage.
>
> I'm not sure how my statement that a programming language should match
> the needs of the application programmer is mangled in your mind to be a
> statement that I'm a "hermit programmer."
If you'd said "I know what my *team* needs" I'd have a different attitude.
>
>>> I guess if I was a Forth vendor or someone who had some irrational
>>> emotional investment in Forth I might care.
>>
>> I don't think I'm irrational about it. Recently I spent a day
>> characterizing a piece of hardware using one-liners in LSE64 to make
>> test stimuli. Then I'd pick up a scope probe. The programming part was
>> a tiny part of the work, and that's what I like: a programming system
>> that doesn't complicate my life. But once I pass the stuff on to
>> others, it does complicate my life because Forth is an unfamiliar
>> technique. Of course it helps that LSE64 is relatively simple:
>> Standard Forth would be a nightmare here.
>
> Regarding irrational emotional investment: When it comes to LSE64,
> you're like the annoying father with an average kid who believes that
> everything that Junior or Missy does is special, unique, and so much
> better than everyone else's kids.
LSE isn't even my language: it's Bob Goeke's. A brilliant simplification
of STOIC. I wish he'd published it back in the day, but he didn't. LSE64
is the 0.3 version, which should tell you how mature I think it is.
Still, it's doing useful things.
I think any Forth dialect that's serious about moving into the 21st
century, rather than merely piling kludges atop a 1975 vision, deserves
serious study. StrongForth. ColorForth. But not Standard Forth. Ugh.
>
>> Elizabeth closes her eyes tightly to anything that doesn't match her
>> world view.
>
> Pot to kettle. Do you really think your various rationalizations about
> LSE64 demonstrate to comp.lang.forth that your eyes are any more open?
I'm *trying* to make a Forth that *users* can return to. I'm probably
not succeeding. But I don't have my head in the sand.
John Doty
> Elizabeth D Rather wrote:
>> Elizabeth regrets nothing. FORTH, Inc. is doing fine, and I gather
>> MPE is, as well. Yes, Forth is a niche language, but it continues to
>> get new users in that niche, and many of our old customers are doing
>> well with it. It's too bad John Doty doesn't personally know any, or
>> that Forth isn't mentioned in the papers he reads or hears, or that
>> Michael Coughlin can't find Starting Forth in his bookstore, but I'm
>> afraid those are not very reliable indicators.
>
> In case it wasn't clear, I don't have a problem with Forth being a niche
> language. I do believe that there is no reason why Forth couldn't move
> beyond that niche if the community cared. But everything I see suggests
> that the major players in the Forth world simply don't care.
Bingo.
>
>> As for Chuck, he has his hands (as well as his pockets) full, and I
>> seriously doubt he's shedding many tears right now.
>
> The best I can figure out is that John Doty suffers from some form of
> techno sentimentalized nostalgia regarding the first adopters of Forth.
Huh? *You're* the one who wrote:
"So maybe Elizabeth Rather regrets the loss of a dozen more users, or
Charles Moore is standing in a cubicle somewhere, shedding a tear like
that Native American in those old commercials begging people not to litter."
I didn't say *anything* about Charles Moore shedding tears. I think his
work is admirable and interesting, although not directly relevant to the
problems I'm trying to solve.
As for "techno-sentimentality", that's expressed in things like my
bedside radio, a 1934 model. I don't use Fortran II any more. I did some
cool things in PL/M once upon a time, but I don't miss it. But LSE was
unreasonably effective, even in the 1990's on obsolete and underpowered
hardware from the late 70's. And I haven't really found a modern substitute.
> Whatever it is, he seems incapable of expressing his concern
> rationally. Any such defense seems to quickly degenerate into a
> one-sentence snarky comment.
I can't type as fast as you can. And I'm kinda busy.
John Passaniti
>> I'm not sure how my statement that a programming language should match
>> the needs of the application programmer is mangled in your mind to be
>> a statement that I'm a "hermit programmer."
>
> If you'd said "I know what my *team* needs" I'd have a different attitude.
Congratulations on discovering a new kind of annoying. Others in
comp.lang.forth take what I write and inject meaning that isn't there.
You're now taking what I didn't write and injecting meaning.
>> Pot to kettle. Do you really think your various rationalizations
>> about LSE64 demonstrate to comp.lang.forth that your eyes are any more
>> open?
>
> I'm *trying* to make a Forth that *users* can return to. I'm probably
> not succeeding. But I don't have my head in the sand.
What then do you call your reflexive defense of arbitrary design
decisions in LSE64? In past conversation with you, I've pointed out a
variety of issues I had with the design of LSE64. And in every case I
can remember, what I hoped would be a discussion of the tradeoffs
between pros and cons behind those decisions instead turned into a
statement that could be translated as "that's the way I did it, I like
it that way, my users don't complain, therefore it is good."
John Passaniti
> I didn't say *anything* about Charles Moore shedding tears. I think his
> work is admirable and interesting, although not directly relevant to the
The point of my statement was that you seem to believe that it is in
some way significant that some early adopters of Forth (the astronomers)
have gone to other languages. But beyond *you* caring, your seem to
believe that *others* should also care about this. And of all the
others who should care, I would expect you would think that Charles
Moore would care.
So the notion of Charles Moore shedding a tear because some astronomers
from more than 25 years ago no longer care about Forth was my overly
dramatic way of highlighting that nobody who matters gives a damn.
Howerd
On Apr 5, 12:45 pm, Elizabeth D Rather <erather...@forth.com> wrote:
[snip]
> Elizabeth regrets nothing. FORTH, Inc. is doing fine, and I gather MPE
> is, as well.
[snip]
Inventio Software is doing fine too - that's me by the way.
I've just realised that the last time I did a purely C-based contract
was April 2004.
Forth may be a niche market, but its keeping me off the streets...
Stumbling across Forth in 1978 has given me the opportunity to work on
some really interesting projects - KKIA in Alabama, OTA in Brussels,
ACE in the UK.
And I've just started that "Forth job in Oxfordshire" posted on clf a
few days ago. I had already got a call from an _agency_ - how
mainstream.
So I have no regrets either. I've worked with some great people on
some fun projects.
Thanks to Chuck, Elizabeth and the rest of the pioneers!
I don't think its irrational to do what you enjoy doing...
Regards
Howerd 8^)
ne...@absamail.co.za
> > guidance other than the generic "hey, think in Forth." How is that
> > useful to him or anyone else?
werty wrote:-
> Forth is to eliminate the "overhead"
> like ASCII text , yet those here , insist
> on defining and redefining , definitions ...
> in ASCII !
>
> When we use NON-text Forth , we can
> temp use redefined ASCII chars to
> bridge us over to totally GUI , posts here
> in the NG .
Although it may be unrelated to the OP thread, which I don't know,
I think this is what YOU are advocating:-
Any [unused yet] single ascii-char can, in forth, designate
[call] a single instruction -- or even a whole big program.
Ie. may be a 'forth word'.
The 128 non-ascii-chars could be allowed to do so too.
These 128 non-ascii-chars could be mapped to render suitable
images; eg. with a/the simple dot-matrix LCD.
The images could be designed to have heuristic value, which
also frees the user from eg. english.
So, eg. with standard/ascii based forth, where the program
'triangulates', the designer may have chosen the heuritic
string 'value' of "trng" as the word to call it.
Now he can instead just use a single char, specially designed
to look like a triangle, to call it - from the dictionary.
Perhaps even, some of the new-chars can be mapped to render
images which are bigger/more-complex than the standard
ascii-char set.
The advantages are obvious, not to mention the billions of
non-ascii-reading potential users.
After an existing ascii-based forth system is extended to use
the upper non-ascii char-set, a totally non-ascii system could
be ported, to totally eliminate/replace ascii ? Since "WE"
have a tremendous amount of knowledge/capability invested
in ascii, this seems unwise.
== Chris Glur.
John Doty
>.what I hoped would be a discussion of the tradeoffs
> between pros and cons behind those decisions instead turned into a
> statement that could be translated as "that's the way I did it, I like
> it that way, my users don't complain, therefore it is good."
Many are Bob's decisions, not mine. And sometimes the users affirm they
like them, rather than simply not complaining. Especially "repeat" (tail
recursion). There's nothing like that in Standard Forth. And I try to
look at code written by users to see how users perceive the the way a
language serves (or doesn't serve) the task at hand.
Moore's approach to Forth is explicitly hardware-driven, while van
Rossum's approach to Python is explicitly driven by user psychology.
Both are well worth attention. Can they be combined? Could we have a
great language close to the hardware that builds a large user community,
giving the user great leverage? I think so. Forth came close, but
fizzled out. Maybe LSE64 is a baby step on this path.
Bob Goeke's npublished, unportable LSE from 1978 was good enough that
people who knew about it (and there weren't very many) were buying chips
and assembling obsolete computers to be able to use it up until about
1990, and were still using it (on 2 MHz 1802's) up until at least 1998
in cutting edge scientific research.
John Doty
> John Doty wrote:
>> I didn't say *anything* about Charles Moore shedding tears. I think
>> his work is admirable and interesting, although not directly relevant
>> to the problems I'm trying to solve.\
>
> The point of my statement was that you seem to believe that it is in
> some way significant that some early adopters of Forth (the astronomers)
> have gone to other languages.
You can't name *any* class of adopters who haven't mostly gone to other
languages.
If you traveled to Rome and found no Catholics there, wouldn't you
conclude that something significant had taken place?
> But beyond *you* caring, your seem to
> believe that *others* should also care about this.
Hermit programmers need not care. But anyone who needs community
leverage should.
> And of all the
> others who should care, I would expect you would think that Charles
> Moore would care.
Well, maybe he's the ultimate hermit programmer, following his research
interests. Very valuable. But research doesn't lead automatically to
practical application. We need to pay attention, but we also need to adapt.
>
> So the notion of Charles Moore shedding a tear because some astronomers
> from more than 25 years ago no longer care about Forth was my overly
> dramatic way of highlighting that nobody who matters gives a damn.
No wonder Forth is in decline.
George Peter Staplin
> On Apr 2, 9:43 am, George Peter Staplin
><georgepsSPAMME...@xmission.com> wrote:
>> I'm extremely frustrated by Forth lately.
>>
>> I was working on an interface to my new window system in Ficl. I found
>> it extremely frustrating to juggle around data on the stack, such as 2
>> RGBA color components when building a gradient. 8 items or more.
>
> Local variables are the wrong approach for this. If you are
> programming in C, it might be good practice to write code like
>
> int r,g,b,a;
>
> Then have lots of rather arbitrary scalar expressions in r,g,b,a.
> However this is a poor way of abstracting a color value because you
> always have to deal with those four values as a group. The same is
> true in C as well as in Forth.
The problem with that as I see it is the byte-order. If I treat a
single pixel as a single quantity like a uint32_t then I have ordering
constraints to deal with, that I wouldn't otherwise. At the moment in
the window system only a few special cases that are #ifdef __i386__ are
concerned with byte-order, plus the nx_vbe_driver which is only for x86
systems.
> When you realize that a color component is in fact a single entity --
> or "object", if you will, you'll see that stack juggling is not a
> problem at all. Computing something like a gradient becomes trivial:
> you write some words to perform arithmetic on colors, then put
> together a loop.
>
> One way to define 'colors' as an entity in the language is to use OOP.
> But on the other hand, if your color is really just a quadruple of
> numbers -- integers or floats, depending on your window system, you
> can get by with array processing words instead. If you can add
> vectors, scale vectors and build a list of vectors, you can compute a
> smooth gradient in a line of code. Take a look at APL and Lisp and
> borrow the concepts.
Hmm, interesting.
> The stack is incidental, by the way. Forth uses a stack because this
> happens to be the simplest way to glue functions together -- you put
> whitespace between them! When you're programming in Forth, you're not
> programming with a stack, you're programming Forth. You get a stack
> for free -- but it doesn't mean you have to store everything there.
> Object systems, array processing and so on are really just examples of
> data structures together with a library of supporting idioms. You can
> build these in Forth -- this is Forth's strength.
>
> I've found that in almost every case where I had to juggle a lot of
> values on the stack, it meant that I was simply missing a higher
> level, more declarative approach, one that would also give me a more
> reusable abstraction for solving similar problems in the future.
Thank you Slava.
-George
ken...@cix.compulink.co.uk
put-my-firs...@JapanIsShinto.com (John Passaniti) wrote:
> or if it would be more efficient and worthwhile to look at
> languages, tools, libraries, and frameworks that are *designed* for
> that domain.
There are Forths that do come with development tools for various
environments WinForth for example supplies a form designer for Windows
applications. Compared with something like Delphi it is limited as an
IDE but there is enough to be useful. Off course as IDE both Delphi and
Visual Basic were far easier to use than the Microsoft C++ compiler due
to the limitations of the class libraries supplied with that.
In fact that was the main selling point of early versions of Delphi, it
was as easy to develop with as Visual Basic and the programs ran a lot
faster and did not need to ship extra run time support which could
double program size.
Ken Young
rickman
> LSE isn't even my language: it's Bob Goeke's. A brilliant simplification
> of STOIC. I wish he'd published it back in the day, but he didn't. LSE64
> is the 0.3 version, which should tell you how mature I think it is.
> Still, it's doing useful things.
>
> I think any Forth dialect that's serious about moving into the 21st
> century, rather than merely piling kludges atop a 1975 vision, deserves
> serious study. StrongForth. ColorForth. But not Standard Forth. Ugh.
>
>
> I'm *trying* to make a Forth that *users* can return to. I'm probably
> not succeeding. But I don't have my head in the sand.
This is one of those threads that is very difficult to read to find
the actual content in the midst of all the rhetoric. Can you state
clearly and sucinctly what it is about Forth 94 that makes it not
worth using in your opinion? I am asking for your opinion, but please
try to give facts.
John Passaniti
>> .what I hoped would be a discussion of the tradeoffs between pros and
>> cons behind those decisions instead turned into a statement that could
>> be translated as "that's the way I did it, I like it that way, my
>> users don't complain, therefore it is good."
>
> Many are Bob's decisions, not mine. And sometimes the users affirm they
> like them, rather than simply not complaining. Especially "repeat" (tail
> recursion). There's nothing like that in Standard Forth. And I try to
> look at code written by users to see how users perceive the the way a
> language serves (or doesn't serve) the task at hand.
And here again we get back to the same problem I have with your
messages. I'll use your example of "repeat."
You've talked about making a language for users, not just programmers.
I assume by that you mean a language where programmers can create a set
of useful tools for end users. For example, in a system, you might
consistently represent voltages in millivolts or angles in radians.
Users might think more in terms of volts and degrees, so you might
create words to assist them by providing appropriate conversion.
Now the user has a language that matches their problem domain. A user
might be able to type:
5 mV fire 172 degrees aim
Presto, the user now has a language that matches their problem domain.
But that language isn't LSE64 since LSE64 doesn't come with definitions
for mV, fire, degrees, or aim. That user-centered language came from a
programmer somewhere (or an advanced user) who created those definitions.
The same applies for Standard Forth. Users don't care about the deeper
mysteries of compilation verses interpretation and don't have to if
someone has created a user-centered language that matches their problem
domain. When you're talking about users, you're not talking about
someone who is running an "out of the box" LSE64 or Standard Forth.
You're talking about a user sitting at a prompt with a system
pre-populated with words that are designed to work nicely together.
So in that context, you brought up "repeat" (which incidentally exists
in Postscript and in a related form in Smalltalk and Ruby). You think
that users perceive that LSE64's "repeat" serves them better than the
equivalent Forth do/loop structure. I don't have a problem with that
claim, but I do have a problem with you forgetting the premise-- that
the language a user uses isn't the base language. It's the language
pre-populated with words for their problem domain.
So what is the difference to the end user if they are using LSE64 (which
has "repeat" plus the words added to address their problem domain) and
the end user using Forth (which would also have words added to address
their problem domain, including the magical "repeat")? In both cases,
the end user has "repeat." That one is native and one is a trivial
extension won't matter to the end user.
You might have an argument that LSE64 is a better language for
programmers. I don't necessarily agree-- you've got just as many
arbitrary decisions in LSE64 as Forth does and the same annoying mixture
of postfix and prefix. But for end users, I think your arguments fail
because the language they use isn't going to be raw LSE64 or raw
Standard Forth. They'll be using a language that has words added for
their problem domain.
John Doty
> On Apr 5, 8:53 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> LSE isn't even my language: it's Bob Goeke's. A brilliant simplification
>> of STOIC. I wish he'd published it back in the day, but he didn't. LSE64
>> is the 0.3 version, which should tell you how mature I think it is.
>> Still, it's doing useful things.
>>
>> I think any Forth dialect that's serious about moving into the 21st
>> century, rather than merely piling kludges atop a 1975 vision, deserves
>> serious study. StrongForth. ColorForth. But not Standard Forth. Ugh.
>>
>> I'm *trying* to make a Forth that *users* can return to. I'm probably
>> not succeeding. But I don't have my head in the sand.
>
> This is one of those threads that is very difficult to read to find
> the actual content in the midst of all the rhetoric. Can you state
> clearly and sucinctly what it is about Forth 94 that makes it not
> worth using in your opinion? I am asking for your opinion, but please
> try to give facts.
Forth 94 is too complicated. It is, of course, hard to succinctly
describe excessive complexity! But I will try. Perhaps you should take a
look at the documents LSE64_Tutorial.html and LSE64.txt from
http://space.mit.edu/home/jpd/lse64-0.3.tar.gz. Compare the complexity
of the language described with your favorite Forth dialect. The original
LSE was even simpler: I've added floating point and some experimental
features. Maybe I should start taking things out. But anyway, a few
specifics:
1. Forth 94 is really two different languages: for example, the phrase:
"CHAR X" does two *different* things, depending on STATE. There is a lot
of vocabulary to support this useless distinction: multiple ways to
quote a string (LSE64 has only one), and all of the [] words. And the
STATE distinction is truly useless: there is nothing the text
interpreter can do that compiled code cannot do.
2. Maybe there are two number stacks, maybe there is one. SWAP doesn't
reliably swap things: the user must take care to understand what *might*
go where and the number of cells the operands *might* occupy. Many
similar issues result from the abandonment of Forth's cell orientation
by Forth 94.
3. Algol-style flow control inhibits factoring, requires the user to
maintain yet another mental stack, and just doesn't fit very well. The
single most appreciated feature of the original LSE, by users, is the
"repeat" (simple tail recursion) loop. Indeed, most never used any other
loop construct. Forth 94 has too many loop constructs. For conditionals,
I see the use of "short-circuit" evaluation growing in other languages,
and it seems to fit Forth very well. IF ELSE THEN is notoriously confusing.
4. Forth 94 standardized the facade of the language rather than its
foundation. The implementation is supposed to be hidden. But the nature
of Forth requires the user to mentally model the behavior of the
implementation to a greater extent than is necessary in other languages.
"x=y+2*z" isn't as connected to the implementation than "z 2 * y + x !".
So the user of Forth 94 must cultivate an Orwellian capability to
mentally model the implementation precisely as far as allowed, no
shallower and no deeper.
Why do you suppose Chuck Moore doesn't use Forth 94?
Andreas Kochenburger
> Forth 94 is too complicated. <snip/snap/snuff>
You seem to be saying:
Roll your own Forth. If you can't roll it, it ain't Forth.
The downside of that notion is the old saying:
When you've seen one Forth, you've seen one Forth.
I don't like Forth94's word zoo either. However it helps to have a
common core language definition. And whether a programming language is a
Neandertal language or not, can't be defined by acclamation or booing
down from some few loners here.
John Doty
> John Doty wrote:
>> Forth 94 is too complicated. <snip/snap/snuff>
>
> You seem to be saying:
> Roll your own Forth. If you can't roll it, it ain't Forth.
I didn't roll the original LSE. I used it for a decade or so. Helped
discover the atmosphere of Pluto, study clusters of galaxies, study
pellet implosions in thermonuclear fusion experiments, develop and
calibrate instrument technology for spacecraft...
>
> The downside of that notion is the old saying:
> When you've seen one Forth, you've seen one Forth.
>
> I don't like Forth94's word zoo either. However it helps to have a
> common core language definition.
It would help of it was a *simple* common core language definition. But
an excessively complicated standard is worse than no standard at all. A
Forth without simplicity seems pretty pointless to me.
> And whether a programming language is a
> Neandertal language or not, can't be defined by acclamation or booing
> down from some few loners here.
Nor can a language prosper if it is rejected by nearly all of the
community of users.
John Passaniti
>> The point of my statement was that you seem to believe that it is in
>> some way significant that some early adopters of Forth (the
>> astronomers) have gone to other languages.
>
> You can't name *any* class of adopters who haven't mostly gone to other
> languages.
Huh? Did you forget a word or two in there?
> If you traveled to Rome and found no Catholics there, wouldn't you
> conclude that something significant had taken place?
Something significant? Sure. But you're commenting on the effect, not
the cause. In much the same way, you cite that astronomers no longer
use Forth (the effect) but you don't offer a cause. You offer a lot of
armchair analysis that seems driven more by your sense of aesthetics and
emotional investments. But I can think of a variety of causes that are
neutral with respect to Forth:
Here's a possibility for you: Forth never was the right tool for
astronomers. It did the job, but they were never really happy (or
unhappy) with it. They just used it because it was there and worked.
But just like you can drive a nail with a screwdriver, there are better
ways. Time passed, and when those better ways came forward, they jumped
ship to what was better.
Here's a related possibility: Those early adopters cared more about
tools than technologies, and were interested more in results than
personalities. Forth was a tool that worked, but they never really had
the kind of emotional investment you apparently do in it. They saw it
as a way to get results. It could have been Forth, C, an abacus, or a
particularly good tea-leaf reader. Doesn't matter to them. Time passes
and the old skool krew dies off. Those younger kids come sweeping in
and they have different tools. And so it just transitions over time.
Or how about this: Those adopters were tracking Forth and were active
and experimenting with all the latest Forth research. Looking around
and saw that instead of having to transform their equations into
postfix, they could use a Forth-based infix parser to generate the code
for them. They look around some more and find OOP classes that help to
further insulate them from the underlying machine. They continue
working, creating domain-specific languages that get closer and closer
to their ideal. And then, someone points out that their Forth-based
domain specific language seems to have an awful lot in common with
Python. So they look closer and say, "hey, let's get rid of some layers
here and just go with that."
>> But beyond *you* caring, your seem to believe that *others* should
>> also care about this.
>
> Hermit programmers need not care. But anyone who needs community
> leverage should.
At best, your argument seems to be something like the loss of the
astronomers is kind of like a canary in a coal mine. Their move away
from Forth is presumably some kind of signal to you that something bad
is happening.
My problem isn't that I disagree with the premise, but it's perhaps the
weakest demonstration of the premise possible. You don't need the loss
of the astronomers to see the many ways that the Forth community's
relative immaturity and unsophistication is slowly killing it. By
focusing on a group of esoteric people who's only real connection to
Forth is some involvement in the early years, you're actually
trivializing the issue and helping people disconnect from it.
Want to show how Forth hasn't progressed? Drop the astronomers. Point
instead to the wild successes of other languages and the ecosystems they
are generating. Point to the rise of scripting languages that favorably
overlap on the capabilities of Forth. Point to the rich libraries
people are using to get work done and to further bootstrap their
communities.
Astronomers? Who cares. If I remember correctly, didn't Charles Moore
do an early Forth database system for Mohasco, a carpeting manufacturer?
Oh god, tell me it isn't true-- first the astronomers leave, and then
the carpeting manufacturers! Why Forth, Inc. should just fire everyone
and sell off the office furniture right now.
>> So the notion of Charles Moore shedding a tear because some
>> astronomers from more than 25 years ago no longer care about Forth was
>> my overly dramatic way of highlighting that nobody who matters gives a
>> damn.
>
> No wonder Forth is in decline.
That's simplistic. Forth is in decline for a variety of reasons, some
having absolutely nothing to do with Forth but with the increase of
options available to programmers.
John Doty
> John Doty wrote:
>>> .what I hoped would be a discussion of the tradeoffs between pros and
>>> cons behind those decisions instead turned into a statement that
>>> could be translated as "that's the way I did it, I like it that way,
>>> my users don't complain, therefore it is good."
>>
>> Many are Bob's decisions, not mine. And sometimes the users affirm
>> they like them, rather than simply not complaining. Especially
>> "repeat" (tail recursion). There's nothing like that in Standard
>> Forth. And I try to look at code written by users to see how users
>> perceive the the way a language serves (or doesn't serve) the task at
>> hand.
>
> And here again we get back to the same problem I have with your
> messages. I'll use your example of "repeat."
>
> You've talked about making a language for users, not just programmers. I
> assume by that you mean a language where programmers can create a set of
> useful tools for end users. For example, in a system, you might
> consistently represent voltages in millivolts or angles in radians.
> Users might think more in terms of volts and degrees, so you might
> create words to assist them by providing appropriate conversion.
>
> Now the user has a language that matches their problem domain. A user
> might be able to type:
>
> 5 mV fire 172 degrees aim
Yep. That's indeed the approach.
>
> Presto, the user now has a language that matches their problem domain.
> But that language isn't LSE64 since LSE64 doesn't come with definitions
> for mV, fire, degrees, or aim. That user-centered language came from a
> programmer somewhere (or an advanced user) who created those definitions.
Often a not very advanced user, especially in the old days of LSE.
>
> The same applies for Standard Forth. Users don't care about the deeper
> mysteries of compilation verses interpretation and don't have to if
> someone has created a user-centered language that matches their problem
> domain.
The "someone" who creates a user-centered language is almost always a
user. Programmers generally lack the viewpoint necessary to do this. To
make a user-centered language you must learn how to think like a user,
and you must master the application domain.
> When you're talking about users, you're not talking about
> someone who is running an "out of the box" LSE64 or Standard Forth.
> You're talking about a user sitting at a prompt with a system
> pre-populated with words that are designed to work nicely together.
And then the requirements change and no programmer is available.
>
> So in that context, you brought up "repeat" (which incidentally exists
> in Postscript and in a related form in Smalltalk and Ruby). You think
> that users perceive that LSE64's "repeat" serves them better than the
> equivalent Forth do/loop structure. I don't have a problem with that
> claim, but I do have a problem with you forgetting the premise-- that
> the language a user uses isn't the base language. It's the language
> pre-populated with words for their problem domain.
But the users must be able to read the base language in order to
maintain and extend the code, even if they didn't write the first draft.
That's how it works in a research environment. There's never a
programmer around when you need one ;-)
>
> So what is the difference to the end user if they are using LSE64 (which
> has "repeat" plus the words added to address their problem domain) and
> the end user using
*Standard*
> Forth (which would also have words added to address
> their problem domain, including the magical "repeat")? In both cases,
> the end user has "repeat." That one is native and one is a trivial
> extension won't matter to the end user.
Only if they don't have to understand the underlying code. That's a big if.
>
> You might have an argument that LSE64 is a better language for
> programmers.
In my world, programmers don't do much coding. You need the skills of a
professional programmer to review, to clean up code, make it more
efficient, and especially to make it bullet proof. But programmers
usually don't have the domain knowledge to write the code in the first
place.
Forth used to be prominent in my world for this reason. It was simpler
and more flexible than Fortran and easier than assembly language, so
ordinary users, not specialized programmers, could do the coding. But
the alternatives got better, while Standard Forth is in many ways worse
than the Forth of 1975.
> I don't necessarily agree-- you've got just as many
> arbitrary decisions in LSE64 as Forth does and the same annoying mixture
> of postfix and prefix.
Maybe there's a better way. LSE64 doesn't need a lot of prefix. Quoting
a string seems hard without a prefix word, but maybe other parsing
things could be postfix. Figuring out what's easy to read isn't trivial,
but Forth experts are not good judges. I can't claim to be very good
either, but at least I don't ignore the problem.
I do have a useful resource: printouts of LSE code from the 1980's. I
study these to see how ordinary users understood the language.
> But for end users, I think your arguments fail
> because the language they use isn't going to be raw LSE64 or raw
> Standard Forth. They'll be using a language that has words added for
> their problem domain.
Only if they don't have to understand the underlying code. That's a big if.
John Doty
> John Doty wrote:
>>> The point of my statement was that you seem to believe that it is in
>>> some way significant that some early adopters of Forth (the
>>> astronomers) have gone to other languages.
>>
>> You can't name *any* class of adopters who haven't mostly gone to
>> other languages.
>
> Huh? Did you forget a word or two in there?
What word? Can you actually claim Forth is a major player in *any*
domain any more?
John Passaniti
>>> You can't name *any* class of adopters who haven't mostly gone to
>>> other languages.
>>
>> Huh? Did you forget a word or two in there?
>
> What word? Can you actually claim Forth is a major player in *any*
> domain any more?
I'm not claiming anything other than I didn't understand the sense of
your statement; it was unclear to me. Now that I understand the sense
you had, I'll reject it as irrelevant.
I guess I simply don't understand the point because I lack either a
financial or emotional investment in Forth. To me, it's a tool. It
works great for some things, and fails miserably for others-- just like
every other tool I've ever used. So when I hear about astronomers
dropping Forth and going to other languages, I don't have a problem in
the least. People *should* use whatever tool makes the most sense to
them and their work.
Now, it is possible to learn something here. We might ask what was
lacking in Forth that made them leave. And through a careful analysis
of their response, we can determine if Forth *should* change. Your
messages suggest that Forth needs to change, but that isn't logically
demonstrated. For example, let's say that astronomers really want to
have a language that can do arbitrary precision math. (I have no idea
if this is true or not, but let's just assume it for the sake of
argument.) So the astronomers say, "hey Forthers, we'd love to stay,
but we really want arbitrary precision math like in Python."
Is it your position that Forth should be all things to all people and
that it should immediately adopt arbitrary precision math so that this
community of users isn't lost?
As always, what I'm most interested here isn't a direct reply to my
example. Much more insight into how your mind works will come from you
abstracting my example and giving me the principle on which you're
basing your arguments.
Duke Normandin
[snip]
> Forth 94 is too complicated. It is, of course, hard to succinctly
> describe excessive complexity! But I will try. Perhaps you should take a
> look at the documents LSE64_Tutorial.html and LSE64.txt from
> http://space.mit.edu/home/jpd/lse64-0.3.tar.gz. Compare the complexity
> of the language described with your favorite Forth dialect. The original
> LSE was even simpler: I've added floating point and some experimental
> features. Maybe I should start taking things out. But anyway, a few
> specifics:
[snip]
> Why do you suppose Chuck Moore doesn't use Forth 94?
Is FIG-Forth _still_ closer to the original "spirit" and "intent" of the
Moore's creation? BTW, Forth 83 / 94 -- were these primarily commercial
Forth initiatives - or visa versa?
--
duke | A: Yes. |
| >Q: Are you sure? |
| >>A: Because it reverses the logical flow of conversation. |
| >>>Q: Why is top posting frowned upon? |
Charlie Springer
(in article <Uo7Rh.39576$x9.31934@edtnps89>):
>> One major reason I've heard for not using it any more is that it is
>> "write-only". This is not dogma, this is simply what users with real
>> problems to solve report. But the same sorts of users once used Forth.
>
> Thanks for the heads-up!
I once built and wrote the software for a scanning spectrophotomoter and
flourescence lifetime instrument. It was 100% Forth including plotter
drivers and fonts and nonlinear iterative fits to data. It was used for
research and maintained by others for over 20 years simply using the
commented code. When it was ported to a PC they used a Forth-like analysis
language. I forget the name. My point is that a big pile of code from
assembly language drivers to plotting for publication was factored and named
and commented in a way that made sense. "Write-only" applies to crappy code
in any language.
Even the famous "One block disk interface" for Fig-Forth is readable. On the
other hand, a bunch of numbers stuffed into unamed locatiotions is not
readable. I recently worked on an application that was all assembly. It could
not be understood by looking at the code since there were jump tables of
addresses that were changed dynamically during execution. That was
"write-only" and a source of income for the writer for many years after he
left the company.
Forth is a blast. Getting a good version for embedded work is the hard part.
I have bought and discarded several. Go with Forth Inc. if you can.
-- Charlie Springer
Charlie Springer
(in article <L_bRh.6262$ya1....@news02.roc.ny>):
> Is your repetitive and tedious lament really a long-winded indirect way
> of saying Forth hasn't significantly grown over the years? If so, I
> agree. But even with languages that have grown, there are still
> converts to newer and sometimes better ways of working. So even if the
> Forth community had done everything right and even if Forth had turned
> toward your ideals, there is no guarantee that the early adopters would
> still be using Forth.
There are a few version that grew nicely. Win32Forth and Mops for example. I
would like to see something like three levels of standard Forth. A simple
small Fig-like system that embeds and debugs easily. An ANSI Forth, but less
complicated and with complete specifications. An OOForth. Just do Mops as a
standard.
Mops or Win32Forth would be my choice for the more sophisticated web server
type applications. I think they are made for each other.
Or not. This McClelland's sure has a smokey peaty flavor. Stick with Cutty
Sark?
-- Charlie Springer
Elizabeth D Rather
...
> Is FIG-Forth _still_ closer to the original "spirit" and "intent" of the
> Moore's creation? BTW, Forth 83 / 94 -- were these primarily commercial
> Forth initiatives - or visa versa?
Fig-Forth was derived from FORTH, Inc.'s first microprocessor Forth,
called microFORTH, in the late 70's, primarily aimed at the hobbyist
market. The people who did most of the work were new to Forth and
didn't understand a lot of things. Their main goal was to make a system
easy to bring up on a variety of platforms (by typing in the assembly
language for the processor of choice), and so optimized portability at
the expense of efficiency. Chuck wrote Forth in Forth (metacompiling
for new platforms) and made massive efforts to optimize efficiency on
each. He thought FigForth was terrible, although he mellowed toward
some of the later incarnations.
Forth83 and Forth94 were developed by a combination of hobbyist
developers and users, commercial vendors, and users of the commercial
systems. The big difference is that Forth83 was developed in only two
3-day meetings, 6 months apart, with somewhat differing membership,
informal rules, and no official sanctioning body such as ANSI. As a
result, many decisions were taken with relatively little thought. Some
actions in the second meeting reversed decisions made in the first.
Although a lot of people adopted Forth83, because there was a wide
demand for standardization, there were a lot of bad feelings over it.
The ANSI process began in 1986, under the same formal rules governing
all other ANSI language standards. The developers met 4 times a year, a
total of 16 meeting days/year, in various parts of the country
encouraging local Forthers to attend and voice their opinions. Drafts
were published for public comment, and all comments were responded to.
There were 4 drafts published for public review, and the standard was
adopted in 1994 only after there were no more substantive changes
resulting from the last review period. The list of members of the
committee is published in the document. It's a large and diverse bunch.
It's fair to say no one is 100% in agreement with everything in ANS
Forth, because compromises are necessary to reach a consensus. But a
consensus was reached on every issue, and everyone I know who has been
seriously using it thinks it's pretty good (that includes me). The
dissenters are roughly evenly divided between folks who think it's way
too large and complicated and those who think it's way too limited and
incomplete. Those of us who are using Forth in commercial projects
(many of which are for large companies) know that the very existence of
an ANSI Standard has facilitated its acceptance in these organizations.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Charlie Springer
(in article <N6OdnURhv8zhM4vb...@wispertel.com>):
> IF ELSE THEN is notoriously confusing.
I found that new users caught on straight away if I simply said
IF true do this ELSE do this THEN continue
-- Charlie Springer
sl...@jedit.org
> There are a few version that grew nicely. Win32Forth and Mops for example. I
> would like to see something like three levels of standard Forth. A simple
> small Fig-like system that embeds and debugs easily. An ANSI Forth, but less
> complicated and with complete specifications. An OOForth. Just do Mops as a
> standard.
>
> Mops or Win32Forth would be my choice for the more sophisticated web server
> type applications. I think they are made for each other.
Unfortunately, the lead developer of Mops has stated that he does not
intend to port Mops to Intel Macs. So it appears that Mops will fade
into the sunset, along with the PowerPC hardware it is closely tied
to.
Slava
Charlie Springer
(in article <1175923259.6...@q75g2000hsh.googlegroups.com>):
> Unfortunately, the lead developer of Mops has stated that he does not
> intend to port Mops to Intel Macs. So it appears that Mops will fade
> into the sunset, along with the PowerPC hardware it is closely tied
> to.
Mike (the M in Mops - Mike's own programming system) includes the source code
with Mops and the OO part is written in ANS Forth to run with ANS as the
core. Mike spent a lot of effort making a great ANS Forth for the PowerPC and
System9 then OS-X. He doesn't want to do it all over for the Intel
Architecture. When I started an ARM project a few years ago and asked if he
would do an ARM implementation he just said load the OO code on an ANS Forth
for the ARM. Being an extension to ANS (I think the same is true for
Win32Forth, they are both inspired by Yerk/NEON) makes it a natural to be an
official OO version. The object model is so much more natural than the C++,
C#, Java stuff that when I first read though the examples I felt a great
weight had been lifted. The self same moment I could pray, the albatross fell
from my neck and sank like lead into the sea. Well, kind of.
-- Charlie Springer
PS. Speaking of PowerPC and Xeon, The new 8 processor 3 GHz PowerMac is said
to be "almost twice as fast as the Quad G5". Looks like either the G5's are
holding up well, or utilizing parallel resources is harder than expected.
When Wolfram brings out a dual-quad Xeon version of the parallel Mathematica
sales will jump in academia and when FinalCut Pro and some of the FX software
can really use the 8 processors Hollywood will start buying by the truckload.
Of course Steve owns Pixar and Disney now... man, that is a heck of a story,
isn't it? I wonder what Uncle Walt would think?