ir230@sdcc6.ucsd.edu (john wavrik) (02/15/90)
Remark:
This thread was originally started by Doug Philips with questions
about why the Forth community does not regard Postscript as Forth.
Philips now says that his intent was to clarify his understanding of
"the Essence of Forth" -- I am renaming the thread in accordance with
this intent.
-------------
Mitch Bradley makes some comments as a contribution to the discussion
about "Why Postscript is not Forth". The quotes below marked # are
from his article 2226.
I.
When a computer scientist talks about the formal properties of Forth
there is always a tendency for users to read in negative connotations
which may, or may not, be either intended or even important. There is
an air about the way comments are made that give them weight. What
Forth programmer does not shrink in shame to learn that 'D' (the
successor to 'C' being heavily pushed by by Yamaha which bought out
AT&T) has orthogonally tangential control structures, while Forth does
not?
Computer scientists have as sure a belief that the power of a computer
language comes from an accumulation of formal properties as
programmers do that it comes from subjective factors: how the language
"feels" and how expressive it is.
Forth (and other semi-compiled or interpreted languages) seems to be
called to task for the lack of attributes which are more appropriate
in the world of compiled languages. Since so few languages provide an
interactive environment, there is apparently little recognition of the
fact that to get a language to run interactively and efficiently
requires a different set of implementation decisions than a language
designed for pure compilation.
One case in point is typing of data objects (primarily important for
error trapping and for the overloading of operator symbols). Some find
it objectionable that a Forth system has several names for addition
operations: + and D+ together with, perhaps, F+ in a basic system and
then $+ for concatenation of strings, and, if you are doing math
programming, perhaps also a MD+ for addition mod p, MAT+ for matrices,
P+ for polynomials. Compiled languages allow all addition-like
operations to be performed by the same symbol + because the decision
of which + to perform can be made by the compiler. In an interpreted
language, where the decision usually cannot be made until run time
(experiments with multiple CFAs notwithstanding), a choice must be
made as to whether or not to overload symbols. As Mitch Bradley points
out, Postscript chooses to type its objects and allow overloading of
symbols -- which results in substantial run time penalties:
# 1) Operator overloading. Many of PostScript's basic operators operate
# on multiple data types. The operator (e.g. "add") must test its operands
# at run time and decide what how to handle them. In some cases, it
# may be possible to optimize some of this at compile time, but the
# compiler's ability to do so is somewhat compromised by the default
# late binding (see 3), and the "visibility" of innards of the compiled
# procedure.
APL also does this -- but the overloading is restricted to system-
defined data types. Interpreted BASIC (dare I mention it) also does this.
Overloading of operator symbols requires typing of objects. The idea that
it is desirable is inherited from our experience with compiled languages,
where it does not exact a runtime penalty. The use of overloading in
interactive languages exacts a substantial runtime penalty -- it is one
of the reasons that people believe that interactive languages must be
slow.
Part of the examination of the "essence of Forth" should involve looking
at the distinction between compiled and interpreted languages. One must
ask questions like "Is it really better or easier to write programs if
one is allowed to confuse several conceptually different operations by
giving them the same name?" [Since, in traditionally implemented Forth,
the children of the same defining word have the same address in their
code field, some typing information is available for those who want to
experiment. My own conclusion is that overloading symbols does not
facilitate the programming I do -- and certainly does not justify the
runtime penalty.]
P.S. In a private communication, Mitch Bradley has reminded me that
many of the things I have attributed to Charles Moore actually
should be credited to the FIG team that first defined the model
that popularized Forth. So let me acknowledge the wisdom of Bill
Ragsdale, John James, Kim Harris, and others who were part of
this effort.
Later in this article, Mitch Bradley will say "I claim that 'Forth-
like' means 'ad-hoc' and I will respond by saying "It is ad hoc in the
best sense -- it is designed to produce the best practical solution to
the problem at hand". The traditional Forth approach to overloading
symbols is not to do it (because of runtime penalties) but to provide
the means if it is deemed necessary. The same applies to range checking
of arrays, having functions check the number and types of their
arguments, etc. I think part of the "essence of Forth" is to provide
tools to build appropriate features rather than provide features which
may or may not be appropriate.
II.
Bradley, in describing Postscript vs Forth, says:
# As stated above, the visibility of the stack is a similarity, and the
# fact that the stack elements are typed abstract objects in PostScript
# and untyped bit patterns in Forth is a fundamental difference.
I think this is misleading. It's like saying that your checkbook is an
organized collection of accounts and debits while the arithmetic
calculations on the paper next to me is a collection of curves and
lines made with a pencil. It is quite possible to program in Forth in
such a way that the programmer visualizes the objects on the stack as
abstract objects: I have two strings on the stack -- I SWAP them, then
take the left three characters of the string on top of the stack and
concatenate the two. (The fact that what is really on the stack are
untyped bit patterns is incidental -- the fact that these bit patterns
are pointers to data which occupy a segment of memory provided by a
dynamic allocation scheme was something I thought about when I wrote
the string package -- the fact that the end result is that there are
STRINGS on the STACK which I can manipulate with consistent Forth
semantics is what is important to me as a programmer.)
Can a programmer in Forth think about stack elements as if
they were abstract objects? -- YES.
Can a Forth programmer think about stack elements as other
things? -- YES.
Does the language force the Forth programmer to think of stack
elements as untyped bit patterns? -- NO.
III.
# Obviously, this depends on a subjective judgement of what "Forth-like"
# means. I claim that "Forth-like" means "ad-hoc".
Here I strongly agree. Forth was designed pragmatically rather than as
an embodyment of someone's theory of programming languages. It was
designed by a programmer to solve programming problems. It is ad hoc
in the best sense -- it is designed to produce the best practical
solution to the problem at hand.
# Forth is rarely
# consistent about anything. The naming is inconsistent, the syntax is
# reverse polish except when it isn't, there are 4 different kinds of
# strings, there are some obvious comparison operators that just happen
# to be missing.
Here I disagree. I think the semantics involved in Forth are fairly
consistent. Some of what has been posted recently regarding the
supposed dual PRE/POST-fix nature of Forth syntax stems from a desire
to have undeclared strings be a fundamental data type. If undeclared
strings are not a fundamental type then they are (consistently)
preceeded by a handler.
If I treat horses differently than chickens, I'm only inconsistent to
people who think I should treat all animals the same way. To the best
of my knowledge, I have never treated a chicken like a horse.
(Sometimes I do treat horses like chickens -- but that's just my
"ad hoc" nature 8-)
# No wonder Forth doesn't have a good standard string package; nobody
# can figure out which string representation to use. Besides which,
# the lack of dynamic memory allocation facilities makes it pretty hard
# to figure out where to put them.
Forth is fairly consistent in storing its strings as counted strings.
(I don't think that null-terminated, for example, is ever used when
treating the string as a unit -- although the Forth-79 EXPECT produced
a null-terminated string.) The fact that a string be treated as a
unit (e.g. can be pointed to by a single address) is important in
allowing standard stack manipulation words to be used. The fact that
TYPE uses an address and count extends its usefulness, COUNT should
not be thought of as producing a different representation, just as a way
of generating parameters for a word that can also be used for other
things.
An examination of the limited string manipulation which takes place
within the Forth system ignores the mechanisms which can and have been
sucessfully used by Forth programmers to added string handling
capability to their systems. Forth does not contain a string package.
Forth supports a variety of string packages which can be added on.
III.
I think that one of my greatest problems is dealing with the view "if it
isn't built in to the language it doesn't exist". I keep finding people
who tell me that "you can't do strings in Forth" (in spite of the fact
that MMS sells a commercial quality wordprocessor and a database system
written in Forth and I have somehow managed to use strings in my own work
[I started before I knew I wasn't supposed to be able to do it]). There
are a wide range of string-handling capabilities that someone might want
in Forth ranging from none to substantial.
A moderately comprehensive string package can be added to Forth using
about 4 screens. If you want to treat the strings in the same way as
other objects, you need a storage management scheme taking another 4
screens. This will be enough to meet the needs of about 85% of Forth
programmers (and does not deny the validity of the needs of the other
15% who either need no strings on one hand, or a full-blown memory
allocation with garbage collection system on the other).
The nature of Forth permits features to be added-on which would, in
other languages, need to be built-in. It is silly, both in thought
and standardization efforts, to treat Forth as a rigid language. Part
of the "essence" is its ability to accept features as "changeable parts".
IV.
In response to Bradley's listing of 4 different string types:
It is quite unlikely that people reject Forth because they find that,
somewhere in its innards, that an implementation team found it useful to
tag the ends of the name field (thereby producing your example 4 of
inconsistent ways strings have been handled).
I think it is more likely that people reject (or leave) Forth because
it has been rendered non-portable. Not because of genuine hardware
problems, but by the unwillingness of vendors to realize that portability
is more important than exercising their eccentricities.
If you want a string package in Forth, the best first step would be to
have the Forth community get its act together and make the language
highly portable again. This would allow people to produce a variety of
string packages (among other useful things) that will run on everyone's
Forth [and therefore have a larger market].
V.
# (BTW, I am pretty sick of all this "Zen philosophy" nonsense (weakness
# is strength, dah-dah, dah-dah) regarding Forth; we are talking about a
# programming language that deals with physically real hardware, whose
# success or failure is ultimately determined by economics, measured in
# real money. We are not talking about a way in which to live your life
# and interact with your fellow man and achieve spiritual salvation.)
I somewhat agree with Bradley to the extent that I have discovered
that no one is really interested in the religious experiences that you
have had with your programming language.
This, however, should not deny the fact that the most important thing
about a programming language is the way programmers feel about using it.
We may be talking about "physically real hardware" but we are also
talking about "physically real programmers".
I'd like to discourage some people before I go on:
To those of you who think you will make megabucks by
exploiting Forth:
IT WON'T HAPPEN -- GO FIND ANOTHER LANGUAGE.
This being said, we now are rid of all the people who want to add to
Forth inappropriate characteristics because it will sell (regardless of
whether it is healthy for the language). We can talk about "essence"
where it counts: what is a language like when you use it to write
programs.
There are, in fact, subjective characteristics of a programming language
which are an important part of the man-machine interface. These are no
less important because we do not know how to articulate them. I am
impressed if someone tells me of a language by saying: "It's the only
language where I feel I can do anything I want -- I can conceive of
something and carry it out, and not be limited by what the language lets
me do". I'm less impressed by someone who tells me "Its control
structures are orthogonally tangential". I guess that's because I'm a
programmer and not a computer scientist.
A group of people do not sit down together and say "let's put together a
language that feels like Zen Buddism". Instead, a group of people are
confronted with a language -- and they find that it feels so different
that they can only describe the experience in religious terms. If someone
becomes involved with Forth and does not have this sense about it, it may
be because we have managed to remove from Forth its essence.
If you do have this sense about Forth, I agree with Mitch that you
probably will not help the cause by beating other people over the head
with it. You can't spread a religion by talking about it -- you have to
put other people in a position to experience it for themselves.
Of course the Forth community is not taking the steps to have others
experience it for themselves. It is not taking the steps needed to
have the language taught (or even teachable). It is not making it
possible for those likely to teach the language to use if for their work
(which is the prelude for using it in teaching). This is a far reaching
issue -- it has to do with many things (none of which involves the fact
that name fields are stored in the dictionary with high bits set at both
ends).
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093
P.S. The Forth community may owe apology to people who are genuine Zen
Buddists -- I don't think the analogy comes from a deep study of
Zen. Basically it is an expression that simple things can be
amazingly powerful and complex things can be very weak.wmb@ENG.SUN.COM (02/16/90)
I stick by my claim that PostScript's strong typing is a fundamental difference from Forth. It is true that you can choose to think of Forth stack items as "objects", but that does not change the fact that PostScript's basic design is heavily influenced by its strong typing and Forth's basic design is heavily influenced by its lack of same. This does not imply that I think strong typing is necessarily "good" (whatever than means) in all cases. It just means that the difference has far-reaching consequences for the language design. By the way, Forth (unfortunately) does have operator overloading. The AND operator is used both as a way to perform logical operations both on bit vectors and also on truth value flags resulting from comparison operators. This has led to such hotly-debated concerns as "should the value of a flag be 1 or -1", and how does this all work on 1's complement or sign-magnitude machines (the answer: nobody is really sure). The + operator is used both for integer arithmetic and also for address calculations (I'm sure people will dispute this, but address arithmetic, in the general case, has different properties from integer arithmetic). Forth has a tendency to exploit "accidental" properties of particular number representations that just happen to be true for a subset of the computers in the world. Forth's operator overloading is thus "ad-hoc". > Forth was designed pragmatically rather than as > an embodyment of someone's theory of programming languages. It was > designed by a programmer to solve programming problems. It is ad hoc > in the best sense -- it is designed to produce the best practical > solution to the problem at hand. Forth as we know it was not "designed by a programmer". A subset of what is now Forth was invented by a single programmer Charles Moore (admittedly a rather large subset). Then it evolved in an ad-hoc fashion, to solve a rather-abitrarily limited subset of programming programs, subject to dynamically-changing sets of hardware constraints, many of which are no longer relevant. There were LOTS of fingers in the final pie. In point of fact, the "designer of Forth" (CM himself) uses a variant of Forth that is only approximately compatible with any other widely- available Forth system. Every time that I talk to Chuck, he has changed his mind about some basic thing. He just wants to do what he wants to do this week, and he is smart enough to get by with it, so more power to him. I am in favor of pragmatic design, and a lot of Forth's good points (in particular its general space and time efficiency) reflect this. Some of Forth's not-so-good points reflect a narrow viewpoint about the universe of programming problems and computer system environments. This is reflected in one attitude that I heard expressed when I was trying to push the ANSI memory allocation wordset: "The system I use cannot benefit from [the proposed form of] memory allocation, and I do not care about your application, so I will vote against the proposal". Mitch
ir230@sdcc6.ucsd.edu (john wavrik) (02/17/90)
Mitch Bradley writes:
# > ... Forth's confusion about strings, and the possibility of defining
# > your own strings package ...
#
# The argument that "you can define your own" is often cited in defense
# of Forth's lack of particular features. However, many people do not
# wish to have to "roll their own" this and that. Perhaps they do not
# have the skill. Perhaps they do not have the time. Perhaps they would
# rather concentrate on their application without having to build up
# the tool base by themselves. Having well-debugged, optimized, supported
# tool packages (e.g. strings) can save application developers time and
# money. Given the choice between "rolling your own" and buying, the
# "buy" decision is often economically sound.
This may be a significant breakthrough in rather protracted exchanges.
It indicates a major misunderstanding of what I had always assumed was a
well-understood point.
The issue is NOT that Forth programmers do not want features -- the
issue is how features should be provided and whether they should be built
in or not.
The most significant feature of traditionally implemented Forth is that
F1) the *user* has access to the implementation in a way that in most
languages is reserved to the specialists who implemented the
language.
F2) the implementation is simple enough for the *user* to make use of
the access.
F3) the "compiler" is extensible -- so that features that would normally
have to be incorporated into an (inaccessible) compiler can be
introduced as additions by the *user*.
There are several rather enormous benefits to this:
B1) The user only needs to incorporate language features that are
actually needed.
B2) The user can select from a variety of variants of a feature to
choose the one best suited for an application (this particularly
is important for memory allocation schemes, string packages, etc.
where there are definite tradeoffs between extent, size, execution
speed, etc.)
B3) The user can modify a package implementing a feature to suit his
needs.
[Please note (to Doug Philips and others) that I am talking about access
to the *implementation* not just to the *hardware*]
Forth programmers are not necessarily cave men who plan to build
everything from scratch. An argument that Forth programmers are
insisting upon "rolling their own" misses the point. The point is
that the Forth language is capable of allowing people to ADD features
rather than build them in -- and that retaining whatever is responsible
for this capability is more important than encrusting Forth with
someone's idea of desirable features.
There is a big difference between a situation in which portable feature
packages can be purchased or written and will run as add-on's to anyone's
Forth system -- and a situation in which features must be supplied by a
vendor because the underlying Forth (as defined by the Standard) is too
weak to support them as additions.
Forth standards should define a nucleus capable of supporting string
packages, memory allocation schemes, etc. as portable add-ons. The
nature of Forth makes this feasible -- and the definition of the nucleus
should be powerful enough to support it. This, rather than quibbles about
whether 1 or -1 should be used for TRUE, is my main concern with the ANSI
effort. It simply does not answer to say that the ANSI team has spent
hours of effort building in the features that people most seem to want.
The real question is whether it is spending hours of effort to make sure
that the nucleus of the language can (as it has in the past) accept these
features as portable additions.
I will, like many others, buy optimized and debugged tool packages -- but
when it comes to distributing work that I have done, I'd like to know
that the power of the core language has been retained -- that what I
have done (on the level of difficulty of some of these tool packages) in
XYZ-Forth will also run on ABC-Forth. This, rather pragmatically (or "ad
hoc") is my bottom line.
I don't know how to make this any clearer -- but the issue is not about
"people who want to roll their own this or that", it is about making a
Standard which preserves Forth's ability to let people roll their own,
add their own, buy their own, or modify their own AS THEY CHOOSE.
I can also put it as an economic issue:
Borland can afford to make its Turbo-X languages as eccentric as hell,
because more people will buy Turbo-X than program in all varieties of
Forth put together. Turbo-X will be its own standard. If you write in
Turbo-X there will be so many other people who do too that you won't
worry that your Turbo-X programs don't run on Microsoft-X. (I should
mention that, in most cases, Borland has actually been fairly
conventional -- but in other cases not.)
NAME ME THE FORTH VENDOR WHO WILL BE THE BORLAND OF FORTH.
Failing that, we can standardize Forth to the extent that a package
written for one vendor's Forth will run on any other vendor's Forth.
In this way, a (second party) author of a package (who deserves a just
reward for the time it takes to write a professional optimized and
debugged package) will be assured of adequate compensation.
It will also be possible for a teacher to produce a future generation
of Forth programmers and users. He will be able to say in 2 minutes
how a certain word acts -- knowing that we have finally agreed on
a complete and powerful set of core words. He will no longer have
to explain the differences between the '79 tic and the '83 tic or how
WMB-Forth differs from YUK-Forth. And he will not have to mention, as
a footnote, that there are ANSI standards for Forth, but no one really
uses them because they are not adequate for writing substantial
programs.
Forth should be a relatively easy language to standardize -- the kernel
needed to support the features we are talking about is relatively small.
That's all we need to agree on.
[Note to Mitch Bradley: If your memory allocation package, file package,
string package (do you have one?), etc. cannot be written in the Standard
core vocabulary, then pester people about the core. In return, I'll
grant that a floating point package must be an Extension.]
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/18/90)
Category 18, Topic 52 Message 2 Fri Feb 16, 1990 M.HAWLEY at 21:15 EST I'm not religious , but I studied Zen on the post-graduate level long before I had ever heard of Forth. I think the analogy runs deep. No apology is probably called for. However, the question of who is a [C [C [C [C [C [C [Cgenuine " Zen Buddhist is at least as nebulous as the question of hat is the "essence" of Forth. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
dwp@willett.UUCP (Doug Philips) (02/19/90)
In <7414@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: > Forth (and other semi-compiled or interpreted languages) seems to be > called to task for the lack of attributes which are more appropriate > in the world of compiled languages. Since so few languages provide an > interactive environment, there is apparently little recognition of the > fact that to get a language to run interactively and efficiently > requires a different set of implementation decisions than a language > designed for pure compilation. Hmmm... What about all the LISP/APL systems in use? I suspect that what's really going on is that Forth is interpreted *and* can run in 5-10K. Of course, then you must raise the issue of "Basic". I suspect that the 'interpreted/interactive' business is not the significant issue. I suspect that the size/time constraints that Forth grew out of are. > APL also does this -- but the overloading is restricted to system- > defined data types. Interpreted BASIC (dare I mention it) also does this. > Overloading of operator symbols requires typing of objects. The idea that > it is desirable is inherited from our experience with compiled languages, > where it does not exact a runtime penalty. The use of overloading in > interactive languages exacts a substantial runtime penalty -- it is one > of the reasons that people believe that interactive languages must be > slow. SmallTalk implementors would have something to say about this. Runtime typing, late binding, etc. are *not* necessarily slow. > Part of the examination of the "essence of Forth" should involve looking > at the distinction between compiled and interpreted languages. One must > ask questions like "Is it really better or easier to write programs if > one is allowed to confuse several conceptually different operations by > giving them the same name?" [Since, in traditionally implemented Forth, > the children of the same defining word have the same address in their > code field, some typing information is available for those who want to > experiment. My own conclusion is that overloading symbols does not > facilitate the programming I do -- and certainly does not justify the > runtime penalty.] Hmmm... what does operator overloading have to do with the distinction between compiled and interpreted languages? ADA and C++, just to name two, both have operator overloading and yet are both compiled. SmallTalk and APL, just to name two, both have operator overloading and yet are both interpreted. I am willing to join you in the examinition of the 'essence of Forth' by considering the C/I distinction, but I don't see it here. > Later in this article, Mitch Bradley will say "I claim that 'Forth- > like' means 'ad-hoc' and I will respond by saying "It is ad hoc in the > best sense -- it is designed to produce the best practical solution to > the problem at hand". The traditional Forth approach to overloading > symbols is not to do it (because of runtime penalties) but to provide > the means if it is deemed necessary. The same applies to range checking > of arrays, having functions check the number and types of their > arguments, etc. I think part of the "essence of Forth" is to provide > tools to build appropriate features rather than provide features which > may or may not be appropriate. Yes, I strongly agree here. Provide the right building blocks, not the end structures. Or at least keep the building block layer available to the end programmer. > If you want a string package in Forth, the best first step would be to > have the Forth community get its act together and make the language > highly portable again. This would allow people to produce a variety of > string packages (among other useful things) that will run on everyone's > Forth [and therefore have a larger market]. And not just string packages. I hope X3J14 can pull this one off. > There are, in fact, subjective characteristics of a programming language > which are an important part of the man-machine interface. These are no > less important because we do not know how to articulate them. I am > impressed if someone tells me of a language by saying: "It's the only > language where I feel I can do anything I want -- I can conceive of > something and carry it out, and not be limited by what the language lets > me do". I'm less impressed by someone who tells me "Its control > structures are orthogonally tangential". I guess that's because I'm a > programmer and not a computer scientist. I'm impressed when someone tells me 'I feel I can do anything I want because the language provides a powerful *and* simple set of building blocks, and the implementation is transparent (i.e. there is no part of it I cannot examine/modify if I need to).' I'm impressed by 'orthoganlly tangentiality' because it means simplicity. As far as Forth is simple it is impressive, as far as it is capricious, it is silly. Ad hoc-ism and being driven by practical considerations is OK. Sometimes the real world doesn't simplify into conceptually separate boxes. There may be a theoretical/practical dichotomy here, at least that is the impression I'm getting. I think such a black and white distinction is silly if not counterproductive. > A group of people do not sit down together and say "let's put together a > language that feels like Zen Buddism". Instead, a group of people are > confronted with a language -- and they find that it feels so different > that they can only describe the experience in religious terms. That could be a sign of either: a) Such a different frame of reference that there isn't yet proper language to describe it; or b) they don't understand what they 'know' well enough to describe it. I find choice 'a' somewhat appealing here, but then I think, they've been at it 10 years and still no language? I suspect that 'b' is more likely, but one cannot prove these kinds of things ;-) > If you do have this sense about Forth, I agree with Mitch that you > probably will not help the cause by beating other people over the head > with it. You can't spread a religion by talking about it -- you have to > put other people in a position to experience it for themselves. Sounds like the Forum or a religous conversion. At least those have pyschological explanations for 'mystic' experiences. I agree though, that the only way to experience a new point of view is to experience a new point of view. It does not follow, however, that one cannot describe *why* one should do it. -Doug --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
dwp@willett.UUCP (Doug Philips) (02/19/90)
In <7516@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: > [Mitch Bradley refutes Forth's 'write your own' defense for its lack of > string package(s).] > This may be a significant breakthrough in rather protracted exchanges. > It indicates a major misunderstanding of what I had always assumed was a > well-understood point. > > The issue is NOT that Forth programmers do not want features -- the > issue is how features should be provided and whether they should be built > in or not. Yes! Yes! Yes! > The most significant feature of traditionally implemented Forth is that > > F1) the *user* has access to the implementation in a way that in most > languages is reserved to the specialists who implemented the > language. > F2) the implementation is simple enough for the *user* to make use of > the access. > F3) the "compiler" is extensible -- so that features that would normally > have to be incorporated into an (inaccessible) compiler can be > introduced as additions by the *user*. Ok, but does this make commercial Forth's that don't provide source and/or capability for metacompilation not Forth? > There are several rather enormous benefits to this: > B1) The user only needs to incorporate language features that are > actually needed. > B2) The user can select from a variety of variants of a feature to > choose the one best suited for an application (this particularly > is important for memory allocation schemes, string packages, etc. > where there are definite tradeoffs between extent, size, execution > speed, etc.) > B3) The user can modify a package implementing a feature to suit his > needs. > > [Please note (to Doug Philips and others) that I am talking about access > to the *implementation* not just to the *hardware*] Yes, I hear you. I strongly agree with all of this. > Forth standards should define a nucleus capable of supporting string > packages, memory allocation schemes, etc. as portable add-ons. The > nature of Forth makes this feasible -- and the definition of the nucleus > should be powerful enough to support it. This, rather than quibbles about > whether 1 or -1 should be used for TRUE, is my main concern with the ANSI > effort. It simply does not answer to say that the ANSI team has spent > hours of effort building in the features that people most seem to want. > The real question is whether it is spending hours of effort to make sure > that the nucleus of the language can (as it has in the past) accept these > features as portable additions. But questions of TRUE/FALSE and representation cut to the heart of portability. Perhaps what X3J14 should do is *not* define TRUE/FALSE except to say that they are returned by the relational operators (and what ever else) and are consumed by conditionals. That is the kind of thing which makes portability easier. It is also anti-Forth's-grab-the-bits-and- run-like-hell-and-screw-portability-attitude. > I will, like many others, buy optimized and debugged tool packages -- but > when it comes to distributing work that I have done, I'd like to know > that the power of the core language has been retained -- that what I > have done (on the level of difficulty of some of these tool packages) in > XYZ-Forth will also run on ABC-Forth. This, rather pragmatically (or "ad > hoc") is my bottom line. And also mine. I don't have the luxury of working in Forth professionaly. If I'm going to putz about on my own hobby stuff, I'd like to be able to make it available to other Forthers. I hope that there is some chance of that after X3J14 is done. > NAME ME THE FORTH VENDOR WHO WILL BE THE BORLAND OF FORTH. > > Failing that, we can standardize Forth to the extent that a package > written for one vendor's Forth will run on any other vendor's Forth. > In this way, a (second party) author of a package (who deserves a just > reward for the time it takes to write a professional optimized and > debugged package) will be assured of adequate compensation. But you said in another posting that noone will ever get rich off of Forth. (and implied it was a good thing). Therefore there will never be a Forth vendor who will be the Borland of Forth. Maybe one of the ZEN, PYGMY, FPC, etc will make it big, but they aren't going to be commercial successes. > Forth should be a relatively easy language to standardize -- the kernel > needed to support the features we are talking about is relatively small. > That's all we need to agree on. > > [Note to Mitch Bradley: If your memory allocation package, file package, > string package (do you have one?), etc. cannot be written in the Standard > core vocabulary, then pester people about the core. In return, I'll > grant that a floating point package must be an Extension.] Here here!!! (As soon as I get BASIS11 I'll join in the pestering!) -Doug --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
wmb@ENG.SUN.COM (02/21/90)
> [Note to Mitch Bradley: If your memory allocation package, file package, > string package (do you have one?), etc. cannot be written in the Standard > core vocabulary, then pester people about the core. In return, I'll > grant that a floating point package must be an Extension.] When running under an operating system, the underpinnings of both memory allocation and file access is a call to the operating system, which is not standard Forth. The irreducible requirement is some set of words to get at those system functions. Direct system calls cannot be standard, because then they would depend on the particular OS. The next obvious solution is to construct a wordset that can be efficiently implemented on top of most operating systems, yet provide a portable interface. That is exactly what the file and memory allocation wordsets in BASIS do. Strings is a different story. It is certainly possible to write just about any string package in standard Forth (but having a good memory allocator certainly can help the implementation). On the other hand, the efficiency may suffer unless one resorts to CODE words, which are not portable. The problem is not that I cannot write whatever string package I want. The problem is that I should not HAVE to. Lots of people reject Forth because it forces them to reinvent wheels, when they would prefer to build upon other's work, adding value in their own domain of expertise instead of building this basic library and that basic library. One could claim that one could simply select a string package that somebody else has written. True, one could, if one happened to know about its existence and if one knew where to get a copy and if one trusted the quality of that package. Of course, then you would probably have to spend some money documenting the package and training your personnel about it. If there is a standard package, then one can assume that competent programmers know about it and that every worthwhile vendor implements it and supports it, and you can depend on market pressure to ensure its quality. The grass roots approach works up to a certain point, and then it gets bogged down in endless variation and uncertainty. For some uses, this is fine, but for large-scale commercial viability, it is not fine. Mitch
ir230@sdcc6.ucsd.edu (john wavrik) (02/23/90)
Mitch Bradley writes:
# When running under an operating system, the underpinnings of both memory
# allocation and file access is a call to the operating system, which is
# not standard Forth. The irreducible requirement is some set of words to
# get at those system functions. Direct system calls cannot be standard,
# because then they would depend on the particular OS. The next obvious
# solution is to construct a wordset that can be efficiently implemented
# on top of most operating systems, yet provide a portable interface.
#
# That is exactly what the file and memory allocation wordsets in BASIS do.
Gee, I'm sorry -- I thought you were talking about dynamic memory
allocation schemes. It is true that many operating systems do not,
for obvious reasons, attach to a Forth system all the memory in its
address space. Users do, indeed, need to be able to increase the
dictionary area on such machines. (I'm not sure that I see why this
needs to be done by a Standard wordset -- but if you want to specify
it, what harm could it do.)
I was thrown off, I guess, by your discussion of "inconsistent"
handling of strings by the Forth system itself -- and your mention
of the need for a dynamic memory allocation system to make a string
package useful. I just assumed that you were pushing for the
incorporation of a particular dynamic memory allocation system and
a "consistent" string package to be built in to Forth.
As long as we're just talking about a word to specify the static memory
requirements of Forth, perhaps running with other tasks, everything is
fine. The rudimentary heap management built in to operating systems for
allocating memory for tasks is really not a suitable basis for the kind
of dynamic memory scheme needed by some Forth applications.
--John
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093