HDTenEightyP/NetNews huggingface dataset:
From: Interface!Lady_Bacardi@under.mind.ORG
Newsgroups: comp.lang.forth
Subject: figtree
Date: 05 Jan 93 22:24:00 -0500
Organization: Interface BBS, 707-544-9661
X-newsreader: Fortress v1f-75

 FigTree:  a final word? 
    FOr those who may be interested, my FigTree BBS program is now 
online at 509-627-0637... you may take an instant lok-see by using 
"Guest" as handle and password.  I just spent a little time putting 
together a forth for it on the IBM, and it runs fine by me. I will 
not be netting yet, because I want to fully beta test before I risk 
causing troubles in that realm. 
   And yes, I was speaking of my program, and not the bbs of 
apparently the same name... 
   Chow. 

--
via Fortress Gateway at uumind.mind.ORG
Newsgroups: comp.lang.forth
From: paulb@harlqn.co.uk (Paul Butcher)
Subject: Re: What's the abbreviation DPMI ?
Organization: Harlequin Ltd, Cambridge, UK
Date: Fri, 8 Jan 1993 13:43:41 GMT

In article <1ih23pINNe0k@nz12.rz.uni-karlsruhe.de> DAHMS@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
>I have a quite good knowledge about computers, but never heard about "DPMI"
>outside this newsgroup, so I what does it mean?
>
>
>Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)

DPMI stands for "Dos Protected Mode Interface".  It's a means by which
DOS programs can cooperate in using 386 features (e.g. virtual memory,
virtual 8086 processors etc.).

I believe the first program to offer DPMI support was Windows 3.0, but
others now do so as well.

It supercedes an earlier standard called VCPI (Virtual Control Program
Interface) which performed a similar function.

PaulB->msgCount++
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Subject: Re: What happened to the group working on free ANSI FORTH?
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Mon, 4 Jan 1993 11:34:43 GMT

In article <1992Dec24.014830.26592@oclc.org>, aph@oclc.org (Andrew P. Houghton) writes:
|> I have not seen any progress from the people working on the free
|> ANSI FORTH implementation.  Has the group working on it disbanded
|> or are they hard at work?  Inquiring minds would like to know.

We are hard at work.

- 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: "elliott chapin" <elliott.chapin@canrem.com>
Subject: pc-yerks
Reply-To: "elliott chapin" <elliott.chapin@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 11 Jan 93 12:01:00 EST

I also want to find PC-yerks.

Elliott Chapin
---
  DeLuxe 1.12 #4315  elliott.chapin@canrem.com
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
From: nick@sw.stratus.com (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 8 Jan 1993 13:55:42 GMT
Organization: Stratus Computer, Inc.
Distribution: world
NNTP-Posting-Host: osa.sw.stratus.com

In article <1ijimoINN3u9@charnel.ecst.csuchico.edu>, fish@ecst.csuchico.edu (Kevin Haddock) writes:
> 
> I would argue that it does not fly in the face of Forth phylosophy to use
> screens because if you do your code correctly screens do not get in the way
> and since they are vastly simpler to impliment and use in creative ways
> in your source code they VERY MUCH fit into Forth phylosophy.
> 
> A lot of Forth is EXACTLY this way.  For instance: only really being
> able to get to the top few items on the stack (no problem if you
> are factoring properly), highly restrictive control structures (same
> reason), RPN math (take two minutes to unravel the occaisional formula)
> space delimited tokens (and the SIMPLE single character parser WORD),
> 'gas tank' style linear memory management, pointers with fetch and store,
> etc, etc, etc,......

I'm sorry, but I don't see your argument.  You are correct that if you write Forth
in the 'traditional' manner, then you can get by with screens without a problem,
and therefore not be too bothered by the arbitrary screen structure imposed on
your source.  This does not invalidate my argument that a limit does exist, and
Forthers (rightly) boast that the language does not impose artificial restraints
on them, (like syntax.)  Also, it does not invalidate the original reason
for this thread, which is, that screens encourage a code structure more suited to
efficient use of the screen (disk space,) than interpretation of the source by
humans.

[Personally, I'd like to see Forth move beyond screens and files, to something more
like FIFTH, which is oriented toward individual words.  But that's another mail
war... :-)]

								/nt
From: dwp+@cs.cmu.edu (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Summary: something salient, shortly stated, sadly seldom satoric
Date: 5 Jan 93 03:08:32 GMT
Organization: EIEI-U

In article <BEVAN.93Jan2174249@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
+The one thing I don't want when I use a compiler is to have to use a
+new editor.  This particular brain-dead idea seems rampant in the PC
+area, were a compiler often comes with its own editor.  Unless your
+target market is a small niche system where there might not even be
+and editor, there is no excuse for foistering a particular editor on
+users.  Note I'm aware you can often still run the compiler without
+the integrated editor, but you lose all the "nice" features.  For the
+sake of a bit more effort these could be made available whatever
+editor is being used (see below).

Yes!  Just want to add my agreement here.  In the Forth world it is more
comical (and more tragic) than for C or Basic or whatever.  Every Forth
has what its author thinks is "the best Forth editor".  After all, the
author(s) should know, having found numerous flaws and misfeatures in
editors done by others, either ideological design differences, or mere
implementation differences.  Funny how they can't see that those who might
want to use their system(s), being the stereotypical rampantly independent
and rugged Forthers that they are, would in fact think the same thing of
the very editor that they supply.  

-Doug
-- 
---
email to: dwp@willett.pgh.pa.us is preferred to From: address but both work.
Newsgroups: comp.lang.forth
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: Documenting
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Mon, 11 Jan 1993 22:17:23 GMT

now THERE"S an oxymoron for ya: BASIC and correct phrasing style...
Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
Subject: This is NOT 'Documenting'.. yuk
From: mentink@wronz.org.nz
Date: 8 Jan 93 14:02:35 +1300

	Hi all you eforth-ers,

          Can anyone help, the standard EFORTH word-set includes the word
NUMBER? which converts a number string entered interactivly by the user.
Although it accepts hex numbers e.g $4000, it does not conform to the
usual FORTH and allow you to enter a double number e.g 123.45

Can anyone help by providing a modification of the EFORTH source for the
word. Follows below ....... 

  Alternatively....
  Provide a seperate word to allow you to enter a double number on the
  stack.


  Thanks in advance.

/ --------------------- Source starts here -----------------------------


: NUMBER? ( a -- n T, a F )
  BASE @ >R  0 OVER COUNT ( a 0 b n)
  OVER C@ [ CHAR $ ] LITERAL =
  IF HEX SWAP BYTE+ SWAP 1 - THEN ( a 0 b' n')
  OVER C@ [ CHAR - ] LITERAL = >R ( a 0 b n)
  SWAP R@ - SWAP R@ + ( a 0 b" n") ?DUP
  IF 1 - ( a 0 b n)
    FOR DUP >R C@ BASE @ DIGIT?
      WHILE SWAP BASE @ * +  R> BYTE+
    NEXT R@ ( ?sign) NIP ( b) IF NEGATE THEN SWAP
      ELSE R> R> ( b index) 2DROP ( digit number) 2DROP 0
      THEN DUP
  THEN R> ( n ?sign) 2DROP R> BASE ! ;

  --------------------------------------------------------------------------
	Bernie Mentink   ( Christchurch N.Z. )
	email: mentink@wronz.org.nz

	Huru the guru says ......
        1. T'is better to know some of the questions than all of the answers.
     	2. It's what you learn after you know it all that counts ....
 ---------------------------------------------------------------------------


Newsgroups: comp.lang.forth.mac
From: rumley@netcom.com (Richard Rumley)
Subject: Mach forth???
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Mon, 4 Jan 1993 19:51:27 GMT


I am helping a co-worker to find a version of forth called Mach.
Does anyone know who sells this product?
Please e-mail a response.

Richard Rumley
rumley@netcom.com

Newsgroups: comp.lang.forth.mac
From: John Matthews <jm@vcd.hp.com>
Subject: Writing INIT's with Yerk/MOPS
X-Useragent: Nuntius v1.1a5
Date: Sat, 9 Jan 1993 00:03:25 GMT
Organization: Hewlett-Packard

I am new to Mac-Forth programming (Although I did do some a long time ago
on the Atari 800 system). I would be interested in using either Yerk or
MOPS to do the following:

1) Write quick little utility Apps to give to my co-workers. I would like
to be able to bring up windows, draw text and graphics into them, etc...
(The usual Mac U.I. stuff). Minimizing development time is more important
to me than minimizing memory usage or time efficiency. Good debugging
capability is particularly important.

2) Write Stand-alone code resources, particularly INIT's. Often I want to
patch some traps to keep track of some aspect of the O.S. I would like to
be able to create an INIT that, whenever it was entered, would dump me
into a Forth interpreter/debugger so I could incrementally add and test
the INIT's functionality. Once I finished (after many reboots), I would
like to create a small INIT that executes in the desired manner.
(Actually, the Forth interpreter + windowing code is likely to be small
enough that I wouldn't mind if it remained in the init, as long as users
of the INIT don't see it).
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PYGMY Forth
Date: 11 Jan 93 11:17:38 GMT
Organization: EIEI-U

Category 7,  Topic 22
Message 136       Sun Jan 10, 1993
B.RODRIGUEZ2 [Brad]          at 14:27 EST
 
For anyone who's interested, I had occasion to define ;CODE for Pygmy 1.4 the
other day:

COMPILER
 : ;CODE
   \ DOES>  -3 ALLOT     ( COMPILE does)
   \ RECURSIVE  POP DROP
   ASM-RESET ;
 FORTH

If you recompile the kernel so that 'does' has a header, you can use 'COMPILE
does' instead of ' \ DOES> -3 ALLOT '.  Example usage:

: OFFSET    ( build words which add an offset to TOS)
   CREATE ,
   ;CODE
      BX AX XCHG,  3 [BX] AX ADD,  BX AX XCHG,  NXT,
   END-CODE

3 OFFSET 3+

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)
 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
Newsgroups: comp.lang.forth
From: John_Somerville@mindlink.bc.ca (John Somerville)
Subject: Re: Forth Standard Debate
Organization: MIND LINK! - British Columbia, Canada
Date: Tue, 5 Jan 1993 04:13:18 GMT

I don't see what the problem is. The ANSI standard should only address what
certain words do, not how they are done. I deal with mechanical and
electrical standards and it is a distinct advantage not to say how things are
done, but what needs to be done. If one company writes tighter, faster code
than another, and they provide source so you can play with the internals...
great, if they don't then I guess you shouldn't buy it. Really if one is
going to roll their own, and one wants all the nitty-gritty stuff, what is
the relevance of the standard? Perhaps the standard implies, that FORTH must
be regraded as a high level language, with nifty access to assembler. I
believe that there are good commercial FORTHs available now that allow one to
do whatever they want, that is there is enough information on intermediate
words that the interpreter can be tinkered with adequately.

The real advantage of a standard is that one uses it only when it is
required. Companies may look for programmers who are familiar with ANSI.
Programmers can communicate with other programmers much better under the
standard than they do now. And communication is the name of the game.
Otherwise: dkfd0 j jdkfirn knkduir nfkdirkn mdrjeorn aknrtoeh. I don't think
you can argue with that.

regards john
--
john somerville B.C. Hydro
affiliations FIG Forth Interest Group
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Subject: Re: Hardware ONLY issues
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Mon, 4 Jan 1993 14:45:12 GMT

In article <4186.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
|> Category 9,  Topic 2
|> Message 126       Tue Dec 22, 1992
|> G.LEFAVE [Gene]              at 11:23 EST

|> One question.  Why would keeping the address of NEXT in a register on a 68040
|> be considered unrealistic?  Since the 68040 has more registers then Forth can
|> realistically use, I would think that was desirable.  It would also make the
|> 68040, 486 comparison even more interesting.

In the benchmarks all occurences of NEXT are inlined. In the
subroutine threading benchmark the address of the word "Next" is taken.
That work just performs a NEXT and could also be called "Noop".

I a real Forth program we do not just use two different words, but
hundresds. While the Forth system could hold the addresses of the,
say, three most frequently used Forth words in registers, this would
result in about 20% of calls through registers. So, the typical case
is calling with immediate address, and doing this unoptimization makes
the benchmark more realistic.

BTW, I was surprised to find out that the unoptimized version is
slightly faster (on the 68040).

- 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: nick@sw.stratus.com (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 7 Jan 1993 21:04:46 GMT
Organization: Stratus Computer, Inc.
Distribution: world
NNTP-Posting-Host: osa.sw.stratus.com

In article <1993Jan7.190102.3517@mksol.dseg.ti.com>, strohm@mksol.dseg.ti.com (john r strohm) writes:
> 
> Blocks forces every single chunk of code to fit in a very restricted window,
> and it makes it darned near impossible to "slide" the window.  In my
> personal opinion, based on the code that I have seen, this restriction
> TENDS to force a greater degree of modularization, conciseness, and
> coherence, as compared to code developed under programming support
> environments that allow and even encourage the programmer to ramble on for
> hundreds of lines.

Which brings us back to why Forth programs are so badly structured stylistically...

There is no shame in preferring blocks over files,  but this argument started
when someone asked why the Forth programs he had seen were so abominably structured.
It was pointed out that the language's blocked heritage has a lot to do with it;
simple statement of fact to anyone who had to fit a large program onto a an 80K
floppy.  You don't want to waste real estate storing spaces.

The restriction you view as an asset is to a constricting liability to most
brought up on other languages.  More importantly, it flies in the face of the
Forth phylosophy that the language should not get in the way of the programmer.
The language should not TEND to force modularization upon the programmer, it
should trust the programmer to do the right thing.  Most Forthers do.

I don't mean to be judgmental on screens/blocks.  If you are more productive with
them, then by all means use them, and rejoice in the fact that you use a language
which lets you choose the best way to work.

								/nt
Newsgroups: comp.lang.forth
From: pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan)
Subject: Re: forth for the Acorn Archimedes?
Originator: pazsan@hphalle5h.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 8 Jan 1993 10:42:59 GMT
Distribution: comp


In article <JKH.92Dec30035747@whisker.lotus.ie>, jkh@whisker.lotus.ie (Jordan K. Hubbard) writes:
|> Subject says it all:  Anyone heard of one for this beast?

Yes I heard of one, but don't ask me what's it's name and who is the vendor or
distributor. On the CeBit exponation '91 an officer from Acorn told me that there
is even a Forth for that machine. That's all I know.
-- 
Bernd Paysan
"Late answers are wrong answers!"
Newsgroups: comp.lang.forth
From: r3btg@vax1.cc.uakron.edu (Ben T Galehouse)
Subject: Re: Forth Standard Debate
Organization: The University of Akron, Akron, Ohio
Date: Mon, 4 Jan 1993 23:46:21 GMT

It is quite amusing to listen to everyone argue.  Here is what I think.
There should be standards.  This isn't difficult to justify.  People
need to know that there is _a_ forth standard that everybody uses.  This
makes learning forth much easier.  Code portability is also a factor.

However, for forth to keep it's spirit, must also be deviation from the
standard.  Often, a machine's architechture dictates the fastest or the
shortest way to do something.  Also, especialy in embedded applications,
no one application will need all the commands often included with forth.
This sort of deviation from the standard must be accepted and even
supported, no matter how badly a person advocates that standard.

One of the most important characteristics of forth is it's size and
consision.  To this end, I suggest a group of malleable standards.
There should be a very short basic description of forth.  On top of
that, there should be a description of how forth should be implimented
on 16-bit machines and on 32-bit machines (size of stack? if the stack
is 32 bits, how to work with 16-bit arrays?).  If somebody wants to
devise a graphic standard (variable names that contain the screen size?)
that is also fine.  Not all 32-bit machines have graphic interfaces.
Not all people want floating point support.  The standard should be
modular.  There should be a 16-bit standard.  There should be a 32-bit
standard.  There should be a floating point standard.  (why not add a
floating point stack) 

Most importantly, however, all source code should always be provided,
and everything should be no larger than necessary.  This is the most
universal forth standard  --- the programer should understand the
compiler and everything about it.
 
-- 
r3btg@vax1.cc.uakron.edu          15764 Galehouse Rd.
Ben Galehouse              Doylestown, OH, 44230
(216) 658-3556
From: fish@ecst.csuchico.edu (Kevin Haddock)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: 8 Jan 93 18:55:10 GMT
Organization: California State University, Chico
NNTP-Posting-Host: cscihp.ecst.csuchico.edu

In article <1ik14uINNclv@transfer.stratus.com> nick@sw.stratus.com (Nicolas Tamburri) writes:
>
>I'm sorry, but I don't see your argument.  You are correct that if you write Forth
>in the 'traditional' manner, then you can get by with screens without a problem,
>and therefore not be too bothered by the arbitrary screen structure imposed on
>your source.  This does not invalidate my argument that a limit does exist, and
>Forthers (rightly) boast that the language does not impose artificial restraints
>on them, (like syntax.)  Also, it does not invalidate the original reason
>for this thread, which is, that screens encourage a code structure more suited to
>efficient use of the screen (disk space,) than interpretation of the source by
>humans.
>
>[Personally, I'd like to see Forth move beyond screens and files, to something more
>like FIFTH, which is oriented toward individual words.  But that's another mail
>war... :-)]
>
>								/nt


I agree with almost everything you say.  I don't however think that
Forth does not place artificial restraints on programmers.  All those
items I mentioned are 'artificial restraints'.  Those were restraints
that were chosen to exist in order to get some other 'valued' feature
at minimal cost (i.e. compile speed, simplicity, interpretation, portability,
etc...).  IMHO using vertical, poorly factored, code in Forth is misusing
the tools as much as is beating on a ratchet wrench with a hammer. (Perhaps
using vertical, properly factored, code is like using a cheater bar?)

I personally like Fifth very much, although I think it could stand some
improvement.  I think that basic concept (in something like a hypercard
format) is close to the ideal.  BTW, I still write properly factored,
horizontal, code in Fifth.

Is anyone interested in working on (discussing?) a Fifth-like environment
in a C/metacompiled hybrid form?  Perhaps ANS Forth compliant?

One thing I like about Fifth is that the whole source 'file' is memory
resident so your program can look ahead in the source (past the current
line) with no hassle.  The down side is you lose your work if you crash
without constantly saving.  This should be mapped to a file hierarcy in
a 'virtual' fashion in my opinion.  Anyway followup on Fifth via Email
if interested.

-Kevin
fish@cscihp.ecst.csuchico.edu

-------
There are no complex problems; only complex solutions!
Newsgroups: comp.lang.forth
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: Forth Standard Debate
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Mon, 4 Jan 1993 21:47:39 GMT

Whoever wrote the following:
>>>>>
Forth has not been standardized, not at all, ever.
<<<<<

(with apologies in advance) is sorely mistaken and misinformed.

I was there, I saw the standards come out and I have copies of the figFORTH
installation manual (somewhere) as well as the FORTH-79 and FORTH-83 standard
descriptions.

On the contrary, there's more than one standard! :)
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Documenting
Date: 11 Jan 93 11:17:36 GMT
Organization: EIEI-U

Category 3,  Topic 3
Message 52        Sun Jan 10, 1993
H.SIMMONS                    at 13:38 EST
 
In response to the mini-flame about Forth code formatting style, I would  like
to suggest that the essence of the question has been missed by most  postings.
The question was why Forth code is often seen without multiple  indents to
show structure.  The answer is that Chuck Moore, FORTH, Inc.,  and many who
follow in their footsteps do not write words that have more  than one control
structure per word.

If there are no more than two levels per word, (main and an if-then or a 
loop) then not much indenting is required.  When writing a word with no  more
than 5 to 7 "phrases" and only one control structure, blocks do not  constrain
the programmer.  Text files do not offer much to those who never  use more
than two lines per word anyway.  The PolyForth block index  listing looks very
pretty to those of us who use this style. 

The original question was not from a Forth user trying to provoke a flame 
war.  It was from someone experienced in customary languages.  It is as 
though a German or Russian speaker asked why English speakers don't use  the
same phrasing patterns with which he is familiar.  Some of the  responses have
been of the tenor of "those native Forth speakers were  illiterate; when we
better trained (read more intelligent) express our  ideas in Forth, we use the
`correct' phrasing we learned from `C' or  BASIC."

Let's agree that many people are used to page-long functions where 
indentation is required for human understanding.  But let's also agree  that
other ways of expressing code need not be condemned until they have  been
tried by fire and been found wanting. 

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