HDTenEightyP/NetNews huggingface dataset:
From: mikeh@starnine.com (Mike Haas)
Subject: Re: CASE tools
Date: Thu, 28 Jan 1993 02:23:36 GMT
Organization: StarNine Technologies, Inc.

In article <1993Jan21.153746.2948@crd.ge.com> eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
>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_.

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.

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

There is a growing awareness, however, that engineers increasingly
fails due to their reliance on such simulations.  It must be
remembered that simulations are only as good as the programmer(s)
that created them...there is a tendency to over-estimate how
accurately these model reality.

Invention magazine had an extremely interesting article in their
last issue RE: this.

Newsgroups: comp.lang.forth
From: John_Somerville@mindlink.bc.ca (John Somerville)
Subject: Re: DIR/REG
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 22 Jan 1993 20:06:43 GMT

I think you can get copies of X3J14 via FIG. Jack Woehr comes on here
frequently and may suggest alternates. Note so far there are just draft
proposals.

regards john
--
john somerville B.C. Hydro
affiliations FIG Forth Interest Group
Newsgroups: comp.lang.forth
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Yet more on blocks vs. files
Organization: Motorola Codex, Canton, Massachusetts
Date: Sun, 24 Jan 1993 03:37:12 GMT

It just occurred to me that for those die-hard block users, it
wouldn't be hard to write an Emacs save-file hook that translated
buffers into Forth-style blocks before saving. You could even write a
Dired mode that read your block directory, and a find-file hook so
that you could read your blocks into Emacs buffers to edit them.

:-) :-) :-)

				Peter Desnoyers
-- 
Newsgroups: comp.lang.forth
From: penev@venezia (Penio Penev)
Subject: Recent FORTHs' guts  (was: Documenting)
Organization: Rockefeller University
Date: Sat, 23 Jan 1993 12:27:39 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

Julian V. Noble (jvn@fermi.clas.Virginia.EDU) wrote:
: 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.

I think, that when one designes a FORTH for a machine with a lot of
memory, native code is the better way. It's faster, while not wasting
much. On a i386 one have 4-byte 'address' and a 5 byte 'call address'.
Well, it's not like having 15 bit 'address' and 16 bit 'call address'
like in RTX, but it's still tolerable.

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. The call on this
processor cannot be made less that 2 instructions (read 2 clocks and 8
bytes). But the You have something like this for the @ , TS being top
of stack :

: @   TS ) TS lw  ; IMMEDIATE  
: @   @ ;

I even developed a 8051 FORTH, (polyFORTH - like) that used native
calls and inlining. It performed about the speed of some old 8088
FORTHs. The good thing there is that one has near (2K) calls, which
compile to 2 bytes instaed of 3. With well structured applications the
tendency is to make near calls. There one can use phrases like

: AWORD  FORTH WORDS [ assembly operators ] OTHER FORTH WORDS ;

Great for controlling devices. _Fast_.

Flames welcome.

-- Penio.
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: comp.lang.forth
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Date: 25 Jan 93 18:02:25 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 think, that when one designes a FORTH for a machine with a lot of
>memory, native code is the better way. It's faster, while not wasting
>much. On a i386 one have 4-byte 'address' and a 5 byte 'call address'.
>Well, it's not like having 15 bit 'address' and 16 bit 'call address'
>like in RTX, but it's still tolerable.
>
>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).

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.

--
James Hague   
exuhag@exu.ericsson.se
Newsgroups: comp.lang.forth
From: piggy@hilbert.cc.utas.edu.au (La Monte Yarroll)
Subject: POINTLESS OBSERVATION: "Forth" in subject line
Summary: Posters to comp.lang.forth identify Forth very often.
Organization: University of Tasmania, Australia.
Date: Wed, 27 Jan 1993 10:48:34 GMT

Feel free to flame this abuse of the Net.  It's late and my code still
doesn't work :-(.

Every time I read comp.lang.forth, I notice that an EXTRAORDINARY
number of subject lines mention the word "Forth".

This may not seem surprising until you start watching for the same
thing in other groups.

This evening, out of 14 messages pending in comp.lang.forth, 8 mention
the word "Forth" in their subject lines.  I've actually noticed days
when 20 out of 20 articles mention the word "Forth".

In groups like comp.lang.lisp, I typically see maybe 4 or 5 out of 30
or so articles which actually mention the word "Lisp" in their subject
lines.

Why does this happen?  Do forth users have a greater devotion to the
name of their language than lisp users?  Does everybody cross-post to
groups that have nothing to due with the language "forth"?  Do ducks
really fly north for the winter (after noticing that Orion is
upside-down)?
--
La Monte H. Yarroll	Home:		piggy@baqaqi.chi.il.us
   Work:		piggy@hilbert.maths.utas.edu.au
   AKA:			piggy@gargoyle.uchicago.edu
   Once upon a time:	postmaster@clout.chi.il.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Data types
Date: 24 Jan 93 13:45:26 GMT
Organization: EIEI-U

Category 10,  Topic 29
Message 18        Sat Jan 23, 1993
ELLIOTT.C                    at 14:35 EST
 
 -----via CRS Premium Bulletin Board -
 USR 16.8K Dual Standard  (416) 629-7000

 Date: 01-18-93 (01:27)
   To: ALL
 From: MARCEL HENDRIX
 Subj: VALUES

 Re Re ``Changes in dpANS-3'' (Bernd Paysan):

  ...
 |> bp> 8. VALUE changed to take an initial argument from the stack
 |> bp>    (like CONSTANT)
  ...
 |>                           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.

 bp> Hm, I don't see were the problem is.

 Well, take "3 VALUE foo". When target compiling, the "3" is
 stored in ROM. When the system ``boots'' from ROM, code will be
 needed to copy the value 3 in the RAM location occupied by foo at
 run-time. There will be no user code that does this explicitly,
 as the standard suggests that VALUE is somewhat like CONSTANT in
 this respect (this is what I fear, I hope to be wrong).

 bp> Every object in Unix, TOS or MS-DOS has (at least) three parts:
 bp> The TEXT (initialized, but unchanged at runtime) which could
 bp> stay in ROM, the DATA (initialized, but possibly modified at
 bp> runtime), which is copied to RAM at boot time and the BLOCK
 bp> STORAGE, (uninitialized or initialized to zero and modified
 bp> while running) which is only allocated and erased at boot time.

 Somehow, I do not think it is a solution to simply burn all RAM
 into ROM ( CREATE bar 128000 ALLOT ), although it has the kind of
 elegant simplicity Forth is famous for. I hope I'm
 misinterpreting your comment :-)

 bp> I prefer VARIABLES and CREATE structures to be initialized at
 bp> target compile time.

 I do not know how a commercial target compiler will handle
 "VARIABLE foo  3 foo !", but personally I would not expect (nor
 demand) it to (have) work(ed) when the system is booted and runs.

 In fact, it will not be very difficult to handle initialization
 of VALUE's -- doing the same with CREATE structures poses real
 problems. ( CREATE ape  33 , 0 ,  8 ape 2 CELLS + ! ).

 bp> "Late answers are wrong answers!"

 Marcel Hendrix,       | "an engineer is somebody who spends three
 Dutch Forth Workshop. |  hours figuring out how to do a two hour
                       |  job in one hour."


 NET/Mail : FS FORTH Systeme BBS West Germany ++49 7667 556
 ---
  * 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
From: bs764@cleveland.Freenet.Edu (Fred H Olson)
Newsgroups: comp.lang.forth
Subject: MSI-6000 disk test unit in Forth?
Date: 24 Jan 1993 21:38:33 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu


MSI-6000 disk test unit in Forth ?
 
                                  Sat  01-23-1993
                                  Fred H. Olson    ( WB0YQM )
                                  1221 Russell Av N
                                  Minneapolis, MN 55411
                                  (612) 588-9532
                                  (Internet: fred%jwh@vx.cis.umn.edu)
 
A friend of mine who works for IBM has asked for my help
modifying some code for a piece of disk test equipment known
as an MSI-6000. He has found very little documentation other
than various source (?) files and command summaries.  He is an
electrical engineer (analog) and does not know Forth and is
not a programmer.  I have only seen some listings and not the
actual equipment or files.  It is programmed in what appears
to be Forth. One listing which starts "Extension FORTH du
Langage" and " FF: Fichier des Mots d'Extension du Langage"
appears to be in French.
 
Does anyone know anything about this equipment or the version
of Forth used?
 
Does anyone know whether IBM engineers typically have
Internet connected Email access?
 
Fred
--
From: duncan@nic.cerf.net (Ray Duncan)
Newsgroups: comp.lang.forth
Subject: Re: Forth's Adaptability
Date: 27 Jan 1993 02:23:41 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <BEVAN.93Jan26102555@tiger.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>
>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.
>

Sure, the choice is: try and pick a stable vendor and then use
their extensions (knowing, that if worst comes to worst, the
functionality across vendors is pretty much the same even if
the word sets are somewhat different), reinvent the wheel from
scratch yourself, or just do without such niceties as memory
management, file interfaces, and floating point until those things
are standardized. 

One point that has gotten lost in your discussion is that 
language standards tend to codify common practice.  They don't
(usually) just invent things out of thin air.  If you pick a 
vendor or implementation that is widely used, your chances of
getting badly burned by a standards process are not high - 
either the standard will look a lot like the implementation that
you're already coding to, or your vendor will have the resources
to migrate to the new standard and supply you with transitional
aids or compatibility layers.

For example, the functional mapping between the ANSI floating 
point, memory management, and file extensions and our existing
systems is very close.  The stack effects are different here and
there, but most of the differences can be taken care of with
a few lines of code layered on the existing systems.  So no one
who really cares about ANSI compatibility is going to suffer
because they picked an LMI Forth system.  And they will have had
access to these capabilities for a decade or so before X3J14
existed.

Newsgroups: comp.lang.forth
From: skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant))
Subject: Forth for robotic control?
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Fri, 22 Jan 1993 10:15:26 GMT

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.

After 10 years, is it true now?
Is it popular in the robot industrial to use forth in robotic control?
I only know that prolog is quite suitable for writing a planner for
robotic.

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.

Thanks!

Mr.Sai-Kee WONG
skwong@se.cuhk.hk
From: duncan@nic.cerf.net (Ray Duncan)
Newsgroups: comp.lang.forth
Subject: Re: Forth's Adaptability
Date: 22 Jan 1993 18:24:28 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <1993Jan21.152822.24631@exu.ericsson.se> exuhag@exu.ericsson.se writes:
>Chuck Eaker writes:
>>
>>I happily stand corrected. Tell me about LMI's products. What
>>platforms are supported? Will they conform to dpANS when adopted?
>>And, yes, I'm a hot prospect who has to get jobs done and looking
>>for more productive ways to do them.
>Ditto.  Please feel free to hawk your products (I don't consider
>this commercial use of the Internet, just good information.)  I'll
>repeat my plea for comments from users of Harvard Softworks' HS/Forth
>as well.

LMI sells interactive Forth development systems for MS-DOS, OS/2,
and Windows.  We also sell DOS-based cross-compilers for ROMable
applications on many of the common 8-bit, 16-bit, and 32-bit
microprocessors and microcontrollers including the 80x86 family,
80x96 family, 8051/31 family, 680x0 family, 68HC11, Z-80, 8080,
V25, 6809, 6303, and so on. We have been in business since 1979
and all of our systems are Forth-83 standard (16-bit) or 
Forth-83 compatible (32-bit).  We have a technical support BBS
system where registered users can ask questions and download free
updates.  For more information:

  Laboratory Microsystems Inc.
  12555 W. Jefferson #202
  Los Angeles, CA 90066
  or
  P. O. Box 10430
  Marina del Rey, CA 90295
  phone: 310-306-7412
  fax: 310-301-0761
  BBS: 310-306-3530 (1200/2400/9600 baud, 8/N/1)

Thanks for your interest.

Ray Duncan

Newsgroups: comp.lang.forth
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Selecting a Public Domain Kernel
Date: 25 Jan 93 11:18:44 GMT
Organization: EIEI-U

Category 1,  Topic 7
Message 118       Sun Jan 24, 1993
ELLIOTT.C                    at 10:01 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-23-93 (00:57)
   To: ALL
 From: M SIMON
 Subj: Z8 FORTH

 The Following Message was Received from: B.RODRIGUEZ2 [BRAD]

 Subj: SELECTING A PUBLIC DOMAIN
 Conf: FORTH (1)

 > Has anyone done [a Z8 Forth] yet in a PD package...
  > (I really would prefer a native Forth) - anybody have any idea
 how much [MPE's] products run?

 1. I don't know of any PD Z8 Forths.  TCOM perhaps?
  2. MPE's package includes _both_ a cross-compiler and a full
 native Z8 Forth.
  3. MPE's package costs 950 pounds U.K., or somewhere in the U.S.
    $1600-$1800 range depending on the exchange rate.

 Brad Rodriguez    B.RODRIGUEZ2 on GEnie
  b.rodriguez2@genie.geis.com   (at last! preferred, fastest
 response)
  bradford@maccs.dcss.mcmaster.ca  (use this for long messages, >
 4Kb)

  * Origin: GEnie and the Forth Interest Group via The GrapeVine BBS


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++

 I have designed a Forth for the Super Z8. The code is native and
 includes a built in ROM compiler. Because the NEXT loop is an
 assembly language instruction it runs FORTH like greased
 lightning for an 8 bitter. 70 - 90 K Forth instructions a second.
 32K 16 X 16 multiplies a second. Useful for industrial control
 DSP. Object code for a version that runs on very simple hardware
 is available on Genie and the RCFB at  (303) 278-0364
 300/1200/2400 24 hours. An assembler that runs on a PC is free
 from Zilog or the below addres. Source code, Schematics in Orcad
 format and a Development Board are available from:

 M. Simon / Space-Time Productions
 3124 Meriday    Suite 103
 Rockford, Illinois 61109
 [ 815 ]  874-2296

 /// this space for lend, lease, sale, rent, or time \\\


 If you will leave me a name and address I will snail mail you
 lit.

 M. Simon

 NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for
 Forth! ---
  * 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: bible@iastate.edu (Anthony E Bible)
Subject: Using other-language libraries from Forth
Organization: Iowa State University, Ames, IA
Date: Thu, 28 Jan 1993 20:04:04 GMT

	I'd like to see a thread started on using Forth in 
conjunction with other languages.  More specifically I'd 
like to know how Forth programmers could use library 
facilities from another language in their programs.  I 
assume it is not too difficult to write a code word to 
access operating system services in most cases, but linking 
library routines into a program seems to me rather more 
difficult.
	I think I recently saw mention of someone who compiles 
a stub program using another language to get the library 
member loaded and then somehow links that into the Forth 
program.  I am thinking more along the lines of something 
that could be done "seamlessly" in Forth itself, something 
like a word 

EXTERN: <forth-word-name>
		<library-info> <library-member> ;

and this would load the library member, resolving additional 
references, into the Forth dictionary.
	Obviously I don't much care whether or not it's called 
EXTERN: and obviously there are other issues to consider 
such as parameter passing and -- well, that's the kind of 
thing I would like to see discussed.  What are the 
considerations for implementing a capability like this?  If 
it has already been done then I apologize for (yet again) 
displaying my ignorance, and perhaps someone could summarize 
how it was implemented and on what operating systems.

One minor request: although I don't want to try to control 
what anyone has to say on this subject (as if I could! :) I 
am not really interested in discussions of whether or not I 
should want to do this.  This thread is just directed toward 
people who have-to/want-to use Forth within a "typical" 
operating system environment.  No offense meant nor implied.

Regards,
tony
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Documenting
Date: 26 Jan 93 11:33:34 GMT
Organization: EIEI-U

Category 3,  Topic 3
Message 99        Tue Jan 26, 1993
G.LEFAVE [Gene]              at 06:02 EST
 
> Building a nucleus to use a particular shared library or a combination
 > of them is no more than 5 min work in the beginning of the development
 > of Your application. This ideology should work quite well with all
 > breeds of Unix which support shared libraries.

If there was ever a topic for Forth Dimensions this has to be it! Will this
work with DOS?
-----
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