ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/20/90)
Date: 01-18-90 (13:15) Number: 1565 (Echo) To: ARCHIE WARNOCK Refer#: 1563 From: STEVE PALINCSAR Read: NO Subj: C + libriaries Status: PUBLIC MESSAGE Now you raise the question of what's part of the C language and what isn't. Seems to me that the "standard" libraries or library functions are a part of the language whether they're part of the ansi def. or K&R or what. To call C a "small, lean & mean" language is a joke when you realize it takes about a 500 page book to describe each function in the Turbo C package! Somebody here once raged on a about the number of reserved words in forth vs C, claiming that that number indicated someting about the size or power of the language. Pity that at the time I didn't know enough about C to expose that particular sham... ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
koopman@a.gp.cs.cmu.edu (Philip Koopman) (02/02/90)
In article <363.UUL1.3#5129@willett.UUCP>, ForthNet@willett.UUCP (ForthNet articles from GEnie) writes: > To: STEVE PALINCSAR Refer#: 1565 > From: ARCHIE WARNOCK Read: NO > Subj: C + libriaries Status: PUBLIC MESSAGE > > Me, too. I recall the debate, and I'm somewhat surprised that somebody > didn't raise that point (ain't hindsight wonderful). Still, the > difference is that most of the stuff in the standard C libraries is in > _every_ compiler. ... > ... You sure can't say _that_ about Forth systems. Nearly > everything outside the standard is named differently in different > systems. Partly this is because Forth vendors have traditionally based their sales differentiation on newer/slicker/better kernel implementations and extension sets (which promotes incompatibility) instead of newer/slicker/better support, development environments, etc. I am hoping that this will change on the move to ANS-Forth, but somehow I doubt it. The ANS extensions aren't inclusive enough to accomplish this, and probably can't be, since there is no "standard practice" for what to include in Forth most libraries. Forth vendors should realize that the time has come to stop basing their reason for existence on promoting incompatibility in the name of "better" base systems. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor, adjunct professor at CMU. I don't speak for them, and they don't speak for me.
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/14/90)
Date: 02-11-90 (19:14) Number: 2899 (Echo) To: LEE BROTZMAN Refer#: NONE From: ZAFAR ESSAK Read: NO Subj: C STREAMS Status: PUBLIC MESSAGE I have taken a portion from the discussion in the Modula-2 area in the hope that it can be expanded on. LB> C is built on the "streams concept", making all input and output, LB> regardless of origin, look like a file. LB> That is both a blessing and a curse. Could you please elaborate on how the Stream approach is a curse. Having used Forth for many years without Streams I was surprised at the ease with which a number of problems could be solved once stream I/O was added to Forth. This was especially true of data translation from one format to another. I am inclined to think that stream I/O should be made a fundamental component of Forth, after all doesn't the interpreter view input as a "stream" coming either from the keyboard or mass storage? --- * Via Qwikmail 2.01 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
dwp@willett.UUCP (Doug Philips) (02/14/90)
In article <461.UUL1.3#5129@willett.UUCP>, ZAFAR ESSAK writes: > LB> C is built on the "streams concept", making all input and output, > LB> regardless of origin, look like a file. > LB> That is both a blessing and a curse. > > Could you please elaborate on how the Stream approach is a curse. > Having used Forth for many years without Streams I was surprised at the > ease with which a number of problems could be solved once stream I/O > was added to Forth. This was especially true of data translation from > one format to another. I am inclined to think that stream I/O should > be made a fundamental component of Forth, after all doesn't the > interpreter view input as a "stream" coming either from the keyboard or > mass storage? From my Unix/C experience, the problem with streams is that you run into hardware weirdness when dealing with any real device. Things like suppressing echoing on input from the keyboard, raw vs. cooked input, blocking factors, cr/lf translations, parity and stop/start bit(s) considerations, timing and padding constraints, speed(bps rate) selection. Additionally there are the relatively recent windowing/screen management interfaces and issues of mixing text with windowing calls and graphics primitives. But, streams may still be a step in the right direction. -Doug --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/18/90)
Category 3, Topic 16 Message 73 Fri Feb 16, 1990 L.ZETTEL at 19:46 EST Just thought it worth mentioning that, IMOH QUICKBASIC is a very nice package, and excellent value for the money. If you want (or have to) use a conventional procedural language, it is very complete and offers an exceleent development environment. Note Forthers: here is the level you now have to compete with! (yes, I know they used Forth pricipals to do it). ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/19/90)
Date: 02-17-90 (10:12) Number: 2916 (Echo) To: L.ZETTEL Refer#: 2910 From: STEVE PALINCSAR Read: NO Subj: NON-FORTH SYSTEMS/LANGUAG Status: PUBLIC MESSAGE Other splendid low-cost commercial "conventional language" compilers include Turbo C, Turbo Pascal, MS Quick C, and MIX Power C. There's definitely no shortage of low cost programming tools out there for the PC world. (Far as I know, that is emphatically _not_ true for the Mac world, however.) Commercial forth systems obviously cannot compete with Borland, Microsoft or MIX on the basis of price. OTOH, the public domain forth systems have a lot going for them (except support, of course!) and they don't have any real counterparts in the worlds of C, Basic or Pascal, do they? But any of us would immediately agree that price is not why you want to use forth! ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/19/90)
Category 3, Topic 16
Message 75 Sun Feb 18, 1990
L.ZETTEL at 18:34 EST
To: Zafar Essak (GEnie Category 3, topic 16, msg 72)
In my experience (which is likely not exactly the same as Lee's)
streams tend to impel you to the White Queen's way: "Begin at the
beginning, go through to the end, then stop". If that is what you
want to do, fine; otherwise, depending on the capabilities of your
operating system, you may have troubles. Certainly, backing up in a
pure stream is usually less convenient than putting the water back in
the hose.
IMHO, what really made streams was pipes. Without pipes and
a means of easily switching in midstream they are very limiting.
Especially without that, what you tend to end up with are a lot of
big files that are all slight variants on each other - wasteful and
a nightmare come error correction time.
As a long time admirer of the beauty in Kernighan and Plauger's
Software Tools, I have now and again contemplated implementing them
in Forth. But with my Forth style what it is, I have concluded every
time that I wouldn't have much use for them in a Forth environment.
Long streams of stuff needing wholesale programmable modification
just don't happen to me that often.
-LenZ-
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/22/90)
Date: 02-20-90 (21:10) Number: 2936 (Echo)
To: L.ZETTEL Refer#: 2926
From: ZAFAR ESSAK Read: NO
Subj: NON-FORTH SYSTEMS/LANGUAG Status: PUBLIC MESSAGE
To: Len Zettel (GEnie Category 3, topic 16, msg ??)
Re: Streams.
Thankyou for your response to my earlier message.
LZ> streams tend to impel you to..."Begin at the beginning, go
LZ> through to the end, then stop".
LZ> otherwise, depending on the capabilities of your operating
LZ> system, you may have troubles.
LZ> Certainly, backing up in a pure stream is usually less
LZ> convenient than putting the water back in the hose.
LZ> Long streams of stuff needing wholesale programmable
LZ> modification just don't happen to me that often.
In addition to the usefulness of streams when modifying long strings
of stuff streams can also be very useful in the implementation of a
database, where random access is the primary method of access.
The implementation used of Streams in Forth was developed by Dan
Phillips and fully documented with source in a proposal to the ANSI
Committee and uploaded to the Forth Net. Maybe the benefits are the
result of the implementation used, but I don't think that's all there
is to it.
The ability for "backing up" or resetting the stream pointer is a
necessity and the syntax is as readable as BLOCK I/O.
e.g. d1 ( old place ) <from> >dseek
d1 ( old place ) 1024 UM/MOD BLOCK +
There may be some performance penalty for the stream as compared to
the block approach depending on the implementation.
Another advantage Streams offer is not having to remember the
"boundaries" of blocks when data extends over from one to another.
Certainly not a trivial requirement when data is variable length.
Also the ability to switch streams at any time is required and can be
provided by having "Stream Stacks" or using some other method of
explicitly identifying the stream.
What I find most enticing about Streams is the versatility of a few
simple words such as IN ( --c) OUT ( c--) INPUT ( adr,n--) and
OUTPUT ( adr,n--).
LZ> As a long time admirer of the beauty in Kernighan and Plauger's
LZ> Software Tools, I have now and again contemplated implementing
LZ> them in Forth.
Having not read this I guess it is going to require a trip to the
library or bookstore. In the meantime, can you provide a brief
summary of what you are refering to.
Thanks, Zafar.
---
* Via Qwikmail 2.01
NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/15/90)
Date: 07-13-90 (08:38) Number: 3494 (Echo) To: ALL Refer#: NONE From: STEVE PALINCSAR Read: (N/A) Subj: Am I nuts, or what? Status: PUBLIC MESSAGE There's been a lot of discussion in the past about Forth as a "write-only" language, and Forth has been the subject of much criticism on this account. Imagine my surprise when I saw the advertisement for a product by Gimpel Software called "The C Shroud" in this month's Dr. Dobb's Journal. To quote from the ad, "Don't lose sleep while distributing C source code! Translate your C programs into an obscure form, compilable but not understandable.... [Obfuscation features incude] comment removel, identifier translation, optional replacement of if, if ... else, for, while do, continue, break for more primitive control structures... string and character constants optionally expanded to their octal or hex equivalents, optional name space merging or splitting to enhance confusion." This product, at its special introductory price, costs $198.00. Now I ask you, am I nuts, or what? Have I missed something along the line? Pay almost two hundred bucks for a product whose purpose is to create unintelligible source code??? I suppose you could say this is another of Forth's advantages over C: we can easily create unintelligible source code without any extra cost options... ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/15/90)
Category 3, Topic 16
Message 86 Sat Jul 14, 1990
D.RUFFER [Dennis] at 15:56 EDT
Re: STEVE PALINCSAR
> Translate your C programs into an obscure form
Steve, Forth, Inc. once had to do a program for the government where even the
source code had to be secure. So, they just went through and changed all the
word names to something obscure. Of course, they did this only after they had
the system working. <grin>
I can see where this might be useful. DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (07/17/90)
Date: 07-14-90 (22:05) Number: 3507 (Echo) To: STEVE PALINCSAR Refer#: 3494 From: JACK WOEHR Read: NO Subj: AM I NUTS, OR WHAT? Status: PUBLIC MESSAGE > >Now I ask you, am I nuts, or what? Have I missed something along the >line? Pay almost two hundred bucks for a product whose purpose is to >create unintelligible source code??? > You just don't understand, Steve ... this new Gimpel product is just the logical continuation of the whole C philosophy! :-) You *might* have understood earlier if you were Jewish. "Gimpel" is a famous character in Jewish literature ... "Gimpel the Fool". =jax= NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth! ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
wmb@MITCH.ENG.SUN.COM (07/18/90)
> Imagine my surprise when I saw the advertisement for a product by Gimpel > Software called "The C Shroud" in this month's Dr. Dobb's Journal. > To quote from the ad, "Don't lose sleep while distributing C source code! > Translate your C programs into an obscure form, compilable but not > understandable.... > Now I ask you, am I nuts, or what? Have I missed something along the > line? Pay almost two hundred bucks for a product whose purpose is to > create unintelligible source code??? C source code is one of the few portable means of distributing an application to run on a variety of platforms. It also offers no security against somebody ripping off your work. (Regardless of whether or not software *ought* to be 'free', there are a lot of people who make their living based on it not being free). This product fulfils a valid economic need: the ability to distribute a single "shrink-wrapped application" that will run on a variety of platforms, without "giving away the jewels". Several years ago, I proposed exactly this (machine-obfuscated C code) as a standard distribution means for Unix applications. This is essentially an intermediate step between an "ABI" (Application Binary Interface; hot buzz word for Unix application delivery) and an "API" (Application Program Interface). It offers some of the benefits of the API without requiring companies to give away their intellectual property. Mitch
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
Date: 07-15-90 (21:38) Number: 3516 (Echo) To: JACK WOEHR Refer#: 3507 From: JERRY SHIFRIN Read: NO Subj: AM I NUTS, OR WHAT? Status: PUBLIC MESSAGE JW> You *might* have understood earlier if you were Jewish. "Gimpel" JW>is a famous character in Jewish literature ... "Gimpel the Fool". Jim Gimpel was one of the original implementors of SNOBOL4 and is a fairly well-known expert in C. He's the author of a widely used LINT package and has written a couple of books. No fool he. --- ~ EZ 1.31 ~ ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/19/90)
Date: 07-17-90 (12:57) Number: 3523 (Echo) To: JERRY SHIFRIN Refer#: 3516 From: STEVE PALINCSAR Read: NO Subj: AM I NUTS, OR WHAT? Status: PUBLIC MESSAGE Well, you have to figure it would take a pretty bright individual to create a compiler that can overcome all the best intentions of both programmers and language designers (all of whom are striving to produce clarity and comprehensibility, right?) to produce obfuscated code that nobody can make sense of! It's just that after all the stress that has been placed on clarity, all the criticisms of forth as "write only" to come upon a commercial product whose purpose it is to undo all that... I'll admit it, I was flabbergasted. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/25/90)
Date: 10-23-90 (03:45) Number: 4083 (Echo)
To: GARY SMITH Refer#: 4064
From: GENE LEFAVE Read: NO
Subj: NON-FORTH SYSTEMS/LANGUAG Status: PUBLIC MESSAGE
This is a reply to:
GS> From: schmidtg@iccgcc.decnet.ab.com
GS> Newsgroups: comp.lang.forth
GS> Subject: How do I do this in FORTH?
GS> Message-ID: <1450.2719bf62@iccgcc.decnet.ab.com>
GS> Date: 15 Oct 90 18:53:38 GMT
GS>
GS> invocation. The problem I am encountering in Forth is the difficulty
GS> of accessing seven variables on the stack while still using the
GS> stack for intermediate results. Forth seems to do well when the
My technique for handling recursion is to use the dictionary like a stack
frame. First I make up a defining word that accesses the disctionary
relative to it's top. Then I just comma that arguments at the beginning
of the word and un' ALLOT them at the end.
Example:
: IS CREATE , DOES> @ HERE + ( @ ) ;
( Add the @ if it needs to work like a constant. )
( I usually make it a ;CODE word for speed.)
-2 IS E or -1 CELLS IS E
-4 IS D
-6 IS C
-8 IS B
-10 IS A
: ROUTINE ( a b c d e f )
5 0 DO , LOOP ( or , , , , , )
( body of code can use A @ B @ C @ etc. )
a' b' c' d' e' RECURSE ( Recursive call.)
-10 ALLOT ; ( Exit )
I sometimes put my stack frame in PAD, or in a special area (in the
case of strings.) In my multiuser enviorment I have to be
real careful about using any variables.
I can't read "C" very well but I trust that this answers your general
question.
Gene
It's a miracle to me how this can possibly get back to USENET but I
hope that it will.
---
~ EZ-Reader 1.13 ~
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/23/90)
Date: 12-20-90 (19:54) Number: 629 of 629 (Echo)
To: ALL Refer#: NONE
From: JACK WOEHR Read: (N/A)
Subj: PROLOG IN FORTH Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
Harris originally intended to release a PROLOG written in Forth
for the RTX.
Whatever happened to this language?
Is source available?
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpkoopman@a.gp.cs.cmu.edu (Philip Koopman) (12/24/90)
> From: JACK WOEHR Read: (N/A) > Conf: FORTH (58) Read Type: GENERAL (+) > Harris originally intended to release a PROLOG written in Forth > for the RTX. > Whatever happened to this language? The PROLOG was written by Lou Odette, and was to be distributed through Harris for the RTX 2000 (and later for the RTX 4000). The deal fell through when up-front money amounts couldn't be agreed upon. I never got my hands on the code to try it out. Lou wrote an article entitled "Compiling Prolog to Forth" that appeared in JFAR Vol. 4 No. 4. (pp. 487-533) that has source code to a primitive version of his stuff. The last I heard from Lou Odette was at the following address: Applied Expert Systems, Inc. 5 Cambridge Center Cambridge, MA 02142 Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 *** this space for rent ***