HDTenEightyP/NetNews huggingface dataset:
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Flames
Date: 6 Jan 93 12:21:00 GMT
Organization: EIEI-U

Category 12,  Topic 6
Message 145       Tue Jan 05, 1993
ELLIOTT.C                    at 14:42 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 12-27-92 (02:15)
   To: B-LEE [B0B]
 From: RAY DUNCAN
 Subj: FLAMES



  >Jaxfanz and others have noted it.  I would urge you to notify
  >your lawyers that their newly-proposed title for your book is
  >uncomfortably close to the
  >preexisting title, "FORTH: A TEXT AND REFERENCE".

 As a sometime book author, I don't feel that the titles of the
 Kelly/Spies book and the prospective Jax Fan Club Bible are
 alarmingly similar. They both have "FORTH" up front in the title,
 which is just good commonsense title design, but "A Text and
 Reference" doesn't really have quite the same ring as "The New
 Model" -- do you think?

 Anyway, for better or worse, it's a fact of life in the
 publishing industry that you can't copyright a title - only the
 contents.

 NET/Mail : LMI Forth Board, Los Angeles, CA (310) 306-3530
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.04  GRAPEVINE (#318) : RelayNet(tm) Hub



-----
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: mauricio@beethoven.aero.ufl.EDU (Mauricio Tavares)
Subject: FAQ - forth for Unix, Apple ][, and CoCo wanted
Keywords: FORTH, Unix, Apple, CoCo, where
Reply-To: mauricio@beethoven.aero.ufl.EDU (Mauricio Tavares)
Organization: THAT would be telling
Date: Thu, 7 Jan 93 14:10:00 GMT


	I have seen quite a lot of references to a Unix forth; where can I find it (them)?  Also, does anyone know where can I find forth compilers for my Apple ][+ and my TRS Color Computer?
Newsgroups: comp.lang.forth
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: Forth Standard Debate
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Fri, 8 Jan 1993 02:52:28 GMT

In article <1ihl5vINNr1o@life.ai.mit.edu> mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:
>In article <1993Jan4.214739.11660@netcom.com> jimlynch@netcom.com (Jim Lynch) writes:
>:Whoever wrote the following:
>:>>>>>
>:Forth has not been standardized, not at all, ever.
>:<<<<<
>:
>:(with apologies in advance) is sorely mistaken and misinformed.
>:
>:I was there, I saw the standards come out and I have copies of the figFORTH
>:installation manual (somewhere) as well as the FORTH-79 and FORTH-83 standard
>:descriptions.
>:
>:On the contrary, there's more than one standard! :)
>:
>  I confess, it was picky hard to please me that wrote that.

Well then, be truthful.

>  If you have more than one standard, it seems to me that you
>  have no standard at all. A double standard is condemmed,
>  and we seem to have at least three of them (with another
>  comming soon).

Standards are conveniences for the vendor. Said vendor doesn't have to write
the whole manual; can refer to others.

It's also a convenience to users: portability to other vendors' forths.

Forth _is not_ and probably never will be carved in stone. Forth is the poor
man's integrated dev environment. If you like it, use it. In either case,
please don't provide disinformation. That does alot more harm than good.
(you _are_ here for good, right? Not just to watch a <quote> condemned <unquote>
ship sink?)
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting
Date: Fri, 8 Jan 1993 01:45:45 GMT
Organization: StarNine Technologies, Inc.

In article <19259@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
>
>Some potential Forth'ers might be turned off by seeing heated "screens vs
>files" composing half the net traffic.  :(

Ah... that must be the reason Forth is not very popular...

because we discuss it's rough edges on the net.

Sorry.  So what would you like us to talk about, Nick?

Newsgroups: comp.lang.forth
From: John_Somerville@mindlink.bc.ca (John Somerville)
Subject: Now for something completely...
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 8 Jan 1993 06:38:54 GMT

What sort of AI projects are you working on. If you are using Prolog, I would
like your comments on the implementation you use.
regards john
--
john somerville B.C. Hydro
affiliations FIG Forth Interest Group
Newsgroups: comp.lang.forth
From: larry@tsd.arlut.utexas.edu (Larry Maturo)
Subject: Re: Documenting
Organization: Applied Research Labs, The University of Texas at Austin
Date: Thu, 7 Jan 1993 14:24:56 GMT

In article <1492@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
...

>If others prefer text files, that's great, but I resent the
>implication that I haven't moved to text files because of laziness.
>It's because blocks work best for my uses.  If others use text files
>that doesn't bother me at all.
>

...

You never really explained why blocks work best for your uses.  Being new to
Forth I would really like to hear the reasoning behind your preference.  I
currently prefer files becuase I've never seen any good explanation for why I
should want to use blocks and they are currently unfamilar to me while files
arn't. Also, there does not appear to be a good standard for Forth block editors
that is anywhere near as powerful as many text file editors.  There may be great
ones around, but they do not appear to be standard (I could be wrong on this, my
knowledge is limited to the block editor in Starting Forth which does not appear
to be very powerful).

+-----------------------------------+----------------------------------------+
|                                   |                                        |
| Larry Maturo                      | Opinions expressed herein must be      |
| Tactical Simulation Division      | yours, neither I nor my employer have  |
| Applied Research Laboratories     | any.                                   |
| University of Texas at Austin     |                                        |
| P.O. Box 8029                     +----------------------------------------+
| Austin, Texas 78713-8029          |                                        |
|                                   | When you're as great as I am it's hard |
| larry@titan.tsd.arlut.utexas.edu  | to be modest, but I succeed where      |
|                                   | others fail.                           |
+-----------------------------------+----------------------------------------+
Newsgroups: comp.lang.forth
From: John_Somerville@mindlink.bc.ca (John Somerville)
Subject: Re: Documenting
Organization: MIND LINK! - British Columbia, Canada
Date: Wed, 6 Jan 1993 01:09:01 GMT

You may be right Nick that people would be put off by the screens vs files
discussion. However, the last time I looked in on Pascal and C++ much of the
discussion was on bugs in the compilers and work-arounds.
regards john
--
john somerville B.C. Hydro
affiliations FIG Forth Interest Group
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting - blocks source to target
Date: Wed, 13 Jan 1993 04:38:37 GMT
Organization: StarNine Technologies, Inc.

In article <1ijtaoINN3m4@usenet.INS.CWRU.Edu> bs764@cleveland.Freenet.Edu (Fred H Olson) writes:
> 
>In a message about blocks vs text files cbbrowne@csi.uottawa.ca
>(Christopher Browne) states:
> 
>>In the case of an embedded controller, there may not BE anything
>>connected in the end, aside from an RS-232 connection.  In this case,
>>"streams" win out, since there is nothing that even resembles a BLOCK.
>>I think that EForth works this way.
> 
>   Blocks can work fine here without going to 'serial block
>emulation'. It is trivial to send blocks as a stream...  (Not so

>  One feature
>of such a system was that the host could filter the blocks before
>sending them -- not sending 'trailing spaces' or anything after a
>;S on a block for example. 

This is what kills me about blocks... the above fella used -TRAILING when
sending screens over a communications media, adding extra code to both
the SEND and RECEIVE routines  (the RECEIVEr has to put them back in, no?).

Why is he not concerned about the terrible waste of disk space that
SCREENS cause?

In short, he did extra work to efficiently transfer his source from one
place to another, but once it got to the other end, he has to do more
work to cause his source code to (once again) take up much more disk space
than necessary.

Go figure.

Blocks just don't make sense.

Newsgroups: comp.lang.forth
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: Forth Standard Debate
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Tue, 5 Jan 1993 10:31:40 GMT

In article <1993Jan4.234621.12186@news.uakron.edu> r3btg@vax1.cc.uakron.edu (Ben T Galehouse) writes:
>It is quite amusing to listen to everyone argue.  Here is what I think.
>There should be standards.  This isn't difficult to justify.  People
>need to know that there is _a_ forth standard that everybody uses.  This
>makes learning forth much easier.  Code portability is also a factor.
>
>However, for forth to keep it's spirit, must also be deviation from the
>standard.  Often, a machine's architechture dictates the fastest or the
>shortest way to do something.  Also, especialy in embedded applications,
>no one application will need all the commands often included with forth.
>This sort of deviation from the standard must be accepted and even
>supported, no matter how badly a person advocates that standard.
>
>One of the most important characteristics of forth is it's size and
>consision.  To this end, I suggest a group of malleable standards.
>There should be a very short basic description of forth.  On top of
>that, there should be a description of how forth should be implimented
>on 16-bit machines and on 32-bit machines (size of stack? if the stack
>is 32 bits, how to work with 16-bit arrays?).  If somebody wants to
>devise a graphic standard (variable names that contain the screen size?)
>that is also fine.  Not all 32-bit machines have graphic interfaces.
>Not all people want floating point support.  The standard should be
>modular.  There should be a 16-bit standard.  There should be a 32-bit
>standard.  There should be a floating point standard.  (why not add a
>floating point stack) 
>
>Most importantly, however, all source code should always be provided,
>and everything should be no larger than necessary.  This is the most
>universal forth standard  --- the programer should understand the
>compiler and everything about it.
> 
>-- 
>r3btg@vax1.cc.uakron.edu          15764 Galehouse Rd.
>Ben Galehouse              Doylestown, OH, 44230
>(216) 658-3556           

Contact the Forth Interest Group.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Selecting a Public Domain Kernel
Date: 6 Jan 93 12:20:55 GMT
Organization: EIEI-U

Category 1,  Topic 7
Message 111       Tue Jan 05, 1993
ELLIOTT.C                    at 14:42 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-04-93 (00:16)
   To: B-LEE [B0B]
 From: RAY DUNCAN
 Subj: SELECTING A PUBLIC DOMAIN

   >any generic CP/M or MS-DOS based Forth ... such as from LMI or
 ...

 We did sell a generic CP/M-86 Forth and a generic MS-DOS Forth at
 one time that would run on the DEC Rainbow, but gave up on it due
 to lack of demand.

 The Forths we currently sell would not run on the DEC Rainbow
 without quite a bit of tinkering. We do have a "generic" video
 driver that is dependent only the BIOS as an option in our Forth
 systems, but the DEC Rainbow was not even compatible with the IBM
 PC at the BIOS level.

 The person inquiring about this would be best off to get one of
 the older generic Laxen & Perry F83 systems for CP/M-86 or MS-DOS
 and working from there.

 Ray Duncan, Laboratory Microsystems Inc. (LMI)
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.04  GRAPEVINE (#318) : RelayNet(tm) Hub  


-----
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: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
Subject: Re: Documenting
Originator: pazsan@hphalle7c.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 8 Jan 1993 14:40:03 GMT


Thanks, Kevin for pointing out what is the essential reason for using
screens in Forth.

I use screens and streamfiles both. Because I work under host OSs
(Atari TOS and MS-DOS since last week), my screens are in host files
and I use the host directory for naming the file. Transparent work with
both screens and streamfiles is easy and possible; my editor has both
modes and chooses automatically. Loading from the cursor position is
possible with both formats. Easy inserting or deleting screens or
lines. I use a nearly horizontal format both in screens and
streamfiles. To show structures, I use spaces, capital notation of
structure words, lowercase notation of other words and a capital letter
followed by lowercase for creating words. if an IF ELSE THEN statement
has more than 3 or 4 words in it, I break it up in lines and I indent,
certainly. The same with assembler. Registers are uppercase, mnemonics
are lowercase, structures uppercase and indented. Certainly there are
some crowded words in old sources; because they are old, they are
screen sources ;-).

Disk size: If you really have problems with your source and your 100 MB
HD, use SuperStore or how it is named, it is designed to compact your
screen files. If you like your stream editor and like to write vertical
code like

: DOGJUMP
	THE	\ article
	QUICK	\ fast, moving like a flash
	BROWN	\ a dark read-yellow color
	FOX	\ a fast wildbeast with brown hairs
	JUMPS	\ moving up into the air
	OVER	\ above
	THE	\ yet another article
	LAZY	\ doing almost nothing
	DOG	\ a domesticated wulf
;
\ I'm not shure to remember all the comments correctly.

do it. Buy a Forth that allows the use of stream files. Or write your
block>stream tool (you should have host OS files as blocks). That's
what I did with my bigFORTH. I scan through the block file for
linefeads, delete the last cariage return and copy that into the TIB.
Someone has to do this anyway (and if it's the host OS). I would prefer
counted strings in streamfiles, because they don't require scanning,
but once I start with streamfiles, compatibility to the host OS is
required.

I grew up with screens and I like them. I like horizontal notation. I
use it in stream files, too. I hate people writing 2-page words in
stream files. Once upon a time a bigFORTH user sent me a tool for
stack checking. He implemented a word named (S and then scanned in a
very big loop for the strings until the next ")". Then he compared the
word found with several strings, like "d" or "n" or "addr" and so on.
He was proud that it was working, and every new type would have
required one additional line in his (S. The easy solution was to use
the dictionary and FIND.

>There are no complex problems; only complex solutions!

That's it!
-- 
Bernd Paysan
"Late answers are wrong answers!"
Newsgroups: comp.lang.forth
From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble)
Subject: e-forth has no DOES> !!!
Organization: University of Virginia
Date: Mon, 4 Jan 1993 14:44:30 GMT

Dear Friends,

Has anyone added DOES> to e-forth? I presume that with study I could
do it, but if someone else already has, I would rather not waste the
time. This is a time-critical question, as I am trying to put together
a Forth diskette for beginners, to be given away free at the Forth-
coming ACM meeting in Indiana. If Borland can give away large boxes of
C++ for free, why can't we do Forth?

I propose my disk to contain e-forth (if I can add DOES>, that is) and
F-PC, as examples of minimal and (fairly complete) Forths. The assembler
source will be included with both, as well as some applications. As an
example of an app for e-forth I was going to include my MINI parser,
that translates integer expressions into Forth. But it is vastly smaller
and more readable using CREATE...DOES> to build the necessary FSMs to
recognize the grammar, than if I were to simulate them with
BEGIN...WHILE...REPEAT and BEGIN...UNTIL loops.

By the way, does anyone know why they use FOR...NEXT rather than DO...LOOP
in e-forth? Is this what ANSI is leading us to?

Regards, and an early answer would be greatly appreciated. Thanks in ad-
vance for any help.   --J.V. Noble

"Forth without DOES> is like a day without wine."
From: d7stfax@dtek.chalmers.se (Stefan Axelsson)
Newsgroups: comp.lang.forth
Subject: Re: Forth for Sparc and other Unix based computers
Date: 4 Jan 93 16:58:32 GMT
Organization: Chalmers University of Technology, Gothenburg Sweden
X-Newsreader: NN version 6.4.19

mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:

[Discussion about SPARC native code forth vs C version deleted]

>     Right, its not native code. But the trouble is that the SPARCstation
>is a Unix box. And Unix works with C. So if you want a native code
>anything on a Unix box you'll have trouble with the documentation. The
>documentation tells you how to write C programs, but finding what you
>need for native code from an assembler is not easy. 

Hmm, what *exactly* do you mean by "finding what you need for native
code from an assembler?" I've just started to look into SPARC
assembler, since I didn't have any experience with RISC based
processors. I found some info in Sun's manuals, some in "Structured
computer organization" by Tanenbaum, and some from a friend who had
just started on a SPARC compiler for Lazy ML.

But my main source of information about how to program our SUN
SLC/ELCs came from the C compiler. Every Unix C compiler I've come
across have an option to show the generated assembly file, and careful
study of selected example C programs often reveal all there is to know
about assembly programming that machine, such as procedure calling
conventions and the like.

This all assumes that we want a native code forth that uses the
underlying operating system. I you really want to code the naked iron
of the current crop of Unix workstations you are, as you state, on
your own. (As the Linux project has shown not even the PC/AT
architecture is very well documented when you skip beyond the BIOS
level.) I think the original question stated however, that the forth
should run in a "window," or something, I interpret that as he wanted
a native code forth, that used the OS.

The reason I think forth in C is the way people have gone is that that
is the portable way to do it across all sorts of workstation
platforms. If anyone knows better please enlighten us.

Regards,
--
Stefan Axelsson,			Chalmers University of Technology,
d7stfax@dtek.chalmers.se		Sweden
Newsgroups: comp.lang.forth
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: Forth for Sparc and other Unix based computers
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Mon, 4 Jan 1993 21:50:22 GMT

I think, by 'native code forth' the poster means he wants a direct threadded
code forth.
From: nick@sw.stratus.com (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Forth Standard Debate
Date: 4 Jan 1993 15:01:22 GMT
Organization: Stratus Computer, Inc.
Distribution: world
NNTP-Posting-Host: osa.sw.stratus.com

In article <1i7flnINN9or@life.ai.mit.edu>, mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:
>     Well I'm glad I did manage to write a little bit of helpful prose. 
> Which part of my paragraph above do you dissagree with most? Has
> Forth ever been standardized? Has a new Forth standard ever replaced an
> old standard? Do you expect people to stop using F-PC, F83 or fig Forth
> when the ANSI standard is finished? 

By this definition, nothing is ever standardized because there are always hold-outs
hanging on to their older standards.  ANSI C did nothing to standardize C because there
are still people with programs that only compile under K&R C.  Of course people will
still be using existing systems.  The question to ask is what will new applications
be written in?  I suspect that existing commercial languages will quickly move to
support the ANSI model if they want to survive.  I also suspect that anyone who
values cross-platform compatability will buy only ANSI compliant Forths as a matter
of course.  I could be wrong.  We'll see when the standard hits the streets.

BTW: I note that you defend the idea that Forth has never had a standard by naming
     two standard implementations F83 which implements the FORTH-83 standard, and
     fig-Forth which was a defacto standard.  How you can invoke these 2 implementations
     and simultaneously deny that Forth ever had standards is beyond me.

> |        You ignore what must be hundreds of thousands of installations
> |of 83-STANDARD, the finest embedded control language known to computer
> |science.
>     There is no particular need to follow any sort of Forth standard in 
> embedded systems. The Forth code is hidden away where only its author 
> will see it.

The first sentence is ridiculous.  There is always a need to follow standard
procedures and use standard tools where available in any non-throwaway application,
and often even there.   Regarding the second sentence:  How is this
different from any stand-alone application?

>    Michael Coughlin             mikc@gnu.ai.mit.edu  

									/nt
Newsgroups: comp.lang.forth
From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
Subject: Re: X3J14 Holding Pattern Here
Originator: pazsan@hphalle5h.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 8 Jan 1993 08:51:35 GMT


In article <4187.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
|> Category 10,  Topic 12
|> Message 195       Sun Dec 13, 1992
|> ELLIOTT.C                    at 20:44 EST
|>  
|>  -----via CRS Premium Bulletin Board -
|>  USR Dual Standard 16.8K  (416) 629-7000
|> 
|>  Date: 12-07-92 (01:40)
|>    To: ALL
|>  From: MARCEL HENDRIX
|>  Subj: VALUE
|> 
|>  Re Changes in dpANS-3 (Bernd Paysan):
|> 
|>  bp> 8. VALUE changed to take an initial argument from the stack
|>  bp>    (like CONSTANT)
|> 
|>  I hope we'll get some background on this. Of course, it is now
|>  reversed to the way it is in F-PC and like everybody else has
|>  had it for a decade, but the previous dpANS proposal was better
|>  with respect to ROMmability (IMHO).  I suppose now we'll have to
|>  put in code ( a chain? ) to initialize all VALUE's when the
|>  system boots from ROM.

Hm, I don't see were the problem is. Every object in Unix, TOS or MS-DOS has
(at least) three parts: The TEXT (initialized, but unchanged at runtime) which
could stay in ROM, the DATA (initialized, but possibly modified at runtime),
which is copied to RAM at boot time and the BLOCK STORAGE, (uninitialized or
initialized to zero and modified while running) which is only allocated and
erased at boot time. Target compiling for ROM means then: Use two buffers
(one for DATA, one for TEXT), and generate addresses for DATA space when
CREATE, VARIABLE or CONSTANT (and switch to RAM or DATA allocation
scheme until the next CODE or COLON definition).

|>  Does this mean that VARIABLE's and CREATE structures may be
|>  initialized too (I know the committee doesn't want to think
|>  about ROMmability yet, but...)

I prefer VARIABLES and CREATE structures to be initialized at target compile
time. Sometimes my CREATE structures are more likely to be constants than
variables (i.e. an uppercase converting table), then I use LABEL to get
the address.
-- 
Bernd Paysan
"Late answers are wrong answers!"