HDTenEightyP/NetNews huggingface dataset:
From: kasajian@netcom.com (Kenneth Kasajian)
Subject: Re: Forth's Adaptability
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 26 Jan 1993 18:08:36 GMT

>   [ LMI FORTH has files & blocks, floating point ... etc. ]

>   they've [LMI users] had access to these capabilities, if they
>   needed them, for many years.

>And I'm sure they are happy with them, but consider what happens if
>they decide, for one reason or another, that they don't want to use
>LMI FORTH anymore, but prefer to use a different vendor's system.
>What are they to do with all the code they've developed using LMI
>specific extensions?  Unless the "extensions" are either standard or
>defacto standards then there may be significant effort involved in
>changing the code, so much so you may have to stick with the system
>you have even though you know you can get better/cheaper elsewhere
>(I've suffered just this situation with large amounts of code written
>using VAX FORTRAN + extensions).  This is good for vendors since it
>keeps users locked into their system, but it is definitely not a good
>deal for users.

I don't think it is a fair to compare Fortran and Forth in the context
of portability.  If the Vax Fortran + source code had many Forth extensions
which were not supported by another vendor's Fortran, then you need to
change your source code considerably.  With Forth, it's very easy to
add the extensions to the language so that the source most often need
not be changed.

Kenneth Kasajian
Newsgroups: comp.lang.forth
From: penev@venezia (Penio Penev)
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Organization: Rockefeller University
Date: Tue, 26 Jan 1993 06:20:19 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

James Hague (exuhag@exu.ericsson.se) wrote:
: Penio Penev writes:
: >Another consideration is when You run RISC processors (I'm running
: >R3000 currently). There You have even more space and You can benefit
: >_a lot_ from the inlining of some primitives.
: 
: I have mixed feelings about making a true compiler an integral part 
: of Forth.  It would remove the simplicity and understandability of
: the traditional Forth system--a step toward the 'black boxes' of
: conventional language IMO.  But a native code generator which could
: be run after development was complete would be a godsend and there
: seem to be surprisingly few of these.  Tom Almy's ForthCMP, which I
: am a registered user of, is nice but does force you to give up some
: of the power of Forth in exchange for native code (you have to keep
: ForthCMP in mind while you are writing an application).

I feel a bit confused what You mean by 'true compiler'. I suppose You
mean something You pass a text stream to and it returns some kind of
assembly or object. 

What I ment is something completely different. I ment native coding,
inlining and local (I think the term is peephole) optimisation. The
interpreter and compiler stay the same (I mean the definitions of
INTERPRET and ] ). When You write code You cannot tell the diference.
The only point is that You have more IMMEDIATE words, which check
whether some optimisation can be performed and put the binary code
into the dictionary. These are words like LITERAL @ ! DUP DROP SWAP
and others. You cannot decompile, but You never need this, since You
have the source and LOCATE (or VIEW on some FORTHs).

: 
: More and more I'm discovering one of the reasons for Forth's lack
: of popularity is that, while it doesn't have to be used solely for 
: embedded systems, there isn't much support outside of that area.

I guess this statment will be flamed by the FORTH vendors, who are
suppose to 'support [products] outside of that area'.

-- Penio.
Newsgroups: comp.lang.forth
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Evolution of Forth (was: Documenting)
Date: 22 Jan 93 23:07:44 GMT
Organization: EIEI-U

In article <1504@eouk9.eoe.co.uk>
	ahaley@eoe.co.uk (Andrew Haley) writes:
+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.

[It would be interesting to see if there is a "core" set of words that
CM has consistently used through out all his modifications and new systems.]

I think the argument about blocks versus files versus either-or-both has
very reactionary elements in it.  It seems to me that CM's own process of
evolving Forth clearly indicates that any specific version of Forth (fig,
79, 83, ANSI, whatever), is merely a snapshot in time/utility-space.  I
think Chuck Eaker's point about questioning versus rejecting complexity is
salient here.  While we may find particular insights from what CM has done
in his evolutionary process, we need to recognize that his changes are in
response to specific needs and constraints, and that his needs and
constraints may be very different from anyone elses.  Just because CM at
some point in history said, for example, that blocks are the be all and
end all of disk storage, doesn't mean that statement is still true given
current needs and constraints.  Dogmatic insistence on change and dogmatic
resistence to change are not opposites.

-Doug
---
Preferred:  dwp@willett.pgh.pa.us	Ok:  {pitt,sei}!willett!dwp
From: duncan@nic.cerf.net (Ray Duncan)
Newsgroups: comp.lang.forth
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Date: 27 Jan 1993 17:19:28 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <1993Jan27.161520.15484@crd.ge.com> eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
>
>I have been told that LMI does not plan to support the new
>standard. Is that correct? If so, would you care to discuss
>the reasons?
>

I have gone through several changes of heart about this.
Originally I was an enthusiastic supporter of X3J14.  After
the committee was invaded by the FIGgies like Berkey and Shaw
and began to diverge radically from the existing common practice
and Forth-83, I became exasperated and lost interest.  We have
a large body of existing code of our own and a lot of users who
count on us for a stable development environment; I couldn't 
see any sense in wantonly breaking all that source code and
cluttering up the language with bizarre word sets (if you've
followed the X3J14 process from the beginning and read all the
technical proposals, you know what I'm talking about). 

Now that X3J14 has returned to its senses and most of the 
really silly stuff has been trimmed back out of the dpANS, 
we're leaning strongly toward supporting ANS Forth.  But the
final decision will have to await the final standard!

Ray Duncan, LMI
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: comp.lang.forth
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Date: 26 Jan 93 14:16:06 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.

Penio Penev writes:
>
>I feel a bit confused what You mean by 'true compiler'. I suppose You
>mean something You pass a text stream to and it returns some kind of
>assembly or object. 
>
>What I ment is something completely different. I ment native coding,
>inlining and local (I think the term is peephole) optimisation.

I meant the same thing you did, an interactive Forth system that creates
native code (within the Forth environment) which is more than just
subroutine threading.  My (possibly unfounded) objection is that this
complicates the underlying Forth system to the point where you can no
longer change things on a very low level; in effect, the compiler is
sealed off from the user as with C or Pascal.  My feeling is that the
interactive system should be a simple and easy to understand as possible
and a full-blown compiler can be brought in later.  Or maybe just have
a special function that can be called to optimize the most recently
defined word into native code.  This would give the user a choice (HS/Forth
might do this, I think.)

>: More and more I'm discovering one of the reasons for Forth's lack
>: of popularity is that, while it doesn't have to be used solely for 
>: embedded systems, there isn't much support outside of that area.
>
>I guess this statment will be flamed by the FORTH vendors, who are
>suppose to 'support [products] outside of that area'.

I'm seriously hoping it will be.

--
James Hague   
exuhag@exu.ericsson.se
From: eaker@ukulele.crd.ge.com (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 25 Jan 93 20:14:04 GMT
Organization: GE Corporate R&D Center

In article <1993Jan23.115426.24547@sol.ctr.columbia.edu>, penev@venezia (Penio Penev) writes:
|> Mike Haas (mikeh@starnine.com) wrote:
|> : BTW, this idea of "inserting" a screen may apply to BigForth, but
|> : not in most of them.  In fact, it's those Forths that use
|> : screens-within-files that provide this capability.  And it's the
|> : fact that there's a FILE SYSTEM underneath that allows you to do this!
|> 
|> Well, the file system has nothing to do with it. When You insert a
|> screen You copy a block range one screen further. This You can do on
|> any BLOCK system. And text editors do the same. I've never seen an OS
|> function "isert bytes(blocks) at the file pointer". I know CPM, DOS &
|> UNIX. I may be wrong for the rest OSes.

You're right, the file system has nothing to do with it.
However, the insert commands in typical Forth block editors
usually cause a number of characters (equal to the number of
inserted characters) at the end of the line or the end of the
block to be discarded. This is not true of file based editors.
I don't especially care for this block editor behavior.
It's an implementation quirk that requires attention, and, in
the old days, often distracted me from the real work I was trying
to do. Running out of room on a block almost always required
shuffling the contents of blocks around to free up the next
sequential block to avoid fragmentation that would undoubtedly
proved to be another distraction later. This was time spent
not doing real work.

-- 
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
Newsgroups: comp.lang.forth
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: Re: FOR...NEXT in Eforth
Organization: MIND LINK! - British Columbia, Canada
Date: Wed, 27 Jan 1993 07:15:02 GMT

jvn@fermi.clas.Virginia.EDU (Julian V. Noble) writes:

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

<hand>  :)

> 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 don't really like any of those (which means they aren't the _right_
choice). How about a FOR...MORE loop?  Nah, MORE is too useful for other
uses.  Needs more thought.

--

Nick_Janow@mindlink.bc.ca
From: Interface!b0b@under.mind.ORG
Newsgroups: comp.lang.forth
Subject: Multiple modem controller
Date: 20 Jan 93 23:11:00 -0500
Organization: Interface BBS, 707-544-9661
X-newsreader: Fortress v1f-75

    We need to control 16 modems and a SCSI interface.  The data 
from the modems is to be sent via SCSI to a Unix host.  The bus is 
an ISA passive backplane. 
   
    Any recommendations for a controller card?  The people on the 
project are most comfortable with Intel 80x86 processors, but the 
programmer is pretty sharp and says he wouldn't mind doing it in 
Forth.  The device driver on the Unix side will be written in C, 
though. 
   
    As usual, development time is our primary concern. 
   
 --- 
    b0b@Interface.via.mind.ORG 

--
via Fortress Gateway at uumind.mind.ORG
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Forth's Adaptability
Date: Wed, 27 Jan 1993 07:50:24 GMT
Organization: StarNine Technologies, Inc.

In article <1993Jan21.152822.24631@exu.ericsson.se> exuhag@exu.ericsson.se writes:
>Chuck Eaker writes:
>>
>  Please feel free to hawk your products (I don't consider
>this commercial use of the Internet, just good information.)  

If you insist...   :-)

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

For the Amiga, JForth provides an ideal commercial software
development environment.  It allows complete access to all
Amiga shared libraries, even custom ones and they can be
developed in any language.  That means the entire width and breadth
of the AMiga's multitasking graphics, sound, I/O & system
libraries are available for games, multimedia tools...anything.

In the package, we include EZ-interfaces to Amiga menus, animation,
graphics, etc. etc.

Both normal motorola AND RPN assemblers are supported (the moto
assembler is simply built on top of the RPN one!).

JForth's CLONE facility will create small standalone versions
of your dictionary-compiled application.  These standalone
programs (they do not include ANY headers or unused JForth
code like the compiler, assemblers, debug code, etc..it all gets
stripped out) support both launching from the Amiga's Shell
via command line or double-clicking them from the Amiga's
GUI-based Workbench interface.  Typing in...

    : Hello   ." Hello, World!"  cr  ;

...and then CLONEing the worh HELLO will produce a
standalone Amiga executable of about 4.5K.  After,
if you type:

    hello<return>

...into the AMIGA SHELL (not JForth), the Amiga shell responds...

    Hello, World!

A source-level debugger with multiple breakpoints and many
other functions (including interactive access to the JForth
interpreter) is included.

I might mention that B.A.D. (a commercial hard-disk optimizer with
a beautiful GUI) is written in JForth and the developer
(MV Micros) tells us that B.A.D. is the best selling
commercial Amiga utility of all time!

Anyway, Forth CAN be implemented such that it provides a
WONDERFUL platform commercial application development
system, and I think most vendors try to put out such
products.

Unfortunately, the PD Forth image goes a long way to
wreck the "professional" image of Forth.  (Oh, oh, I really don't
mean to open ANOTHER can of worms!).

Here the SCR vs. FILES and PD vs. COMMERCIAL arguments merge...
the proliferation of Forths which provide only the minimum
may be great for a Forth hacker who wants to build his own
"thing" cheaply, but it is useless to the newcomer who
wonders how they use this new .EXE they just downloaded.

In other words, Forth gets more popular all the time...
with those who already like it!
From: bs764@cleveland.Freenet.Edu (Fred H Olson)
Newsgroups: comp.lang.forth
Subject: Forth stack checker
Date: 24 Jan 1993 21:36:57 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu


In his article Re: forth type checker" Chris Gray ponders an 
"offline checker" for stack depth.

I have developed such a tool and all of his comments - and many more
apply to it.  Which is to say that it is a rather "fussy" sort
of program with always one more "gotcha" waiting in the wings.
But that said, it does work for me and gives me a "browser tool"
for target code thrown in.  It still has some limitations that
I haven't eliminated yet - it doesn't yet handle new defining
words , it works with source code in blocks (oh oh better duck quick),
and the documentation after several reworks still could be better.
I'd very much like to have someone beta test it, but even that
will probably require some study of the implementation to
deal with the "gotcha" 's .  

My approach is to build a special purpose interpreter/compiler and hence
the source code becomes it's "input data" and it's hard to anticipate
all possible data permutaions that get thrown at it.

As a consequence I have dispaired of try to get it used more widely,
an am content to have a neat tool that I do use.

Fred Olson
-- 
Newsgroups: comp.lang.forth
From: penev@venezia (Penio Penev)
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Organization: Rockefeller University
Date: Tue, 26 Jan 1993 06:22:16 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

Anton Ertl (anton@mips.complang.tuwien.ac.at) wrote:
: 
: Note that just doing subroutine threading usually makes your system
: slower (than direct threading). You have to go native code, i.e., add
: inlining and optimization, to reap the benefits.
: 

Sure. And this allows You to inline a few instructions in a
time-critical portion by hand. (Yes, this is non-portable.)

--Penio.

Newsgroups: comp.lang.forth
From: penev@venezia (Penio Penev)
Subject: Re: Documenting
Organization: Rockefeller University
Date: Tue, 26 Jan 1993 06:02:31 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

Chuck Eaker (eaker@ukulele.crd.ge.com) wrote:
: However, the insert commands in typical Forth block editors
: usually cause a number of characters (equal to the number of
: inserted characters) at the end of the line or the end of the
: block to be discarded. This is not true of file based editors.
: I don't especially care for this block editor behavior.
: It's an implementation quirk that requires attention, and, in
: the old days, often distracted me from the real work I was trying

I avoid data loss by pressing the key for UNFLUSH, which copied the
current screen to a safe location (screen 0) and re-reads the block
from disk. I have rarely been unhappy about this.

: to do. Running out of room on a block almost always required
: shuffling the contents of blocks around to free up the next
: sequential block to avoid fragmentation that would undoubtedly
: proved to be another distraction later. This was time spent
: not doing real work.

Coping a range of blocks to a new location is pressing the key for
MoveBlocks and specifying three numbers. Less that 10 seconds work. On
a hard disk no other time counts. I've been wacthing myself using this
function. I do not use it every week. So the time spent in doing it is
negligible. If I counted this time, I'd also count the time for
logging into the machine and whatching the Window manager pop up all
windows.

Again, I do not say, that everybody must use blocks (or FORTH even). I
say that works fine for me. _Much_ finer, than text files (or C).

-- Penio.
Newsgroups: comp.lang.forth
From: esj@harvee.billerica.ma.us (Eric S Johansson)
Newsgroups: comp.lang.forth
Subject: Re: PHILOSOPHY & CM
Date: 26 Jan 93 02:25:44 GMT
Reply-To: esj@harvee.billerica.ma.us
Organization: gators 'r us
X-Software: HERMES GUS 1.10 Rev. Dec 23 1992
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <4271.UUL1.3#5129@willett.pgh.pa.us>, ForthNet articles from GEnie writes:
>Category 1,  Topic 12
>Message 12        Sat Jan 23, 1993
>L.ZETTEL [Len]               at 19:44 EST

> From SIGFORTh Neswletter Vol1 #2, p9:
>
> The harsh fact is that few people know what to do with a computer.  They 
> decide that running an operating system is a substitute for productive work.

from what I can tell, folks run news as a substitute for productive work.  
an os exists only to support news.

--- eric

p.s. :-)
-- 
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
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.forth
Subject: Re: Forth's Adaptability
Date: 22 Jan 93 13:18:46 GMT
	<1993Jan20.150614.20069@crd.ge.com> <1jk69lINNhjo@news.cerf.net>
Organization: Department of Computer Science, University of Manchester
In-reply-to: duncan@nic.cerf.net's message of 20 Jan 93 18:39:49 GMT

In article <1jk69lINNhjo@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes:
   It is a mistake to judge the "Forth community" by the public
   domain implementations of Forth.  People who insist on using
   public domain Forths and reinventing the wheel time after time
   get what they paid for.

Agreed, but :-

   [ LMI FORTH has files & blocks, floating point ... etc. ]

   they've [LMI users] had access to these capabilities, if they
   needed them, for many years.    

And I'm sure they are happy with them, but consider what happens if
they decide, for one reason or another, that they don't want to use
LMI FORTH anymore, but prefer to use a different vendor's system.
What are they to do with all the code they've developed using LMI
specific extensions?  Unless the "extensions" are either standard or
defacto standards then there may be significant effort involved in
changing the code, so much so you may have to stick with the system
you have even though you know you can get better/cheaper elsewhere
(I've suffered just this situation with large amounts of code written
using VAX FORTRAN + extensions).  This is good for vendors since it
keeps users locked into their system, but it is definitely not a good
deal for users.

bevan
Newsgroups: comp.lang.forth
From: John_Somerville@mindlink.bc.ca (John Somerville)
Subject: Re: Forth's Adaptability
Organization: MIND LINK! - British Columbia, Canada
Date: Mon, 25 Jan 1993 06:44:45 GMT

I write code in about eight languages. LMI Forth happens to be one of them. I
have also used several public domain Forths. I found the greatest portability
to be roughly in this order 1) ProlAWK, 3) BASIC) Basic. After that
portability becomes more and more mythical. I have found the public domain
Forths to be very incompatible. If you refer to Guy Kellys comparison of
several Forths in Forth Dimensions you will find some astounding differences.
The chief problem in porting from LMI to some of the other Forths is that
they don't conform to the 83 standard at all. In fact LMI may be the only
true blue 83 of the commercial Forths, and perhaps F83, (FPC?), of the public
domains.

Since I don't write C I can't comment, but I have heard complaints. The key
is I believe: find a good vendor and stick with them. Even then I've found
some vendors, will break your code. Borland for example left out overlays for
version 5.0 of Turbo Pascal.
--
john somerville B.C. Hydro
affiliations FIG Forth Interest Group