HDTenEightyP/NetNews huggingface dataset:
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PHILOSOPHY & CM
Date: 24 Jan 93 13:45:18 GMT
Organization: EIEI-U

Category 1,  Topic 12
Message 11        Sat Jan 23, 1993
L.ZETTEL [Len]               at 19:39 EST
 
 OK, with some trepidation, here we go.  I am all too vividly 
 aware of the complaint of Immanuel Kant: "I can defend myself 
 against my enemies; who will protect me from my friends?"  I 
 decided to start out by posting some excerpts from Chuck's 
 writings - mostly from the GEnie FIG library, with one quote from 
 the SIGFORTH newsletter.

 These, by the way, along with back issues of Forth Dimensions, 
 are the best source I know on Charles Moore, who would much 
 rather be doing it than writing about it.  Since he has never had 
 to publish to avoid perishing, there isn't a whole lot available, 
 unfortunately.

 To work on understanding his philosophy, my personal 
 recommendation would be:
 1) Read Starting Forth CAREFULLY (I know Brodie wrote it, but 
 Chuck was in touch).
 2) Read Thinking Forth.
 3) Read the GEnie files and whatever else you can get ahold of.

 Chuck is on my short list of people who, if it looks to me like 
 they are talking nonsense, I figure the most likely reason is 
 that I don't understand what they are really saying.  Sure 
 enough, if I think about it long enough, or manage to get a 
 question or two answered, it makes sense.
                        -LenZ- 
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: ahenden@magnus.acs.ohio-state.edu (Arne A Henden)
Subject: Forth books for sale
Organization: The Ohio State University
Date: Thu, 28 Jan 1993 22:38:19 GMT

There are still a few Forth books left from my collection that have
not sold.  In addition, there are a handful of Uniforth Professional
Systems that are left -- if you want one at the $40 special, order
now!

Book                                  Price (postpaid)
Seagraves/The HAO MultiUser Forth            $5
  System Listing
James/PDP-11 Forth User's Guide               5
Haydon/All About Forth                        6
FOST/Forth-79 Standards Document              5
IAFR/Bibliography of Forth Refs, 1st ed.      6

plus I have several dozen general computer books for sale -- email
for a list.  NOTE:  postpaid prices are continental U.S. only; other
areas are higher.

Arne Henden
Unified Software Systems
1288 Nantucket Ave.
Columbus, OH 43235
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Detroit/Ann Arbor/SE Mich FIG doings
Date: 21 Jan 93 11:33:42 GMT
Organization: EIEI-U

Category 8,  Topic 6
Message 9         Wed Jan 20, 1993
L.ZETTEL [Len]               at 21:21 EST
 
The Detroit FIG Chapter will meet 7:00 PM January 28 (the Forth Thursday) at
Room 238 (The Hammerle  Conference Room) Dodge Hall, Oakland University,
Rochester Michigan. Speaker: Daron Smith, Rockwell International. Topic: The
Datamax 2 Data Collection System. This system is used in trucks to monitor &
record speed, gear selection, engine rpm and idle time after  engine start to
achieve efficient operation.  A high-end version ties in to the Global
Positioning Satellite  System to allow vehicle location to be continuously
monitored and reported to a dispatcher.  Daron had a  major part in developing
the system, which is written in assembler (not Forth). For further
information, contact Bill Walters (313) 861-6465 (h) or (313) 731-9660 (w).
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting
Date: Thu, 28 Jan 1993 01:22:23 GMT
Organization: StarNine Technologies, Inc.

In article <1993Jan21.171538.29836@exu.ericsson.se> exuhag@exu.ericsson.se writes:
>Andrew Haley writes:
>>
>>I asked him about that a few weeks ago.
>
>Thanks for posting this, Andrew.  This is interesting stuff.
>
>>Chuck's environment has never stood still.  He's been refining it and
>>making it simpler and simpler for what he wants to do. 

This may be exactly why Chuck is not necessarily an authority on
what's necessary for "mainstream" Forth... his work always has a strong
flavor of "just what I want".  This is exactly the wrong point of view
if one is trying to develop platform software development environments.

>>
>>Chuck has always been willing to throw away
>>anything in Forth which isn't ideal for the job at hand; what we might
>>recognize as "classical Forth" is microFORTH, circa 1978.  He's been
>>changing things ever since. 

And I'm very sure that he always ends up with a system that is
excellent for what he is working on.  But I doubt if others
would be as successful with his syetm unless they were involved
in a similar project.

>
>I suspected as much.  He sounds like a true user of the language, not
>someone just interested in making a fancy, asthetically pleasing tool
>for it's own sake. 

As one myself, I doubt if the developers of super-forths do so
"just for it's own sake".  I'm quite certain that others have the same
goal as I... to try and raise Forth to a level of genuine general
useability... to show others how well Forth can serve in that role.

>Arguing over various improvements is a waste of
>time when you can simply implement them and get on with your work,
>especially since this is the whole point of Forth.  

I didn't know there WAS a single "point" for Forth.  No wonder
it is rejected by mainstream industry.

Arguing over improvments is normally an important step in
improving anything.  I suppose I'm to assume that Forth can't be improved,
maybe that's why the various standards met with so much resistance,
because they weren't needed?

If Forth is ever to become a viable mainstream language (and I
realize it probably never will), there is much arguing ahead.
Actually, I have no doubts there is much arguing ahead in any
case, and that's not a bad thing, except it seldom leads anywhere.

Newsgroups: comp.lang.forth
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: comp.lang.forth
Subject: Re: Forth's Adaptability
Date: 21 Jan 93 15:28:22 GMT
Reply-To: exuhag@exu.ericsson.se
Organization: Ericsson Network Systems, Richardson, TX
X-Disclaimer: This article was posted by a user at Ericsson.
              Any opinions expressed are strictly those of the
              user and not necessarily those of Ericsson.

Chuck Eaker writes:
>
>I happily stand corrected. Tell me about LMI's products. What
>platforms are supported? Will they conform to dpANS when adopted?
>And, yes, I'm a hot prospect who has to get jobs done and looking
>for more productive ways to do them.

Ditto.  Please feel free to hawk your products (I don't consider
this commercial use of the Internet, just good information.)  I'll
repeat my plea for comments from users of Harvard Softworks' HS/Forth
as well.

(I do find it suprising, however, that almost no Forth vendors
are attempting to cover the 'commercial software production'
market.  That is, people who write end-user software [word 
processors, computer games, utilities, etc.] and not simply 
industrial applications.  Perhaps there simply isn't such a
market. I for one would be happy to use a professional level
Forth system instead of Borland C++ or the like.)

--
James Hague   
exuhag@exu.ericsson.se
Newsgroups: comp.lang.forth
From: penev@venezia (Penio Penev)
Subject: Re: FOR...NEXT in Eforth
Organization: Rockefeller University
Date: Tue, 26 Jan 1993 06:40:29 GMT
X-Newsreader: TIN [version 1.1 PL6]
Reply-To: penev@venezia.rockefeller.edu
X-Posted-From: venezia.rockefeller.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

Julian V. Noble (jvn@fermi.clas.Virginia.EDU) wrote:
: Thanks to all the kind folks who sent their implementations of DOES>
: for Eforth.
: 
: Now I would like a show of hands: How many people agree with me that
: the word NEXT is too important, universal, ubiquitous, etc. to be
: taken over as the terminus of a FOR...NEXT loop? I would propose
: that NEXT be reserved for its traditional purpose, and that the end
: of a FOR...NEXT loop be called one of several possibilities:

It is so in indirect threaded FORTHs. When You have a native FORTH, it
is not used. The former kind of FORTHs usually have a VOCABULARY
ASSEMBLER and the NEXT should ne define as a macro in it. So its in
VOCABULARY FORTH should not be a problem. Well, the Enginsh language
has so few words...

I personally do not have a NEXT macro, since I use a native FORTH. I
use lower case for the assembler words to distinguish them from FORTH
words ( e.g. AND & and , OR & or ..). When I write CODE definitions, I
finish them with ret . May be I could use END ( a shorcut for
END-CODE) too. Yet another example of the saying: "The best tool for
the FORTH programmer is a good thesaurus."

-- Penio.
From: hamish@sybase.com (Just Another Deckchair on the Titanic)
Newsgroups: comp.lang.forth
Subject: Forth and Adaptation
Date: 21 Jan 93 18:17:20 GMT
Organization: Sybase Inc, Emeryville CA USA

In article <1j9rt7INNafb@charnel.ecst.csuchico.edu> fish@ecst.csuchico.edu (Kevin Haddock) writes:

>Adapting is what Forth is all about.  Forth is the most adaptable
>language that I know of.  The fact that there is an ARMY of C programmers
>working constantly on adapting a less flexible language to new arenas
>while there are relativly few Forth programmers that are not completely
>tied up with more fundamental 'real-world' applications does not make
>Forth any less adaptable.

So why *hasn't* Forth adapted? Why *don't* we see armies of Forth
programmers out here in the Real World (tm)? Why doesn't a company like
(e.g.) Sybase use Forth in applications that would seem to be ideal for
Forth? What makes something a "fundamental 'real-world' application"?
And why are so many of them being written in something like Smalltalk
(the Forth for the nineties...) rather than Forth?

There's more to adaptation than just having a nifty *language*. It's
not language adaptability that's all important - rather, it's the
adaptability of things (applications, modules, etc) built in that
language that's important, and the adaptability of the programming
tools and environment.

Even more important is the ability to let the vendors do as much of
your work as possible - why reinvent the wheel? If a system supplies a
set of networking and (say) windowing functions as a C library or C++
or Smalltalk class hierarchy, you should just plug into these for the
services (and generally can in any of the languages I work with).
 
Similarly, interoperability is a huge issue - if I can't work in all
three of the languages together on the same (large) application or
suite of applications, then I'm screwed.

Similarly, if I can't easily use the system-supplied tools on my source
code, then it's not even worth considering the language. The recent
screens vs. files argument was classic - if a Forth source can't be
made to look exactly like a normal text file to my tools (grep, SCCS,
RCS, Envy, etc. etc. ad nauseam), then it's lierally worthless.

*Those* are the sort of things that are important in this little
corner of the Real World (tm), where, frankly, even though I was once
a Forth evangelist, I wouldn't even consider it for serious work
now....

	Hamish (Long Time Lurker)
---------------------------------------------------------------------------
Hamish Reid       Sybase Inc, 6475 Christie Ave, Emeryville CA 94608 USA
+1 510 596-3917   hamish@netcom.com  hamish@sybase.com  uunet!sybase!hamish
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Help for F-PC and TCOM
Date: 27 Jan 93 11:27:56 GMT
Organization: EIEI-U

Category 7,  Topic 35
Message 32        Wed Jan 27, 1993
B.SUTTON1 [Brian]            at 00:12 EST
 
  >  -----via CRS Premium Bulletin Board -
  >  USR Dual Standard 16.8K  (416) 629-7000

  >  Date: 01-10-93 (12:15)
  >    To: ALL
  >  From: M SIMON
  >  Subj: PROGRAMMING PROBLEM FPC

  >  I tried the following program which I cribbed from the
  >  files included with FPC (PDP-8 stuff). It does not open a
  >  file which is known to reside in the same directory as
  >  FPC. No error message is returned. HOPEN indicates
  >  success opening the file. I am stumped.

It worked on my computer.  I suspect that you are using the
 .FILES word to see if it was opened; it wouldn't show up there
 with the code you use.  It actually is opened though, if you
 execute the following code you'll get the DOS handle:

    ofile >hndle c@ .

What you might try is substituting $HOPEN for HOPEN in your
 OPEN_OFILE definition which will put the handle in the current
 SEQHANDLE location (and subsequently show up when you .FILES);
 but there's really no need if you use OFILE to access it and
 don't need to reset the input buffer and close a previous
 file.


-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble)
Subject: Re: Recent FORTHs' guts (was: Documentation )
Organization: University of Virginia
Date: Thu, 28 Jan 1993 20:03:29 GMT

I am reminded of the chap who asked his girlfriend "Why do women take things
so personally?" to which she replied "Well, I'm sure ***I*** don't!"

I personally use HS/FORTH, despite some minor coolness between me and
Jim Callahan, its author/vendor/guru, because it is a) very good; b) very
complete; c) very clever. I can unhesitatingly recommend it to anyone who
needs a big Forth for Intel-based machines.

However, in putting together a disk that will be distributed free at the
Forthcoming ACM/SIGForth conference in Indianapolis, I naturally had to
employ public-domain Forths. So PD Forths have their place. 

Let me provide an analogy: when PCs came out they were supplied with a
BASIC interpreter, free, gratis and for nothing. So everyone who bought a
PC and didn't know how to program but felt inclined to learn learned in
GW-BASIC. If they should later become more serious programmers or developers,
then the could ***buy*** BASCOM for several hundred clams, or a C or maybe
a FORTRAN. But the number of people who would go out and invest several
hundred dollars on a new compiler in a new language was small.

Buying HS/FORTH for some $250 in 1984 was a moderately expensive decision.
I had already had a modest Forth encounter with the Jupiter Ace; but had I
been able to play around with a PD Forth for a while on my PC, the whole
thing (that is the decision to lay out serious bread) would have seemed
more of a natural evolution.

Anyway, my student primer disk has F-PC, Eforth and some tutorials for F-PC
donated by Jack Brown and C.H. Ting. I included Eforth because it is very
simple and contains a really well designed .ASM source that any moderately
serious CS student can understand at a glance. Although Eforth for the PC
is terribly inefficient, it would be very simple to produce a Fast Eforth, 
and this would doubtless serve as an excellent exercise for the student.

So I can't agree with Ray Duncan that Eforth and other PD Forths are 
abominations unto the gods or whatever. They are useful in themselves, and
provide the necessary entree into Forth for beginners that should be
followed by the purchase of serious tools when heavy programming tasks are
encountered. In my opinion, Forth vendors have been both narrow-minded and
short-sighted, compared --say-- to C vendors like Borland. At the last ACM
meeting, the latter's reps were giving away large complete boxes of C++ to
anyone who cared to tote them away. Gratis. I mean for free! The notion was
undoubtedly akin to "Bread cast upon the waters..." There must be something
to it: C++ is flourishing everywhere despite its manifest and obvious short-
comings that should be apparent to the meanest intelligence; whereas Forth
is, despite its beauties that we all appreciate so well, still struggling
20 years after its inception.

--jvn
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 21 Jan 93 09:35:28 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

James Hague (exuhag@exu.ericsson.se) wrote:
: I assume Mr. Moore has written quite a few articles outlining his thoughts
: and opinions of Forth and programming in general.  Perhaps some references
: are necessary, to prevent further such alterations of history.  (This is
: not meant to be snide; as Forth gets older, it's history becomes more and
: more muddled.)

I asked him about that a few weeks ago.  He has written some things,
but they aren't really in a publishable state.  (There was a piece in
the special Forth issue of Byte, but it wasn't very detailed.)  He's
much more inclined to spend time working on the uP21, his new
processor.

Chuck's environment has never stood still.  He's been refining it and
making it simpler and simpler for what he wants to do.  His current
system (which is called OK) doesn't use BLOCK at all because all of
the code and data he needs fits into memory, and he can just write all
of memory into a file.  This system is used to design a 100 MIP
microprocessor, which traditionally requires a good sized workstation
with a big disk; Chuck does all of his design without using the disk
at all!  It's only there to make backups.

Also, he's discovered that standard Forth isn't the best way to
control transistors; the uP21 has an instruction set which is
obviously inspired by Forth, but is much lower level.  This is
essential because of the way the uP21 decodes its instructions, using
very simple logic.  Chuck has always been willing to throw away
anything in Forth which isn't ideal for the job at hand; what we might
recognize as "classical Forth" is microFORTH, circa 1978.  He's been
changing things ever since.  Because of this attitude to his tools,
he's very disinclined to spend time writing about something he created
long ago; he's too busy creating new things.

However, Chuck did write a paper on the origin of Forth for the
upcoming History Of Programming Languages conference, but it was
rejected because it was "too informal."  I don't know if the paper
will be published elsewhere.

Andrew.
From: esj@harvee.billerica.ma.us (Eric S Johansson)
Newsgroups: comp.lang.forth
Organization: gators 'r us
Subject: types (forth and other)
Reply-To: esj@harvee.billerica.ma.us
X-Software: HERMES GUS 1.10 Rev. Dec 23 1992
Date: Sat, 23 Jan 1993 09:32:32 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

there have been a series of good articles on forth, types and how
they relate.  But, as usual, it got bogged down in a debates over a
faulty implementation of a type system.  So in the spirit of throwing
a little more fuel on the fire, here are another few concepts and ideas
for folks to chew on.

"type" describes properties and some think of type as specifying
the operations one can perform on a type.  I tend to think of
operations specifying type instead of the converse, but for now, the point 
is not terrible important.

pre and post conditions are associated with implementation of a type. 

For an example: an integer is a type.
		x is of type integer.
		limiting x to a range of [3..8] is a postcondition of x

frequently types and postconditions are merged in the implementations
of type systems.

checking postcondition, and the related preconditions, at compile time
are more difficult than checking type but it can be done if the
compiler has knowledge of types, preconditions and postconditions for
all operations. 		

lets play with an example.  the definition below is of type int
yielding int.  the definition takes an int with precondition of being 
in the range of 3 to 8 inclusive.  the definition yields an int with a
post condition of being in the range of 3 to 8 inclusive.

: pl1 ( int [3..8] --- int [3..8] )
	1 +
;

A type+pre/postcondition aware compiler (from now on called a tpp
compiler) would flag the above as violating the postcondition.  it could
do this only because it knows the type and properties of +.  if a
tpp compiler did not know the properties of +, it would have to insert
a runtime check to enforce the post condition.

Now, things get messy if we look at +.  it is real easy to specify
its type.  + is of type int by int yielding int.  however adding
the information needed by a tpp compiler to verify postconditions
of anything using + is a bit sticky but can be done.

I suggest that anyone interested in working with these concepts look
into formal methods in general and the work done by the Z folks
specificly.  there are some more applical areas of formal methods but the
Z stuff is more accessible and should work well in the forth domain.

overall, I think designing an extensible type system and building a
tpp compiler base on that type system would be very interesting and
*very* useful. 

--- eric
-- 
HOME: esj@harvee.billerica.ma.us  HAM  ka1eec
WORK: 617.630.4687 (w)   esj@ruby.polaroid.com
source of the public's fear of the unknown since 1956
Newsgroups: comp.lang.forth
From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble)
Subject: FOR...NEXT in Eforth
Organization: University of Virginia
Date: Mon, 25 Jan 1993 21:37:16 GMT

Thanks to all the kind folks who sent their implementations of DOES>
for Eforth.

Now I would like a show of hands: How many people agree with me that
the word NEXT is too important, universal, ubiquitous, etc. to be
taken over as the terminus of a FOR...NEXT loop? I would propose
that NEXT be reserved for its traditional purpose, and that the end
of a FOR...NEXT loop be called one of several possibilities:

	ROF	( my favorite)
	;FOR	( same # of letters as NEXT)
	>FOR	( how's this? )

I realize this is not of earthshaking proportions, but would still
appreciate comments, etc.