HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.forth
Subject: An Open ANSI Forth Implementation
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Date: 18 Aug 92 11:49:22 GMT
Organization: EIEI-U

Category 10,  Topic 41
Message 58        Tue Aug 18, 1992
E.RATHER [Elizabeth]         at 01:33 EDT
 
Bevan writes: How do I _evaluate_ different FORTHs without having to buy them
and
 try them out?

Well, you can look at what features they offer, talk to current users, buy
documentation (for maybe .1 the cost of the system), etc.

Someone else worried about becoming dependent on the features that
differentiate the various commercial Forths.  If they're the features you
need, I'd look at it as saving you the cost of re-inventing them. This is an
advantage, not a liability.  If you roll your own, you not only foot the bill
for doing so, you're stuck supporting it forever... or your employer is stuck
with a system whose only guru has gone down the road.  Whereas a supported
commercial system backed by a reputable vendor with a history will be there to
support you.

I see no reason to fear being "trapped" on a single platform.  Again, most
commercial vendors support multiple platforms...if that's important to you,
that should be one of your evaluation criteria. And, of course, it's also why
folks were willing to invest so heavily in ANS Forth.
-----
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
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for ROMability
Date: 12 Aug 92 11:50:33 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 72        Wed Aug 12, 1992
E.RATHER [Elizabeth]         at 00:35 EDT
 
Brad, you say: >Starting from the TC's premise "it is impractical to deal
properly with ROMability issues in the near term", someone has leaped to the
conclusion "we will never have to deal with ROMability issues."

That someone is you.  Given that embedded systems are one of the big markets
for Forth, I'm sure that will be an early priority in the next round.  That
may, indeed, have some impact on ENVIRONMENT?, but then there are also folks
on the TC that were persuaded by you at Rochester to have another look at that
one.

My point is, the fact that we've given up on solving the ROMability issue this
round is far from any conclusion on the TC's part that it will "never" be an
issue.
-----
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
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Environmental Queries
Date: 22 Aug 92 13:27:24 GMT
Organization: EIEI-U

Category 10,  Topic 33
Message 9         Fri Aug 21, 1992
B.RODRIGUEZ2 [Brad]          at 22:45 EDT
 
                 ANSI X3J14 FORTH TECHNICAL PROPOSAL
                     (X3J14 dpANS-3, March 1992)

TITLE:  Environmental queries should be known at compile time

SECTION:  6.1.1345 ENVIRONMENT?

SUMMARY:  The Standard currently does not specify when environ-
     mental data is known.  Such data should be known at compile
     time.

PROPOSAL:  Add the following text to section 6.1.1345:

          "If the attribute does not have a known value at the
          time the program is compiled, then ENVIRONMENT? shall
          return the 'unknown' result."

DISCUSSION:  A major weakness of the ENVIRONMENT? concept is that
     it is not known, and cannot portably be known, which envi-
     ronmental values can be queried successfully at compile
     time, and which only at execution time.

     Official statements from the X3J14 Technical Committee (Doc.
     No. X3J14/92-1PRC18R) have implied that both may occur:

          "in an embedded system environment, these tables would
          likely reside on the host."  [i.e., the compiling
          system]

          "It is expected that ENVIRONMENT? will most often be
          used during compilation of program preludes."

          "It is true that not all responses to ENVIRONMENT? are
          fixed at compile time."

     It has been noted previously (dpANS-2 PRC #18) that the
     memory and execution time requirements of ENVIRONMENT? are
     prohibitive at run time in many Forth applications.  The
     assumption that seems to underlie the proposed use of
     ENVIRONMENT? is that it can be queried at compile time.  But
     this is nowhere stated in the dpANS document.

     This proposal would rectify this oversight, by specifying
     that all environmental values are fixed at compile time.
     This is my current understanding of the TC's intent.  If
     this is not so, some explanatory text must be added to
     clarify when environmental data is valid.

-----
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
From: eaker@ukulele.crd.ge.com (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: Free Forth
Date: 12 Aug 92 21:58:54 GMT
Reply-To: eaker@ukulele.crd.ge.com
Organization: GE CR&D Computer Science Program

In article <5508@transfer.stratus.com>, nick@sw.stratus.com (Nicolas Tamburri) writes:
|> but can anyone really argue that the availability of the free figFORTH has
|> hurt Forth's popularity.  I for one would never have even tried Forth
|> had it not been for figFORTH.  I wonder how many others are in the
|> same boat.
|> 
|> More importantly, figFORTH was a springboard for supported Forths.  My second

These are interesting points. My introduction to Forth was also through the
early fig Forth. I was interested because I had a new-fangled micro at home
with a whopping 16K bytes of memory, and I hated (still do) BASIC. So I agree
that free or cheap opens the markets of hobbyists, students, and many schools,
but it's irrelevant to businesses. There are many businesses who use
commercial Forths to get things done that earn them money. Perhaps there would
be more if there weren't so many professionals who have negative attitudes
about Forth because of all the early free ones. Or maybe you're right, and
Forth is now more successful commercially than it would have been had there
been no free Forth's. If I had a lot of money and time, I'd survey those
using Forth and ask how they came to use it. I'd survey those who aren't
and ask them why not.

-- 
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Maryland FIG News
Date: 15 Aug 92 13:47:38 GMT
Organization: EIEI-U

Category 8,  Topic 8
Message 1         Fri Aug 14, 1992
ELLIOTT.C                    at 08:18 EDT
 
 -----via CRS Premium Bulletin Board

 Date: 08-12-92 (17:31)
   To: ALL
 From: MIKE NEMETH

 Maryland Forth Interest Group

 Next will meet Wednesday August 19, 1992 at 6:30 pm in Building
 1 Parsons Auditorium , John Hopkins U. Applied Physics Lab.,
 Laurel, MD. Topic: Graphics in FPC, by Mark Smiley .

 For more info contact: Mike Nemeth at 301-262-8140(h) or
 301-794-1678(w)


 RBBS-UTI v2.0 : The Palace -- 30+ confs, doors, games

 PCRelay:PALACE -> #266 RelayNet (tm)
 4.11              The Palace BBS  (703)866-4452  USR Dual Stnd


-----
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
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Newsgroups: comp.lang.forth
Subject: Re: Free Forth
Date: 22 Aug 92 03:54:16 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

mikeh@starnine.com (Mike Haas) writes:

> I would propose that "platform-oriented" Forths (which I take to mean a Forth
> that is designed to mate particularly well with a particular operating
> system) should not care at all about their size.

I think that's going a bit too far.  Having no regard for size usually leads to
sloppiness, and all the problems that go with it: slow, buggy, difficult to
read, maintain or understand...

I agree that 4K kernels are going too far in the other direction; minimal size
shouldn't be a major priority, though I think it should be a concern.  A
word--or program--that is no larger than it needs to be is elegant, and it
carries with it many benefits: robustness, ease of understanding and
applying...

As with other tools, such as a woodworking plane, a fine tool encourages the
user to do fine work, and allows him to do fine work.  A clumsy tool leads to
clumsy work, and that is all it is capable of.

> As long as larger size resultss from increased functionality (a more powerful
> Forth) I'll gladly make that trade.

Yes, if the development system is considered a workshop, adding fine tools is a
worthwhile trade-off for size.  Power tools, such as a power planer, can also
be worth the extra size, handling the "grunt work" of software development.
However, simply offering lots of tools of low quality is not a worthy
trade-off.  I've encountered cheap tools before, and I don't want them.

To sum up, there should be a balance between trying to provide the most
functions and trying to make each word as small as possible.  Spending too much
effort on either aspect will result in an inferior product.


Besides, wouldn't you like to watch a C programmer load his development system,
taking hours, with lots of disk swapping, referring to manuals, etc, and then
load your powerful Forth development system in a minute or two, with no fuss,
muss or disk swapping?  :)

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.lang.forth
Subject: Does anyone read these things!!
From: mentink@wronz.org.nz
Date: 14 Aug 92 14:57:32 +1200


        Can anyone HELP please.

        I have a version of eforth which I have ported to an H8
        micro controller. It runs very well but I need some extra words
        that eforth (standard 1.0 version) hasn't. These are as follows:

        1. DO .. LOOP +LOOP WORDS.
        2. CREATE DOES> construct
        3. or <BUILDS DOES> construct
        4. CASE .. ENDCASE, OF .. ENDOF
        5. FORGET, VOCABULARY

        Has anyone some source (forth) to the above words so I can 
        implement them, especially the DOES> word.

        Thanks in advance.

        P.S Still looking for any documentation on existing eforth words
        if anyone has any.

        Regards.

        B.R.Mentink
        W.R.O.N.Z
        Christchurch
        New Zealand. 

        email: mentink@wronz.org.nz
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for ROMability
Date: 22 Aug 92 13:27:05 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 77        Fri Aug 21, 1992
B.RODRIGUEZ2 [Brad]          at 22:48 EDT
 
                 ANSI X3J14 FORTH TECHNICAL PROPOSAL
                     (X3J14 dpANS-3, March 1992)

TITLE:  Add clarifying text re. cross-compilers

SECTION:  4.1 ANS Forth Programming System

SUMMARY:  This text clarifies the status of cross-compilers under
     the dpANS.

PROPOSAL:  Add the following text to section 4.1:

          "An ANS Forth System must be capable of executing,
          interpretively, all of the words from the Core word set
          and any words included from the optional or extension
          word sets, except those words designated in the
          glossary with the 'C' attribute (see section 5.1).

          An ANS Forth System must be capable of executing,
          interpretively, any newly defined words which are
          created in accordance with the rules for an ANS Forth
          Program (see section 4.2).

          No cross-compiler can be labeled an ANS Forth System
          unless it is capable of executing, during the
          compilation process, words defined for the target
          system which conform to the rules for an ANS Forth
          Program."

RELATED PROPOSALS:  "Can there be ANS Forth cross-compilers?"

DISCUSSION:  Recent discussions with members of the Technical
     Committee have made it evident that the status of cross-
     compilers is unclear under the dpANS.  This proposal adds
     language to the document that explicitly states the require-
     ments for cross-compilers in relation to ANS Forth.

     This proposal represents the best synthesis of the informal
     opinions I have received.  If this interpretation is incor-
     rect (see related request for clarification), please substi-
     tute language that represents the true state of affairs.
     However, some explanatory text must be added on the subject
     of cross-compilers.

-----
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: Free Forth
Date: Tue, 18 Aug 1992 02:18:19 GMT
Organization: StarNine Technologies, Inc.

In article <5508@transfer.stratus.com> nick@sw.stratus.com (Nicolas Tamburri) writes:
>
> The time
>that has been spent reinventing all these various versions which have
>little differences in functionality and large differences in compatability
>could have been much better spent writing utilities and applications
>for existing platforms which make developing Forth programs easier, and
>taking away some of Forth's austerity.  IMO this turns people off to
>Forth a lot more than its RPN notation.

This point hits home for me.  There has been little, IF ANY, effort
put into making Forth a general purpose language.  It is a niche
language of a high order.  Imbedded controller applications.
That's the sum total of Forth's "big" market.  Even that is not as
large as it would be had Forth "molded" itself better with the
general task of computing.  Many companies, even when facing
imbedded controller products, turn to  languages that they are
familiar with in terms of technology, development costs, hiring
capabilities etc.

Any modern computing platform provides some set of capabilities
in the form of rom routines, libraries, etc.  Even from forth-to-forth
on the same platform, there is no standard way to access such
entities.  There has not even been a standard layer upon which
to map such services as file access and memory utilization, things
that are as common as 8-bit bytes.  Thankfully, ANSI finally
addresses some of these FUNDAMENTAL operating-system-provided
capabilities.

Even assembly language programs provide the ability to create and
utilize object files.  The man-years of solid, debugged work can be
integrated into a product from the link command line.  It is not necessary
to re-code everything, to have to provide source code for your
proprietary algorithms you may liscence to others.

Don't get me wrong, if the ascii character set included a "heart"
symbol, I'd gladly include it here between the words "I" and
"Forth".  But the concept of Forth becoming more popular to the
mainstream is fantasy.  It just won't do what general folk want a
language to do.  We have been bitten and smitten.  For personal
use, I wouldn't trade it for the world.

If someone were to start a large, funded effort to produce a hot
general-purpose product (game, word processor, etc.), and they
chose YOU to head up the engineering effort...would you choose
Forth?
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.forth
Subject: Re: Free Forth
Date: 13 Aug 92 09:59:45 GMT
	<BEVAN.92Aug8212328@jaguar.cs.man.ac.uk> <5508@transfer.stratus.com>
	<1992Aug12.215854.19195@crd.ge.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: eaker@ukulele.crd.ge.com's message of 12 Aug 92 21:58:54 GMT

In article <1992Aug12.215854.19195@crd.ge.com> eaker@ukulele.crd.ge.com (Chuck Eaker) writes:

   I agree that free or cheap opens the markets of hobbyists,
   students, and many schools, but it's irrelevant to businesses.

I don't see how it can be irrelevant.  When I went to work for a
FORTRAN only shop, I introduced them to C as an alternative for the
more system oriented programs they were writing (they were mainly
doing scientific/numerical work).  This wouldn't have happened if I
hadn't picked up C using a _free_ compiler while I was at university.
I don't see why the same thing couldn't happen with FORTH.  As it
happens they also had a couple of control/instrumentation projects
with PCs.  The project language was BASIC !  IMHO FORTH would have
been much better, but I couldn't sell them on it as there wasn't a
standard (even a defacto one like PC BASIC) that they could use.  Sure
they could have bought into a particular vendor's products, but they
wanted portability and the freedom to mix and match vendors products
as necessary.  Note the slight hypocrisy here as they were tied to
Microsoft BASIC, but to bastardise an old saying, "no one every got
fired for buying Microsoft" :-)

bevan
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth Dimensions - the FIG journal
Date: 12 Aug 92 11:50:23 GMT
Organization: EIEI-U

Category 1,  Topic 5
Message 19        Wed Aug 12, 1992
JDHALL [John]                at 00:23 EDT
 
As soon as we get the listing of the FIG Chapters corrected we will
 print the list in every third issue. Other months will include
 Resources and Vendors.
-----
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
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Graphics, GUIs, and Events
Date: 22 Aug 92 13:27:36 GMT
Organization: EIEI-U

Category 18,  Topic 2
Message 49        Sat Aug 22, 1992
B.DUNN5 [Brian]              at 05:08 EDT
 
A minor bug in graphwin: <open_window> and <create_window> do not take the
size of the window border into account before calling GEM, the way
<move_window> does.  Check <move_window> and make open and create do the same,
then change init_window to compensate for the size difference.

I expect that some day it'll be time to change all the _ words into - words,
as ANS Forth does.

Many people are downloading this, does anyone have suggestions?  Has anyone
gotten it working on their own systems, and what systems are they?
-----
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
From: Jim.Bilderback@f606.n914.z8.rbbs-net.ORG (Jim Bilderback)
Newsgroups: comp.lang.forth
Subject: Forth Nutsnbolts Echo?
Date: 16 Aug 92 18:10:00 GMT

Sun  08-16-1992    
  
Hello folks .. this echo (comp.lang.forth) has just arrived at our   
local bbs via Internet and i'm wondering if there isn't another Forth
echo with a bit more application specific type msgs going on? In
particular .. an echo supporting the (apparently) dreaded and ill
conceived *free* (there i said it) forths. Are they frustrating and
oft time torture to learn? yes! Problems with missing our non-existant
support files? yes! Don't u just want to trash the darn things never
to see them again ??? YESSS! ... but i won't because they are too
interesting and too much fun when they work .. rsvp .. jim

GFx+ BBS Eureka,CA [707]442-3684 <HST Dual> 1:125/45 (8:914/606)

 * Origin: GFx+ BBS, Eureka CA.[707]442-3684<HST Dual>1:125/45 (8:914/606)
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Advertising Forth
Date: 13 Aug 92 21:07:29 GMT
Organization: EIEI-U

In article <4210@wet.UUCP> jpeters@wet.COM (John A. Peters) writes:

+In the Forth Dimensions of July 1992 Mike Elola writes "To use this
+message in advertising, it must be made simpler"  Here is my edited
+version:

I'm glad you commented on that, and I'd like to take your comments
one step further.

+Forth is a High-Tech "open" language that reveals it's internals and
+allows it to be extended and scaled to match the project.

Unless you buy a commercial system in which case you usually _do not_ get
access to its internals.

+expressions with fewer syntax rules than is usually customary.  No
+part of Forth is hidden or inaccessible to the programmer, therefore
+any known hardware interface is possible.

Except as noted above, but that ususally won't interfere with accessing
hardware.

+Forth programmers are free to add new components and language constructs
+as soon as they are understood, instead of waiting for compiler vendors
+to get around to implementing it.

That phrasing doesn't inspire much confidence in Forth.  I'd rather
see something like:

	Forth programmers are free to add new components and language
	constructs in order to grow/extend/etc. Forth into a comprehensible
	application specific language tailored for the task at hand.

+Example: The state machine SWITCH statement in C

Sorry, but C and Forth have both been around long enough for that example
to merely point out just how far behind the times Forth is (I can hear it
now:  What!?!? You have to a CASE/SWITCH construct YOURSELF!)

-Doug
---
Preferred:  dwp@willett.pgh.pa.us	Ok:  {pitt,sei}!willett!dwp
Newsgroups: comp.lang.forth
From: mylai@cs.uh.edu (Ming-Yung Lai)
Subject: Multitasking on R65F11
Organization: Computer Science dept.,  Univ. of Houston (Main Campus)
Date: Sat, 22 Aug 1992 16:50:55 GMT

 I wonder if there's someone has developed or known some multitasking
 words on the Rockwell's R65F11 MCU, please let me know.
 Thank you for your time.