HDTenEightyP/NetNews huggingface dataset:
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: X3J14 Holding Pattern Here
Date: 26 Aug 92 11:51:43 GMT
Organization: EIEI-U

Category 10,  Topic 12
Message 193       Sun Aug 23, 1992
ELLIOTT.C                    at 10:53 EDT
 
 -----via CRS Premium Bulletin Board

 Date: 08-15-92 (02:44)
   To: E.RATHER [ELIZABETH]
 From: MARCEL HENDRIX
 Subj: REFEREE

 er> Marcel notes the need for...
 er>  >a relatively independent referee with inside ANS
          ^^^^^^
 er>  >Forth knowledge

 er> I'm a little concerned about the possibility that there
 er> needs to be anyone with knowledge beyond what's written in
 the er> document.

 I didn't express myself too exact there. You may leave out the
 ``inside'' qualifier. I hope you'll agree that there must be a
 referee, and that she must be a Forth expert.

 I have not received any further information from Dennis, so the
 point is moot anyway.

 er> If there are any areas of ambiguity that you see, *please*
 er> write us about them now during this public review period!

 You realize that this is a joke on us Europeans. The period is
 one month, and I got the the letter two weeks after it had
 started.  Fortunately, we are very happy with the standard as
 it is now (sorry, will be).

 The past few months my Forthnet connection has been very bad, so
 I am (probably) not up to date on mailed comments on dpANS-3.
 Jax has suggested that some of the (new) floating-point words
 and even ; were broken, but he didn't go into details. Could
 these be summarized?

 I must confess that our ANS (?) tForth (transputer) and iForth
 ('386 in pm) work, but that we simply provide our own words were
 the Standard seems to have ``forgotten'' something (like
 formatted floating-point, strings, or elementary header
 manipulation).

 Marcel Hendrix
 Dutch Transputer Forth Workshop

 NET/Mail : FS FORTH Systeme BBS West Germany ++49 7667 556

 PCRelay:GRAPEVNE -> #318 RelayNet (tm)
 4.11            The GrapeVine (501)753-8121 3.6 gigs Dual Std


-----
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: meyer@dbsun.uucp (Don Meyer)
Subject: Re: Guerrilla Forth ! (Was "Re: $15 Forth-like Language...)
Organization: BioMerieux-Vitek, St. Louis Mo.
Date: Fri, 4 Sep 1992 18:57:25 GMT

In article <1678@sousa.ltn.dec.com> secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.) writes:
>In short, he uses C++ as an enhanced C compiler so the 
>conversion is trivial.  UNTIL is meant as the kernel for an 
>embedded applications language, so that does not mean that 
>this concept doesn't "lend itself to the strengths of C++."
>Quite the contrary, Forth -- or in this case something like 
>it -- lends itself well to that paradigm.  In the True Forth 
>Ethic he just doesn't force you into doing it that way.
>Likewise I challenge your notion that well-written C is 
>necesarily "badly written C++."  Get a life !  ;-)

I didn't mention the "Written in C but promoted as C++ because that's
a hot keyword in today's market".  That sounds like what this is.
If it uses so few of the C++ features that conversion is trivial,
than it should be written in C with a notation that it will also
compile under C++ IMHO.  Anything else is marketing hype (IMHO again).

If I implied that in all cases "good C == bad C++" it was unintentional.
This is not _necessarily_ true, but if someone uses code constructs
that are the only way to do something in C whilst ignoring a
better way to do something in C++, then, yes, it's bad C++ code
no matter how good it may be in a C context.  Case statements instead
of virtual functions would be a common example of this error.

<We now return you to the free FORTH debate>   ;-)

Speaking of which, I have actually spent a bunch of money at one time
for a commercial FORTH.  Like hundreds of dollars.  The company
proceeded to cut the price to 1/3 or 1/2 of what I paid a month
or so later.  A few years after that they abandoned the market (Amiga).
Sigh.  Should have bought the other guy's product (the one recently
mention here sounds as though it has thrived and become a 1st
class toolset.  Oops.

Don
-- 
-------------------------------------------------------------------------
meyer%dbsun.uucp@wupost.wustl.edu        |||     I am at two with nature.
Opinions expressed are personal.         |||       -- Woody Allen
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth Taught at Schools/Universities
Date: 26 Aug 92 11:51:33 GMT
Organization: EIEI-U

Category 2,  Topic 2
Message 123       Mon Aug 24, 1992
E.RATHER [Elizabeth]         at 21:41 EDT
 
Chris Waters writes:

>You need both users and vendors on standards committees.

 Users alone could come up with all sorts of blue-sky nice-to-have.s,

 but have a hard time finding a vendor to implement them.

 Vendors alone would stick with what's easiest for them. I agree that a TC
needs both users and vendors, and I'm happy to report X3J14 has good
representation of both.  But I take exception to the notion that Vendors
"stick with what's easiest for them."  This may be true of PD implementors,
who are after all volunteer labor.  But vendors stick with *what sells,*
because if they don't they're out of business.  The thing I find characterizes
vendor attitudes (my own and others on the TC) is the realization that they
have a significant customer base who have heavy investments in the current
product.  We are always interested in benefitting them or attracting new
customers, but are very reluctant to approve anything that will cause that
current customer base to find their existing code invalidated in ways that
will be expensive or difficult to fix.
-----
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: ForthNet Information
Date: 26 Aug 92 11:51:28 GMT
Organization: EIEI-U

Category 1,  Topic 15
Message 15        Mon Aug 24, 1992
E.RATHER [Elizabeth]         at 21:32 EDT
 
RE the Q "Where to get Forth for the Mac"...I note you're still recommending
Mach2.  Having heard for several years that they appeared not to be in
business any more, I now read the following in Creative Solutions' Summer 92
newsletter:

"Special upgrade pricing for a limited time is available to users of the now
defunct Mach2 Forth product.  Give us your disk number or other proof of
ownership & you can get a brand new MacForth Plus 4.2 for $99."

We evaluated MacForth a couple of years ago, and thought it was a very good
approach to the special problems of Forth on a Mac. I assume it's even better
now several releases later.  You might update your recommendations.

CSI's phone# is 1-800-367-8465.
-----
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: Environmental Queries
Date: Wed, 26 Aug 1992 21:03:40 GMT
Organization: StarNine Technologies, Inc.

In article <l6+n+w-.xtifr@netcom.com> xtifr@netcom.com (Chris Waters) writes:
>In <4007.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>
>>Category 10,  Topic 33
>>Message 10        Fri Aug 21, 1992
>>B.RODRIGUEZ2 [Brad]          at 22:49 EDT
>> 
>>                 ANSI X3J14 FORTH TECHNICAL PROPOSAL
>>                     (X3J14 dpANS-3, March 1992)
>
>>     Note: if the related proposal, "ENVIRONMENT? should take
>>     text from input stream" is adopted, then I withdraw this
>>     proposal as no longer being necessary.
>
>I prefer the current proposal (make S" interpretive in CORE), but I
>would definitely support either of these proposals.

I agree with your preference.  The problem with words that only derive
strings from the input stream is that it is difficult to compile the
word and bind a string to it.  No standard way, is there?

>
>The current definition of ``ENVIRONMENT?'' seems very poor to me, and I
>think that either of Brad's proposals here would provide an excellent
>and robust alternative.

I heartily agree.  It always seemed to me that ENVIRONMENT? came into
existance to satisfy one person's needs, with no more thought going into
how to make it more general purpose.

It's a king of function that needs to be thought out very well before
being standardized.

Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Forth Taught at Schools/Universities
Date: Wed, 26 Aug 1992 01:45:12 GMT
Organization: StarNine Technologies, Inc.

In article <3997.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>
> E[>I am trying to satisfy a request from the Navy for
> information about schools E[>and universities that teach Forth.
> They're considering using it for a large E[>project, and are
> concerned about the availability of Forth programmers

This is an amazing piece of news.  Do you have any more info
as to the nature of this project?
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Free Forth
Date: Wed, 26 Aug 1992 01:42:14 GMT
Organization: StarNine Technologies, Inc.

In article <14487@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
>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...

Agreed.  I suppose "not care at all about their size" can have some
pretty negative conotations.

In the 'ole' days, when every personal machine was almost an imbedded
system unto itself :), i.e. max 64K, no file system, or one that
didn't raise any eyebrows if you lived without (via SCREENS), there
was much emphasis on cramming stuff in small places.

In this day & age, where 640K seems like a little, I think this
attitude is wasted effort.

Of course, for true imbedded controller work (where Forth is very
happy), the old postulates still apply.  Lean & mean & worth every
drop of sweat to get there.

But I was addressing "platform-oriented" Forths.

>
>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...

Yes, but I didn't say "larger than necessary".  I meant that
for a powerful platform development system, not increasing the size 
of the Forth should never take precedence over adding useful, powerful tools.

No one should be ashamed if their platform-Forth is over 200K in size,
if it's an amazing piece of work.
>
>> 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.

I'm not talking about  low-quality tools... it goes without saying that
they are of no value, small or not.

I WAS addressing the philosophical differences between developing for
a platform and developing a standalone, imbedded product.  

For me, Inferior tools are never a component in the equation.
Newsgroups: comp.lang.forth
Subject: -- EFORTH -- Help! please.
From: mentink@wronz.org.nz
Date: 26 Aug 92 09:37:34 +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: Nick_Janow@mindlink.bc.ca (Nick Janow)
Newsgroups: comp.lang.forth
Subject: Re: "Free" Forth is expensive
Date: 27 Aug 92 08:43:42 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

mikeh@starnine.com (Mike Haas) writes:

> If the Forth community could AGREE on standards, they could begin to be
> implemented cross-platforms. ....  We have fought over SCREENS and FILES
> while the rest of the world was discussing device-independant graphics!

Yes, we've discussed the language implementation, while the others have been
holding discussions based on real applications.  The C programmers have been
writing applications for photorealistic rendering, and what the language needs
for doing that portably; we've been discussing  which of several (decades old)
implementations of "/" should be standard.

Hmmm, no wonder Forth hasn't gotten very far in anything but embedded systems.
:-/

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.lang.forth
From: mylai@cs.uh.edu (Ming-Yung Lai)
Subject: Help needed
Organization: Computer Science dept.,  Univ. of Houston (Main Campus)
Date: Thu, 27 Aug 1992 13:21:19 GMT

 I've asked the question last week, since I don't reveived any response
 I would like to try my question again.
 (1) Is there anyone out there had developed some multitasking words
     under Rockwell's FORTH based R65F11 MPU?
 (2) Is there any PD or Shareware FORTH system developed on Hitachi's
     HD64180 MPU?
 Thank you for your time.

 Email: mylai@cs.uh.edu
From: secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.)
Newsgroups: comp.lang.forth
Subject: Guerrilla Forth ! (Was "Re: $15 Forth-like Language...)
Date: 2 Sep 92 18:10:51 GMT
Organization: Digital Equipment Corporation


meyer@dbsun.uucp (Don Meyer) writes:

	; Hopefully I'm wrong, but if it was truly easy to convert
	; from "C++" to C than I suspect one of two situations exist. 
	; Either it is an application that really doesn't lend itself
	; to the strengths of C++, or it is badly written C++. :-(  
	; To be fair, a third possibility is that you (the converter)
	; are really, really fast! :-) 

In short, he uses C++ as an enhanced C compiler so the 
conversion is trivial.  UNTIL is meant as the kernel for an 
embedded applications language, so that does not mean that 
this concept doesn't "lend itself to the strengths of C++."
Quite the contrary, Forth -- or in this case something like 
it -- lends itself well to that paradigm.  In the True Forth 
Ethic he just doesn't force you into doing it that way.
Likewise I challenge your notion that well-written C is 
necesarily "badly written C++."  Get a life !  ;-)

	; How FORTH-like is it?  I'm still intending to get a small
	; FIG-like :-) FORTH up and running on a 68k platform.  The
	; "real" code for the instrument is written in C++, but I'd
	; like to tuck a small subversive FORTH environment on the
	; board for debugging etc.  Even though I'm paid to write
	; C/C++, FORTH was my first "real" language and I miss it! 

It's very Forth-like, and the author makes no bones about 
it -- he talks about Forth outright and even mentions FIG
someplace (okay, he's a card-carrying member !).  You can 
either create colon definitions called "macros" or add your 
own C routines to the base code to make new primitives.  
It is quite evident that the author, like you, is paid to 
write C/C++ by people who would be scared off by "Forth," 
and so he wrote this tool for embedding a logical Forth in 
his applications -- only he could say it was written in C
and featured some extensive "application macros."  If 
you're careful about your compiler options I'm confident
it'd fit in a ROM, but I haven't thought much about any
code changes which might be required to use it that way.
If you're looking to "tuck a small subversive FORTH 
environment" into your work, then this guy is after your 
heart !  I believe the only requirement, much like what 
Mitch Bradley does, is that you include a copy of his book 
with every copy of your product that you sell.

Regards,
rcs
From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
Newsgroups: comp.lang.forth
Subject: Re: ANS TC Magnet for ROMability
Date: 4 Sep 92 13:09:15 GMT
Organization: /etc/organization


   The discussion of cross compiliers, meta compiliers and related
things like ROMable code as part of the ANSI Forth standard shows
how we are doing things in the wrong order. Deciding on a standard
for a process that is done in radically different ways will lead
nowhere. The first step in standardising cross compiliers should
be to write a clear explantion of how a cross compilier works 
and publish code that does it in an efficient manner. We will
know the code is good when it gets copied into various new Forth
systems.
   I don't think the groundwork for a cross compilier has been 
done yet. I also think documentation for a cross or meta compilier
would be an important part of a standard document for Forth.
Newsgroups: comp.lang.forth,comp.lang.forth.mac,misc.books.technical,misc.forsale.computers
From: toma@romulus.cray.com (Thomas Arneberg)
Subject: Book for sale: _Starting FORTH_ (Leo Brodie), $12 obo
Organization: Cray Research, Inc.
Distribution: usa
Date: 1 Sep 92 09:10:44 CDT

   	BOOK FOR SALE:  
   	"Starting FORTH" by Leo Brodie, FORTH, Inc. (c) 1983

   from the forward by Charles Moore, inventor of FORTH:
	"The FORTH community can celebrate a significant event with the
	publication of _Starting FORTH_. A greater effort, talent, and
	commitment have gone into this book than into any previous
	introductory manual."
	
        "_Starting FORTH_ was written and illustrated by Leo Brodie, a
	remarkably capable person whose insight and imagination will become
	apparent. This book is an original and detailed prescription for
	learning. It deftly guides the novice over the thresholds of
	understanding that all FORTH programmers must cross."

   the book is in brand-new condition, virtually untouched by human hands

   Paid $20; will sell for $12 (INCLUDING shipping) or best offer.

---------------------------------------------+------------------------------
;-) I'd rather be ____  Thomas R. Arneberg   | Inet: toma@cray.com
:-) singing in a |____| Senior IC Design Eng.| UUCP: ...!uunet!cray!toma
:-) Barbershop  _|   _| Cray Research, Inc.  | CLAIM TO FAME: Loni Anderson 
:-) Quartet!   (_)  (_) Chippewa Falls, Wisc.|   went to my high school 
---------------------------------------------+------------------------------
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Searching For Connections (ForthNet interconnectivity)
Date: 26 Aug 92 11:51:48 GMT
Organization: EIEI-U

Category 14,  Topic 12
Message 7         Sun Aug 23, 1992
ELLIOTT.C                    at 10:52 EDT
 
 -----via CRS Premium Bulletin Board

 Date: 08-22-92 (18:46)
   To: ELLIOTT CHAPIN
 From: Jim Wenzel
 Subj: Forth BBS's
 ->CRS

 Elliott Chapin * The info/FAQs should be  coming around again before too
                  long;  they're posted  to Usenet  about twice
                  a month. Right now I'm porting them  to GEnie
                  (via Canada Remote Systems)  and I  expect that
                  others will  put them  on RIME.
                                  = = =

    The port  from Genie -> GrapeVine  -> RIME is back  in place.
    We also carry the Forth Use-Net conference here.  It would be
    a simple matter to port it directly in to RIME..  Have you
    taken over Gary's place of porting from Use-Net / Rime to
    Genie?
 ---
  * SM 1.06 A0059 * A clean desk is a sign of a cluttered desk
    drawer.

 PCRelay:GRAPEVNE -> #318 RelayNet (tm)
 4.11         The GrapeVine (501)753-8121 3.6 gigs Dual Std


  BBS: CRS Premium Bulletin Board
 Date: 08-23-92 (09:33)
   To: Jim Wenzel
 From: ELLIOTT CHAPIN
 Subj: Forth BBS's

 JW>   to port it directly in to RIME..  Have you taken over
 Gary's place of JW>   porting from Use-Net / Rime to Genie?

 Only RIME -> GEnie.  Bob Lee is doing the Usenet tasks on GEnie
 (via Citadel) except that the process he uses doesn't handle the
 info/FAQ msg's yet, so I'm doing them until he straightens it
 out. Your msg (above) will go -> GEnie.

 Elliott Chapin
 ---
    DeLuxe  1.12 #4315   elliott.chapin@canrem.com


-----
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: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for ROMability
Date: 26 Aug 92 11:51:45 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 82        Tue Aug 25, 1992
B.RODRIGUEZ2 [Brad]          at 21:21 EDT
 
Chris: thanks for your answers to my cross-compiler questions.  Your answers
agree with my understanding of the dpANS; but I have received divergent
opinions in the past from members of the TC, so I think I can safely say the
dpANS is not clear on this issue.  Hence the formal request for clarification.
At Len Zettel's suggestion, I made it as detailed and specific as I could.

I should add that I have written significant applications under the
restrictions that I proposed.  With pain, I admit...it's rather like
programming in C.  :-)  I deliberately chose a restricted set of words to
accomodate the largest variety of existing cross-compilers.

> Writing cross-compilable code almost always entails using various
 > extensions to specify whether words exist in the host or target
 > system.

Actually, you should see the cross-compiler I'm currently using (from MPE in
the U.K.).  My application code looks exactly like "ordinary" Forth.  I've
converted huge files from "resident" to "cross" compilation, with no edits at
all!  Admittedly, I do have to provide directives such as ORG, but if
commercial assemblers are any indication, we don't need to standardize these.

Brad Rodriguez
 B.RODRIGUEZ2 on GEnie   |   bradford@maccs.dcss.mcmaster.ca
 So many projects....so little time.

-----
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