HDTenEightyP/NetNews huggingface dataset:
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 21 Jan 93 17:15:38 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.

Andrew Haley writes:
>
>I asked him about that a few weeks ago.

Thanks for posting this, Andrew.  This is interesting stuff.

>Chuck's environment has never stood still.  He's been refining it and
>making it simpler and simpler for what he wants to do. 
>
>Chuck has always been willing to throw away
>anything in Forth which isn't ideal for the job at hand; what we might
>recognize as "classical Forth" is microFORTH, circa 1978.  He's been
>changing things ever since. 

I suspected as much.  He sounds like a true user of the language, not
someone just interested in making a fancy, asthetically pleasing tool
for it's own sake.  Arguing over various improvements is a waste of
time when you can simply implement them and get on with your work,
especially since this is the whole point of Forth.  I am curious if
he has developed the entire Forth system he uses from scratch, or if
he is building on another product (polyForth?).

>However, Chuck did write a paper on the origin of Forth for the
>upcoming History Of Programming Languages conference, but it was
>rejected because it was "too informal."  I don't know if the paper
>will be published elsewhere.

Sounds like something that would be well received.  I hope he will
consider attempting to get it published or at least distributing it
himself.  (Too informal?  Good grief.)

--
James Hague   
exuhag@exu.ericsson.se
Newsgroups: comp.lang.forth
From: jvn@fermi.clas.Virginia.EDU (Julian V. Noble)
Subject: Re: Documenting
Organization: University of Virginia
Date: Fri, 22 Jan 1993 23:21:44 GMT

Review of HS/Forth

I have used HS/Forth since version 1.x, which I acquired sometime
in 1984. It has grown to be a very complete system with all sorts of
utilities, libraries, etc. included. A late version (that I have not
yet tried) includes a DOS extender and can therefore address a 32-bit
flat memory space with reasonable speed (i.e. not swapping it in and out
of 64K buffers below in the top of the first 1 Meg).

Although I have not personally done any of this, Callahan provides
interfaces to C and other compiled programs. This lets you use
commercial C libraries, e.g., for graphics, etc.

Finally, most of the kernel (code primitives) is very slick and semi-
optimized. Ex: the BX register is used as TOS, hence @ is just
	CODE  @   BX [BX] MOV.  END-CODE
Note also that Callahan does the obvious, incorporating NEXT in
END-CODE. I was a bit surprised to see fairly recent Forths that do
not do this.

Although the user interface is not as slick as F-PC's, and probably much
less so than WinForth (which I have only heard, not seen), it is per-
fectly adequate. I use Sidekick in TSR mode to edit and recompile, 
rather than the built-in tiny editor, but the latter can be used with
the DOS append command almost as well.

HS/Forth provides good debugging, single-step tracing, decompiling and
optimizing tools, making for rapid program development.

Finally, HS/Forth is the language used in developing the routines in my
book.  Nuff said. --jvn
~F
From: nick@sw.stratus.com (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Forth and Adaptation
Date: 26 Jan 93 14:47:41 GMT
Organization: Stratus Computer, Inc.
NNTP-Posting-Host: kyron.sw.stratus.com

hamish@sybase.com (Just Another Deckchair on the Titanic) writes:
> 
> Even more important is the ability to let the vendors do as much of
> your work as possible - why reinvent the wheel? If a system supplies a
> set of networking and (say) windowing functions as a C library or C++
> or Smalltalk class hierarchy, you should just plug into these for the
> services (and generally can in any of the languages I work with).

Mitch Bradley once quoted Charles Moore with saying that he (Chuck,) would
never consider using Unix, because most of the tools that exist on it are
not up to his standard of efficiency.  He would rather rewrite the ones he
needed.  This philosophy seems to permeate the Forth programming world.
Kevin Haddock [to which the above paragraph was replying,] seems to have
implied as much about himself.

Charles Moore said he invented Forth because he wanted to increase his
productivity, measured in programs written per lifetime by a factor of
10.  Forth seems to be a good tool to do this with,  but I hope he was
not counting rewriting existing tools in his goal.

								/nt
From: eaker@ukulele.crd.ge.com (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: CASE tools
Date: 21 Jan 93 15:37:46 GMT
Organization: GE Corporate R&D Center

In article <1jl4guINN4c4@usenet.INS.CWRU.Edu>, cq184@cleveland.Freenet.Edu (Spencer W. Hunter) writes:
|> ...
|> In his book, Martin outlines a CASE methodology, known as HOS,
|> wherein programs are constructed top-down and the compiler
|> statically verifies the validity of each control structure
|> through I/O analysis.  In contrast, traditional Forth programs
|> are mostly constructed bottom-up and the programmer is
|> responsible for dynamically testing individual routines for
|> correctness.  However, like good Forth, each HOS routine has only
|> one main control structure; this is an inevitable result of the
|> rigidity of the compiler.

I don't agree that the traditional Forth development approach
is bottom-up. This is certainly not the approach illustrated
in Brodie's _Thinking_Forth_.

|> What does the Forth community think not only about the above, but
|> of CASE tools in general?  Enquiring minds want to know!

I think it's an interesting application area. What the world
needs is more and better ways to model and simulate an
application's requirements, do various kinds of analyses on
the model, then generate code for specific platforms in ways
that yield implementations provably equivalent to the model.

It seems to me that what you have goes the other way: a
language which is used to model implementations (i.e., Forth
code must be translated into the modeling language) so that
analysis will show them to be correct. But in this case I'm
not sure what "correct" means?

-- 
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Subject: Re: forth type checker
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Thu, 21 Jan 1993 08:23:04 GMT

In article <1993Jan20.183012.1078@csi.uottawa.ca>,
cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
|> In article <1993Jan20.093607.20349@email.tuwien.ac.at>
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

[on strongly/weakly typed]
|> >I agree. Therefore I advocate not using them at all.
|> 
|> I mildly disagree: "strong" tends to refer to systems that attempt to
|> forbid the type errors; the fact that they aren't PERFECTLY strong
|> doesn't deny the ATTEMPT.  "Weakly" typed languages tend either to
|> either enforce few or no type errors.

That would be alright, if the terms were used with these meanings.
Unfortunately they aren't. Pascal, which (as usually implemented) has
holes in it's type system, is usually called strongly typed, whereas
Lisp, which has no holes, is usually called weakly typed (and some
people even call it untyped).

[on the variant record hole in most Pascal implementations]
|> This special exception doesn't deny the fact that Pascal's compile
|> time type checking is normally rather strong.  You have to do
|> something fairly special to be able to ignore type checking in Pascal.

I would not call variant records "something fairly special". They are
present in every significant program. And once you have them, you just
have to, e.g., remember the wrong field name and, voila, there's your
uncaught type error.

- 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
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting
Date: Fri, 22 Jan 1993 01:03:53 GMT
Organization: StarNine Technologies, Inc.

In article <4262.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>Category 3,  Topic 3
>Message 69        Sun Jan 17, 1993
>L.ZETTEL [Len]               at 17:11 EST
> 
>> From: starnine.com!mikeh   (Mike Hass) > Subject: Re: Documenting > Date: 13
>Jan 1993  4:06 am GMT > Room: comp.lang.forth > Organization: StarNine
>Technologies, Inc.
>
>> It is nuts to suggest that blocks were implemented because they were
>>thought superior to text files and to do so is rewriting history.
>
>Damnit!  This piece of ignorant arrogance is finally too much!  I have had
>personal conversations with Chuck Moore in which he explained at length why
>blocks were the only rational way to do mass storage on disks.

Of course they are... and that's the way Operating systems do it.
But they relieve the applications from having to deal with them in this way.

Besides, Chuck has always been notorious for implementing what HE needs...
he is not usually concerned with GENERAL programming practices.

One look at the three-key keyboard and Novix chip should tell you that.

>
>Based on much other personal contact, I suspect the only way you will get
>blocks away from Forth, Inc. is to pry them from their cold, dead fingers (and
>they sell some  systems that run under DOS).

I know.  That's why this discussion is so much fun.

>
>Myself, I can see merits on both sides of the argument.  It depends on your
>priorities,  your experience, and the facilities you have available.

AAARRRGHH!  What arrogant ignorance!
From: fish@ecst.csuchico.edu (Kevin Haddock)
Newsgroups: comp.lang.forth
Subject: Re: Multiple modem controller
Date: 28 Jan 93 21:22:05 GMT
Organization: California State University, Chico
NNTP-Posting-Host: cscihp.ecst.csuchico.edu

In article <2440751@under.mind.ORG> Interface!b0b@under.mind.ORG writes:
>    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. 
>   

Doesn't Galactacom (sp?) produce such a board that goes direct into
the ISA?  I think they have Unix drivers to boot.

-Kevin
fish@cscihp.ecst.csuchico.edu

-------
There are no complex problems; only complex solutions!
-------
Bureaucracy:  The process of turning energy into solid waste.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.forth
Subject: Re: Forth's Adaptability
Date: 26 Jan 93 10:25:55 GMT
	<BEVAN.93Jan22131846@panda.cs.man.ac.uk> <1jqe2lINNiv8@news.cerf.net>
Organization: Department of Computer Science, University of Manchester
In-reply-to: duncan@nic.cerf.net's message of 23 Jan 93 03:29:25 GMT

In article <1jqe2lINNiv8@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes:
   In article <BEVAN.93Jan22131846@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
   >In article <1jk69lINNhjo@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes:
   >   [ LMI FORTH has files & blocks, floating point ... etc. ]
   >   they've [LMI users] had access to these capabilities, if they
   >   needed them, for many years.    
   >
   [ fine, but unless these features become standard, your programs
     are forever tied to one FORTH system ]

   I must admit I don't quite see your point.

Well I must admit I don't understand how you don't see the point :-)  So,
all I can do is reword what I've already written :-

If you write embedded code, or are otherwise not worried about
portability you are free to use whatever features of your FORTH system
you want.  However, if you are worried about portability, using said
extensions ties you to that system until (if ever) those extensions
become standard or a defacto standard.

bevan
Newsgroups: comp.lang.forth
From: gcouger@olesun.okstate.edu (Gordon Couger)
Subject: Re: Forth for robotic control?
Organization: Oklahoma State University, Stillwater
Date: Sun, 24 Jan 1993 01:49:05 GMT

In article <1993Jan22.101526.1027@cucs5.cs.cuhk.hk> skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant)) writes:
>Currently, I am preparing a robotic lab for undergraduate students.
>I am not familiar with forth, I learnt it briefly ten years ago.  I
>remember at that time, someone had proposed to use it in controlling
>robot.
>
>I am developing a hypercard stack (in Macintosh) for teaching elementary
>concepts on robotic.  It is intended for use in an undergraduate course
>in our faculty.  It will include instructions in dealing with the
>ESHED ROBOTEC's ER5 & ER7 robot arm.  If it succeeded, I will post it
>to the public.
>
Having designed and built both hardware and software for a robot for a
sophomore levelclass for non-technical agriculture majors; I believe that 
FORTH would be a very good language for teaching robotics. The way I
 did it was to use a $2000.00 Acro connected to a PC  and the robot. 
I wrote a Basic program that ran on the Acro  that ran the pump, read 
the sensors and turned the stepper motor. I wrote a basic like language 
in C that ran on  the PC and sent commands to the Acro. The robots
 (20 of the little buggers) have eight sensors (Photo Transistors) a stepper
 motor and a water pump form a battery powered water gun.  It finds a 
beaker then finds the other side backs up an fills the beaker. The 
programming took over a month.

If I were to do this project over I would use 68hc11 board from New 
Micros in Dallas that has an onboard FORTH interpreter and let them
 use FORTH it might be a little left handed for the technically deprived 
but no more than any other computer language.The boards cost less 
than $100.00.

One mans opinion
Good luck
Gordon

Gordon Couger
AB5Dg   Agriculture Engineering Oklahoma State University
gcouger@olesun.agen.okstate.edu 405-744-6514 day 744-2794 evenings   
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Forth's Adaptability
Date: Sat, 23 Jan 1993 03:42:47 GMT
Organization: StarNine Technologies, Inc.

In article <1993Jan19.202421.14156@crd.ge.com> eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
>In article <1993Jan19.085827.18730@Informatik.TU-Muenchen.DE>, pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
>|> In article <1993Jan18.163733.19857@crd.ge.com>, eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
>|> |> ...                                        C is less
>|> |> flexible? In what sense? ... Use a memory heap if you want.
>|>
>|> Show me the C library with a real dynamic memory management that
>|> prevents splitting the available memory until you can't get any
>|> more without paging. Don't tell me "I always include half of the
>|> GNU emacs project to have this".
>
>The fact that there are implementations of C with inefficient
>dynamic memory packages is not a reason to reject C in favor
>of Forth. That fact that virtually every implementation of C
>comes with a rather standard dynamic memory management package
>and has for years whereas there is as yet no such Forth standard
>is a good reason for rejecting Forth in favor of C.

Not to mention that one of the jobs of a good OS is to hide the
details of dynamic memory management from the application, which
fundamentally only needs to allocate & free memory.

An application should not have to worry about fragmenting, swap
files, "splitting memory"...only whether it's memory request was
completed successfully or not.


>
>Competitive pressures in the software industry are making it
>more and more difficult for us to spend time climbing up
>learning curves. And those pressures will be getting worse
>very quickly. That's the main reason why a comprehensive
>standard is so important.
>
>I would much rather use Forth in my work, but I can't afford
>to take the time to implement all the missing pieces or search
>for them in other people's work and port them into my environment.

Chuck, I think you have stated the needs of the average professional
computer user well.   Many in the Forth community seemed satisfied
with Forth as it was 15 years or more ago...and it hasn't substantially
changed.  Perhaps their needs haven't changed much in that time, and that;s
all well and good.  But there is so much resistance to introducing
concepts that are now fairly standard in the rest of the computing
universe that I have grown quite doubtful that Forth will succeed in
the popular sense.

Forth believers, IMHO, are today looked at in the same way as
those that exclusively use BASIC, Commodore 64's, CP/M, etc.
It's viewed as old technology that has failed to adapt.
>
>-- 
>Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
>eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
From: eaker@ukulele.crd.ge.com (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Date: 27 Jan 93 16:15:20 GMT
Article-I.D.: crd.1993Jan27.161520.15484
Organization: GE Corporate R&D Center

In article <1k42ueINNj90@news.cerf.net>, duncan@nic.cerf.net (Ray Duncan) writes:
|> The Forth community can't have it both ways. It can't have free
|> Forth everywhere with complete access to source code and rapid 
|> evolution to support all the latest FORML coding fads-du-jour,
|> and still have vendors investing serious time in bringing Forth
|> up on new processors, providing stable programming interfaces
|> over a period of many years, developing extensive printed documentation,
|> and deploying man(woman)power to technical support services.  As
|> far as I know, all the vendors that are still in business are 
|> selling Forth development environments really as a sideline, and
|> paying the bills some other way (consulting, hardware development,
|> whatever). 
|> 
|> It's certainly been clear to me from lurking in this newsgroup for
|> months that *this* sector of the Forth community, although it
|> prides itself on being a center of Forth expertise, has no clue
|> whatsoever as to what the Forth vendors (Forth Inc., LMI, 
|> Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
|> or the capabilities of their systems.  Thus, newcomers to Forth,
|> who come here for advice, are being steered to EFORTH, FPC, and
|> other undocumented unstable unsupported public domain Forth systems
|> as "solutions."  No wonder Forth is in decline!
|> 
|> Harsh words, perhaps, and certainly a vendor-centric viewpoint, but
|> a viewpoint that has received little attention here.
|> 
|> Ray Duncan, LMI

Harsh, indeed. But squarely on target and long over-due.

Actually, Forth expertise is rarely exercised in this group. 
Calls for help are a small proportion of the traffic and are
usually asked and answered within a particular implementation
the details of which are beyond the expertise of many of us.
Very little code is shared because very little of it can be
used as is by most of us.

The reason for this, I think, is the lack of standards. Too many
holes in the 83 standard have been plugged by too many
implementations (both PD and commercial) in too many ways to
make much *really* useful code shareable. It was my hope that
the forthcoming standard would change this, but I'm no longer
sure of this because of the financial weakness of Forth vendors
and the softness of the Forth market.

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?

-- 
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
From: bs764@cleveland.Freenet.Edu (Fred H Olson)
Newsgroups: comp.lang.forth
Subject: Re: Forth stack checker
Date: 25 Jan 1993 12:56:52 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu



cbbrowne says:
"CREATE/DOES is going to be some of the words that would make such an
interpreter "throw its hands up in despair."

Well, dont let me give the wrong impression.  My stack checker 
works fine for me and I'm confident that I can implement most
defining words since my standalone browser database generator
works similarly and implements them. It's just that I haven't
gotten it done 

Fred go comp.lang.forth
--
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: comp.lang.forth
Subject: Re: uP21
Date: 25 Jan 93 09:31:48 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

Nick Janow (Nick_Janow@mindlink.bc.ca) wrote:
: ahaley@eoe.co.uk (Andrew Haley) writes:
: 
: > He's [Chuck] much more inclined to spend time working on the
: > uP21, his new processor.
: 
: uP21?  What happened to the uP20?
: 
: Is he never going to actually release a processor for commercial
: use?

He already has!  Don't forget about the NC4000...

If someone today is to produce a new microprocessor, embodying radical
ideas about computer architecture, it mustn't just be better, but many
times better.  That's why the new chip is needed; it's a 100 MIP, low
power, fully asynchronous (self timed) processor on a 0.1 inch square
die.  It connects directly to commodity memories with very little glue
logic, so makes for potentially very cheap systems.

The rest of the semiconductor industry is looking for ways to use more
transistors; Chuck wants to use less transistors.  The industry is
getting increasingly entrenched.  Even if someone comes up with
something that's faster and cheaper there's a tremendous amount of
inertia to overcome.  After all, designers have been using Intel parts
for years, why should they change?  What would really get things going
is a customer who needs millions of processors, for a product which
couldn't be done with a more conventional design.  Any ideas, anyone?

Andrew.
From: cq184@cleveland.Freenet.Edu (Spencer W. Hunter)
Newsgroups: comp.lang.forth
Subject: Re: CASE tools
Date: 28 Jan 1993 10:29:21 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu


mikeh@starnine.com (Mike Haas) writes:
 
>Yes, one of the strong advantages I remember when I first came
>to know Forth was that is was touted as promoting top-down
>programming techniques due to it's extremely modular
>architecture.
 
: _THIS ." This " ;
: _IS ." is  " ;
: _BOTTOM ." bottom-" ;
: _UP ." up." ;
 
: MAIN_PROGRAM  _THIS _IS _BOTTOM _UP ;
\ Main program is constructed from previously-defined words.
 
Forth may be _designed_ top-down, but it's usually
_constructed_ bottom-up.  My implementation of the HOS compiler
_begins_ with the main program declaration, and then proceeds
to define what it will do through a successive breaking-down of
functions which the compiler checks for correctness.  By
correctness, I mean that the control stuctures used are
logically correct (yes, I know Forthies never make logic errors,
but _I_ do, and they're often the trickiest bugs to track down).
-- 
+-------------------------------------+----------------------------------+
| Spencer W. Hunter  Tucson, Arizona  |  Veni, Vidi, Vamos.              |
| Internet: shunter@ccit.arizona.edu  |  They came, They saw, They left. |
+-------------------------------------+----------------------------------+
Newsgroups: comp.lang.forth