Re: The Promise of Forth
- From: Jonah Thomas <jethomas5@xxxxxxxxx>
- Date: Tue, 25 Mar 2008 00:43:34 -0400
Duke Normandin <dukeofperl@xxxxxxx> wrote:
Having read this thread from its beginning, it sweep over this newbie
that the current Forth community - such as it is - is _not_ a
co-operative society, but rather a chronically argumentative one. It
is truely sick!
First, note that comp.lang.forth mostly gets posts from the same dozen
or so people repeatedly, and may not be representative of the whole
community. On the other hand, there aren't a lot of places that
represent the whole Forth community. The communication that isn't going
on here may not be going on anywhere else either.
I agree with John Doty in that I sense that Forth has the makings of
becoming great in some form. I have no clue what needs to change with
Forth. All I know is that I taught myself Perl, PHP, TCL/Tk and now
newLisp with very little effort. But for some reason, I'm struggling
with Forth. It feels like a hodge-podge of kludges to me. Perl is like
that too in some ways, IMO.
That could be valuable! If you don't mind, would you write down what
looks like kludges to you as you notice them? If you keep learning Forth
after awhile the things that seem wrong will start to look natural and
you'll forget that they ever looked kludgey.
I remember a few from when I was first learning Forth. Like, I looked at
how IF ... ELSE ... THEN worked. I wrote a definition that had it, and
then I looked at the code that got laid down.
: FOO
IF 5 ELSE 3 THEN ;
And the code went
0branch address1 lit 5 branch address2 lit 3 exit
address1 was the address of the lit in "lit 3" and address2 was the
address of the exit.
There was an unconditional branch to an exit, for no reason. It would
have worked better to just do EXIT. Shorter and quicker.
But then I thought about it, and I considered how much more complicated
it would be to handle that kind of thing, and I realised that we got a
much simpler control structure if we just ignored these little
inefficiencies. A few years ago I read that ColorForth has extremely
simple control structures that make it easy to do this without the
waste. It took Chuck Moore something like 20 years to get around to
finding the better way.
I remember I wanted to do something with strings, and I thought the
command WORD ought to be useful. You give WORD a character and it gives
you a string from the input buffer that ends just before that character.
Or the rest of the input buffer if the character isn't there. Just what
I needed. But the Forth I was using didn't quite do that. It copied my
string onto the top of the dictionary, along with a byte to say how long
it was, and it flipped a bit on the last character. It did far more than
I wanted it to, so that I couldn't use it. Ten years later we
standardised PARSE which did some of what I wanted. Now we're
standardising PARSE-NAME which almost does the rest.
One of the things that seemed most kludgy to me was DO +LOOP . After I
studied it I understood why it had to be that way, but I forgot a few
times and had to track down bugs because of it.
: TEST1 10 0 DO I . 1 +LOOP ;
: TEST2 -10 0 DO I . -1 +LOOP ;
TEST1
0 1 2 3 4 5 6 7 8 9
TEST2
0 -1 -2 -3 -4 -5 -6 -7 -9 -9 -10
If you can accept that it has to be this way, then you'll accept any
other oddity you find in Forth.
People get blinded to such things. Write them down while you still
notice them.
Let's resurrect FIG!! Can we do that together?
I don't know. We're scattered so monthly physical meetings had better
not be important. There's been a reasonably active Forth Chat which I
hear is not nearly as abrasive as comp.lang.forth. Maybe write up stuff
and publish it on a wiki?
Can we crank out a
"generic Forth" that we can all live with to be the new FIG flagship?
Maybe the new "generic Forth" can include something from each of the
current Forth hackers' Forth ;) You guys set up a core team and
designate who can commit code to the project, a la the FreeBSD
project. What do you say? You guys have the brain-power to do it --
and you need now is the WILL!
Gforth was intended to be something like that, and it looks like a
technical success to me.
Just in case it helps, I'll tell you my story. I started out with Forth
because I was playing with a toy computer that only had Basic. I could
buy Forth on a ROM that replaced the Basic ROM and it was in theory far
more powerful. I taught myself how to use it. Forth in 8K ROM *did* do
far more than the Basic 8K ROM. And it was simple. After awhile I
learned that Forth well enough to decompile all the Forth commands. I
found a chart of the Z80 command set and I wrote a disassembler, and I
got the assembly language commands for the Forth primitives. I felt like
I really understood how it worked, far better than any other computer
system I'd ever seen.
I wrote some simple programs. An assistant for the DM of an AD&D game. A
hybrid genetic algorithm for the traveling salesman problem. It solved
the parts of the problem it was good at, and it displayed a map and let
the user solve the parts that human eyeballs helped with. A local
dispatch game, you'd send trucks around a map picking up stuff and
bringing it back to the warehouse, and you wanted to minimise the
distance traveled but new calls came in at random. Etc.
I got a new computer. I wrote a disassembler for the M68000. The new
Forth system was more complicated and I thought not as well done, but I
could use it. I never got around to decompiling it all. I lost interest
in adding assembler routines because it always seemed to be fast enough.
And I didn't have as much time.
I started using PCs and used F83. The standard did a lot of things
better but people complained. I wrote population genetics simulations,
plasmids spreading in evolving bacterial populations. I could write a
Forth program for my M68000 computer and then it ran unchanged on F83.
Impressive. I tried out lots of new ideas from Forth Dimensions but
somehow didn't use many of them. I particularly remember the generic
stack operator. You could make names like abcde|aabbeb and it would
figure out a way to get that stack effect and compile a command to do
it. It looked like a good idea but I never ever used it. And there were
lots of people coming up with improved CASE statements. Lots and lots. I
looked at the ideas and thought about which ones were better, but I
never ever used any CASE .
Then I got my own PC and I tried out Pygmy Forth. Pygmy had a
metacompiler that was very easy to use. So if you didn't like something
about the way it was designed, you could redesign it from source code
and if you didn't make any mistakes and you didn't change something that
would keep it from being metacompiled, you could make a Forth that did
it your way. Not just add your own commands on top, you could change the
fundamentals of how it worked. Suddenly all the things I didn't like
about whichever Forth I used, were open for change! I changed things for
my convenience. So for example, I didn't like the inconvenience of
changing BASE . Particularly when compiling, sometimes I'd want to
change to base 16 or base 2. But I had to switch back or later code
might be all wrong. Usually I'd do BASE @ >R and when I was finished I'd
to R> BASE ! to restore the old value. This was tedious. Sometimes I
wanted to use the return stack for something else and my base would get
in the way. Sometimes I wanted to keep the new base for more than one
input-buffer length and the system would treat my base as a return
address. It seemed -- kludgey. But now I had the power! I made a
separate stack to hold base values. I made a separate stack to hold DO
LOOP values, so it didn't interfere with the return stack. I changed
Pygmy around to suit myself. Occasionally I'd send my changes to Frank
Sergeant who wrote Pygmy, in case he was interested in any of them. I
wrote a simple routine that compared his source code and mine, so that
similar code always had the same block numbers. That way he could look
at his version and then switch to mine with a keystroke to see what was
different. He used a few of my changes including a few of my changes to
the metacompiler. But he basicly didn't like what I was doing to his
Forth. I was heading somewhere he didn't want to go. I made lots of
changes that made programming easier for me, but nobody else could run
my code unless they wanted to run my Forth. And nobody wanted to run my
Forth, they had their own Forths. The more changes I made, the more it
turned into my own private programming language that nobody else had any
interest in. And after awhile Pygmy was running in a DOS box on a
Windows computer. There was no hope to build marketable applications
with it. Designing my perfect Forth was a waste.
I looked at how to write maximally portable programs. It turns out that
the maximally portable parts are the glue that holds together the
special stuff. Different hardware requires different code. Different
Forths require different code in subtle ways. It was a mess. Very simple
code could be maximally portable pretty easily. Do anything the least
bit complicated and you had to know a whole lot to tell whether it would
port. Easier to build a lot of tests and test them on the new system and
hope that it would be OK if it passed the tests. Often it's harder to
port a complex application than it is to port the Forth the application
runs on. Why use another Forth? Just because it's available on the
target system? Port your Forth and your application doesn't have to deal
with subtle incompatibilities.
Now I leave comp.lang.forth for awhile, and then I come back and see
extremely interesting conversations going on. I participate, and after
awhile it looks like a lot of people don't like what I'm saying, and
that isn't what I want so I leave again. You can't expect to get much
more than argument from a Usenet newsgroup. That's what the format
encourages, and it doesn't encourage much else. You might do better with
something like a wiki. Explain what you want to accomplish. People who
agree with your goals can look at how to achieve them. People who
disagree can make their own wikis. Make it all fit into a design
specification, and build software to manage multiple paths toward
implementing what gets specified. I have some ideas about a format that
might encourage people to work together, different from Usenet. But when
I tried to present them on comp.lang.forth I got told that the experts
already know how to manage software projects, and I should shut up about
it. What you'd expect from a Usenet newsgroup.
.
- Follow-Ups:
- Re: The Promise of Forth
- From: Aleksej Saushev
- Re: The Promise of Forth
- References:
- The Promise of Forth
- From: Jonah Thomas
- Re: The Promise of Forth
- From: William James
- Re: The Promise of Forth
- From: Duke Normandin
- The Promise of Forth
- Prev by Date: Re: The future of computing (is Forth left behind?)
- Next by Date: Re: The Promise of Forth
- Previous by thread: Re: The Promise of Forth
- Next by thread: Re: The Promise of Forth
- Index(es):
Relevant Pages
|
