bouma@cs.purdue.EDU (William J. Bouma) (07/22/89)
I really love the structure of forth. It is elegant in its
simplicity as anyone who has used, (or especially written), it
knows. But I feel that the standard is lacking in many ways
and wonder if any of you agree with me?
People have questioned here why forth has failed to catch on as
a general purpose language. I think it is beacuse the standard
is at such a low level. People are used to using files these days.
Why does the standard still deal with primitive junk like BLOCKS
and BUFFERS? Sure, given the primitives, someone who knows forth
quite well can hack together a usable abstract file system. But
people want that stuff to be available when they start using the
language. I also think they would like to have their i/o be
compatible with that in someone else's system rather than everyone
having different words to do the same function.
People want a language that is flexible and self documenting. For
the most part, forth is that way. But there are stupid and needless
exceptions. For example, DO seems quite inflexible in requiring you
to use I and J as the loop variables. And if you want to nest 3 deep
you have to define a new word which indexes directly into a system
stack. Why not just say DO I ... where I could be any variable name?
People want to have a rich set of data types available without
having to load seperate packages that are incompatible with every
else'. Suggestions have been made in this group to have a seperate
floating point stack. Why bother? Just have one stack with data
types tagged. Sure it will be a bit slower, but think about what
is gained. Besides, forth doesn't burn unless its on a special
chip anyway. Words could also be provided that don't do type
checking for an increase in speed.
Well, I was just dissapointed to look at the forth 83 standard and
see that basically nothing had improved from the forth 79 that I
knew. Only a few of the words have changed. Forth as it still stands
seems mainly good for interfacing to hardware or for cramming much
functionality into a limited memory space. Most of the people who
talk about using forth seem to be dealing with computers at the
hardware level.
--
Bill <bouma@cs.purdue.edu> || ...!purdue!bouma wmb@SUN.COM (Mitch Bradley) (07/22/89)
The current draft of the ANSI standard contains an extension wordset for file access. The wordset they chose has a few problems, but it's workable, and a whole lot better than the "nothing" we have now. Mitch
sabbagh@acf3.NYU.EDU (sabbagh) (07/24/89)
In article <7224@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: > > People want a language that is flexible and self documenting. For > the most part, forth is that way. But there are stupid and needless > exceptions. For example, DO seems quite inflexible in requiring you > to use I and J as the loop variables. And if you want to nest 3 deep > you have to define a new word which indexes directly into a system > stack. Why not just say DO I ... where I could be any variable name? Actually, I agree that, in many ways, FORTH standards fail to address high level issues (32+ bit implementations, OS co-existence), but I have to argue about the inflexibility of DO. Many of the newer ALGOL-based languages, most notably Ada, have struggled with the issue of loop indexing. In general, it is considered very bad to have an index that can be read outside the loop. In languages like C, the programmer usually declares a local variable named i,j, etc., used only for loop indexing. I like the fact that FORTH has basically eliminated this trouble spot. Snap! (The sound of the last button on my asbestos suit...) Hadil G. Sabbagh E-mail: sabbagh@csd27.nyu.edu Voice: (212) 998-3285 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 186,282 miles per second -- it's not just a good idea, it's the law!