Are there any FORTH implementations of computer languages?
Michael Winters
there are any computer languages that run on PCs, Macs, mainframes etc..
that were implemented in Forth? Does the RPN syntax of Forth affect
programming a compiler, such as FORTRAN or C? A long time ago, I read
some article by C. Moore that stated that a BASIC interpreter written in
Forth took up only a fraction of the code that it normally would take, due
to the power of FORTH. Are there any FORTH written interpeters or compilers
in the public domain where the source is available, since from recently
examining some languages written in C, they seem extremely complicated and
long, to say the least. I was just wondering whether FORTH would be suited
for language development, since I have a few projects in mind..... Thanks
for any advice or opinions on this subject.
----- Michael Winters
Tom Almy
toys. There is no getting around the fact that it is difficult to make a
good compiler for today's complex languages.
--
Tom Almy
tom....@tek.com
Standard Disclaimers Apply
Ulrich Hoffmann
--------------------------------------------------------------------------------
>A long time ago, I read
>some article by C. Moore that stated that a BASIC interpreter written in
>Forth took up only a fraction of the code that it normally would take, due
>to the power of FORTH.
CM's Basic was indeed a _compiler_ that took BASIC source code and compiled it
into threaded code. It had only six screens and was amazingly powerful.
Writing BASIC code you had to take care of spaces because the compiler used the
outer interpreter to parse the BASIC program. Not a signicant restriction to a
Forth programmer, though.
>Are there any FORTH written interpeters or compilers
>in the public domain where the source is available, [...]
There is Tom Zimmer's (shareware) tinyPASCAL which is distributed with his
F-PC/TCOM package.
From Offete Enterprises you can get a tinyMODULA-2 for the RTX-2000. It was
announcend in one of the "More on Forth Machines" newsletters.
At euroFORML'87 I talked about a "Lisp Kernal for the NC4000". It was
published by FIG in one fo the FORML proceedings. The paper includes
the kernel source code. A version which runs under F83 is available
on request.
>I was just wondering whether FORTH would be suited for language development,
>since I have a few projects in mind..... Thanks
>for any advice or opinions on this subject.
Look for Anton Ertl's GRAY, a Forth written parser generator. This makes it
especially easy to write a parser in Forth.
Greetings,
Ulrich
--
Ulrich Hoffmann email: u...@informatik.uni-kiel.de
Institut fuer Informatik, Universitaet Kiel Tel: +49 431 560426
Preusserstr 1-9, D-24105 Kiel, Germany Fax: +49 431 566143
Heribert Dahms
[Inquiry about languages written in Forth]
At home on my PDP11/RSX, the default output of the Fortran IV compiler is *not*
machine object code, but threaded code! This is not Forth, of course, and also
I've not yet checked wether it stacks its parameters like RPN, but interesting.
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
Ray Duncan
>In <21jmgb$3...@access.digex.net> win...@access.digex.net (Michael Winters) writes:
>>A long time ago, I read
>>some article by C. Moore that stated that a BASIC interpreter written in
>>Forth took up only a fraction of the code that it normally would take, due
>>to the power of FORTH.
>CM's Basic was indeed a _compiler_ that took BASIC source code and compiled it
>into threaded code. It had only six screens and was amazingly powerful.
It was an interesting demonstration of using the Forth interpreter
for unexpected purposes, but as an implementation I would characterize
it as amazingly pathetic, not amazingly powerful. It supported only
a few BASIC keywords, and none of the control structures or capabilities
that make modern implementations of BASIC interesting. Furthermore,
using Forth's "WORD" as the basis for the BASIC parser means that
it will choke on a great deal (most, actually) of the BASIC source
code that exists out there, because BASIC interpreter/compilers
tend to be relatively insensitive to the presence/absence of blanks.
The Charles Moore implementation of BASIC in a few screens is one
of those great old apocryphal Forth stories that doesn't stand up
well to direct inspection. THis is not a reflection on Charles, who
I will be the first to agree is a brilliant fellow, but on the
Forth community's tendency to idolize Charles Moore and to trivialize
other programming languages.
Anton Ertl
|> Look for Anton Ertl's GRAY, a Forth written parser generator. This makes it
|> especially easy to write a parser in Forth.
I will mail the current version (Release 3) of Gray to anyone who is
interested. It will take a while, since I'm away during the next
week. Gray currently runs on TILE, but I will convert it to ANS Forth
Real Soon Now.
BTW, can anybody tell me why everybody writes ANSI C, ANSI Cobol, but
ANS Forth?
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Ulrich Hoffmann
>>CM's Basic was indeed a _compiler_ that took BASIC source code and compiled it
>>into threaded code. It had only six screens and was amazingly powerful.
>It was an interesting demonstration of using the Forth interpreter
>for unexpected purposes, but as an implementation I would characterize
>it as amazingly pathetic, not amazingly powerful.
Six screens means 96 lines of source code. In relation to the size of
this source I would call it amazingly powerful.
But, I agree, it was only a sparse tiny BASIC and merely a toy, no doubt.
Not comparable to current production level BASICs.
>Furthermore, using Forth's "WORD" as the basis for the BASIC parser means that
>it will choke on a great deal (most, actually) of the BASIC source
>code that exists out there, because BASIC interpreter/compilers
>tend to be relatively insensitive to the presence/absence of blanks.
Right. And reusing existing BASIC programs was also a problem because of
the mismatch in semantics.
Bernd Paysan
In article <220d67$k...@email.tuwien.ac.at>, an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>BTW, can anybody tell me why everybody writes ANSI C, ANSI Cobol, but
>ANS Forth?
Because ANS Forth expands to American National Standard Forth - which is
correct, but ANSI C expands to American National Standard Institute C - which
is wrong, because the C isn't from the institute, it just approves the
standard!
However, let people saying LCD display and ANSI C... abbrevations tend to
become a unmodifyable word.
--
Bernd Paysan
"Late answers are wrong answers!"
Roger Bicknell
>The Charles Moore implementation of BASIC in a few screens is one
>of those great old apocryphal Forth stories that doesn't stand up
>well to direct inspection. THis is not a reflection on Charles, who
>I will be the first to agree is a brilliant fellow, but on the
>Forth community's tendency to idolize Charles Moore and to trivialize
>other programming languages.
I've seen both Moore's BASIC and Zimmer's Pascal and I couldn't agree with
you more. Apocryphal? Exactly.
Bradley Forthware
>ANS Forth?
ANSI wants people to use the phrase "ANS whatever" but most people don't
know that so they (incorrectly) say "ANSI C".
When you write it out, it becomes clear:
American National Standard Forth
adjective adjective adjective noun
whereas
American National Standards Institute Forth
adjective adjective adjective noun noun
is gramatically incorrect.
Mitch
--
Bradley Forthware <w...@rahul.net>
Chris Waters
>In article <220d67$k...@email.tuwien.ac.at>, an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>BTW, can anybody tell me why everybody writes ANSI C, ANSI Cobol, but
>>ANS Forth?
>Because ANS Forth expands to American National Standard Forth - which is
>correct, but ANSI C expands to American National Standard Institute C - which
>is wrong, because the C isn't from the institute, it just approves the
>standard!
Actually, the same reasoning could be used to object to ANS Forth--the
"standard" didn't create a particular implementation. A vendor did.
They just made one that *complies* with the standard. Therefore, ANS
compliant Forth would be the truly correct term for describing an
implementation. And, since the standard itself isn't a Forth system,
calling *it* ANS Forth is not really correct either. ANS for Forth
might be more technically correct.
>However, let people saying LCD display and ANSI C... abbrevations tend to
>become a unmodifyable word.
Yes, I suspect that accepted use will be "ANSI Forth" (or the just as
technically bad "ANSI compliant Forth") before too much longer. Just
like ANSI C. The total purists may object, but those, like me, who love
English because of its "Humpty-Dumpty-ness"[*] can only offer a wry
grin. :-)
[*] "When I use a word, it means what I want it to mean."
-- Humpty Dumpty
in Lewis Carrol's _Through the Looking Glass_
--
Chris Waters | I think, there- | "Never look a gift horse in the mouth"
xt...@netcom.COM| fore I thwim. | --Priam, King of Troy
Will Duquette
writes:
>Actually, the same reasoning could be used to object to ANS Forth--the
>"standard" didn't create a particular implementation. A vendor did.
>They just made one that *complies* with the standard. Therefore, ANS
>compliant Forth would be the truly correct term for describing an
>implementation. And, since the standard itself isn't a Forth system,
>calling *it* ANS Forth is not really correct either. ANS for Forth
>might be more technically correct.
Disagree: ANS Forth is the language, divorced from any particular
implementation.
>Yes, I suspect that accepted use will be "ANSI Forth" (or the just as
>technically bad "ANSI compliant Forth") before too much longer. Just
>like ANSI C. The total purists may object, but those, like me, who love
>English because of its "Humpty-Dumpty-ness"[*] can only offer a wry
>grin. :-)
Consider: ANSI C is the American National Standards Institute's
definition of C, just as ISO Pascal is the International Standards
Organization's definition of Pascal. Given Borland's success in
the market, ISO Pascal is definitely not the international standard,
merely the dialect endorsed by ISO.
The real reason for the use of the ANSI C rather than ANS C, though,
is that ANS C would be pronounced "ANSI"! ;-)
---------------------------------------------------------------------
Will Duquette, | C Functions, SIMSCRIPT Processes,
WI...@CLIFF.JPL.NASA.GOV | but OPS5 Rules
Heribert Dahms
: In <1993Jul14.1...@Informatik.TU-Muenchen.DE> pay...@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
:
:
: >In article <220d67$k...@email.tuwien.ac.at>, an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
: >>BTW, can anybody tell me why everybody writes ANSI C, ANSI Cobol, but
: >>ANS Forth?
:
[...]
: >However, let people saying LCD display and ANSI C... abbrevations tend to
: >become a unmodifyable word.
:
: Yes, I suspect that accepted use will be "ANSI Forth" (or the just as
: technically bad "ANSI compliant Forth") before too much longer. Just
: like ANSI C. The total purists may object, but those, like me, who love
: English because of its "Humpty-Dumpty-ness"[*] can only offer a wry
: grin. :-)
:
: [*] "When I use a word, it means what I want it to mean."
: -- Humpty Dumpty
: in Lewis Carrol's _Through the Looking Glass_
:
I don't spell "A N S Forth", I like to say "ANSI Forth", "ANSI C"...
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
Jeff Fox
FORTRAN code can be included in a FORTH application.
Stephen J Bevan
At home on my PDP11/RSX, the default output of the Fortran IV
compiler is *not* machine object code, but threaded code!
This fact is mentioned in either Bell or Dewar's articles on threaded
code in Communications of the ACM 16(6):370-372 1973 and 18(6):330-331
1975 respectively. Both are short articles but worth a read IMHO.
Mike Haas
>
>BTW, can anybody tell me why everybody writes ANSI C, ANSI Cobol, but
>ANS Forth?
Probably has to do with the average programmer's perception of Forth...
too many people would confuse ANSI with ANTSY (how most of them feel).
Jim Schneider
This is a result of the fact that state machine that implements the parser
is based on a highly non-obvious state transistion table. (I'm describing
a yacc-type parser here, not a recursive or top-down parser). In fact, the
compiler bible ("Compilers: Principles, Techniques, and Tools", better known
as "The Dragon Book") says (in section 4.7):
"The principal drawback of the method [LR parsing] is that it is too
much work to construct an LR parser by hand for a typical programming
language grammar. One needs a specialized tool - an LR parser
generator."
The reason more programming languages aren't written in FORTH is that FORTH
doesn't have the tools built into it to support it. (This is not to say that
the tools can't be built in FORTH, just that they haven't been, yet.)
Dick and Jill Miller
more, including ForthTran!
>>into threaded code. It had only six screens and was amazingly powerful.
>It was an interesting demonstration of using the Forth interpreter
>for unexpected purposes, but as an implementation I would characterize
>it as amazingly pathetic, not amazingly powerful.
"Programming a BASIC Compiler in Forth", WERE amazing when presented 'way
back at the 1981 FORML meeting in California.
They weren't amazing examples of a full-blown BASIC compiler, and weren't
meant to be. They were an amazing demonstration of how easy it is to
implement BASIC in Forth. The demonstration didn't attempt to complete the
job, just to demonstrate the path. I recall that it covered that quite
well, and in that surprisingly small amount of Forth code.
It was throw-away code. Literally. Because Chuck ended his talk with,
approximately, "Now that you see how easy it is to implement BASIC in
Forth, why would you use BASIC when you have a language like Forth?" For
Chuck, that was the end of his BASIC project!
Hans Nieuwenjuijzen and his graduate students at the University of Utrecht
also programmed some other languages in Forth. I think it was the 1980
FORML where I saw Hans demonstrate his Forth-built Pascal on the Apple II.
It was a stunner, clearly out-performing the then-current commercial
versions on all obvious counts. Its incremental screen scrolling,
however, drew the most oohs and aahs.
Hans also reported success with versions of Basic and, a punster's delight,
ForthTran. You might want to read his 1980 FORML paper, "Why Languages on
Top of FORTH", and (with student Bramms Harm) his 1985 "Basic on Forth" in
The Journal of Forth Application and Research.
Some specialty-languages have been successfully implemented in Forth.
Nowadays, PostScript comes to mind. In 1980 or so, Andy Watson used
MMSFORTH to duplicate, on the little TRS-80 Model 1, a near-complete
implementation of the IBM-mainframe world's independent word-processor of
choice; the only missing items were ones not appropriate to the stand-alone
TRS-80. Andy knew his business well; that year, he was one of the officers
of the user-group for that mainframe program, and was able to demonstrate
it running quickly and well in 10% of its accustomed RAM space, on a 'toy'
computer!
MMS and others have programmed LOGO in Forth. Our own version is simply a
small, fast and accurate LOGO-like vector-graphics extension to MMSFORTH.
Some others have built fully LOGO-compliant implementations. Like Chuck
Moore, I never had the urge to make Forth that compliant with a slower and
larger language, once I discovered that Forth could inherit the other
language's good features without inheriting the penalties.
--Dick Miller
A. Richard & Jill A. Miller | MILLER MICROCOMPUTER SERVICES |
InterNet: dmi...@im.lcs.mit.edu | 61 Lake Shore Road |
Voice: 508/653-6136, 9am-9pm -0400(EDT)| Natick, MA 01760-2099, USA |
MMSFORTH: The cure for the common code.| 42 18'00.79" N, 71 22'27.68" W|
Dick and Jill Miller
implementations of computer languages?" mis-spelled an important Forther's
name.
In it, please correct "Hans Nieuwenjuijzen" to read correctly, "Hans
Nieuwenhuijzen". Also, correct "Bramms Harm" to "Harm Bramms". Thank you.
^
Mike Coughlin
When I read Chuck Moore's article on Basic in Forth years ago, I got
the idea that he was not trying to write a good Basic implementation.
Basic is a useless language that should be forgotten completely. It
was an advance for its time but should be seen as a confusing way to
do things today. Chuck's article presented that idea by showing how most
of Basic could be written in a few lines of Forth. It also showed a
few sneaky tricks of writing Forth that would not be obvious otherwise.
The Forth community may idolize Chuck Moore, but it also fails to
understand many of his best ideas. Compare Forth with other programming
languages and you will see that they are not trivial. The other languages
are excessively complex and do things upside down and backwards. Forth
programmers can see that other programming languages make trivial tasks
into complicated struggles.
--
Michael Coughlin mi...@gnu.ai.mit.edu Cambridge, MA USA
Julian V. Noble
> InterNet: dmi...@im.lcs.mit.edu | 61 Lake Shore Road |
> small, fast and accurate LOGO-like vector-graphics extension to MMSFORTH.
> Some others have built fully LOGO-compliant implementations. Like Chuck
> Moore, I never had the urge to make Forth that compliant with a slower and
> larger language, once I discovered that Forth could inherit the other
> language's good features without inheriting the penalties.
>
> --Dick Miller
Bravo, Dick! That's precisely why I wrote a FORmula TRANslator for embedding
formulae in Forth words, but not a full FORTRAN compiler (although I have done
a partial translator that handles FORTRAN DO loops and structured IFs as well
as formulae). IMHO the control structures and fine-grained factoring in Forth
qrN+I superior to anything in FORTRAN and lead to vastly smaller programs.
For example, my demo of vehicular rollover (a very complex problem in applied
mechanics) at the 1993 Rochester Conference was only a few hundred lines long
and most of those were SCALAR (intrinsically typed variables) declarations
(with explanations and documentation), or the initial section describing the
algorithm.
BTW, in answer to someone who posted a remark about writing compilers in Forth,
to the effect that the finite state machine is difficult to write or to under-
stand, let me ***seriously recommend*** my article "Avoid Decisions" in the
July/August 1991 issue of Computers in Physics, dealing with how to write
fsm's in Forth (I have defined a compiling word that makes an fsm from the
state-transition table representation thereof). Although my article touted the
replacement of convoluted logic trees in complex algorithms (such as the
downhill simplex function minimizer) with fsm's for simplicity and clarity,
the fsm's are of course perfectly usable in writing language parsers without
all the bother of LEX and YACC.
A more succinct description of the fsm code appears in the 1990 Rochester
Forth Proceedings. Finally, my book, "Scientific FORTH: a modern language
for scientific computing" deals with the subject ad nauseam.
A word of caution: the method I used for defining the fsm compiling word
FSM: (using CREATE...DOES> ) is valid only in indirect-threaded systems, and
definitely ***not*** ANS-compliant. Basically I used ] after CREATE to
switch to compilation mode. In my system, this means the execution tokens
(cfa's) are written down in successive cells of the parameter field of the
new word. So their addresses can be computed from the width of the table,
the current state and the beginning address of the parameter field; the
run-time action defined by DOES> is to compute said address, fetch the cfa
stored there, and execute it. The run-time code also updates the state per
instructions in the transition table being compiled.
The new ANS word COMPILE, can be made to replace the ] I used, but it would
have to be placed within a suitable BEGIN...WHILE...REPEAT loop. And (IMHO,
unfortunately) COMPILE, will probably not execute the immediate word ; that
I used to terminate my compilation process, so a more elaborate termination
will doubtless be necessary.
--jvn
Bernd Paysan
In article <2268q2...@life.ai.mit.edu>, mi...@gnu.ai.mit.edu (Mike Coughlin) writes:
>The other languages
>are excessively complex and do things upside down and backwards.
Well, that's exactly the point people knowing other language say of Forth -
it does things upside down and backwards (postfix, IF .. THEN and so on).
Speaking so, Forth is a totally normal language mirrored on the notation axis
of the universe (infix -> postfix). Once walking through the mirror,
everything else looks mirrored ;-)
(BTW I believe many conflicts result in just such mirroring processes - US
and SU were perfect mirrors in the last 40 years (read GEB), the Motorola
"world" is Intel mirrored on the endian and the source,destination axis and so
on... The US - SU mirror has broken (SU is now GUS :-) - the world looks
strange after a mirror breaks).
>Forth
>programmers can see that other programming languages make trivial tasks
>into complicated struggles.
However, programmers of other programming languages can't see that these
tasks are trivial.
Roger Bicknell
>
>I recall that Chuck Moore's six-screen BASIC compiler and related talk,
>"Programming a BASIC Compiler in Forth", WERE amazing when presented 'way
>back at the 1981 FORML meeting in California.
>
>They weren't amazing examples of a full-blown BASIC compiler, and weren't
>meant to be. They were an amazing demonstration of how easy it is to
>implement BASIC in Forth. The demonstration didn't attempt to complete the
>job, just to demonstrate the path. I recall that it covered that quite
>well, and in that surprisingly small amount of Forth code.
>
>It was throw-away code. Literally. Because Chuck ended his talk with,
>approximately, "Now that you see how easy it is to implement BASIC in
>Forth, why would you use BASIC when you have a language like Forth?" For
>Chuck, that was the end of his BASIC project!
>
It is VERY easy to impliment %70 of the design, including only the well-behaved
parts, omitting all the horrible boundary-effects checking code.
What you end up with is a deception, though. It is **NOT** BASIC if it doesn't run
BASIC code! Of course, one could argue all for all eternaty about what is and what is not
to be considered "BASIC code". To me that is just squabling over the 70-30 split point.
A friend of mine wrote a one page implimentation of an infix parser for forth. It was
beautiful (in a mathematical sense). But it did not handle variables, just literals.
He had no method of fetching from variables on the right-hand side of the equation.
But he said "it is enough to prove the point", patted himself on the back, and went away
smiling. I disagreed. I then wrote a version (two or three pages) that properly handled
this. The question then came up, "what about arrays?". I went back and re-wrote it so that
it would work with almost any data structure. When the dust cleared I had a _functional_
infix parser in forth. It wasn't as pretty or succinct - but it was USEFUL.
I do not consider these parlor-tricks to be implimentations of languages because they
are not useful - they are only curiosities.
Ray Duncan
>It was throw-away code. Literally. Because Chuck ended his talk with,
>approximately, "Now that you see how easy it is to implement BASIC in
>Forth, why would you use BASIC when you have a language like Forth?" For
>Chuck, that was the end of his BASIC project!
But he didn't show how easy it is to implement BASIC in Forth. He
showed how easy it is to implement a crippled, barely recognizable
mutant of BASIC, bending the definition of the BASIC language to suit
himself rather than parsing the language properly. It's this kind
of casual, incomplete, off-the-cuff hacks that give Forth a bad
name among professional programmers, not to mention the demeaning
attitude toward other programming languages. More "throw-away
code" is NOT what the world needs!
Let's put this "famous BASIC implementation by Charles Moore"
in perspective with a little thought experiment.
Suppose J. Random Hacker posted here on the net a "C compiler in
six screens" that recognized a trivial subset of the C language,
wouldn't parse the language at all unless every curly brace, keyword,
parenthesis, function name, argument, and semicolon was set off by
at least one ASCII blank on each side, ignored the existence of the
standard runtime library and trivial issues like strings,
floating point, and stream I/O completely, and required the
C code to be compiled to reside in Forth blocks. Would that be
hailed as a brilliant programming coup and a service to the Forth
community, or as brain-damaged? Would he be comparing the usefulness of
Forth and C in any useful way? Would he be proving anything about the
"superiority" of Forth, or the effectiveness of Forth as a tool for
the implementation of other languages? Could such an example be expected
to have any credibility with the people who work with C for a living
and actually KNOW something about the language?
Stephen J Bevan
Compilers (particularly parsers) are notoriously difficult to write by hand.
This is a result of the fact that state machine that implements the parser
is based on a highly non-obvious state transistion table. (I'm describing
a yacc-type parser here, not a recursive or top-down parser).
I agree that LR parsers are tough to hand code, but why use LR? Most
languages don't have LR grammars so you have to hack them to fit a LR
system anyway. LR systems such as YACC are also generally slower than
top down recursive parsers and the latter are arguably easier to hack,
tailor error recovery and do context checking in. BTW, IMHO parsers
are not the difficult part of a compiler; anything from type-checking
onwards is arguably much harder to get right unless your language has
a trivial type system or you are doing pessimal code generation.
Kenneth Kasajian
> American National Standard Forth
> adjective adjective adjective noun
>whereas
>is gramatically incorrect.
>Mitch
who cares?
It should be ANSI Forth. Not ANS Forth. No one uses ANS. It's ANSI.
Kenneth Kasajian
I wonder when Microsoft is going to come out with Visual Forth for
Applications ?
Mike Haas
>
>Some specialty-languages have been successfully implemented in Forth.
>Nowadays, PostScript comes to mind.
Who has written a PostScript interpreter in Forth?
Jim Schneider
>
>BTW, in answer to someone who posted a remark about writing compilers in Forth,
>to the effect that the finite state machine is difficult to write or to under-
>stand, let me ***seriously recommend*** my article "Avoid Decisions" in the
>July/August 1991 issue of Computers in Physics, dealing with how to write
>fsm's in Forth (I have defined a compiling word that makes an fsm from the
>state-transition table representation thereof). Although my article touted the
>replacement of convoluted logic trees in complex algorithms (such as the
>downhill simplex function minimizer) with fsm's for simplicity and clarity,
>the fsm's are of course perfectly usable in writing language parsers without
>all the bother of LEX and YACC.
Actually, what I meant was it is difficult to design the transition table that
drives the finite _automaton_ by hand, and it is not obvious what decisions
are being made in arriving at the tables used by automatic parser generators.
A finite state machine won't work as a general case parser because it can't
``count''. A finite state machine is perfect for recognizing certain classes
of strings that form the lexical elements of languages, but they cannot
recognize most computer languages on their own. (For example, it is well
known that no finite state machine can recognize all instances of the set of
strings composed of n `(' followed by n ')' ).
On the other hand, it is possible to build a finite _automaton_ that will
recognize just about any given computer language. The one used by yacc, in
particular is a `push-down' automaton, which can ``count'' two items, but not
three. (For example, it can't recognize a string of the form:
a ^n b ^n c ^n
where the symbols `^n' mean `n occurances of the preceding symbol'. This
implies that languages that require variables be declared before they are
used cannot be processed by a parser alone, but the syntactic phase of
analysis must be followed by (or interleaved with) a semantic phase.)
Jim Schneider
While I will agree that the `difficult part of a compiler' mostly resides in
the semantic checking and code generation parts, I must strongly disagree with
two of the things you said.
Any language that has an LL grammar also has an LR grammar. A priori, it is no
harder to write the LR grammar than the LL grammar. The only hard part about
writing an LR grammar is the shift you have to make to think in LR terms rather
than LL terms.
A table driven bottom up parser (like one generated by yacc) is
_significantly_ faster than a comparable top down predictive parser (ie. a
recursive descent parser). While I will admit that a RD parser is easier to
`hack on' than the table driven parser generated by yacc, I firmly believe
the yacc specification file is much easier to understand, much less `hack on'
than the comparable RD parser.
Additionally, LALR(k) parsers will detect errors as soon as the input stream
becomes inconsistent. They may perform additional transitions, but they will
not consume any more input.
And, IMHO, the reason that the parser is not the hard part of the compiler is
that we have excellent tools available to build the parser for us. Just
because you don't understand a particular tool doesn't mean that it's useless
to those of us who do.
Mike Coughlin
nowhere. Since Forth does many things in the reverse order of other
programming languages, Forth code looks impossible to understand to
people who have learned to program with another language. They have
to unlearn their old habits before thay can learn new ones. They are
not going to do this without a good reason.
If a Forth programmer can complete a job in a much shorter time
than another programmer, then he will get the other programmers
attention. This is the method Mitch Bradely used to convince Sun
Microsystems to use Forth in the boot ROM of the Sparc workstation.
He would write a program that would take a month to do in C in one
day. And he did it consistantly, time after time. The order you use
does make a difference. Forth puts things together in a better order.
Forth programmers have the very bad habit of neglecting commenting.
This creates another big problem for Forth's acceptance. The comments
for a Forth program are written in the same human language that other
programmers use. They don't have to learn to read all over again. If
good commenting was used in Forth, the disconcerting effects of
the Forth order of doing things would be reduced. My local Astronomical
research institute threw out several man years of Forth code and
fired the Forth programmers since they couldn't even read their
own programs. A clear indication of rotten commenting -- but they
thought it was due to the inherent difficulty of reading Forth.
From day one, Forth was not written to be read by other people. We
should change this custom. It would be doing things backwards from
the usual way, but we should be used to that by now.
David N. Williams
Adobe! ;-) (Wasn't the point that PostScript is a dialect of Forth?)
--
David N. Williams Phone: 1-(313)-764-5236
Physics Department Email: d...@williams.physics.lsa.umich.edu
University of Michigan David.N....@um.cc.umich.edu
Ann Arbor, MI 48109-1120 DWIL...@umiphys.bitnet
Kevin Haddock
The company who did the language FIFTH initially wrote it to do a postscript
interpreter. They wrote FIFTH then wrote the postscript interpreter
and beat thier competition to market by a considerable margin. Thier
president told me they had found that on a medium scale or larger project
it was easier and faster to teach a C programmer Forth and have him do it
in that than to have him do it in C.
You can get Fifth from:
Software Construction Co., INC.
2900B Longmire
College Station, Texas 77845
(409) 696-5432
I found it to be an excellent system plus there is one for the Amiga,
IBM-PC, and one was under construction for the '386.
BTW, I am not sure but I think Adobe wrote thier postscript stuff in
C. Last I heard they were looking for someone to speed it up and what
they wanted is someone who knew about Forth, C, and compiler optimization.
Go figure!
-Kevin
fi...@cscihp.ecst.csuchico.edu
-------
There are no complex problems; only complex solutions!
-------
Bureaucracy: The process of turning energy into solid waste.
-------
"A politician is a person who can make waves and then make you think
he's the only one who can save the ship." --- Ivern Ball
William B Dwinnell
Is FIFTH a Forth system?
Stephen J Bevan
followups are via email ]
In article <jimCAI...@netcom.com> j...@netcom.com (Jim Schneider) writes:
Any language that has an LL grammar also has an LR grammar. A
priori, it is no harder to write the LR grammar than the LL
grammar.
I agree, indeed if it usually _easier_ to write a LR grammar for a
language. However, the issue isn't the grammar, but the parser for
the langauge, and the two are not necessarily the same thing (they
aren't for any realistic language)
A table driven bottom up parser (like one generated by yacc) is
_significantly_ faster than a comparable top down predictive parser
(ie. a recursive descent parser).
Do you have figures to back that up. I can provide references to
published articles which contradict your claim (as do my own timings
comparing hand coded RD verses YACC/BISON).
While I will admit that a RD parser is easier to `hack on' than the
table driven parser generated by yacc, I firmly believe the yacc
specification file is much easier to understand, much less `hack
on' than the comparable RD parser.
If you want easy to read, use an EBNF such as Wirth's.
And, IMHO, the reason that the parser is not the hard part of the
compiler is that we have excellent tools available to build the
parser for us. Just because you don't understand a particular tool
doesn't mean that it's useless to those of us who do.
I think your assumptions are showing. My opinion, that LR parser
generators (and parser generators in general) are usually worth using,
is based on having used them (e.g. if you mail be with
"b-server-request" as the subject and "send oberon/oberon2p.shar" as
the body you'll get back a LEX/YACC definition I wrote for Oberon-2).
Kevin Haddock
>
>Is FIFTH a Forth system?
As far as I'm concerned it is. The word set is almost identical to Forth.
You don't have the block word set and it doesn't use files like F-PC
does. It stores the source code in a tree structure in memory and you
program it by browsing and editing the tree and source modules. When
you get done editing a source module you just hit escape and it compiles
the module (subroutine threaded code I believe) and installs it in the
system. It is a lot of fun just browsing around and never being aware
of any compile process. You also find errors immediately upon editing
which is a big plus. When you buy one (a FIFTH) you get an application
generator that recompiles all your application and generates an .exe file
with most everything stripped out. There is a shareware version
floating around that a person can check out most of the features on (every-
thing but the appl generator and the source code to the system itself).
I'd personally say it is pretty much of a toss up whether to develop on FIFTH
or on F-PC. I think FIFTH is more fun but F-PC has more libraries.
Mike Haas
>In article <CAHF4...@starnine.com> mi...@starnine.com (Mike Haas) writes:
>> In article <9307151910.AA05283@im4> dmi...@im.lcs.mit.edu (Dick and Jill
>Miller) writes:
>> >
>> >Some specialty-languages have been successfully implemented in Forth.
>> >Nowadays, PostScript comes to mind.
>>
>> Who has written a PostScript interpreter in Forth?
>
>Adobe! ;-) (Wasn't the point that PostScript is a dialect of Forth?)
No. The original statement says "implemented in Forth".
Postscript was not written in Forth. I'm not sure what was used, but
Adobe engineers have stated that they had never heard of Forth when they
wrote Postscript.
And one look at Postscript shows very quickly it can't be considered
a dialect of Forth. It's interprative, and has some of the same
functionality (even with the same names sometimes), but that's
about as far as it goes.
Andrew Haley
> Forth programmers have the very bad habit of neglecting commenting.
^ [ some ]
>This creates another big problem for Forth's acceptance. The comments
>for a Forth program are written in the same human language that other
>programmers use. They don't have to learn to read all over again. If
>good commenting was used in Forth, the disconcerting effects of
>the Forth order of doing things would be reduced. My local Astronomical
>research institute threw out several man years of Forth code and
>fired the Forth programmers since they couldn't even read their
>own programs. A clear indication of rotten commenting --
I don't agree that this follows. in order for code to be that
unreadable, it has to be badly written as well as uncommented.
I've had to maintain badly written (but well commented) Forth, and
I've also had to maintain well written, but almost totally
uncommented Forth. I found it cheaper to maintain the latter.
>but they
>thought it was due to the inherent difficulty of reading Forth.
>From day one, Forth was not written to be read by other people.
I'd be careful about that. I've worked on code from the pre-FIG days
of Forth, Inc, and it's beautiful stuff. In those early days they
didn't bother much with commenting, but the code itself is so good
that I had no problems. Mind you, I'm talking about code written by
real demigods (Dean Sanderson, Chuck, etc.) I guess that the rest of
us had better add comments. ;-)
I'm not arguing against good commenting, by the way. But it's no
substitute for a logical, well thought out program.
Andrew.
Andrew Haley
>Adobe engineers have stated that they had never heard of Forth when they
>wrote Postscript.
And if you believe that you'll believe anything. The language is
very similar, with the same names for many operations. It would be,
to say the least, an amazing coincidence if what they say were true.
Perhaps the original Design System language (PostScript's immmediate
ancestor) was less like Forth than PostScript is, and some of the
names for operations were later changed to be the same as those of
Forth. Even if this is so, the coincidence is too hard to swallow.
At best, I suppose that the original designers of PostScript could
have been subconsciously aware of Forth. Or maybe this is evidence
for Morphic Resonance?
Andrew.
Bill Vance
>From experimenting with my old 8-bit Atari Forth, I was thinking whether
>there are any computer languages that run on PCs, Macs, mainframes etc..
>that were implemented in Forth? Does the RPN syntax of Forth affect
>programming a compiler, such as FORTRAN or C? A long time ago, I read
>some article by C. Moore that stated that a BASIC interpreter written in
>Forth took up only a fraction of the code that it normally would take, due
>to the power of FORTH. Are there any FORTH written interpeters or compilers
>in the public domain where the source is available, since from recently
>examining some languages written in C, they seem extremely complicated and
>long, to say the least. I was just wondering whether FORTH would be suited
>for language development, since I have a few projects in mind..... Thanks
>for any advice or opinions on this subject.
>----- Michael Winters
One of the finest 8 bit forths I ever dealt with, ease of use-wise, and
implementation-wise, was White Lightning forth on the C64. It came with
it's own very extended Basic, and if memory serves, some fractal generating
demos that cooked right along for 8 bits. It was published by Oasis
Software (a British company). My only complaint was the method they used to
foil copying of the documentation. They used black print on red
construction paper, and it used to drive my eyes totally bugshit. Both the
Forth and Basic were otherwise totally excellent.
--
bi...@xpresso.UUCP (Bill Vance), Bothell, WA
rwing!xpresso!bill
You listen when I xpresso, I listen When uuxpresso.......:-)
Julian V. Noble
Interestingly, Einstein told one of his biographers that when he worked
out Special relativity he had never heard of the Michelson-Morley experi-
ment. This was, in fact a falsehood (although perhaps not a conscious one--
he was then an old man) contradicted by a lecture he gave in Japan in 1923
(apparently he was so miffed at getting the Nobel Prize a) late; b) for
the photoelectric effect--which he thought was minor work--rather than for
Relativity; that he excused himself from attending the Nobel Prize ceremon-
ies on the grounds he had promised to go to Japan). One of the Japanese
physicists made careful notes, translating from German to Japanese as he
went. These were unearthed about a decade or so ago, and clearly stated
how important the Michelson-Morley experiment had been in his thinking.
The reason I repeat this little anecdote here is that it is very easy to
rewrite history in one's mind, especially when it did not happen quite as
one wished it had. Long-term memory appears to be treacherous, and so
while the Adobe folks are surely full of it up to here, let's assume they
were not BSing deliberately. Especially as they recently advertised here
for a Forth programmer experienced in optimizing for speed. ;-)
--jvn
Ron Hochsprung
I claim to be the first person to mention to Greschke(?) and Warnock(?)
that
PostScript looked a lot like Forth. Neither had ever heard of it! I gave
them
a copy of a book on Forth that I had (probably, "Learning Forth"), and they
admitted that it was incredibly similar. But, I believe that they did not
have
any prior knowledge of Forth!!
Its not really surprising that the data manipulation part looks like Forth.
If
one wants to define a language which has arbitrary numbers of parameters,
each
of which is likely to be the result of another procedure calls, etc. one is
quickly led to a "stack" based model. If you take a look at the control
flow, it is much "cleaner" than Forth's (e.g., the concept of "blocks").
Remember, also, that the Adobe folke came from Xerox PARC, birthplace of
SmallTalk. In some ways, the control structures of PostScript are very
reminiscent of SmallTalk's.
So, I guess I could go along with the "Morphic Resonance" theory, whatever
that is.....
Ron
Kenneth Kasajian
>Ron
If Chuck Moore didn't invent Forth in the 60/70's, the Charlie Brown would
have invented it a few years later. Same can be said for most any kind of
programming language, concepts, ideas. This is all new, folks. Being the
first, doesn't mean being the only possible one.
Stephen J Bevan
One of the finest 8 bit forths I ever dealt with, ease of use-wise, and
implementation-wise, was White Lightning forth on the C64. ...
My only complaint was the method they used to foil copying of the
documentation. They used black print on red construction paper, ...
Oasis also had a Z80 version, the documentation was black on green :-<
Ray Duncan
>In article <CALI6...@starnine.com> mi...@starnine.com writes:
>>Adobe engineers have stated that they had never heard of Forth when they
>>wrote Postscript.
>
>And if you believe that you'll believe anything. The language is
>very similar, with the same names for many operations.
I dunno... Looking through the Postscript Language Reference Manual
from Adobe (Addison-Wesley, 1985), I'm not very impressed with the
argument that Postscript is derived in any way from Forth.
1) There are certainly some name collisions, but most of them
are either "obvious" (such as "dup" "xor" "abs") and require no
conspiracy theory to account for them, or they are "false" collisions
(i.e. same name, different meaning, such as "roll" and "count").
Compared to the total number of operators in Postscript, the
number of name collisions (whether "real" or "false") is quite
unimpressive, as is the number of operators with exactly the
same function regardless of name.
2) Postscript is a much more complex, rich, language than Forth,
even in its earliest incarnation. It has operators for floating
point, file access, string manipulation, exception handling, and
virtual memory management built-in. These were essentially unheard
of in Forth systems at the time Postscript's predecessors were
designed (ca. 1976-1978), and still pretty rare in commercial
Forth systems when Adobe Systems was formed in 1982.
If you read the very nice interview with John Warnock in
Susan Lammer's book "Programmer's At Work" (Microsoft Press, 1986),
it's very clear that Warnock was aware of the existence of Forth
but that the lineage of Postscript is completely independent of
Forth's lineage. I don't think the Forth community gains anything
by attempting to "piggyback" on the credibility of languages that
have been more successful (Postscript) or have more academic
credibility (Smalltalk), as has been the fashion in this discussion
group over the last week or so.
Jack J. Woehr
>If you read the very nice interview with John Warnock in
>Susan Lammer's book "Programmer's At Work" (Microsoft Press, 1986),
>it's very clear that Warnock was aware of the existence of Forth
>but that the lineage of Postscript is completely independent of
>Forth's lineage.
Every programming language reference I have ever read is part of
every Forth system I write. If Warnock knew Forth, Postscript could not
*possibly* be unrelated to Forth. That's how the minds of programmers work,
right, Ray? Every scrap of info saved for the next time ya need it.
Programmers are packrats of concepts.
> I don't think the Forth community gains anything
>by attempting to "piggyback" on the credibility of languages that
>have been more successful (Postscript) or have more academic
>credibility (Smalltalk), as has been the fashion in this discussion
>group over the last week or so.
No, your right there, Unca Ray ... Forth *obviously* won't gain
*nearly* as much piggybacking on PS as PS got by piggybacking on Forth!
Anyway, PS and Forth are two different languages. Forth is smaller
and cleaner, PS is more powerful and convenient, and, most of all, has
heap management and garbage collection, which technically is most of
the difference between the two (aside form syntactic trivialities).
=jax=
Michael Coughlin
>>but they
>>thought it was due to the inherent difficulty of reading Forth.
>>From day one, Forth was not written to be read by other people.
>
>I'd be careful about that. I've worked on code from the pre-FIG days
>of Forth, Inc, and it's beautiful stuff. In those early days they
>didn't bother much with commenting, but the code itself is so good
>that I had no problems. Mind you, I'm talking about code written by
>real demigods (Dean Sanderson, Chuck, etc.) I guess that the rest of
>us had better add comments. ;-)
>
profit from its good example. I know Forth can be written so it is
easy to read, but it usually isn't. I've asked for examples of readable
Forth code many times. Once in a while somebody says the code he has
written and published is easy to read, but I can't think of a time when
a third party has told me somebody else's published code is easy to
read. I guess anyone who has been interested in Forth for a while has
heard the remark "Forth is a write only language" from people who
have seen Forth but don't use it. Well lets get some Forth code to
show that idea is wrong. Or is readable Forth only used in systems
that are kept as trade secrets?
If we want to increase the use of Forth, we must make every
effort to change its reputation of being hard to read.
>I'm not arguing against good commenting, by the way. But it's no
>substitute for a logical, well thought out program.
>
As a fanatical Forth fan, I naturally assume that any published Forth
code is already logical and well thought out.
--
Michael Coughlin Cambridge, MA USA mi...@trystero.com
This message typed on 100% recycled computers.
Ray Duncan
> Every programming language reference I have ever read is part of
>every Forth system I write. If Warnock knew Forth, Postscript could not
>*possibly* be unrelated to Forth. That's how the minds of programmers work,
>right, Ray? Every scrap of info saved for the next time ya need it.
>Programmers are packrats of concepts.
He was aware of it at the time of the interview (ca. 1985).
That doesn't mean he was aware of it at the time that he and
his colleagues were designing Postscript's predecessors. Even
if he was, so what? Are two languages related just because
the designer of one language was aware of the other? Charles
Moore supposedly implemented one of the early versions of Forth
in Fortran on an IBM 1130. Does that mean Forth is related to
Fortran?
I'm not sure what your point is Jax. Do you have some mystical
belief that Forth has unique attributes that contaminate the
mind of anyone who ever even hears about it, so that everything they
do from there on owes a debt to the very existence of Forth?
Philip Koopman
Software Construction Company in College Station Texas is (last I
checked) primarily in the business of writing PostScript
interpreters in Forth (well, er, Fifth, but it's very
similar to Forth). At one point I think they dominated
the market in terms of installed non-Adobe postscripts.
--
Phil Koopman koo...@utrc.utc.com (203) 727-1624
United Technologies Research Center (UTRC)
Silver Lane M/S 48
East Hartford, CT 06108 USA
I don't speak for them, and they don't speak for me.
Roger Bicknell
>In article <743711...@aph.demon.co.uk> a...@aph.demon.co.uk (Andrew Haley) writes:
> The problem is that people complain that freely available Forth code
> (i.e. that written by amateurs) isn't readable. This shouldn't be
> surprising! But I can't see FORTH, Inc putting their jewels onto the
> net just to persuade people that Forth code can be readable.
>So where does that leave everybody? You have one side saying that
>Forth code isn't readable and pointing at various publically available
>pieces of code as evidence. The other side says you can write
>readable Forth code, but can/will not provide any code to back up the
>claim. It would seem the onus is on the latter camp to back up their
>claim or just ignore the "Forth is unreadable" claims. Unfortunately,
>it seems that most (all?) have chosen the latter course.
Don't you think such a demand is unreasonable? Let's apply this to
<your favourite language here>. Take the C language (please!).
Shall we decide the readability of C based upon publicly available C code?
You better hope not! Who cares if some kook wants to claim that forth is
unreadable because s/he found some pd source that is not well written?
Until criticisms are based upon usage (versus flippant voyeuristic attacks)
they are not to be taken seriously.
Interf...@under.mind.org
on 29 Jul 1993 8:35 pm GMT, cs.man.ac.uk!bevan wrote: > > In
Haley) > writes: > The problem is that people complain that
freely available Forth code > (i.e. that written by amateurs)
isn't readable. This shouldn't be > surprising! But I can't see
FORTH, Inc putting their jewels onto the > net just to persuade
people that Forth code can be readable. > > So where does that
leave everybody? You have one side saying that > Forth code isn't
readable and pointing at various publically available > pieces of
code as evidence. The other side says you can write > readable
Forth code, but can/will not provide any code to back up the >
claim. It would seem the onus is on the latter camp to back up
their > claim or just ignore the "Forth is unreadable" claims.
Unfortunately, > it seems that most (all?) have chosen the latter
course.
Dimensions, and I consider my own code (much of which is freely
available) to be readable as well. The source for F83 and F-PC,
which are probably the most widely distributed Forth source in the
world, are good examples of well commented, readable code, IMHO.
Frankly, I don't see what the fuss is about. If someone doesn't
speak Chinese, their claim that "Chinese is unreadable" would seem
pretty silly. Who are these people?
Reading Forth requires an understanding of the language, which is
fundamentally different from most other computer languages. You
have to read to "the stacks in your head". If those stacks don't
exist, you won't be able to read Forth.
Unreadable source code is available in any language. Forthers
shouldn't feel special in this respect. If you think there's too
much unreadable Forth floating around, counter it with some readable
code of your own.
--- b...@Interface.via.mind.org 707-544-9661 a ForthNet system
---
--
via Fortress Gateway at uumind.mind.ORG
Mike Coughlin
base their decision on Forth code that was written by professional Forth
programmers for a previous software project where they work as well as
on poorly written PD Forth code. Some Forth vendors claim that using
their systems which come with good documnetation and taking their
Forth courses eliminate the problem of writing bad Forth code. This
may be true, but unless readable Forth can be written by self taught
programmers and unless PD systems with clear documentation are available
for beginning students then Forth is useless. If Forth can only be
properly learned by spending thousands of dollars and hundreds of hours
in the classroom, then other programming languages that can be learned
by high school computer kids at home from PD implementations will keep
Forth from being used.
But Forth is not hard to learn and it can be written so other
people can understand it. Its just that Forth programmers don't
think it is important to communicate with other people. They have
too much fun writing to their computers and getting them to do
exactly what they want. The many PD programs and systems that are
hard to read are just the beginnings of good code. They are waiting
for good programmers to optimize them for ease of reading and
speed of understanding. When Forth programmers take up this task,
Forth will gain it true place in the world. Right now Forth hackers
are mainly interested in converting unclear Forth code into more
unclear Forth code.
Ray Duncan
> ... unless readable Forth can be written by self-taught
>programmers and unless PD systems with clear documentation are available
>for beginning students then Forth is useless.
This is a pretty sweeping claim. What has the usefulness of Forth
got to do with the availability of PD systems?
> ... If Forth can only be
>properly learned by spending thousands of dollars and hundreds of hours
>in the classroom, then other programming languages that can be learned
>by high school computer kids at home from PD implementations will keep
>Forth from being used.
From what I've seen, most "high school kids at home" (and other
casual programmers) are using languages like Visual Basic, Turbo
Pascal, Turbo C, Think C --- *NOT* public domain anythings.
However, spending thousands of dollars and time in the classroom
will benefit just about programmer using any language. It is a sad
but well-documented fact that most programmers never read anything
about programming.
> ... The many PD programs and systems that are
>hard to read are just the beginnings of good code. They are waiting
>for good programmers to optimize them for ease of reading and
>speed of understanding. When Forth programmers take up this task,
>Forth will gain it true place in the world....
*SIGH*. Yet another half-baked, lame theory about why C and similar
languages with traditional syntax, infix notation, data typing,
and support for files/floating point/strings/etc. were successful
and Forth wasn't.
Peter Churchyard
There is NO such thing as a readable program in any computer language...
All programming languages need a level of expertise to read and although
you might badly layout your code on the page thats your fault. If you are
not limited to 16 line blocks, you can layout your forth in as readable
way as any other language. Persoanlly I break my code up into a series of
'statements' and have one statement per line and indent control structures
in the same way I would do for C or PASCAL.
So if someone doesnt use say Forth JUST because its 'unreadable' I would
seriously consider getting another programmer..
Pete.
Roger Bicknell
>>
>The many PD programs and systems that are
>hard to read are just the beginnings of good code. They are waiting
>for good programmers to optimize them for ease of reading and
>speed of understanding. When Forth programmers take up this task,
>Forth will gain it true place in the world. Right now Forth hackers
>are mainly interested in converting unclear Forth code into more
>unclear Forth code.
I wonder, just now, how much of this is CAUSED by not using a parser,
which is designed to take some arbitrary syntax and produce machine
code, but instead uses a simple system of recording execution tokens.
A language that compiles machine code from a contrived source text most
probably is already prepared to generate good machine code from
whatever mess of source that the stupid human typed in. But if the
human is required to be sensitive to what will be produced it then
becomes a COMPROMISE between _clear_ intent versus optimum code for
the less-than-expert eye.
One cannot have the essence of expression dictated by a non-expert.
Forth uses RPN and is stack based because it is the most simple system.
If that is unnatural to the novice, so what? Get with the program!
I started out as a electrical designer (power-distribution/lighting/safety)
and you can bet that my cries for Common-English-on-all-Blue-Prints met
with only a smile. Jargon is developed by experts for its terseness and
succinctness (?). This _automatically_ separates the experts from the
great unwashed masses. But this is as it _should_ be.
N.B. this must not be used as an argument for not documenting one's work, or
for being needlessly unclear - it is but an observation that expertise, in seeking
optimums, will continually modify its communications, leaving nonexperts behind.
BTW the flip side of not creating expertise, or not seeking optimums, can be seen
in every bureaucracy, and unfortunately I've seen to much of it in computer code -
VERBOSITY!!! - it's like wading through garbage. It reminds me of the ol' story
about CRAP (Code Recorded by Another Programmer), as in "Hey, who wrote this crap!".
People are quite quick to forget the number one lesson of Structured Programming:
the purpose is to seek an optimum of economics! And it most economical to be terse.
I'm not talking about wasting disk space here... I'm talking about all the lost
hours we have to spend sorting through the meanderings of another undisciplined,
verbose programmer...
...but I digress <grin>
Dave Ruske
:[...] But Forth is not hard to learn and it can be written so other
: people can understand it. Its just that Forth programmers don't
Wow. If that's the stereotypical Forth programmer, I have a lot
of curly-braces in my future... I *NEED* to communicate with other
people, including a future *ME* who'll only have a vague recollection
of what I'm working on today. Speaking only for myself, Forth has
served me well in that regard, certainly no worse than C or assembler.
It really isn't surprising that myths about Forth persist outside the
Forth community.
Dave Ruske ...!uwm.edu!moci!dave
[Opinions mine, not ICOM's] GEnie: D.RUSKE1
M.F.Buchan
>Shall we decide the readability of C based upon publicly available C code?
>
>You better hope not! Who cares if some kook wants to claim that forth is
>unreadable because s/he found some pd source that is not well written?
>
>Until criticisms are based upon usage (versus flippant voyeuristic attacks)
>they are not to be taken seriously.
>
differentiate between comercial and PD code in terms of readability???
There's good PD stuff -- and bad. And -- for certain -- I've seen commercial
stuff [ manuals no less ] that left me climbing the wall in frustration with
their obscurity.
This applies to other languages just as much as to Forth.
Take Cobol [[ please -- please -- far away ]. I can't comprehend it AT ALL
-- and as I understand it the whole concept was to create something that was
"readable" to "non programmers" ??
MASM code [ well - at leat 808xx ] I can wander through quite happily and
work out what's happening with a minimum of comments -- but I guess that's
through many years of CP/M80 and using disassemblers and debuggers.
--
M.F.Buchan
Stephen J Bevan
>So where does that leave everybody? You have one side saying that
>Forth code isn't readable and pointing at various publically available
>pieces of code as evidence. The other side says you can write
>readable Forth code, but can/will not provide any code to back up the
>claim. It would seem the onus is on the latter camp to back up their
>claim or just ignore the "Forth is unreadable" claims. Unfortunately,
>it seems that most (all?) have chosen the latter course.
Don't you think such a demand is unreasonable?
There is no demand in the quoted section.
Let's apply this to <your favourite language here>. Take the C
language (please!).
Classic examples of good% idomatic C would be any of the code
that was written by Ritchie, Pike ... etc. Much of this you have to
pay to see, but there are a number of programs that are freely
available (perhaps the largest being all the source for the Plan 9
operating system).
Shall we decide the readability of C based upon publicly available C code?
No, but people do. That is why it is useful to be able to point at
freely available code that is generally considered to be well written.
You better hope not! Who cares if some kook wants to claim that forth is
unreadable because s/he found some pd source that is not well written?
I would think that FORTH vendors would, since that is one less
potential customer. Personally, I've yet to convince anyone to
_consider_ FORTH as an alternative for projects, but I have been able
to get them to consider languages such as Scheme and Prolog. _One_ of
the reasons being the availability of good _readable_ example programs
in these languages.
Until criticisms are based upon usage (versus flippant voyeuristic attacks)
they are not to be taken seriously.
The "flippant voyeuristic attacks" often come _before_ any usage or
after only minimal usage. Granted such attacks are generally the mark
of an ignorant person, but unfortunately it is the job of some people
to educate these people (ask any university lecturer :-) and their job
is made much easier by having good quality sources to hand.
-------
% Personally I think that much of their code lacks abstraction, but it
is possible that this is a deliberate choice given that the
abstraction would probably only allow less efficient implementation
to be hidden behind the interface.
Roger Bicknell
>In article <1993Aug2.2...@mdd.comm.mot.com> bick...@mdd.comm.mot.com (Roger Bicknell) writes:
> >In <BEVAN.93J...@tiger.cs.man.ac.uk> be...@cs.man.ac.uk (Stephen J Bevan) writes:
> >So where does that leave everybody? You have one side saying that
> >Forth code isn't readable and pointing at various publically available
> >pieces of code as evidence. The other side says you can write
> >readable Forth code, but can/will not provide any code to back up the
> >claim. It would seem the onus is on the latter camp to back up their
> >claim or just ignore the "Forth is unreadable" claims. Unfortunately,
> >it seems that most (all?) have chosen the latter course.
> Don't you think such a demand is unreasonable?
>There is no demand in the quoted section.
> > It would seem the onus is on the latter camp to back up their
> >claim or just ignore the "Forth is unreadable" claims.
Ok. Don't you think such an "onus" is unreasonable?
> Let's apply this to <your favourite language here>. Take the C
> language (please!).
>
>Classic examples of good% idomatic C would be any of the code
>that was written by Ritchie, Pike ... etc. Much of this you have to
>pay to see, but there are a number of programs that are freely
>available (perhaps the largest being all the source for the Plan 9
>operating system).
Yes, and "classic" examples of good Forth code can be found in
"Thinking Forth" and other such books.
> Shall we decide the readability of C based upon publicly available C code?
>No, but people do. That is why it is useful to be able to point at
>freely available code that is generally considered to be well written.
PD C code is every bit as unreadable as PD code in _any_ other
language. People who pick at pd Forth as a reason to claim it unsuitable
deserve their alternative.
Gary Chanson
to write either in ANY language, although some make one or the other a
little harder or easier. FORTH gives the programmer complete freedom to
make the program as readable as desired or totally write-only! In it's
favor, I'll point out that FORTH doesn't get in the way. On the other
hand, many FORTH programmers insist on using tools (editors, etc.) which
promote ugly results!
-GJC
Mike Coughlin
>In article <23lo60...@life.ai.mit.edu> mi...@gnu.ai.mit.edu (Mike Coughlin) writes:
>> ... unless readable Forth can be written by self-taught
>>programmers and unless PD systems with clear documentation are available
>>for beginning students then Forth is useless.
>
>This is a pretty sweeping claim. What has the usefulness of Forth
>got to do with the availability of PD systems?
>
transistors or even vacuum tubes, it took a team of smart mathematicians
to write system code and computer languages. Art and science have
advanced. Chuck Moore showed us one person could write an OS and
language combined while working on other computer projects. Instead
of needing many man years of time, one student can write a Forth system
for practice and afford to give it away for free. The existence of
many PD Forth systems proves that Forth works. We now have the job
of refining these to show Forth at its best. I don't think very
many skeptics will be convinced to buy Forth for $500 to $5000;
they will do so if they use a good free (or PD) Forth first.
>> ... If Forth can only be
>>properly learned by spending thousands of dollars and hundreds of hours
>>in the classroom, then other programming languages that can be learned
>>by high school computer kids at home from PD implementations will keep
>>Forth from being used.
>
>From what I've seen, most "high school kids at home" (and other
>casual programmers) are using languages like Visual Basic, Turbo
>Pascal, Turbo C, Think C --- *NOT* public domain anythings.
>
new langauges and always look for PD systems they can try out. If they
like what they see happening on their home computers with the PD
system they might spend some money for a commercial system.
In the case of BASIC, Pascal and C, they know these languages
are in general use and they get a copy when they buy their computer.
BASIC comes with most computers and is free as far as they are
concerned. If commercial Forth vendors had been able to convince
computer manufacturers to include Forth with the systems they sell,
we would have a completely different computer industry today. If
there were a bunch of popular computer applications that were
written in Forth, there would be a vastly larger interest in
learning to program in Forth. Since these reasons for knowing
about Forth are largely absent, I conclude that the best hope
we have for making Forth more popular is to somehow manage to get
new computer students to try a suitably written beginner's version
of Forth before their attitudes and habits are set in concrete.
The only way I can think of doing that is to hand them a PD disk.
>However, spending thousands of dollars and time in the classroom
>but well-documented fact that most programmers never read anything
>about programming.
>
came with their system to see why their programs don't work and they
read their operating system manuals to find out how to get other
people's programs to work. What they don't read is anything about
how to write better programs or even what makes a program good or
bad. I found that I learned about good vs. bad programs by the
example of other programmers I worked with. Many years later I
found out there were excellent books on how to write really good
programs. When I first read one of these I was afraid I'd never
get another job in programming because I couldn't compete with
the people who studied these books in school. Well, I didn't
have to worry. It takes years of experience before you know that
these books are saying something very important, and most people
don't pay any attention to them.
>> ... The many PD programs and systems that are
>>hard to read are just the beginnings of good code. They are waiting
>>for good programmers to optimize them for ease of reading and
>>speed of understanding. When Forth programmers take up this task,
>>Forth will gain it true place in the world....
>
>*SIGH*. Yet another half-baked, lame theory about why C and similar
>languages with traditional syntax, infix notation, data typing,
>and support for files/floating point/strings/etc. were successful
>and Forth wasn't.
Ha! My half-baked, lame theories are just as good as anybody
elses. Just look around. People use Fortran/Algol/Pascal/C/BASIC
(its all the same language) because they see everybody else using
it. If they saw more people using Forth, they would want to use Forth.
So lets get those better-than-average PD Forth systems out where
people can see them.
Will Duquette
mi...@gnu.ai.mit.edu writes:
>elses. Just look around. People use Fortran/Algol/Pascal/C/BASIC
>(its all the same language)
Not so. Spanish, French, and Italian may look the same to someone who
speaks Mandarin Chinese, but they are hardly the same language.
I *will* agree that they are all based on the same control structures,
these days...but there are things I would use C for that I wouldn't
use BASIC for, and vice versa.
---------------------------------------------------------------------
Will Duquette, | C Functions, SIMSCRIPT Processes,
WI...@SOLSTICE.JPL.NASA.GOV | but OPS5 Rules
Gregory A. Haverkamp
by Mike Coug...@gnu.ai.mit
>elses. Just look around. People use Fortran/Algol/Pascal/C/BASIC
>(its all the same language) because they see everybody else using
>it. If they saw more people using Forth, they would want to use Forth.
>So lets get those better-than-average PD Forth systems out where
>people can see them.
I tend to see this all the time. Most all of the programming at school
here is done using C. If you say you use anything but, you are scoffed
at, almost immediately. Therefore, people who are trying to be
"fashionable" in their programming will continue to use C. In fact, I
would say that most people at Carnegie Mellon (and folks from other
universities I've talked to) are practically bludgeoned into using C.
Heh. But I am not a computer science student, so I can use whatever
I want. For quasi-hacker-types like myself, it might be alright to just
get better-than-average PD Forth systems out there. Others, though, are
going to have to see that Forth is a real development platform, not some
goofy scripting language (as a number of people have thought) or
postscript, as others have said.
Folks in real-time classes here are using C to control motors and
such. And when they talk about the occasions they can't use C, they go
to assembly, which (in my mind) is fine... but Forth is around,
certainly, for most any of the platforms. No one realizes the
usefulness.
I don't think it is a problem of readability, to be honest. I don't
think it is a problem, in actuality, of a lack of good PD systems.
(digression: With a couple of exceptions. Most people now want to make
standalone code. And many people will not use Forth if standalone
applications cannot be created as they can in most C and Pascal
implementations.) Most people who are going to explore languages are
not going to worry about a language's clunkiness.
I think it is entirely a lack of visibility, as Mike mentioned
earlier in his post. Why do so many people think that DOS/Windows are
God's gift to the computer world? Because they know nothing else. That
is also why they think that C and Pascal are the only way to go. After
4 years of computer science education at Carnegie Mellon, graduates will
know how to program in assembly (I believe on the 68000 now), Pascal, C,
and scheme/lisp. Many do not know that Forth exists. And while they do
not come to CMU to learn to program, but to theorize, they will code,
and they will be directing others to code.
In essence, visibility is the key. Problem is: how does one obtain that?
Greg
_____________________
Greg Haverkamp -- gh...@andrew.cmu.edu, diet...@cmu.edu
Industrial Management - '94
Carnegie Mellon University, Pittsburgh, Pennsylvania
"Sometimes I think life is just a rodeo. The trick is to ride and make
it to the bell." John Fogerty, "Rock and Roll Girls"
M.F.Buchan
>of refining these to show Forth at its best. I don't think very
>many skeptics will be convinced to buy Forth for $500 to $5000;
>they will do so if they use a good free (or PD) Forth first.
>
It is indeed a chicken and egg situation -- the same applies to marketing
anything coomercial. If Fred next door has one [ whatever it is ] then soon
the whole street will want one.
On the other hand if you say "How about buying one of these widget enhancers"
the response is -- " eh - what?? never heard of them -- THEREFORE they can't
be much use"
If -- as you say -- the thing costs $500 to $5000 -- **and** has so many
bells and whistles BECAUSE it's designed to be "professional" [ incidentally
-- for a "professional market" that's in the author's dreams rather than
in reality ] -- then the newcomer is going to pass on by without a look.
Although I've seen many PDomain Forths -- IMHO they ALSO are predicated on
emulating the "professional" -- which often means [ again IMHO ] pandering to
the religious fanaticism aspects -- and AVOIDING the simplifications and
enhanced user-friendliness that is NEEDED to attract newcomers.
> In the case of BASIC, Pascal and C, they know these languages
>are in general use and they get a copy when they buy their computer.
>BASIC comes with most computers and is free as far as they are
>concerned. If commercial Forth vendors had been able to convince
>computer manufacturers to include Forth with the systems they sell,
>we would have a completely different computer industry today. If
Well -- actually there WAS a British "home computer" marketed many years ago
with a Forth based OS. Can't recall the name now -- but it died a death due
to a) lack of UK computer awareness at the time b) a very limited capability
anyway.
However -- apparently there's a language [ and again apologies -- my memory
is like a sieve - I'll let you know the name when I look it up ] that was
written by a UK firm for the BBC micro to allow it to handle music
programming. Someone asked about the availability of this today, on
Compuserve but apparently it's no longer available. He gave me some sample
programs and it was essentially Forth. The guy was WILDLY enthusiastic about
its SIMPLICITY -- he being a musical composer -- not a programmer.
There's also a "new" [ ?? ] version of Forth advertised now that handles
Music -- ELUS by Eleusinian Enterprises. I got the advertising blurb -- and
seemingly it's based on MVP Forth [ 7997 Phaeton Drive, Oakland, Calif
94605-4212 (415) 562-2055 if anyone's interested )
I was VERY interested -- till I saw it was based on 1024 byte screens. That;s
when it hit the garbage bin <g>.
Finally -- no names <g> -- but in a reply to a comment I made a year or so
back on Compuserve re PDomain Forths -- a representative of the commercial
field passed the comment [ hope I don't misrepresent ] that PDomain writers
were RESPONSIBLE for the failure of Forth as a language -- because they had a
religious zeal [ implied => to produce good stuff ] to give away for FREE to
everyone they encountered -- and all this free stuff meant that insufficient
people bought the commercial offerings to subsidise the work that was needed.
I see the logic of the argument -- but IMHO it implies that the guy who just
wants to "play around" should be buying a $500 commercial offering -- and
that this -- raher than the "professional" user sales base -- is where the
steady money comes from.
It's relevant to consider the Midi software issue. There's a MASS of PDomain
midi scoring/sequencing software free for download -- but this doesn't kill
the commercial stuff -- quite the reverse.
What most Midi software houses [ including BIG names ] do is to upload to
areas like Compuserve Midiforum "DEMO" versions -- these being FULLY
FUNCTIONAL commercial products -- with NOTHING removed -- except that they a)
won't write to disk b) have limited printout abilities [ 2 pages ] c) in some
cases wipe all memory every ten minutes.
The last section c) is IMHO excess paranoia -- and a turnoff.
Let's have some COMMERCIAL Forth Demos for download -- reasonable docs on
file -- able to write and run programs -- but moderately "crippled" so you
have to buy the real thing if you want to do anything serious. The very LEAST
it would do is spread AWARENESS of what it's all about -- and an ability to
compare "hands on" without forking out $500 or more.
Larry
Ps -- sigh!! just got off my butt and went downstairs where all the old fax
messages are kept. The langauge was called AMPLE -- and I'll outline it in a
parallel message.
M.F.Buchan
Micro. This was a FORTH based language called AMPLE -- and I only heard of it
when a devoted user of it asked on Compuserve MidiForum if an equivalent was
available for the IBM-PC as he wanted to move away from the Beeb on to a PC
base. As far as I know no equivalent exists -- though ELUS may develop that
way.
Samples from INDEX OF WORDS
! move an extra octave up or down
" start literal string
#! store number at address
#* multiply two numbers
#11 duplicate number
#12 swap two numbers
#212 duplicate previous number
#2121 duplicate number and previous number
#213 rotate positions of three numbers
#2 discard number
$12 swap two strings
% introduce comment
& indicate hexadecimal number
( start additional chord notes
+ sharpen next note
: set octave
; set music voice
ACT( start music action sequence
)ACT end music action sequence
ACT execute music action
( comment => here I assume FRED( and JOE( etc are the defining
equivalents of conventional Forth : FRED and : JOE
while the terminating semicolon is replaced by )FRED )JOE etc )
AMPLE restart system
FOR( start definite loop FOR( .... )FOR
SHOW show user words
SCORE prepare for music words
SIMPLEACT remove all music actions
VAL convert string to unsigned decimal number
&VAL convert to unsigned hex number
Well -- enough to show that it's FORTH oriented -- but "original" <g> enough
to give the screaming hab-dabs to an orthodox-Forth religionist. [ probably
send an ANSI addict to the fruitcake wards !! ]
The prefix # seems to define fairly characteristic Forth words applied to
numbers. Seemingly numbers and strings are held on separate stacks. The whole
thing is 6502 based.
I repeat -- the info is all second hand from a wildly dedicated user -- a
non computer oriented mind -- purely a [ professional ] composer of music --
albeit computer generated music as opposed to conventional melodic harmony
based.
SO WHAT??? I hear someone ask <g> -- well maybe it's time someone DID market
a commercial Forth system that actually **DOES** something -- instead of
being a replica of a Swiss Army knife -- with an extension for taking Boy
Scouts out of horses' hooves!
ie -- concentrate on an APPLICATION -- rather than merely a TOOL of such
extreme generality that it has meaning only in a narcissitic admiration of
its own beauty and simplicity. Doesn't have to be music oriented -- choose
something people WANT to do currently. Networking?? Databases??
Spreadsheets?? Communications ?? For a language which boasts extensability I
find it odd that we have masses of "libraries" for C and MASM -- but as far
as I know ZILCH in terms of loadable files [ screens if you MUST ] to turn a
kernel Forth system into an application oriented interpreter/compiler.
Larry
Andrew Haley
>Many years later I
>found out there were excellent books on how to write really good
>programs. When I first read one of these I was afraid I'd never
>get another job in programming because I couldn't compete with
>the people who studied these books in school. Well, I didn't
>have to worry. It takes years of experience before you know that
>these books are saying something very important, and most people
>don't pay any attention to them.
Mike, I'd love to know which books you mean. I've quoted "The
Elements of Programming Style" (which I think is great) here. What
books do you recommend?
Andrew.
Dave Ruske
: [...]
: Let's have some COMMERCIAL Forth Demos for download -- reasonable docs on
: have to buy the real thing if you want to do anything serious. The very LEAST
: it would do is spread AWARENESS of what it's all about -- and an ability to
: compare "hands on" without forking out $500 or more.
Yet another oddly persistent myth: commercial Forth systems are all
unreasonably priced. A fellow I met through the Southern Wisconsin FIG
chapter recently downloaded LMI's FirstForth from their BBS. He sent
in the $50 registration and received what he described as a very nice
400 page book, well worth the price of registration (I haven't seen
this one yet myself; he said he'd bring it to our September meeting).
LMI's WinForth for Windows 3.1 is $100, and in my opinion is well worth
the price just for playing with the Windows API.
I'm not trying to do an LMI commercial here -- I'm a customer, not a
vendor -- but it's a product line I have some familiarity with. Here
are a few other prices, extracted from the July/August 1993 Forth
Dimensions:
MMSForth $ 179.95
HS/Forth $ 299.00
Yes, there are options available on all these products which raise the
price. But the claim that you can't get your hands on a commercial
system and start doing useful work with it for less than $500 appears
(to me) to be unsupported.
Dave Ruske ...!uwm.edu!moci!dave
M.F.Buchan
>lar...@rothesay.demon.co.uk (M.F.Buchan) writes:
>: [...]
>: Let's have some COMMERCIAL Forth Demos for download -- reasonable docs on
>: file -- able to write and run programs -- but moderately "crippled" so you
>: have to buy the real thing if you want to do anything serious. The very LEAST
>
>: it would do is spread AWARENESS of what it's all about -- and an ability to
>: compare "hands on" without forking out $500 or more.
>
>Yet another oddly persistent myth: commercial Forth systems are all
>unreasonably priced. A fellow I met through the Southern Wisconsin FIG
>chapter recently downloaded LMI's FirstForth from their BBS.
Ahhh -- well if that's AVAILABLE I withdraw what I said. However -- a) I live
in UK and not within affordable [ yeah -- money "overheads" on package cost
again ] phone distance of a US BBS b) I haven't seen this package on things
I **can** access like Compuserve or Internet-Simtel c) It's not listed in any
catalog I have [ more on catalogs later ].
Simply replace "UK" with "the rest of the world bar USA" -- because what
we're talking about is acceptability of a computer language generally.
>LMI's WinForth for Windows 3.1 is $100, and in my opinion is well worth
>the price just for playing with the Windows API.
>
Now I **did** see this advertised somewhere I must admit. As I recall it was
when I "into windows" and considering the MSoft SDK kit -- but I'm more
inclined to OS/2 now -- when I get there <g>.
> MMSForth $ 179.95
> HS/Forth $ 299.00
>
Looking through the only up to date US catalog I have handy -- The
Programmers Shop; Spring 1993 -- the only Forths which are advertised are
ELUS at $239 [ discounted ] and HS/Forth Production at $489 discounted.
The Spring 1991 Programmers Connection catalog doesn't even appear to mention
ANY Forth systems.
However -- the "established" UK compnay "Grey Matter" lists in their May 1993
catalog HS Forth Personal 3.8 at UKL 300; HS Forth Production at UKL 495; HS
Forth Professional at UKL 370 and UR Forth (OS/2 & DOS) at UKL 370.
I can ASSURE you that NONE of these prices are even remotely "trivial" enough
for a guy [ me ] to say " Oh gee -- that's only a month's pension income --
I'll buy one for the hell of it and let my family eat bread for a month".
Nor for that matter is your MMSForth at $ 179.95 something that would
PERSUADE a non-Forth addict -- a mildly curious "what is this thing called
Forth" bright-eyed C or Basic fiend to raid his money box for.
>Yes, there are options available on all these products which raise the
>price. But the claim that you can't get your hands on a commercial
>system and start doing useful work with it
We haven't yet GOT to the stage of wanting to do "useful work" -- we're at
the stage of AVAILABILITY for NEWCOMERS. That's where the shareware/freeware
issue arises.
> for less than $500 appears
Well Dave -- $500 is something I personally can't afford to throw away on a
"maybe I'll like it -- whatever it may be" software package. You're talking
real alternative buying power here in terms of things like disk drives;
SIMMs; sound cards; etc.
Anyway -- I don't think I was suggesting there may not BE "reasonably" priced
low-end commercial products around. I was simly advocating the Freeware or
Shareware non-commercial offerings as a VALUABLE medium to INTRODUCE Forth to
people who were either too financially underpriveleged <g> -- or not yet
adequately fired-up with religious zeal -- to fork out $$$$ up front to sdo
no more than FIND OUT what it's all about.
Going back to midi -- I doubt if I personally would EVER have bought a $200
and a $500 midi sequencing/scoring package had I not first downloaded dozens
of a) crippleware commercial demos [ including those I eventually bought ] b)
Shareware equivalents.
Add to that the downloadable midi song-files themselves [ equivalent to
typical Forth Source code to load in and do real things with ].
And again a MidiForum community who aren't [ as with Forth ] saying "we were
given the truth by an angel descending from heaven -- it's the supreme one's
gift and must NEVER be defiled by innovation" -- a Midi community who say
"try it -- there's lots of variation -- yeahh -- THAT bit's REALLY bad -- but
this new approach is fantastic".
It's the religious zealotry and conservatism of the "established" Forth
community that IMHO kills Forth stone cold dead. You do it THEIR way -- or
you 'aint even worth talking to.
Going back to a previous comment I made about the extensive Forth "non
commercial freeware" availability < allegedly > killing off commercial
vendors' market opportunities -- I will agree that there's a large body of
the "user community" who regard Shareware -- and anything bbs related -- as
dangerous; inferior; and probably virus loaded. If a language - or any
utility - is NOT high profiled in their retail outlets or catalogs - then
they don't WANT to know about it.
The Forth PDomain stuff is really only "seen" by bbs users -- and the
"maverick" community who frequent what's seen as a "shady" Shareware
secret-society. At least that's the UK situation. Though my impression is
that Forth a language is NOT as "unknown" in UK as is being implied re US in
these discussions. It's a fairly small "specialised community" that sells and
uses it though -- as opposed to the wide market C and C++ and such like sees.
All software here is grossly over-priced anyway.
For that matter -- I haven't noticed much effort in this news area -- or on
Compuserve -- for commercial vendors to advocate either their product; or
Forth generally. Sorry to mention CServe again -- but the presence of "Vendor
areas" is a highlight -- Borland - Centre Point - MSoft - etc. The only Forth
presence I know of is in a MAC oriented Forth area which is very low profile.
Maybe the salient vendors should get up on the rooftops and shout a bit more
-- rather than leaving it to PDomain fringe activists <grin>.
Let me add that befor I retired I worked overseas teaching computer
applications to engineering students. I did make sure that we bought LMS
UR-Forth -- and HS Forth -- and before that LMS-Z80; Stackworks; and all the
other short-lived CP/M80 Forth packages that I saw in BYTE etc. I was lucky
enough to work in a system which encouraged and financed this. What I'm
discussing here is the user community which can NOT afford to "buy on the
offchance".
Did I manage to "spread the WORD"? For a short time - yes. But alas it was a
VERY "fashion conscious" community. No software package would survive when a
"later version" appeared -- DOS included. When Turbo Pascal came along --
that was the rage. Then C appeared -- then C++. Used to drive me crazy that
no-one would "stick with" anything long enough to develop a substantial
familiarity and support base. I doubt if I went back now and looked that
anyone could even FIND these Forth packages -- much less could the guy I
"handed over" control and security to. And we even bought a site licence for
one of them. Sad -- sad -- because they were VERY bright and intelligent
people.
The only language I suspect HAS survived -- ad inf -- will be Fortran;
because I suspect it's still on the networked mainframes -- with large
"engineering and maths" libraries to link to. And I guess I'd still find
people sitting glassy eyed at a catatonic terminal watching their program
compile at 3 or 4 lines per minute -- while their PCs run the very latest red
hot pirateware -- multitasking with the latest virus. Maybe I'm too cynical
<g>.
Larry
Julian V. Noble
>
> Well -- actually there WAS a British "home computer" marketed many years ago
> with a Forth based OS. Can't recall the name now -- but it died a death due
> to a) lack of UK computer awareness at the time b) a very limited capability
> anyway.
>
> However -- apparently there's a language [ and again apologies -- my memory
> is like a sieve - I'll let you know the name when I look it up ] that was
> written by a UK firm for the BBC micro to allow it to handle music
> programming. Someone asked about the availability of this today, on
> Compuserve but apparently it's no longer available. He gave me some sample
> programs and it was essentially Forth. The guy was WILDLY enthusiastic about
> its SIMPLICITY -- he being a musical composer -- not a programmer.
>
>
> Ps -- sigh!! just got off my butt and went downstairs where all the old fax
> messages are kept. The langauge was called AMPLE -- and I'll outline it in a
> parallel message.
I believe there was/is a FORTH-based music language called Formula.
The name of the British FORTH-based machine that died was Jupiter Ace.
It was a very nice machine, except for
a) chiclet keyboard (ugh!)
b) didn't use PALs (unlike the ZX-81) so it had a huge
glue-logic chip count.
c) probably was underfinanced.
As a machine it ran rings around the Sinclair ZX-81 (of which I own 2),
and when I added an AMD 9511 math co-processor to mine it screamed.
(Someday I'll write an article for FD about the Jupiter and my math
board. Sigh...)
--jvn
Dave Ruske
: [...]
: Anyway -- I don't think I was suggesting there may not BE "reasonably" priced
: Shareware non-commercial offerings as a VALUABLE medium to INTRODUCE Forth to
: people who were either too financially underpriveleged <g> -- or not yet
: adequately fired-up with religious zeal -- to fork out $$$$ up front to sdo
: no more than FIND OUT what it's all about.
: Compuserve -- for commercial vendors to advocate either their product; or
: areas" is a highlight -- Borland - Centre Point - MSoft - etc. The only Forth
: presence I know of is in a MAC oriented Forth area which is very low profile.
: Maybe the salient vendors should get up on the rooftops and shout a bit more
: -- rather than leaving it to PDomain fringe activists <grin>.
Agreement on both points: PD systems are useful to get people to play
with Forth, and it'd be nice for vendors to keep a higher profile (though
they have to be able to afford to do so when it comes to advertising,
which isn't cheap). I don't dispute the usefulness of PD systems, but
I did want to bring into question the oft-repeated "shelling out $500
for a commercial Forth" phrase.
One of the reasons I'd like to see vendor products succeed is so the
vendors could afford to advertise in mainstream computing publications.
People can't buy what they've never even heard of, and unless they've
heard of Forth, they very likely don't read comp.lang.forth or FD.
Anyway, Larry, thanks for the detailed reply. You bring up many fine
points.
Cheers,
Dave Ruske ...!uwm.edu!moci!dave
Julian V. Noble
>
[ stuff deleted ]
>
> SO WHAT??? I hear someone ask <g> -- well maybe it's time someone DID market
> a commercial Forth system that actually **DOES** something -- instead of
> being a replica of a Swiss Army knife -- with an extension for taking Boy
> Scouts out of horses' hooves!
>
> ie -- concentrate on an APPLICATION -- rather than merely a TOOL of such
> extreme generality that it has meaning only in a narcissitic admiration of
> its own beauty and simplicity. Doesn't have to be music oriented -- choose
> something people WANT to do currently. Networking?? Databases??
> Spreadsheets?? Communications ?? For a language which boasts extensability I
Well, Peachtree Accounting is supposed to be written in FORTH (at least
the original and some subsequent versions were--it may be written in Lisp
today for all I know!); the ill-fated VP-Planner, that ran rings around
Lotus 1-2-3 and was eating its lunch was put out of business by a battery
of Lotus' lawyers for copying Lotus' "look and feel" (which up to that time
had been specifically held to be uncopyrightable!) was FORTH throughout.
Sopha Imaging Systems (or some such name) use FORTH for gamma ray imaging
(and possibly PET also). It gives them a huge price advantage since they
can use a 68K machine to do what other vendors require a major workstation
for.
In other words, there are plenty of examples to be found, it's merely that
the FORTH community has no full-time publicist to get these apps into
the public awareness.
In fact, there have been many applications of FORTH in the marketplace that
have done well; however, there has been a tendency for programmers not to
emphasize that fact because FORTH is a "flaky" language and corporations
might not buy the product on that account.
If you think I am dreaming this mindset, ask Elizabeth Rather. She has
had the opportunity to observe the near-indomitable corporate herd instinct
that permeates US corporate decision-making.
More interesting, many of FORTH, Inc.'s customers do not permit their
names to be used in publicity--they apparently consider FORTH their
competitive edge and hesitate to alert others of that fact.
--jvn
M.F.Buchan
>lar...@rothesay.demon.co.uk writes:
>> ie -- concentrate on an APPLICATION -- rather than merely a TOOL of such
>> extreme generality that it has meaning only in a narcissitic admiration of
>> its own beauty and simplicity. Doesn't have to be music oriented -- choose
>> something people WANT to do currently. Networking?? Databases??
>> Spreadsheets?? Communications ?? For a language which boasts extensability I
>
>Well, Peachtree Accounting is supposed to be written in FORTH (at least
>the original and some subsequent versions were--it may be written in Lisp
>today for all I know!); the ill-fated VP-Planner, that ran rings around
>Lotus 1-2-3 and was eating its lunch was put out of business by a battery
>In other words, there are plenty of examples to be found, it's merely that
>the FORTH community has no full-time publicist to get these apps into
>the public awareness.
Sorry -- me failing to be explicit again! I didn't mean turnkey utilities
which happened to be written in Forth -- after all -- who CARES what langiage
their wprocessor or spreadsheet is written in -- so long as it doesn't
"suffer" any of the alleged shortcomings of that language.
What I meant was instead of having what I see as [ Commercial ] Forth
compilers which are TOTALLY general -- even in the loadable screens or files
-- write one [ in fact several ] which is APPLICATION oriented.
The notable application I had in mind [ from personal interest ] was a
Music-Midi based application. ELUS claims to do this.
Sure -- there ARE libraries for linking in C, ASM. Basic, Pascal etc --
specifically the MusicQuest programmers' toolkit. Lisp tends to be popular --
and at least one comprehensive Midi scoring-sequencer [ Personal Composer ]
had a Lisp Interpreter built in to it. Where is the equivalent in Forth???
Doesn't EXIST imho -- because [ again imho ] Forth compiler writers are too
busy admiring their own Forthian reflections in the mirror to even THINK of
writing it to cater to a specific market.
The attitude seems to be -- here is the tool -- if you want to carve
animal-figurines or doorposts -- we don't want to know. Just be grateful for
the beauty and simplicity of the TOOL we gave you. Go away and write your OWN
funny peculiar midi words.
Let's be specific -- and definite. I virtually GUARANTEE that if you wrote a
COMPREHENSIVE midi/music compiler based on Forth -- PROVIDED the user
interface was designed to interface with a moderately-proficient
MUSICIAN-programmer [ rather than assuming a Forth-for-its-own-sake
worshipper who loved blocks and shuffling stacks ] -- it'd be an instant
success. And from that an appreciation of Forth itself COULD flow.
No disrespect to the guy who's writing all these FAQ messages on Forth --
they're excellent **BUT** only IMHO to the "already converted". To someone
who's wondering just what Forth is all about -- they seem to me like
explaining what an automobile is for by describing carburettors; ignition
systems; fuel pumps etc.
I repeat -- imho Forth is about building up an inverted pyramidal program
from a few simple words -- each of which can be individually tested. Words
exist to interact with the computer operating system "transparently" from
within Forth. It's a language in which words are compiled [ threaded ] as
they're defined. Facilities are inbuilt for tracing the execution of words --
and decompiling. Words can be in assembly or in lower order Forth words. End
of story!
Larry
Kyle Hayes
>Sure -- there ARE libraries for linking in C, ASM. Basic, Pascal etc --
>specifically the MusicQuest programmers' toolkit. Lisp tends to be popular --
>and at least one comprehensive Midi scoring-sequencer [ Personal Composer ]
>had a Lisp Interpreter built in to it. Where is the equivalent in Forth???
>Doesn't EXIST imho -- because [ again imho ] Forth compiler writers are too
>busy admiring their own Forthian reflections in the mirror to even THINK of
>writing it to cater to a specific market.
For lisp, do not forget Emacs. How many people out there use Emacs? Here
it is around 90%.
Forth is apparently used (in various disguises) in MUDs. I have been
told from people who use them/play them that the base script language
in many MUDs is Forth or at least Forth-like. I have not used them myself,
so it may not be Forth, only some Forth-like language that is used.
This does bring up a point. Where are all the little utilities written in
Forth? The little directory programs, the little sorting programs etc. that
many people used to learn C/Pascal/<fill in language here>. I mean programs
that manipulate things external to the environment/language. Every
time I try to access the site in Portugal, it is down, too slow, or does
not even show up. I can find PD Forths for the PC, and one for Unix
(tile), but other than that, basically _no_ example programs. Where
are they hiding?
>The attitude seems to be -- here is the tool -- if you want to carve
>animal-figurines or doorposts -- we don't want to know. Just be grateful for
>the beauty and simplicity of the TOOL we gave you. Go away and write your OWN
>funny peculiar midi words.
Unfortunately, this is certainly the impression I have had. A raw
language is pretty uninteresting to most people, and Forth's core is
even smaller than most. For instance, why is there no quick and dirty
Forth programming environment for X windows in the public domain?
(If there is, I have never seen it referenced). It probably wouldn't
be that hard, you could just use Tcl/Tk as an embedded command language
for the windowing... Oops, no you can't, sorry, Forth does not talk to
other languages or libraries. No Tcl/Tk, no X windows... So,
no Forth/Emacs super app.
I think this is one of Forth's biggest problems. With other
"standard" languages it is relatively easy to use other libraries as
long as they were written in one of the other "standard" languages.
They all use similar stack conventions (compiler optimizations don't help)
and have similar ideas. I know that there are commercial Forths out there
that do let you link in things, but when this is showing up in the most
simple PD languages, Forth's lack is a bit glaring.
Few are going to be interested in a language where the only thing the examples
show how to do is manipulate the language! It is usually the interest in
seeing the language perform something useful that catches the eye of a
potential language user. Smalltalk went nowhere fast until usable
end-user systems started to be produced with it.
There are even public domain versions with usable libraries. You can get Little
Smalltalk free via FTP and there is an optional windowing package that
works under X. GNU Smalltalk has a windowing package in Alpha or
Beta test (I forget which).
I am concentrating on windowing here, because that is one of my personal
interests, but you could substitue nearly any package of functionality;
files, text handling etc. If I have to hack away for months writing my
own libraries -- knowing full well that no one else will use them -- to do
anything, then Forth will definitely remain shelfware for me. Interesting,
but shelfware. It has a _LOT_ of potential, but I sure do not see it being
used in much public domain code.
>Let's be specific -- and definite. I virtually GUARANTEE that if you wrote a
>COMPREHENSIVE midi/music compiler based on Forth -- PROVIDED the user
>interface was designed to interface with a moderately-proficient
>MUSICIAN-programmer [ rather than assuming a Forth-for-its-own-sake
>worshipper who loved blocks and shuffling stacks ] -- it'd be an instant
>success. And from that an appreciation of Forth itself COULD flow.
Any widely useful software written in Forth that was usable by people
who had no particular interest in Forth will spread Forth. Most people
here who use Emacs do not fiddle with the Lisp inside. They do know how
to use the program other than that. The fact that it is a programming
environment (to some extent) allows that there are dozens if not hundreds
of special little Emacs Lisp programs floating around. Most people
(here) do not write them, but they collect them like packrats.
I assume that the same is somewhat true for Forth. Of course, it helps
that Emacs Lisp is relatively stable and has a large library written for
it already. I would not want to write a text editor from a bare Emacs Lisp
interpreter!
>No disrespect to the guy who's writing all these FAQ messages on Forth --
>they're excellent **BUT** only IMHO to the "already converted". To someone
>who's wondering just what Forth is all about -- they seem to me like
>explaining what an automobile is for by describing carburettors; ignition
>systems; fuel pumps etc.
I think this is a good point.
>I repeat -- imho Forth is about building up an inverted pyramidal program
>from a few simple words -- each of which can be individually tested. Words
>exist to interact with the computer operating system "transparently" from
>within Forth. It's a language in which words are compiled [ threaded ] as
>they're defined. Facilities are inbuilt for tracing the execution of words --
>and decompiling. Words can be in assembly or in lower order Forth words. End
>of story!
I agree here. Since the core of Forth is potentially miniscule
(how few predefined words do you need?), Forth is really more of
a methodology or philosophy than a language. In a sense. There
are not really any key words (beyond ":"?) unlike C, Pascal, Fortran,
Ada, Modula-2/3, etc. etc. If you take out everything that does not
have to be there to implement the language, you get a very small
handfull of primitives and a methodology for programming.
I would disagree that the facilities for tracing etc. are really part
of the language. They may always be included in a core distribution,
but seem to be implementation (thus not language) dependent. The
class browser, stack viewer etc. in Smalltalk are not part of the
Smalltalk language and their functionality is done in different ways
on different Smalltalk platforms.
Best,
Kyle Hayes
technische universiteit eindhoven
ky...@info.win.tue.nl
M.F.Buchan
>For lisp, do not forget Emacs. How many people out there use Emacs? Here
>it is around 90%.
>
I've never got round to looking at Emacs -- just seen various references in
other editors to "Emacs Compatability" -- so decided to see what I could ftp
relative to Emacs.
I find in the Simtel20 area four subdirectories -- demacs -- freemacs --
oemacs -- and uemacs. Could you [ or anyone else ] tell me the relative
merits of each -- and which one is "best" to look at first. Clearly I'm not
interested in any that has omitted the lisp intepreter feature you talk of.
Larry
Ian Woollard
>far as I know, this fact was not known until the Michelson-Morley
>experiment. Hmm, maybe Einstein found the ether idea disgusting and
>just wanted to do a theory without it.
Actually the constancy of the speed of light *is* in Maxwells equations,
and they predate relativity by decades... The only problem was, even
Maxwell didn't believe it... but Einstein did.
-Ian
<It's a quantum thing. It is indeterminate whether one exists until
someone /usr/bin/fingers you to find out.>
<I'm logged in so therefore I am.>
--
-Ian
<It's a quantum thing. It is indeterminate whether one exists until
someone /usr/bin/fingers you to find out.>
<I'm logged in so therefore I am.>
Mike Haas
>>So from where did he know that light has a certain, fixed speed? As
>>far as I know, this fact was not known until the Michelson-Morley
>>experiment. Hmm, maybe Einstein found the ether idea disgusting and
>>just wanted to do a theory without it.
>
>Actually the constancy of the speed of light *is* in Maxwells equations,
>and they predate relativity by decades... The only problem was, even
>Maxwell didn't believe it... but Einstein did.
>
>-Ian
><It's a quantum thing. It is indeterminate whether one exists until
>someone /usr/bin/fingers you to find out.>
><I'm logged in so therefore I am.>
>--
But certainly Einsein understood the relationship between
CREATE and DOES>!
(What's that? Einstein lived WHEN? Oh...)
Make that... BUILDS and DOES>!!!