mccarrol@topaz.rutgers.edu (Mark C. Carroll <MC>) (01/03/90)
This message is going to flash through quite a few topics, so hold on
tight!
Basically, I'm going to put in my two cents about why Forth is less
successful than it should be, and where I think it should go.
First of all, I'd like to add in my comments on what I see as one of
the biggest strikes against Forth at the moment: the snobbishness of
the proponents of Forth! The "defenders of the faith" for Forth are
among the most self-righteous snobs that I've ever seen! Just look
at the latest material here on comp.lang.forth... Someone said
something along the lines of "Everyone creative already uses forth".
Or the message that said, basically, "All those dummies can hack away
in whatever they want - but WE WILL OVERCOME! WE ARE THE FUTURE!".
Anyone who isn't already familiar with Forth is chased away by it!
If it weren't for the fact that I was fascinated by Forth before I
came here, I certainly wouldn't have wanted to have any part of it!
The second strike against forth is a total lack of standardization.
Here at work, I program a Pyramid, which runs both ATT SysV.3, and
BSD 4.2. At home, I program an Amiga. If I use C with only standard
library functions, the programs I write can work very happily on
either one. I have that standard library, and so long as I stick with
the functions in it, I can use the same programs (almost) in both
universes on the Pyramid, and on my Amiga at home. Now, I pick up a
Forth package... I've got two of them for the Pyramid now: Tile, and
CForth. At home, I've got two for the Amiga: A4th, and Multi-Forth. A
program written in any one of the four is almost impossible to run on
the others! Even something as simple as recursion is handled in
different ways in each of the four! Between them, I have 3 different
ways of declaring and accessing simple data structures, none of which
are compatible. (Cforth doesn't have ANY structure handling!) I have
4 different ways of accessing files! It's totally insane! Forth will
never be taken seriously by the mainstream until you can provide a
STANDARD ENVIRONMENT!!!
So, my suggestions for the Future:
1> Try and cut the snobbishness. Forth programmers don't have
a corner on creativity. Being good at Forth doesn't make you
a god, so don't act like it!
2> Let's try to develop some sort of STANDARD ENVIRONMENT! This
should include, at minimum:
a> Recursion
b> File I/O
c> Strings
d> Structures
And we should at least consider the following:
a> Local Variables -- Nice, but kind of against the spirit
of Forth.
b> Multi-tasking -- Also nice, but might be hard to come up
with a portable way of implementing it.
3> Scrap screens! I find that whole screen model to be one of the
most obnoxious, inconvenient, intolerable "features" of Forth!
<MC>
--
\ Mark Craig Carroll: <MC> \ "Don't ever think that you can't
\ Student Systems Programmer - LCSR \ change the past and the future"
\ Rutgers University \ -Kate Bush
\ mccarrol@topaz.rutgers.edu \ (standard disclaimer applies)wmb@SUN.COM (01/03/90)
> 2> Let's try to develop some sort of STANDARD ENVIRONMENT! This > should include, at minimum: > a> Recursion > b> File I/O > c> Strings > d> Structures > And we should at least consider the following: > a> Local Variables -- Nice, but kind of against the spirit > of Forth. > b> Multi-tasking -- Also nice, but might be hard to come up > with a portable way of implementing it. Many people agree with this desire, including many people on the ANSI committee. Some of these things are already part of the draft ANSI standard. In particular, file I/O, strings, and local variables. I think recursion is in there (I don't have my copy handy, so I can't say for sure). The following structure definition will work on just about any Forth system. It is so simple and flexible that I rarely feel the need for standardizing anything fancier. Most of the "built-in" structure mechanisms that I have seen in various systems strike me as being "overkill", and everybody seems to overkill in a different direction. : struct ( -- offset ) 0 ; : field ( offset size -- offset' ) ( Input stream: name ) create over , + does> @ + ; : byte ( offset -- offset' ) 1 field ; : short ( offset -- offset' ) 2 field ; : long ( offset -- offset' ) 4 field ; Usage example: struct ( dma-registers ) long >address short >count byte >control constant dma-reg-size hex f100 constant dma \ Base address of DMA chip \ Or you could allocate a structure instance with: \ create dma dma-reg-size allot : set-dma ( address length -- ) dma >count w! dma >address l! DMA-GO dma >control c! ; > 3> Scrap screens! I find that whole screen model to be one of the > most obnoxious, inconvenient, intolerable "features" of Forth! Many people, again including many ANSI team members, also agree with this. However, there are also a number of people who are just as vehement in favor of screens. At the latest ANSI meeting, a battle about this almost escalated into armed warfare. The current compromise position (which I believe is not likely to change) is that a standard system: a) Need not have any disk I/O at all (e.g. embedded systems) b) May have BLOCK (screen) input c) May have file input, and if it has files, the vendor must support BLOCK too. BLOCK support does not necessarily have to be always loaded. The vendors in the file camp accept this compromise, because they can provide a loadable implementation of BLOCK that a user can load if he wants. All it costs is a little space on the distribution disk. They pretty much all do it already, anyway. Further discussion of BLOCKs vs files is probably not productive; everybody already knows all the arguments on both sides. Mitch
mccarrol@topaz.rutgers.edu (Mark C. Carroll <MC>) (01/05/90)
In article <9001040122.AA11294@jade.berkeley.edu> wmb@SUN.COM writes:
] ] 2] Let's try to develop some sort of STANDARD ENVIRONMENT! This
] ] should include, at minimum:
] ] a] Recursion
] ] b] File I/O
] ] c] Strings
] ] d] Structures
] ] And we should at least consider the following:
] ] a] Local Variables -- Nice, but kind of against the spirit
] ] of Forth.
] ] b] Multi-tasking -- Also nice, but might be hard to come up
] ] with a portable way of implementing it.
]
] Many people agree with this desire, including many people on the ANSI
] committee.
]
That's great, but I'm also strongly opposed to ANSI. I'm a college
student, so I tend to see things from the perspective of a person
who's short on money. Aside from the fact that ANSI standards seems to
be able to turn ANYTHING into a monolith, the standards themselves are
totally innaccessible to anyone who doesn't have a LOT of money to
blow.
If I want to be involved in the standardization process in any way,
how much does it cost me? More than I can possibly afford; that's
about all I'm sure of. What'll a copy of the standard cost me? $60!
That's insane! That's what I payed for a full commercial forth
system.. That's ridiculous. And I haven't even begun to consider
things like when will the standard be ready? It shouldn't take years,
as ANSI will.
What I really want to see is something happening on this newsgroup, or
on a semi-private mailing list, that will develop a small, concise,
FREE description of a standard Forth for Unix.
If people are interested, I am willing to set up a mailing list here
at Rutgers for discussions about a Usenet standard Forth.
Let me throw out some initial suggestions, so that you have even more
of a clue about what I personally want:
1> C-based. Access to assembly is nice; in a Unix environment,
portability becomes more important. I'd rather devote some
energy to finding ways to link external functions, than
to include assemblers.
2> Access to some Unix standard libraries. I really think we
need a standard file i/o.. If we're working in Unix, the
natural way is to do up a stdio subset in Forth.
3> Steam files. Like I said before, I hate screens.
4> Standard recursion. I'm not willing to live without it.
That's just my personal preferences. If this becomes a project, it's
all open to negotiation.
So, anyone who's interested in Usenet standard Unix Forth, send mail
to:
mccarrol@topaz.rutgers.edu
...!rutgers.!topaz.rutgers.edu!mccarrol
carroll@zodiac.bitnet
<MC>
--
\ Mark Craig Carroll: <MC> \ "Humanity isn't a physical description,
\ Student Systems Programmer - LCSR \ it's a spiritual goal. It's not
\ Rutgers University \ something we're given, it's something
\ mccarrol@topaz.rutgers.edu \ we earn" -- Richard Bach, _One_dunn@uhccux.uhcc.hawaii.edu (John Dunn) (01/06/90)
Mark Carroll's suggestions for improving Forth, in part by improving the attitude of Forth programmers hit upon three items I would like to address: > So, my suggestions for the Future: > 1> Try and cut the snobbishness. Forth programmers don't have > a corner on creativity. Being good at Forth doesn't make you > a god, so don't act like it! > 2> Let's try to develop some sort of STANDARD ENVIRONMENT! This > 3> Scrap screens! I find that whole screen model to be one of the > most obnoxious, inconvenient, intolerable "features" of Forth! First, if my earlier posting regarding Forth and creativity made me come off as a snobb, I apologize for a bad job of communicating my point. Here is a second try: Forth is the only generally available language I know of that is ideally suited to exploratory programming ("creative" was the word I had used earler) for the real world. There are a few other languages that have the same or even superior interactiveness. Lisp comes to mind as perhaps the best of these. But none that I know of other than Forth allow you to blow the overhead away and deliver a compact, clean application to the end user. Frankly, if Lisp had that ability, I'd prefer it. But as things stand Forth does indeed seem to have a corner on creativity. This is not to belittle compiled languages, however, I stand by my original premis: if you want to write an original application, if you want to try your hand at the software equivalent of writing a novel, Forth encourages - even compels - a creative mindset. And if you do have that creative itch that makes you prefer the insecurity of a novelist's life to the stability of a journalist's, it dosen't make you a god. But it definitely does put you in the minority. Regarding a standard environment: Why is this desirable for Forth? Portability, yes. And even here I wonder if the tradeoffs are worth the price. Maybe we should look at Forth as a language that specifically encourages non-standard non-portable code. Language strongly affects thinking, even bounds it. Perhaps a maverick language that specifically attempts to *unbound* thinking is a good thing to have around. When we need portability and standardization, we have an excellent choice of compiled, authoritarian languages to pick from. The right tool for the right job. Lastly, some comments on the Forth block editor. While the 64 character line limit does tend to discourage comments - not a good thing in any language - the block editor has one critical thing going for it. It allows you to incrementally compile your code right from the editor. An integrated ascii text editor could do that. Most Lisp editors, for example, are smart editors that allow you to compile individual functions. I would applaud such a Forth editor, in fact I'm writing one in my spare time for the LMI UR/Forth that I use. Naturally, I'm using a block editor to write it with. :-) -John Dunn
gaynor@busboys.rutgers.edu (Silver) (01/07/90)
dunn@uhccux.uhcc.hawaii.edu (John Dunn) writes: | Forth is the only generally available language I know of that is | ideally suited to exploratory programming ("creative" was the word I | had used earler) for the real world. | But as things stand Forth does indeed seem to have a corner on | creativity. | Regarding a standard environment: Why is this desirable for Forth? | Language strongly affects thinking, even bounds it. Ridiculous. [Ag]
dunn@uhccux.uhcc.hawaii.edu (John Dunn) (01/08/90)
gaynor@busboys.rutgers.edu (Silver) writes: > >| Language strongly affects thinking, even bounds it. > >Ridiculous. [Ag] Language strongly affects thinking, even bounds it.
toma@tekgvs.LABS.TEK.COM (Tom Almy) (01/08/90)
In article <6047@uhccux.uhcc.hawaii.edu> dunn@uhccux.UUCP (John Dunn) writes: >Lastly, some comments on the Forth block editor. While the 64 >character line limit does tend to discourage comments - not a good >thing in any language - the block editor has one critical thing going >for it. It allows you to incrementally compile your code right from >the editor. An integrated ascii text editor could do that. Most >Lisp editors, for example, are smart editors that allow you to >compile individual functions. I would applaud such a Forth editor, >in fact I'm writing one in my spare time for the LMI UR/Forth that I >use. Naturally, I'm using a block editor to write it with. :-) I don't think a block editor has anything to do with this. I wrote a Forth system about 1982 that allowed this. When an error occured, you would be placed in the editor automatically. After making any changes, you had the option of continuing compilation from that point. I could have done the same thing with text files. BTW, I prefere blocks for source code because it provides the necessary dicipline to keep definitions short. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
dunn@uhccux.uhcc.hawaii.edu (John Dunn) (01/09/90)
In article <6622@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >In article <6047@uhccux.uhcc.hawaii.edu> dunn@uhccux.UUCP (John Dunn) writes: >>Lisp editors, for example, are smart editors that allow you to >>compile individual functions. I would applaud such a Forth editor, > >I don't think a block editor has anything to do with this. I wrote a >Forth system about 1982 that allowed this. > >BTW, I prefere blocks for >source code because it provides the necessary dicipline to keep definitions >short. > Keeping definitions short is a crucial dicipline in Forth, no argument there. But using block screens for that reason seems a little extreme (of course that was the original point, so I guess you got me there too). The Brief-type editors that pop you back to where the error was is a step in the right direction, but they really aren't the same as the EMACS-type smart editors found in Lisp that are closely wedded to the entire process. The one you describe sounds close - I wish you had persued it. Gotta admit though, if ascii text editors were unavailable for Forth I wouldn't miss them much, but if it were the other way around, I'd be quite upset. -John Dunn
esulzner@cadev4.intel.com (Eric Sulzner ~) (01/09/90)
In article <6047@uhccux.uhcc.hawaii.edu> dunn@uhccux.UUCP (John Dunn) writes: >Lastly, some comments on the Forth block editor. While the 64 >character line limit does tend to discourage comments - not a good >thing in any language - the block editor has one critical thing going >for it. It allows you to incrementally compile your code right from >the editor. An integrated ascii text editor could do that. Most >Lisp editors, for example, are smart editors that allow you to >compile individual functions. I would applaud such a Forth editor, >in fact I'm writing one in my spare time for the LMI UR/Forth that I >use. Naturally, I'm using a block editor to write it with. :-) Anyone else played with TILES forth.el under emacs yet? You can get a 2/3 screen editing window and a 1/3 screen forth window. Edit away, and send paragraphs, regions or the whole buffer to the forth window. It executes whatever it's sent (the forth window is not interactive if you're in it). TILES is a 32-bit Cforth posted to a couple of newsgroups lately (don't remember which, was this one?). I'm running it under Ultrix. It uses sequential files. I'm not wholly pleased yet (F-PC spoiled me), but the author(s?) say there's more to come. TILES outside of emacs is interactive. -- Eric Sulzner esulzner@cadev4.UUCP esulzner@cadev4.intel.com 54177
trolfs@vax1.tcd.ie (Thomas Rolfs) (01/10/90)
In article <6047@uhccux.uhcc.hawaii.edu>, dunn@uhccux.uhcc.hawaii.edu (John Dunn) writes: > > Regarding a standard environment: Why is this desirable for Forth? > Portability, yes. And even here I wonder if the tradeoffs are worth > the price. A good extensive standard wouldn't be much use to an experienced Forth programmer. However, it would be very useful for people who want to break into Forth for the first time. A standard, which supported features that are taken for granted in other languages, would make Forth much more attractive to others. -- Thomas Rolfs mail: 33 Beechwood Lawn, Dun Laoghaire, Eire. // E-mail:TROLFS[Thomas Rolfs On-Line Forth Server - "OLIS"]@vax1.tcd.ie \\//+IV -----------------------------------------------------------------------\X---- "Elvis is my copilot." -- Cal Keegan