HDTenEightyP/NetNews huggingface dataset:
From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
Newsgroups: comp.lang.forth
Subject: Forth will Replace C
Summary: If Forth is ever done right C will go away.
Date: 5 Sep 92 15:02:56 GMT
Organization: /etc/organization

In article <BtIM7n.G7I@starnine.com> mikeh@starnine.com (Mike Haas) writes:
>In article <1992Aug12.213552.18782@crd.ge.com> eaker@ukulele.crd.ge.com writes:
>
>>...Elizabeth Rather's
>>recent posting nicely outlines the business considerations which
>>strongly suggest that ANSI figForth will not meet with the popularity
>>that C did despite its technical merits.
>
>Is there ANYONE who believes that Forth, ANSI or no, will attain
>the popularity that C has?
>
>If so, I've got this bridge...

   No I don't want to buy your bridge, but I do think that Forth will
attain the popularity of C. This doesn't seem to be possible right
now, but that is because Forth is in a very poor state of development.
And the ANSI effort isn't helping matters. The Forth vendors keep 
saying you have to pay to get a good Forth system, but they haven't been
able to sell Forth very well.
   All of us fanatic Forth users know Forth is much better than any C
compilier, but we can't convince C programmers. Seeing the advantage
of Forth takes too much effort on the part of beginners. An explanation
of a new algorithim gets shown in C even when Forth code would be easier 
to write. New computer systems come with C compiliers instead of Forth.
   But there are a few faint hopes for Forth. One person is publishing
articles and books that state Forth is best for scientific programming.
There is a Forth system hiding in the boot ROM of computers from a
major manufacturer. We keep writing network messages about how good Forth
is. There is a possibility that a single individual could write a new
Forth system that will be a surprise hit since it will make some very
complicated computing task very simple.
   The C programming language started out as a small project by a few
people and got to be big because it was the basis for a big operating
system. I don't think computing is always going to depend on that big
opertaing system and programming is not always going to depend on C.
If Forth programmers stop talking to each other and really try to
put Forth in a form that beginners can learn, new people will use it.
Current Forth systems are just not written well enough. Forth needs
more literary experts to improve every aspect of it, and the 
improvements need to produce simplicity, not the 300+ word list of
functions many Forth programmers seem to want. If it is easier to
learn and use Forth than C, which language will survive?
   But we are wasting our time worrying about C. What we really need
to do first is to get rid of non-Forth assemblers.
Newsgroups: comp.lang.forth,comp.lang.forth.mac
From: antero@csr.UVic.CA (Antero Taivalsaari)
Subject: Kevo
Originator: antero@csr
Organization: University of Victoria, Victoria, BC, Canada
Date: Tue, 15 Sep 92 01:51:24 GMT

The beta version of a new experimental prototype-based
object-oriented system Kevo (version 0.9b2) is now available 
by anonymous FTP from: 

	ursamajor.uvic.ca (128.189.88.151)
	directory: /ursa/kevo

Although the Kevo system has been built to experiment with
ideas which are somewhat irrelevant from the viewpoint of Forth,
the system does bear some resemblance to Forth; in particular,
the system executes indirect threaded code, and a great deal of 
the primitives are similar to those of Forth's. 

Kevo runs currently on Macintoshes (with 68020 or later). System 7
is recommended, although there should be no problems with older
Mac OS versions with Multifinder. Kevo creates a lot of windows,
so a large screen is needed.

The FTP directory contains the (binhexed and compressed) executable, 
some demo programs, a user's guide, and a few papers about the system. 

The Kevo system is a research work which is provided 'as is' without 
any warranties or visible support. For further information, send 
comments and questions to: kevo-interest@ursamajor.uvic.ca.

-- Antero Taivalsaari
   antero@csr.uvic.ca

Newsgroups: comp.lang.forth
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Block versus file
Organization: Motorola Codex, Canton, Massachusetts
Date: Tue, 15 Sep 1992 20:36:38 GMT

pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:

>Well, I have thougth quite a long time about the screen vs. stream
>problem. I do not agree withsome of David's points.

>DK>Any block structure imposed artificially on the
>DK>top of the file system will be SLOWER than fully utilizing the
>DK>file system.

>Almost every file system HAS a block structure below it, and in many
>cases, blocks are a 2^n bytes chunck with n integer and n<=10.  So reading
>a Forth block (1K) is straigt forward, unbufferd and faster than
>arbitrary reading (while "arbitrary" means: less than block size).

The concept of buffered I/O has been known for a long time. Forth doesn't
have a monopoly on it. However, the natural read size for most file 
systems that I know of is more in the range of 4K-8K. A reasonable 
interface to the host filesystem will let you read arbitrary blocks,
where arbitrary means any size you can specify.

> Even
>for my stream file interface I read and write blocks of 2^n bytes (where
>n depends on what I found useful). 

I'm glad to see that you discovered buffering, too.

>With scanning for line ends stream
>file interpretation is SLOWER than block file interpretation, although
>less blocks are to read.

It's nice to know that your parser is slower on one file type than
another. That really doesn't tell us much about file I/O performance.

How about creating a benchmark? Create a large file - say a meg or so -
and read it into program buffers either (1) Forth block by Forth block,
or (2) by using sequential file read commands with a reasonable buffer
size, such as 16K. Both are going to translate to the same file system
requests - the only difference is that the buffer size is going to be
more reasonable in case (2).

				Peter Desnoyers
--
From: dmiller@im.lcs.mit.edu (Dick and Jill Miller)
Newsgroups: comp.lang.forth
Subject: FORTH AT BUSCON IN BOSTON THIS WEEK
Date: 15 Sep 1992 09:04:28 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

  --------------------------------------------------------------------
  FORTH EXHIBIT BOOTH (#911) AT BUSCON/BOSTON, TUES.-THURS. THIS WEEK!
  --------------------------------------------------------------------
 
Boston FIG is taking Forth to BUSCON!  That's the major board-level 
computer show in the USA, and this week it's making its every-second-year 
visit to Boston, Massachusetts.
 
Tell your friends in the area to come on down to BUSCON, Booth 911, to say 
hello.  If they have been waiting to see Forth in action, this is the 
place.  Boston FIG will be demonstrating its own Least Common Robot Project 
-- teaching a robot to listen in English, from the bottom up (and from the 
top down).  If they know Forth, they'll be invited to help our own 
volunteers demystify Forth for others.
 
ADMISSION IS FREE to all exhibits.  Be sure your Boston-area friends don't 
miss this Forth event!  Hours are 10-5 today and Wednesday, 10-4 on 
Thursday.  BUSCON-EAST/'92 is at the Hynes Convention Center in Boston's 
Prudential Center.
 
A. Richard & Jill A. Miller            | Miller Microcomputer Services |
InterNet: dmiller@im.lcs.mit.edu       | 61 Lake Shore Road            |
Voice: 508/653-6136, 9am-9pm EasternTZ | Natick, MA 01760-2099, USA    |
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Free Forth
Date: 8 Sep 92 16:52:07 GMT
Organization: EIEI-U

In article <1992Sep5.151245.18215@mintaka.lcs.mit.edu>
	mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:

+In article <BtCvML.Lzu@starnine.com> mikeh@starnine.com (Mike Haas) writes:
+>
+>The trend is more & more memory in the machine, so what do I care
+>if a Forth takes up 100k or 500k if I have Megs to work with?
+>

+   A small Forth fits in a human mind better than a big one. You can
+do more with a system that you understand very well than you can with
+a big system that you don't understand. Forth works very well in a
+small space since it uses a few good ideas put together in a clever
+way. It is a much better way to do things than filling up all
+available memory with more code than a single person can comprehend.

I almost agree with that sentiment.  There is a difference between size and
(in)comprehensibility though.  I think the real issue is organization.  Is a
Forth whose WORDS prints 70 words easier to understand than a Forth whose
WORDS prints 300+?  From that statistic alone an answer is impossible.
WORDS is not a structured/organized way to look at the dictionar(y,ies).

I do not want a tiny Forth that I can understand, but which I have to
completely reimplement the wheel in order to get host file system access,
floating point support, string package support, etc.

I do not want a humongous Forth that has everything including the kitchen
sink thrown in, all in one big incomprehensible glop.

I do want a Forth that is cleanly implemented, can meta compile itself with
minimal fuss, and has loadable (either source or precompiled with source
available) packages for common functionality.o

I do want Forth implementations that conform to and present a portable
interface to common functionality, so that I can convert a Forth program
written on a Unix Box to a PC, MacIntosh, Amiga, etc., with minimal (if any)
headaches.

I do want Forth implementations that permit me to control resource usage
through the control of packaged "add ons".  The "Packaged Add Ons" should
have documented interfaces, so that if one "add on" requires the use of
another "add on", I have the liberty (but not requirement!) to provide
my own alternative and not have to worry about undocumented side effecting
communication channels, etc.

-Doug
---
Preferred:  dwp@willett.pgh.pa.us	Ok:  {pitt,sei}!willett!dwp
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Data types
Date: 4 Sep 92 11:20:52 GMT
Organization: EIEI-U

Category 10,  Topic 29
Message 17        Fri Sep 04, 1992
B.DUNN5 [Brian]              at 02:19 EDT
 
  I would like to make a portable structure/array package.  In order to hide
the names of the fields of a structure, a structure definition would declare a
vocabulary and place the field names inside that. Instances of that structure
would have to activate that vocabulary at compile time, and pointers could be
type cast by explicitly naming that vocabulary in the source code to cause the
field names to become visible.

If a structure is a field inside another structure, the source could be:
  ( ... define some fields ... )
  name1  structure:  name2   \ name1 is previous struct, name2 is fieldname
  ( ... define more fields ... )

When the structure NAME1 was previously defined, its final size was stored
somewhere in the data area for NAME1.  On a typical Forth-83 system this might
be just after the threads and voc-link in the vocabulary which is called
NAME1.  Thus, NAME1 would be an immediate vocabulary with one extra cell of
information in its data area.

At compile time, NAME1 would cause the vocabulary associated with its
structure to become active.  STRUCTURE: would have to look at the context
vocabulary and compute from that the location where NAME1 stored its final
length, so that STRUCTURE: knows how large the field NAME2 must be.

With ANS-Forth:

1) Is there a portable way to create the functionality where NAME1 activates a
wordlist and also has a known location to store its length?

2) Can other words take the top wordlist and compute (portably) where the
length is stored?

-----
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: 1 Sep 92 11:08:11 GMT
Organization: EIEI-U

Category 10,  Topic 33
Message 16        Mon Aug 31, 1992
E.RATHER [Elizabeth]         at 23:56 EDT
 
Chris Waters writes: >Well, personally, I'd rather see something more like the
PACKAGE >feature of Modula II.  But that might be overkill for Forth.  :-)

We've done some experimenting with packages at FORTH, Inc, and use them in our
Express product.  They seem promising for large, multi- programmer projects
(which we do some of), but definitely overkill (meaning in the way) for small
jobs.
-----
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: 4 Sep 92 11:20:45 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 84        Thu Sep 03, 1992
ELLIOTT.C                    at 12:07 EDT
 
 -----via CRS Premium Bulletin Board

 Date: 08-29-92 (03:09)
   To: B.RODRIGUEZ2 [BRAD]
 From: MARCEL HENDRIX
 Subj: Cross-CompilingOR ROMABIL

 Brad Rodriguez writes about ANS Forth Translators:

 br>       definitions.  As a minimum, the words
 br>        :  ALLOT  CONSTANT  CREATE  IMMEDIATE  VARIABLE
 br>       from the Core word set must be available
 interpretively
 br>       to create Forth programs.  The arithmetic and stack
 br>       operators, and such words as
 br>        '  ,  C,

 The idea is very good, I particularly like the master stroke to
 differentiate between cross-compiling and translating.

 I'm not sure if you're proposal includes meta-compilation, that
 is, generating a complete working Forth interpreter for cpu a on
 platform b, using a xx Forth program running on cpu t on
 platform u.

 The process of meta compilation needs the ability to manipulate
 headers of both host and target words. Your proposals do not
 mention headers anywhere, so maybe a ``cross-compiler'' just
 generates a executable program for any hardware? (but note that
 this might include an outer interpreter and thus could need
 headers).

 I'm positively terrified that names like C, : ; become
 officially accepted as *meta* compilation word names. A meta
 ``:'' is completely different in concept from the host Forth
 ``:'' and the programmer should never (want) to forget this
 (He'll need both in a truly universal system). In t/iForth we
 use TC, T: and T; (among others), but at least two other meta
 compilers adopt a similar convention (F83, F-PC).

 An ordinary user will expect a Translator to let her build a
 completely new Forth system of her own design (why not?) but as
 soon as she starts defining : ; for the new system, she'll get
 dreadful conceptual problems (most users *I* know anyway).

 The problem can be resolved if it is officially stated that an
 ANS Forth System is not required to be able to completely
 regenerate itself. The translator need then not support the
 above features. Of course the last three lines should be a joke.

 Marcel Hendrix,
 Dutch Transputer Forth Workshop

 PCRelay:OLEF -> #181 RelayNet (tm)
 4.11            OLEF BBS London England. +(44)-81-882-7353


-----
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: karna@pobox.upenn.edu (Animesh Karna)
Newsgroups: comp.lang.forth
Subject: 386-specific Forth
Date: 16 Sep 92 02:17:05 GMT
Organization: University of Pennsylvania


Does anyone know of a reeeeeeeallllly cheap (or free) Forth for 386 protected
mode?  Thanks!
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for ROMability
Date: 6 Sep 92 13:07:24 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 85        Sat Sep 05, 1992
B.RODRIGUEZ2 [Brad]          at 10:12 EDT
 
Marcel Hendrix writes:
 > I'm positively terrified that names like C, : ; become officially
 > accepted as *meta* compilation word names.  A meta ``:'' is
 > completely different in concept from the host Forth ``:'' and the
 > programmer should never (want) to forget this.

Thanks for the many kind comments, but I'm afraid I disagree with you here. 
I've always disliked T: T; and such.  My attitude is that the programmer
should not need to know if he is writing for a resident or a metacompiled
environment (with the possible exception of certain compiler directives such
as ORG).  At least five metacompilers that I've used (polyForth, LMI, MPE,
Pygmy, and my own) have no problem using ``:'' for target words.

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
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: An Open ANSI Forth Implementation
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 15 Sep 1992 09:02:58 GMT

In article <4057.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
|> Category 10,  Topic 41
|> Message 90        Mon Sep 14, 1992
|> B.DUNN5 [Brian]              at 01:50 EDT
|>  
|> ... meanwhile, how is this ANS-FIG Forth coming along?  What machines do you
|> have it running on so far?

Well, I have implemented most of the primitives of BASIS 15. Since C
is portable, I have been generous with what I classify as primitive -
we currently have 193 (including things like '>=' that are not in BASIS
15).

The primitives compile to quite decent assembly code. We don't have a
main() yet, so it does not yet run anywhere, but it compiles on
DecStations and Apollo's and is easy to port to machines that run
gcc-2.x.

We have also a lot of ideas about the system architecture. One of them
is the question of whether to have indirect threaded code or allow
both direct or indirect threaded systems. What do you think - as users
(We care for the implementation)? We would give you words to
manipulate, what would be the code field in an indirect threaded
system.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for ROMability
Date: 2 Sep 92 11:43:38 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 83        Tue Sep 01, 1992
L.ZETTEL [Len]               at 21:01 EDT
 
 Disclaimer: What follows is necessarily individual opinion because the 
 committee hasn't issued am official position yet.

 First, I call your attention to the following:
      *     *     *
 2.0130 compilation
        The process of transforming source code into definitions in the 
 dictionary.
      *     *     *
 After thinking hard about the matter, the only answer I can give to the 
 question "Can there be ANS Forth cross-compilers?"  is a firm, 
 unequivocal, "it depends".

 It depends on the answer to two questions:

 1) Is the target system (apologies, Elizabeth) necessarily part of the 
 ANS Forth system during the process of cross-compilation?

 2) Must the words in the target system dictionary be treated on an equal 
 footing with words in the host ANS Forth system dictionary during the 
 process of cross-compilation?

 If the answer to these questions is yes, I cheerfully predict the answer 
 X3J14 will give to the question (and the only sensible answer it can give 
 under the circumstances) will boil down to "The answer to that question 
 is beyond the scope of the standard, so we decline to answer at this 
 time."

 On the other hand, if due to the iron whim of the marketing department or 
 an unbreakable geas from the elder gods of hackerdom, I felt an 
 overwhelming urge to produce something I could call an ANS Forth standard 
 system with a cross-compiler, I would argue (and build) as follows:

 1) The target system is NOT part of the standard forth system, but 
 something the standard system communicates with.

 2) The target dictionary is a data structure whose words, at the time of 
 cross-compilation, do not necessarily follow the same rules for search 
 and findability as words in the Standard Forth System dictionary.  Thus, 
 while the target dictionary may be in the dictionary in the same sense an 
 array or text string might be in the dictionary, the words in it might be 
 no more findable than the words in a text string.

 Given that, I can conceive of the possibility of building something that 
 could be called an ANS Standard Forth System with a non-standard 
 extension that would cross-compile.

 And that's where I stand for now.  I really do hope this helps.
                       -LenZ- 
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Newsgroups: comp.lang.forth
Subject: Re: Sampler Forth
Date: 11 Sep 92 07:23:45 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

alan@tree.UUCP (Alan) writes:

>+ Error resistance and compiler security.  Range checking for EXECUTE  !
>+ "store", C!, MOVE, and CMOVE etc.
> 
> This is something which seems so obvious -- but I've never before seen it
> suggested on the net.  Forth people like to argue things like "but range
> checking will slow Forth down" and "if you properly factor and use the stack
> you don't need range checking".

A local Forth'er (Dan Phillips) has a Forth development system (Nirvana) nearly
ready for release (I think he's sold a few copies locally), and he has range
checking and other security features.  He says it runs fast even with the
security features turned on.

> (a) Forth is NEVER  going to be the fastest executing language.

That's not necessarily true.  If Forth had the support C has, it would also
have nice systems with Forth CPUs, and I think for equal investment in hardware
and programming time, the application in Forth would run a lot faster.

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.lang.forth
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Sampler Forth
Organization: Motorola Codex, Canton, Massachusetts
Date: Tue, 15 Sep 1992 20:49:24 GMT

toma@sail.LABS.TEK.COM (Tom Almy) writes:

>Likewise, I've been compiling Forth since 1982. Compiled Forth has always
>had an execution speed and code size edge over C, that is only narrowing now
>because the C compilers are finally getting sophisticated. (It is much
>easier to optimize a Forth compiler)

It's nice that you can optimize a compiler, but can you optimize a
program? Are there any Forth compilers out there that will do constant
folding, find loop invariants, or even do simple peephole optimization?
I've heard something about the RTX people at Harris doing a bit of
work on optimization before they disbanded, but I don't know any details.

				Peter Desnoyers
--