State of Forth 200x
Andreas Kochenburger
http://www.forth200x.org/forth200x.html
and am a bit disappointed about the really minuscule progress made
there towards a more modern Forth. Of course the right answer to me
would be: where are your own contributions?
But anyhow, no proposal seems to have been made towards obvious
lacking things: OO, libraries, string handling, com sockets - you name
others. Instead there are "teacup discussions" about standardizing
already existing defacto words à la DEFER-IS. I don't call that
progress.
So I am dreaming of the day where some people pull together their
courage and time just to propose an OO scheme (damn that zelotic
discussion of object-method or method-object followers) ... or for
setting environment flags (my favourite: float_dpl when 0 a dot in a
number is interpreted as a double, when 1 the dot is interpreted as an
fp number and put on the fp stack) ... or
Andreas
-------
Dead men have no pockets.
Alex McDonald
All credit to Anton Ertl; he's driven this forward. Some lead, some
follow, and that's fine. Following has its disadvantages, of course;
you really don't get to say "wrong direction" or "not fast enough!"
without being invited (as you observantly note) to contribute. Your
float_dpl looks promising; there are a number of Win32Forth users that
would like to see this feature. Writing it up, however briefly, might
be a good start.
--
Regards
Alex McDonald
Doug Hoffman
Andreas Kochenburger wrote:
[snip]
> So I am dreaming of the day where some people pull together their
> courage and time just to propose an OO scheme (damn that zelotic
> discussion of object-method or method-object followers) ...
I have very recently tried, apparently in spectacular failure, to
further the efforts of Andrew McKewan's work towards getting a
standardized OOP scheme. Near as I can tell Forth will never have a
standard here. It seems to be a religious thing. It certainly isn't
performance (object-method or method-object) or popularity of use, or
existence and quality/quantity of class libraries.
I share your lament. But I have given up on this effort. One can only
beat one's head against a brick wall for so long.
Regards,
-Doug
Marcel Hendrix
[..]
> I have very recently tried, apparently in spectacular failure, to
> further the efforts of Andrew McKewan's work towards getting a
> standardized OOP scheme. Near as I can tell Forth will never have a
> standard here. It seems to be a religious thing.
It will become a standard when one \/ a few programmers publish
their model, their extensive libraries, and a lot of useful
application programs. And most certainly if the Forth they use
doesn't need kernel support, but can be layered on top of almost
whatever. Publishing a model without the libs and apps will fall
flat on its face.
How can one standardize what is not used by anyone?
-marcel
Stephen Pelc
>How can one standardize what is not used by anyone?
The point of a standard is to define common practice. If it
ain't common, it can't be standardised.
From observation of a number of packages, they are either
elegantly minimal and not useful for large applications,
or they are useful but ugly and large. The Neon-style
packages appear to have the greatest "market share".
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Alex McDonald
Marcel Hendrix wrote:
(on OO)
>
> It will become a standard when one \/ a few programmers publish
> their model, their extensive libraries, and a lot of useful
> application programs.
W32F might score a few points here...
> And most certainly if the Forth they use
> doesn't need kernel support, but can be layered on top of almost
> whatever.
but looses here. Kernel support appears to be required for the
Neon/MOPS model.
--
Regards
Alex McDonald
werty
another C+ !!
OO is a bad idea , it ruins structure .
the proper method is to make the OpSys so
SimpleSmartStructuredLinked it can
deal with all Objects NOT USING THE CONCEPT OF
ObjectOriented ...
I'm sorry that Forth in it's dragon slaying
did not invent buzz words to oppose Ludite obtuse
programming like OO ..
It's real simple ! If you first study good programming then you
study todays s/w , you will reject EVERYTHING !
It's all B.S. to enhance his reputation , like Linus does ...
Every method used today is to belabor .....
There is a perfect structure for OpSys and it is linked to the
max by a very efficient , adaptive system that does garbage collection
based on use and time . It can even rearrange it's own dictionary
to work faster .....
So why fight it ? Your paycheck is gone for sure , give up and
do it right ....
Linux will be be used in the Future , it's dead ...
______________________________________________________
George Hubert
Alex McDonald wrote:
> Marcel Hendrix wrote:
>
> (on OO)
>
> >
> > It will become a standard when one \/ a few programmers publish
> > their model, their extensive libraries, and a lot of useful
> > application programs.
>
> W32F might score a few points here...
>
The problem is that the W32F libraries (and the applications based on
them) are very Windows specific, so wouldn't be (easily) portable to
other systems.
> > And most certainly if the Forth they use
> > doesn't need kernel support, but can be layered on top of almost
> > whatever.
>
> but looses here. Kernel support appears to be required for the
> Neon/MOPS model.
>
Andrew McKewen wrote an ANSI version of the NEON/MOPS model that didn't
require Kernel support (and Doug Hoffman recently extended it; see his
earlier message). If a small amount of Kernel support is needed it
could be handled with a few implementation specific support words (with
the ANSI versions one problem is multi-tasking support; since there's
no Standard for User variables then ordinary ones are used instead;
also CATCH and THROW really need to be supported).
> --
> Regards
> Alex McDonald
George Hubert
Andreas Kochenburger
<dhof...@talkamerica.net> wrote:
>I believe any effort to achieve an ANSI Forth object model will fail as
>well, but not necessarily for those reasons.
IMO one of the basic reasons is that there is no consensus about how
to organize code. I mean definitions of standard libraries. The shy
temptative definition of "wordsets" in ANS Forth (when there had been
vocabularies since long btw) WITHOUT daring to propose a common syntax
how to include them in your application source, seems to me to have
been "the historic bottleneck". It's analogous to the concept of
header files and libraries in C and C++, of which every programmer can
rely upon that strlen() is available to him after the preprocessor
command #include <string.h>. It does not prescribe HOW it is achieved.
No wonder that practically nobody really welcomed Andrew's great work
to port the MOPS model to ANS Forth. The ground work has not been done
up to today. One cannot rely his work on a class model when even the
fundamental library concept AND minimal standard content is unclear.
If s.th. goes wrong within your own code, nobody can help you because
everybody uses his own syntax or has wandered off, more probably.
BTW who would vote for including the MOPS model into Forth200x ?
The code is there, the user base is there, and it seems to require
only 5 or 6 people to "storm the bastion"? ;-))
Stephen Pelc
>
>
>> -marcel
>
>Don't worry Marcel. I've given up on this. I haven't the time or
>energy to devote to a hopeless effort.
I may have missed this while I was away, but is your updated
ANS code available somewhere?
MPE supports at least three OOP models:
Neon - derived from McKewan's 1996 code
CIAO - in VFX Forth
VfxClass - for a client
There were good reasons for all of these. Other models, such
as Forth Inc's SWOOP have been generated because of other
valid requirements. I believe that a SWOOP implementation was
published in Forth Dimensions some years ago, but am unclear
as to the copyright, and whether reference code is available.
Elizabeth, can you clarify this?
One problem in the Forth 200x process is that some proposals,
e.g. EKEY extensions, are very much desktop application problems.
In my view, we could usefully split proposals into four domains:
core related - Forth in general
desktop - PCs and workstations
mobile - phones, PDAs ..
embedded
Remember that many users of commercial Forths expect a standard
Forth to support everything in the standard. Consequently vendors
are very cautious about accepting extensions that should really
be classified as library code.
Just as the standard has xxx-EXT wordsets, perhaps we should
also have LIB-xxx wordsets?
From the point of view of common practice in OOP, IMHO the
Neon model wins as a desktop library, so don't give up!
Doug Hoffman
> It will become a standard when one \/ a few programmers publish
> their model,
That's been done.
> their extensive libraries,
That's been done.
> and a lot of useful
> application programs.
Is this the standard requirement for new Forth extensions? Win32Forth,
Neon, Yerk, and Mops have been using this object model for a long time.
Earliest was 1984, I believe. I know that a lot of code has been
written. For example, the Yerkes telescope was controlled for many
years by Yerk.
> And most certainly if the Forth they use
> doesn't need kernel support, but can be layered on top of almost
> whatever.
That's been done.
> Publishing a model without the libs and apps will fall
> flat on its face.
I believe any effort to achieve an ANSI Forth object model will fail as
well, but not necessarily for those reasons. From Wil Baden, August
1996:
** Begin Baden quote**
Andrew McKewan (mcke...@austin.finnigan.com) wrote:
> I have ported the object model from Yerk/Mops to ANS Forth. I have
> uploaded the file CLASS01.ZIP to Skip's ftp site and asked him to
> move it the the /pub/Forth/ANS directory.
Bravo, Andrew.
This is the most important work done in Forth this year.
Preliminary tests in ThisForth work fine after defining:
: VALUE , DOES> @ ;
--
Procedamus in pace. Wil Baden Costa Mesa, California
** End Baden quote**
So here we are almost 10 years later. I believe we'll be in the same
place 10-20 years from now.
> How can one standardize what is not used by anyone?
See Stephen Pelc's comment on this.
> -marcel
Don't worry Marcel. I've given up on this. I haven't the time or
energy to devote to a hopeless effort.
Regards,
-Doug
Alex McDonald
werty wrote:
===snipped===
Please, stop dribbling in this newsgroup.
--
Alex McDonald
Doug Hoffman
Stephen Pelc wrote:
> I may have missed this while I was away, but is your updated
> ANS code available somewhere?
Yes.
http://members.talkamerica.net/douglas...@talkamerica.net/
file class.11.zip
[snip]
> From the point of view of common practice in OOP, IMHO the
> Neon model wins as a desktop library, so don't give up!
>
> Stephen
I'd prefer not to. Give up that is. I certainly agree that the Neon
model is an excellent choice. Not just because it has been or is most
commonly used.
Regards,
-Doug
Doug Hoffman
Andreas Kochenburger wrote:
[snip]
> BTW who would vote for including the MOPS model into Forth200x ?
> The code is there, the user base is there, and it seems to require
> only 5 or 6 people to "storm the bastion"? ;-))
That would certainly get my vote. The Mops object model has
extensively evolved the fundamental Neon concept. It is *very*
sophisticated, including optional multiple inheritance, temporary
objects (ala Swoop), an extremely extensive class library including
*many* classes that are not Macintosh-specific, and too many detail
refinements to mention. One such refinement, for example, is the
classinit: message. Most object models use a default initialization
method which, if defined, will assure that all instance variables are
initialized to a known, programmer controlled , state. If you look at
non-Mops models you will notice that a lot of "classinit: super"(or
equivalent) calls are explicitly used. We long ago realized that this
should be the default with no need for the programmer to explicitly
call (of course he/she could, but it simply is not necessary).
Anyway, I view the Mops object model as the gold standard. As you say,
the complete source code is freely available for anyone to inspect and
copy. If we could get the very complete Mops model as the ANSI
standard that would be great, IMHO. But given the resistance to *any*
form of object standardization I think we would be doing good just to
get the basic Neon model implemented.
I have uploaded a slightly revised McKewan-style Neon model for anyone
interested. It contains a few improvements that I had been working on:
A) Public/Private Methods have been dropped. This amounts to a
simplification
of code and a speed increase. All methods are public. In practice I
have found
that I simply do not need to "hide" methods from the programmer (me).
B) A simplified :Class syntax is provided that will default to OBJECT
as the
superclass if no superclass is declared, thus saving the need to always
declare a superclass.
C) Proper 2-dimensional array support is provided.
D) A dynamically sizeable string class has been added to the class
library.
The files are located in the same place as before:
http://members.talkamerica.net/douglas...@talkamerica.net/
file CLASS12.F.ZIP for PC users
file CLASS12.MF.ZIP for Macintosh users (same content, just a
different file format)
This does not mean that I am now willing to carry the torch for a
standardized Forth object model. I am not inclined to expend any more
time on an effort that I believe is doomed to fail. But some may find
these later files to be of interest.
Regards,
-Doug
Krishna Myneni
From my perspective, which is mainly involving the use of Forth in laboratory
and industrial environments, the first order of business is standardization of
the lower level libraries such as sockets and strings. While standardized OO may
be important for large scale applications, most of the time, my problems involve
only a few hundred to a few thousand lines of code. Inside such small/medium
applications, a simple and elegant OO implementation such as Bernd Paysan's
mini-oof is usually enough for me. A student of mine recently used mini-oof to
create a class for a software PID controller. The PID objects are then used to
control multiple devices.
Krishna
Doug Hoffman
Krishna Myneni wrote:
> From my perspective, which is mainly involving the use of Forth in laboratory
> and industrial environments, the first order of business is standardization of
> the lower level libraries such as sockets and strings. While standardized OO may
> be important for large scale applications, most of the time, my problems involve
> only a few hundred to a few thousand lines of code.
Stephen Pelc addressed exactly this issue in his post above:
** quoting Stephen Pelc
One problem in the Forth 200x process is that some proposals,
e.g. EKEY extensions, are very much desktop application problems.
In my view, we could usefully split proposals into four domains:
core related - Forth in general
desktop - PCs and workstations
mobile - phones, PDAs ..
embedded
** end quote
The point being just because *you* don't see the need for something,
because of your programming domain, does not mean there isn't need for
it in other Forth domains. But it sounded like you acknowledged that,
so I'm a bit perplexed regarding the purpose of your post.
Regards,
-Doug
Albert van der Horst
Andreas Kochenburger <a...@nospam.com> wrote:
>On 1 Jun 2006 03:08:03 -0700, "Doug Hoffman"
><dhof...@talkamerica.net> wrote:
>>I believe any effort to achieve an ANSI Forth object model will fail as
>>well, but not necessarily for those reasons.
>
>IMO one of the basic reasons is that there is no consensus about how
>to organize code. I mean definitions of standard libraries. The shy
>temptative definition of "wordsets" in ANS Forth (when there had been
>vocabularies since long btw) WITHOUT daring to propose a common syntax
>how to include them in your application source, seems to me to have
>been "the historic bottleneck". It's analogous to the concept of
>header files and libraries in C and C++, of which every programmer can
>rely upon that strlen() is available to him after the preprocessor
>command #include <string.h>. It does not prescribe HOW it is achieved.
Now he can't. Not until the systemdependant linking step with
the standard library has been done.
The important reason things are better in C++ is that the
*user* of the actual program, has no need to know about linking
the standard library.
>Andreas
>-------
>Dead men have no pockets.
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
John Doty
> Remember that many users of commercial Forths expect a standard
> Forth to support everything in the standard. Consequently vendors
> are very cautious about accepting extensions that should really
> be classified as library code.
>
> Just as the standard has xxx-EXT wordsets, perhaps we should
> also have LIB-xxx wordsets?
Careful, you're on a slippery slope. The unstated organizing principle
behind the standard is "all standardized words are opaque". Your
approach would add a class of transparent standardized words. Of course,
the superiority of that approach might then become apparent and result
in moving the Forth UI to a library where it belongs.
The True Believers in Standard Forth will then be your enemies. A
transparent UI atop a clean foundation would be a good thing, though.
--
---
John Doty, Noqsi Aerospace, Ltd.
---
His diagnosis of the hostility ... reflects the willful blindness of the
invader who assures himself that the natives are only made unfriendly by
some other provocation than his own. -Barbara W. Tuchman
Krishna Myneni
Perhaps my digression about mini-oof obfuscated my main point (and apparently
touched a nerve!). IMO, it's premature to standardize OO without a common string
library in Forth. That's not to say it's not worthwhile to propose a common OO
model; just that we should be careful about putting the cart before the horse.
Krishna
Doug Hoffman
Krishna Myneni wrote:
> IMO, it's premature to standardize OO without a common string
> library in Forth. That's not to say it's not worthwhile to propose a common OO
> model; just that we should be careful about putting the cart before the horse.
OK. Understood. What's interestiing is that an OO implementation will
surely come with or lead to string classes with a rich set of methods
for dealing with strings. This cart would pull the horse quite nicely.
Here's an existing example of what could be had:
http://powermops.com/MopsManual/Classes/Chapter2.html#String
On the other hand, this is likely a larger package than an embedded
programmer would want in his/her toolbox. Once again I wonder if this
newsgroup should be split into at least two, one for full-featured
desktop programming and one for more minimal embedded programming.
Regards,
-Doug
Julian V. Noble
Andreas, I am not finding inconvenient the use of an exponent---even
a bare letter "e"---as a fp-designator. That is, currently
3.14159 \ interpreted as double
3.14159e \ interpreted as fp
It has the advantage that when I look at the number I see what happened
to it. If I understand you correctly you want to have a switch somewhere
to control this behavior. The switch position is invisible. so what you
ask is to add another state to the system.
Why do you think another state is a good thing? Jef Raskin, in his
discussion of a very nice Forth-based gizmo, the SwyftCard for Apple
II, pointed out that states (especially invisible ones) are bad
because it is like a world where tying your shoes the regular way
is fine, except on Thursdays between 10:45 and 13:17. Then you have
to use a special knot, because the regular knot, if executed then, makes
your shoes explode. Human beings being what they are, how many of us
would be walking around on prosthetic feet in such a world?
I had a graphic illustration of that very problem when I was at CERN
using a system called Wilbur (I think invented at Stanford). Many
people raved about it--it had a letter-writing state, a program-
writing state, a program running state, an editing state, and for
all I know, states to get you a new hairdo or shine your shoes. The
problem was that if you thought you were running a program and said
"Kill", but were really editing or composing you lost everything
into the great bit-bucket in the sky.
I vote against more states. Even if you call them environments.
--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
George Hubert
Not me. I'd be the one wearing Wellies (Wellington boots; they have no
laces).
> I had a graphic illustration of that very problem when I was at CERN
> using a system called Wilbur (I think invented at Stanford). Many
> people raved about it--it had a letter-writing state, a program-
> writing state, a program running state, an editing state, and for
> all I know, states to get you a new hairdo or shine your shoes. The
> problem was that if you thought you were running a program and said
> "Kill", but were really editing or composing you lost everything
> into the great bit-bucket in the sky.
>
> I vote against more states. Even if you call them environments.
>
I agree. I still remember the problem I had years ago when I
accidentally loaded a block with decimal numbers when base was hex
(though it did teach me to put decimal at the start of all blocks that
needed it; the same would happen with float_dpl; plus what about
markers and abort; do they reset it, leave it or is it ambiguous).
> --
> Julian V. Noble
> Professor Emeritus of Physics
> University of Virginia
George Hubert
Krishna Myneni
The string class library you refer to is certainly extensive and impressive. The
question is, would we not need a common set of string words, e.g.
STRCPY STRLEN STRCAT ...
or equivalents, in order to implement such an OO framework? It may be possible
to implement the high level framework across Forth systems without reference to
any (additional) common Forth words, but having a common set of string words
would surely make such a task easier.
With regards to the different needs of the embedded programmer vs desktop
programmer, the toolkit one chooses usually depends on the application. I'd
venture that the size of the toolkit is probably less relevant with today's
hardware. The application just may not need a complete framework. Therefore, a
multilayered structure for common libraries might be a good approach. For
example, the existing DPANS STRING EXT wordset can be considered as Layer 1.
Further string words, which build on Layer 1, can then form Layer 2, and so on,
with the OO wordset at the highest layer. An application can then specify which
layer of string words are required.
Krishna
Anton Ertl
>But anyhow, no proposal seems to have been made towards obvious
>lacking things:
Well, I started with proposals for things that many systems already
have and many users already use, and where there is enough commonality
that a consensus should not be too hard to reach. These may not be
very exciting, but my hope was that they would be easy to agree on.
The idea was to tackle the more difficult stuff later on, but if you
feel energetic, don't let that stop you from doing such a proposal
now.
>OO,
It's probably impossible to get a consensus on that. Certainly not by
discussion; establishing a successful library (somewhat like C++'s
STL) might do it, but that's also difficult. And anyway, one can
already implement many schemes in Forth-94. One might consider adding
lower-level stuff that some schemes might miss in Forth-94. The
so-called dot parser is one thing that comes to my mind.
> libraries
The "One-time file loading" proposal should make dealing with
libraries easier.
If you mean foreign-language libraries, yes, a standard foreign
function (or, realistically, C) interface would be nice.
> string handling,
Probably also hard or impossible to get a consensus on. E.g., I am
pretty satisfied with what Forth-94 provides, and the only
non-standard words that I use regularly for strings are SAVE-MEM STR<
STR= STRING-PREFIX?
> com sockets
Make a proposal. I would not know what you want here.
>So I am dreaming of the day where some people pull together their
>courage and time
Well, as long as you just dream and complain, it's not going to
happen.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
Anton Ertl
>
>Marcel Hendrix wrote:
>
>> It will become a standard when one \/ a few programmers publish
>> their model,
>
>That's been done.
>
>> their extensive libraries,
>
>That's been done.
Not that I noticed. Where can I find these libraries, and on what
systems do they run?
>> and a lot of useful
>> application programs.
>
>Is this the standard requirement for new Forth extensions?
It would certainly encourage the adoption of the extension and
libraries.
Anton Ertl
>Remember that many users of commercial Forths expect a standard
>Forth to support everything in the standard. Consequently vendors
>are very cautious about accepting extensions that should really
>be classified as library code.
>
>Just as the standard has xxx-EXT wordsets, perhaps we should
>also have LIB-xxx wordsets?
And you think that these users would then not expect the commercial
Forths to support everything in the LIB-xxx wordsets? I don't see the
difference.
Also, what extensions should really be classified as library code?
Doug Hoffman
Anton Ertl wrote:
> "Doug Hoffman" <dhof...@talkamerica.net> writes:
> >
> >Marcel Hendrix wrote:
> >
> >> It will become a standard when one \/ a few programmers publish
> >> their model,
> >
> >That's been done.
> >
> >> their extensive libraries,
> >
> >That's been done.
>
> Not that I noticed. Where can I find these libraries, and on what
> systems do they run?
I'm well aware of your position on the issue of standardized object
extensions in general, and on the Neon-style syntax in particular. I
believe you already know the answers. Regardless:
If the over 13 classes supplied in the updated McKewan-style ANSI Neon
model aren't enough to consider "extensive", and they probably aren't
(although they certainly show the potential of, and ease of adding to,
that library), the PowerMops library *is* very extensive by any
measure. One need not even have access to a Macintosh to examine this
library. There is an excellent online Manual for all to read. The
full source for PowerMops is also available online as an open-source
project.
The Win32Forth project provides many pre-defined classes for the
Windows/PC platform as well.
Although there are some detail differences, all three of the above
projects provide examples in essentially the same basic Neon-derived
syntax .
Regards,
-Doug
Anton Ertl
>IMO one of the basic reasons is that there is no consensus about how
>to organize code. I mean definitions of standard libraries. The shy
>temptative definition of "wordsets" in ANS Forth (when there had been
>vocabularies since long btw)
Wordsets and vocabularies have very little to do with each other. Are
you perhaps confusing wordsets with word lists (which are ANS Forth's
variation on vocabularies).
>WITHOUT daring to propose a common syntax
>how to include them in your application source, seems to me to have
>been "the historic bottleneck". It's analogous to the concept of
>header files and libraries in C and C++, of which every programmer can
>rely upon that strlen() is available to him after the preprocessor
>command #include <string.h>. It does not prescribe HOW it is achieved.
Just like a Forth programmer can rely that, say, COUNT is available to
him on an ANS Forth system (without nonsense like #include required).
Of course, both standards leave lots of things unspecified (e.g., how
a C program is compiled and linked, or how to start a Forth system),
and there are often problems coming from that.
In the Unix C world, most compilers follow the examples provided by
pcc and more recently gcc, and this helps quite a bit.
In the Forth world, we don't have such an influential system; some
systems always start with all the wordsets (e.g., Gforth and early
PFE), others don't (e.g., bigForth and IIRC iForth and more recent
PFE).
For those that don't, I have usually found it hard to find out how to
get the additional wordsets, so in the meantime my approach is: If an
ANS Forth program does not load on the system without additional
incantations, I usually just give up and conclude that the Forth
system sucks.
There is actually a standard way to ask for a wordset:
s" FLOAT" environment? ...
But AFAIK no existing system uses such a query as a hint that the
program would like to use the wordset.
The extension-query proposal is a little stronger in that respect by
having a reference implementation that does exactly that.
>BTW who would vote for including the MOPS model into Forth200x ?
I would vote against. I find the Neon/MOPS model technically bad
<http://www.complang.tuwien.ac.at/forth/objects/opinion.html>.
>The code is there, the user base is there, and it seems to require
>only 5 or 6 people to "storm the bastion"? ;-))
What bastion?
It needs just one person to make an RfD/CfV (one might use a separate
votetaker, though); then, of course, some people should send in
ballots, the more, the merrier.
Then there is the next stage of approval for Forth200x. The proponent
should find a champion in the committee. If interested people
actually showed up at the meeting, that would not hurt, either.
Anton Ertl
>The string class library you refer to is certainly extensive and impressive. The
>question is, would we not need a common set of string words, e.g.
We have such words:
>STRCPY
MOVE
> STRLEN
NIP
> STRCAT
MOVE
werty
I have explained the streamlined Forth , but not on your hardware .
It's up to you , here to argue it with "Us" to figure how to
code it !! Stop your complaining and start coding , if you can't
figure
how to code a I.P. , or nixing [compiler] words ,
i'll explain . But it is simple elimation ! I justfigured they were
NOT
needed at all !
But you must do some coding on your hardware . You must
start a new Forth ! From ground zero .
First rule : dont waste time on a Full , complete , correct assembler
.
Only code the classic , essential op codes ,later we elegantize ...
So what are you afraid of machine langauge ?
My method skips the hard to figure "SuperOpCodes" !!
Tempting isn't it ? BUT DON"t DO IT ! For it will be faster
to work with the super codes at a higher level !
remember ! The first draft doesnt need RunTime speed .
You will only need to do assembly for a short bit of code ( Forth
built in , instant assembler ) , after that , you NEVER have to
do Low level at a low level ! Cool huh ! Use High level to
do Machine language ...
I'm doin the ARM instruction set . I think the PDA is far easier to
work with and is NOT slow .
It won't need a KeyBoard !!!! it will create the remaining 90%
of Forth
using Voice menu recognition and touch screem ... cooool huh ?
PLease no complaints about "Where's the beef " ...
It's up to YOU !!!!!! You gotta code it . I obsolete and expose
the
stupid stuff and explain a common sense , simple way to do it ,
but i won't hold your hand .....
You gotta do the work ....
If your too lazy to learn machine lang , then you don't deserve a
Forth ,
go use the free stuff ha ha ....
_____________________________________________________________________--
Andreas Kochenburger wrote:
> I scanned through the available info at
> http://www.forth200x.org/forth200x.html
> and am a bit disappointed about the really minuscule progress made
> there towards a more modern Forth. Of course the right answer to me
> would be: where are your own contributions?
>
> But anyhow, no proposal seems to have been made towards obvious
> lacking things: OO, libraries, string handling, com sockets - you name
> others. Instead there are "teacup discussions" about standardizing
> already existing defacto words à la DEFER-IS. I don't call that
> progress.
>
> So I am dreaming of the day where some people pull together their
Krishna Myneni
> Krishna Myneni <krishn...@bellsouth.net> writes:
>
>>The string class library you refer to is certainly extensive and impressive. The
>>question is, would we not need a common set of string words, e.g.
>
>
> We have such words:
>
>
>>STRCPY
>
>
> MOVE
>
>
>> STRLEN
>
>
> NIP
>
>
>> STRCAT
>
>
> MOVE
>
> - anton
Hmm... I'll have to try that next time:
s" hello " s" world" MOVE TYPE
Apart from the trivial cases, real-world string manipulation requires the
ability to return dynamically sized strings.
Cheers,
Krishna
Stephen Pelc
(Anton Ertl) wrote:
>Also, what extensions should really be classified as library code?
In particular, domain specific code, e.g. the EKEY and cursor
key stuff. If you needed to generalise the masks for a vending
machine, you'll need to add at least:
BIT9-MASK
TIMEOUT-MASK
CRC-MASK
and a whole pile of stuff that will never be used in a desktop
app. Similarly, the vending machine app will never use a pile
of stuff in the current proposal.
Stephen Pelc
<dhof...@talkamerica.net> wrote:
>Stephen Pelc wrote:
>
>> I may have missed this while I was away, but is your updated
>> ANS code available somewhere?
>
>Yes.
>
> http://members.talkamerica.net/douglas...@talkamerica.net/
>
>file class.11.zip
It works fine on VFX Forth for Windows.
Stephen Pelc
(Anton Ertl) wrote:
>Krishna Myneni <krishn...@bellsouth.net> writes:
>>The string class library you refer to is certainly extensive and impressive. The
>>question is, would we not need a common set of string words, e.g.
>
>We have such words:
>
>>STRCPY
>
>MOVE
>
>> STRLEN
>
>NIP
>
>> STRCAT
>
>MOVE
This response would lead some of MPE's clients to claim that you
do not write applications, you write kernels instead. Application
developers working with strings need a layer of abstraction that
focuses on strings.
Doug Hoffman
Stephen Pelc wrote:
> >
> >file class.11.zip
>
> It works fine on VFX Forth for Windows.
Thanks for that, Stephen. Good to know the code is robust.
Regards,
-Doug
Jerry Avins
...
> Andreas, I am not finding inconvenient the use of an exponent---even
> a bare letter "e"---as a fp-designator. That is, currently
>
> 3.14159 \ interpreted as double
>
> 3.14159e \ interpreted as fp
...
> I vote against more states. Even if you call them environments.
Julian,
Using the Forth interpreter to accept keystrokes and from them put
numbers on the stack -- either stack -- is bad practice. The application
program, not the interpreter, should echo the keystrokes to the display,
and interpret them according to the program's intent.
My exhortation to programs is "Don't do me any favors." Numbers are not
received from input devices; keystrokes are. Properly used, the
keystrokes will never raise ambiguity with John D's plain 5, and 5.0.
Both can be floats, doubles, scaled singles, or whatever else is wanted.
In one program, I use your FSM to input the keystrokes and create the
internal number -- in the format I chose.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
John Doty
> Using the Forth interpreter to accept keystrokes and from them put
> numbers on the stack -- either stack -- is bad practice. The application
> program, not the interpreter, should echo the keystrokes to the display,
> and interpret them according to the program's intent.
>
> My exhortation to programs is "Don't do me any favors." Numbers are not
> received from input devices; keystrokes are. Properly used, the
> keystrokes will never raise ambiguity with John D's plain 5, and 5.0.
> Both can be floats, doubles, scaled singles, or whatever else is wanted.
If I adopt your practice I can no longer present Forth to my customers
as an scriptable/extensible command language for instrument control.
That would remove most of the point of using Forth and probably drive me
permanently to an alternative like Python.
William James
> Jerry Avins wrote:
>
> > Using the Forth interpreter to accept keystrokes and from them put
> > numbers on the stack -- either stack -- is bad practice. The application
> > program, not the interpreter, should echo the keystrokes to the display,
> > and interpret them according to the program's intent.
> >
> > My exhortation to programs is "Don't do me any favors." Numbers are not
> > received from input devices; keystrokes are. Properly used, the
> > keystrokes will never raise ambiguity with John D's plain 5, and 5.0.
> > Both can be floats, doubles, scaled singles, or whatever else is wanted.
>
> If I adopt your practice I can no longer present Forth to my customers
> as an scriptable/extensible command language for instrument control.
> That would remove most of the point of using Forth and probably drive me
> permanently to an alternative like Python.
To set voltage s3, instead of
5.5 s3 !v
use a parsing word:
s3 setv 5
Or
volts 5 s3 !v
John Doty
That causes exactly the problem I'm trying to avoid. !v is
general-purpose: you might feed it the value of a variable or an
expression. Your setv is special-purpose, not usable for anything
*except* literal keyboard input. The users will remember setv, forget
!v. Then the system ceases to be extensible by the users.
Don't complain that they're lazy unless you are an expert
astrophysicist, solid state physicist, applied physicist, systems
engineer *and* spacecraft operator. These are not lazy people, but they
are very busy: they don't have time to become programming specialists or
remember two definitions where one suffices.
I've considered an *all* floating point version of Forth (like an HP
calculator) for this kind of thing. On a workstation CPU the performance
penalty is small, and it would certainly be nice to get rid of data
types completely...
Jerry Avins
> Jerry Avins wrote:
>
>> Using the Forth interpreter to accept keystrokes and from them put
>> numbers on the stack -- either stack -- is bad practice. The application
>> program, not the interpreter, should echo the keystrokes to the display,
>> and interpret them according to the program's intent.
>>
>> My exhortation to programs is "Don't do me any favors." Numbers are not
>> received from input devices; keystrokes are. Properly used, the
>> keystrokes will never raise ambiguity with John D's plain 5, and 5.0.
>> Both can be floats, doubles, scaled singles, or whatever else is wanted.
>
>
> If I adopt your practice I can no longer present Forth to my customers
> as an scriptable/extensible command language for instrument control.
> That would remove most of the point of using Forth and probably drive me
> permanently to an alternative like Python.
I don't see why you can't create an input package that treats numbers
the way the calling program dictates. In addition of ACCEPT, you could
have ACCEPT-NUM, ACCEPT-FLOAT, ACCEPT-DOUBLE. For a little more effort,
you could write a GET-NUM that accepts a number type and a digit count
as input parameters (The one I can't give away allows editing the
displayed number via the cursor, and rejects unacceptable keys.)
I think it's unreasonable to expect users to respect the difference
between 5. , 5 , and 5e . That's the program's job. It's fine is source
code, but not for user input.
Do you commonly apply range checks to the numbers your programs read?
Input analysis routines take memory, but speed of execution is not an
issue with keyboard (or keypad) entry.
John Doty
> I don't see why you can't create an input package that treats numbers
> the way the calling program dictates. In addition of ACCEPT, you could
> have ACCEPT-NUM, ACCEPT-FLOAT, ACCEPT-DOUBLE. For a little more effort,
> you could write a GET-NUM that accepts a number type and a digit count
> as input parameters (The one I can't give away allows editing the
> displayed number via the cursor, and rejects unacceptable keys.)
If I'm going to do that, why not just write it in C? Would be harder to
use, but wouldn't be as intimidating to some people...
>
> I think it's unreasonable to expect users to respect the difference
> between 5. , 5 , and 5e . That's the program's job. It's fine is source
> code, but not for user input.
In a scriptable system, user input *is* source code. There is no
distinction. That's a crucial advantage of Forth over many other
approaches. If I were to give that up, I would abandon Forth for this
kind of application.
>
> Do you commonly apply range checks to the numbers your programs read?
I apply range checks to numbers that words read from the stack in cases
where I expect the word to be routinely used as a keyboard command. That
allows the code to detect and sometimes repair the most common kinds of
input mistakes. It's pragmatic, not perfect.
>
> Input analysis routines take memory, but speed of execution is not an
> issue with keyboard (or keypad) entry.
Not the issue. A workstation that can usefully run SAOImage DS9 to do
the back end analysis doesn't even notice the CPU/memory load of the
control application. Interactivity, extensibility, and scriptability are
the issues.
>
> Jerry
Jerry Avins
> Jerry Avins wrote:
>
>
>> I don't see why you can't create an input package that treats numbers
>> the way the calling program dictates. In addition of ACCEPT, you could
>> have ACCEPT-NUM, ACCEPT-FLOAT, ACCEPT-DOUBLE. For a little more effort,
>> you could write a GET-NUM that accepts a number type and a digit count
>> as input parameters (The one I can't give away allows editing the
>> displayed number via the cursor, and rejects unacceptable keys.)
>
>
> If I'm going to do that, why not just write it in C? Would be harder to
> use, but wouldn't be as intimidating to some people...
Because C would be harder to use (according to you).
>> I think it's unreasonable to expect users to respect the difference
>> between 5. , 5 , and 5e . That's the program's job. It's fine is source
>> code, but not for user input.
>
>
> In a scriptable system, user input *is* source code. There is no
> distinction. That's a crucial advantage of Forth over many other
> approaches. If I were to give that up, I would abandon Forth for this
> kind of application.
The script is essentially one-time user input. The numbers are put in
repeatedly. I'm discussing number entry here.
>> Do you commonly apply range checks to the numbers your programs read?
>
>
> I apply range checks to numbers that words read from the stack in cases
> where I expect the word to be routinely used as a keyboard command. That
> allows the code to detect and sometimes repair the most common kinds of
> input mistakes. It's pragmatic, not perfect.
You can improve it if you feel that it's worthwhile.
>> Input analysis routines take memory, but speed of execution is not an
>> issue with keyboard (or keypad) entry.
>
>
> Not the issue. A workstation that can usefully run SAOImage DS9 to do
> the back end analysis doesn't even notice the CPU/memory load of the
> control application. Interactivity, extensibility, and scriptability are
> the issues.
I just wanted to head off what might have been an objection. I still
think of memory as precious, despite the puny gigabyte card in my camera.
John Doty
> John Doty wrote:
>
>
>>Jerry Avins wrote:
>>
>>
>>
>>>I don't see why you can't create an input package that treats numbers
>>>the way the calling program dictates. In addition of ACCEPT, you could
>>>have ACCEPT-NUM, ACCEPT-FLOAT, ACCEPT-DOUBLE. For a little more effort,
>>>you could write a GET-NUM that accepts a number type and a digit count
>>>as input parameters (The one I can't give away allows editing the
>>>displayed number via the cursor, and rejects unacceptable keys.)
>>
>>
>>If I'm going to do that, why not just write it in C? Would be harder to
>>use, but wouldn't be as intimidating to some people...
>
>
> Because C would be harder to use (according to you).
The sort of Forth style you are advocating would make the application
as hard to use as an application in C.
>
>
>>>I think it's unreasonable to expect users to respect the difference
>>>between 5. , 5 , and 5e . That's the program's job. It's fine is source
>>>code, but not for user input.
>>
>>
>>In a scriptable system, user input *is* source code. There is no
>>distinction. That's a crucial advantage of Forth over many other
>>approaches. If I were to give that up, I would abandon Forth for this
>>kind of application.
>
>
> The script is essentially one-time user input.
Eh? Absolutely not!
A simple command like:
readout
is also a script. One could addreviate it as:
r : readout
if that's handy. Then there are more complex commands/scripts like:
5.5 s3 !v
The dialect I use is a concatenative language with flow control, so:
5. s3 !v readout 4. s3 !v readout repeat
is a perfectly reasonable command/script that alternates readouts with
different s3 settings. Script != definition. One might slap a name and a
colon in front of it to make it a definition if that's handy, but that's
not necessary.
Remember, I use a STOIC-descended dialect of Forth. In a STOIC dialect,
the command language is the full compiled language, not an abridged
interpreted pidgin as in a traditional Forth. Smart users exploit this
advantage. This also makes it easy to get users into programming what
they need: a definition is just a command with a name and a colon in
front of it. The programming language and the command language are the
same. Is this why traditional Forth users have trouble understanding the
power of the Forth approach here? I'd think that an over reaction:
traditional Forth is hobbled, but it's not completely crippled.
> The numbers are put in
> repeatedly. I'm discussing number entry here.
A command is just a line of code. It might include one or more literal
numbers. If number entry is special, commands become distinct from other
definitions, and a barrier appears between the users and writers of
commands.
Andrew Haley
I think you're missing the point, Jerry. It's useful to write a
package that is extensible by users, and that extensibility is Forth.
So, if there is a command, it's quite reasonable to allow you as a
user to define a word of your own that uses the command. Or, you may
write a script that calls the word in the usual way, passing args on
the stack.
From the very beginnings of Forth, this technique has been used to
provide "open" (as opposed to "sealed" applications to users. Open
Boot is an example of such a Forth application.
Forth isn't so very bad as an application language.
Andrew.
Andreas Kochenburger
<j...@virginia.edu> wrote:
>Andreas, I am not finding inconvenient the use of an exponent---even
>a bare letter
Pardon me, but that's because you are used to it up to a degree to
find a queer thing normal. Nearly everybody in the world reads 1.2 as
1 plus 2/10, and not as twelve. It's even queerer as not having "xx"
for string xx in a standard.
The only plausible reason for continuation is that "changing the old
Forth way would break to much existing code". But while this a good
general point, such conservativism in this special point leads to
frozen stagnation. And that's what this thread is really about.
The Beez'
Andreas Kochenburger wrote:
> But anyhow, no proposal seems to have been made towards obvious
> lacking things: OO, libraries, string handling, com sockets - you name
> others. Instead there are "teacup discussions" about standardizing
> already existing defacto words à la DEFER-IS. I don't call that
> progress.
follow a proper standard than a defacto standard.
> So I am dreaming of the day where some people pull together their
> courage and time just to propose an OO scheme (damn that zelotic
> discussion of object-method or method-object followers) ... or for
> setting environment flags (my favourite: float_dpl when 0 a dot in a
> number is interpreted as a double, when 1 the dot is interpreted as an
> fp number and put on the fp stack) ... or
At that point, I disagree whole heartedly!! Although I don't like the
multitude of numbers in Forth (unsigned, double, etc.) and the host of
words that come with it (U+, M+, D+) I like Forth BECAUSE it's (also)
low level and has a special quality that other languages don't have: I
can TELL the compiler what to do; skip two fields, print the next one,
skip a field, print one, print one. This wording is so perfect..! So
different with other languages that are formula based instead of
language based.
To me, OO is a technique, certainly NOT a paradigm. Adding it to Forth
would certainly kill the language. Ever told your five year old son in
an OO way how to get a newspaper in the local store? OO is not the way
people communicate!!
I use OO techniques when I feel it is the best way to solve a problem,
not like pepper and salt. I even don't need an OO language to do it.
So, your proposal to turn Forth into an OO language won't get any
support from me.
Hans Bezemer
John Passaniti
> To me, OO is a technique, certainly NOT a paradigm. Adding it to Forth
> would certainly kill the language. Ever told your five year old son in
> an OO way how to get a newspaper in the local store? OO is not the way
> people communicate!!
I'm not sure about the dividing line you're drawing between "technique"
and "paradigm." Object orientation can clearly be talked about both as
a practical technique and as a way to view and solve problems.
Your statement that object oriented is not the way people communicate is
very wrong. When I asked the lady this morning to make my chai latte, I
didn't give her a step-by-step procedural list of things to do in order
to make my drink. When I asked my nephew to pick up the baseball and
toss it to me, I didn't describe in detail the process needed to do
those two commands.
In both cases, I issued a message describing an outcome I wanted (my
drink, a ball tossed to me), but I didn't specify the procedure to do
so. I relied on the person (object) to take my command (message) and
perform it however made sense to them. *THAT* is the heart of what
object orientation is about, and is in fact why object orientation is
often talked about using anthropomorphic terms-- because it is very much
how humans communicate with each other.
Moving away from people and now to software, when I tell a window object
to draw itself, I am not telling it "okay, iterate over every child
window and invoke each child's draw command." I tell the top-level
window object to draw itself and rely on behavior embedded in the window
object.
I really have a hard time understanding why people have such a problem
dealing with object orientation. It seems to cause so much passion in
people, when all it *really* boils down to is a fancy namespace
management technique for code and data. That's it. Different languages
may expose that in various ways and layer on features and semantics, but
that's a language issue. Maybe that's why people get bent out of shape
over objects-- they are confusing object orientation with the languages
that expose it.
> I use OO techniques when I feel it is the best way to solve a problem,
> not like pepper and salt. I even don't need an OO language to do it.
> So, your proposal to turn Forth into an OO language won't get any
> support from me.
I find it highly unlikely that any proposal regarding object orientation
would "turn Forth into an OO language." If the existing ANS standard is
any indication of how the community wants to work, object orientation
would be added to Forth as an optional extension, not as a core
component. If you want to use it, fine. If you don't, fine. At least
that is what I as an embedded systems programmer would want.
It's interesting to see how other languages deal with this issue. For
example, the Lua language is not object oriented, but it does have some
basic primitives, semantics, and syntactic sugar that makes it very easy
to add any kind of objects the programmer can dream up. If your view of
objects is class-based (such as Java, C++, Smalltalk, etc.) then you can
implement your objects that way. If your view of objects falls more
along prototypes (Javascript, Self, etc.), then you can make your
objects work like that. Don't like either? Come up with something
new-- maybe you want single inheritance for data, multiple inheritance
for code.
The Lua community simply doesn't have the kind of dumb discussions I've
seen in comp.lang.forth regarding object orientation. People use it
when it makes sense, and don't when it doesn't. The language doesn't
dictate any particular model for objects, and allows programmers to do
whatever makes sense to them. There are some developing standards for
objects to encourage sharing and reuse, but nobody is forced to use them.
I think there is a lesson in there for Forth. In my opinion, all Forth
needs is to bless a simple standard for primitive object semantics,
possibly with some syntactic sugar for the interpreter to encourage (but
not enforce) some consistency. Start there, and let the Forth community
build up from that. Standards can then evolve from practical use.
The Beez'
> I'm not sure about the dividing line you're drawing between "technique"
> and "paradigm." Object orientation can clearly be talked about both as
> a practical technique and as a way to view and solve problems.
there is no escape. Pure object orientation adds any method possible to
any item there is. I don't like floats that have add, substract,
multiply, divide, sine, sqrt etc. methods added to it.
> Your statement that object oriented is not the way people communicate is
> very wrong. When I asked the lady this morning to make my chai latte, I
> didn't give her a step-by-step procedural list of things to do in order
> to make my drink. When I asked my nephew to pick up the baseball and
> toss it to me, I didn't describe in detail the process needed to do
> those two commands.
Then you *ASSUME* that she knows how to make it. Now try to build it
from the ground up, create a chai_latte object and create it with all
ingredients and methods using your "New chai_latte" method. She will
think you're out of your mind. I keep it with coffee. Is it
coffee.add(milk) or milk.add(coffee)? And if so, why not?
MILK COFFEE ADD
or
COFFEE MILK ADD
is much more comprehensible to me. And finally:
COFFEE ME BRING
Is much more logical and natural to me than:
Me.bring()
Whatever that may be.
> In both cases, I issued a message describing an outcome I wanted (my
> drink, a ball tossed to me), but I didn't specify the procedure to do
> so. I relied on the person (object) to take my command (message) and
> perform it however made sense to them. *THAT* is the heart of what
> object orientation is about, and is in fact why object orientation is
> often talked about using anthropomorphic terms-- because it is very much
> how humans communicate with each other.
Object orientation assumes that everything is part of a larger thing.
Obviously, this is not true. The world is a giant network. There are
very few natural hierarchies and most things happen because things
interact, not because things have the methods to do the things
themselves. Next time I'll tell my beer:
beer.open()
But I'm sure it won't arrive without an opener. Still, I can use a
lighter to do it. Still, the lighter doesn't do it by itself, it still
needs me.
> Moving away from people and now to software, when I tell a window object
> to draw itself, I am not telling it "okay, iterate over every child
> window and invoke each child's draw command." I tell the top-level
> window object to draw itself and rely on behavior embedded in the window
> object.
GUIs are often used as OO example, because that is the place where OO
makes sense. It doesn't in a lot of other areas, like DBs.
> I find it highly unlikely that any proposal regarding object orientation
> would "turn Forth into an OO language." If the existing ANS standard is
> any indication of how the community wants to work, object orientation
> would be added to Forth as an optional extension, not as a core
> component. If you want to use it, fine. If you don't, fine. At least
> that is what I as an embedded systems programmer would want.
When it is just another extension, OK, I can ignore it. When it becomes
part of a CORE wordset in order to "modernize" Forth, I'm VERY
suspicious. Another good language gone to the dogs..
> The Lua community simply doesn't have the kind of dumb discussions I've
> seen in comp.lang.forth regarding object orientation. People use it
> when it makes sense, and don't when it doesn't. The language doesn't
> dictate any particular model for objects, and allows programmers to do
> whatever makes sense to them.
I don't consider OO discussions dumb because it opposed to the
"general" view. I don't want any "particular model for objects" because
I can create objects from low level structures when I see fit. BTW, X
did that in C (so did 4tH in its I/O model).
> I think there is a lesson in there for Forth. In my opinion, all Forth
> needs is to bless a simple standard for primitive object semantics,
> possibly with some syntactic sugar for the interpreter to encourage (but
> not enforce) some consistency. Start there, and let the Forth community
> build up from that. Standards can then evolve from practical use.
Forth should first get a proper STRUCT/END-STRUCT standard before it
starts to wander in the realm of objects. Personally, when that is
done, I won't need objects anymore, apart from an operator that
executes a xt in a field.
Hans Bezemer
Jerry Avins
> Jerry Avins wrote:
>
>> John Doty wrote:
>>
>>
>>> Jerry Avins wrote:
>>>
>>>
>>>
>>>> I don't see why you can't create an input package that treats numbers
>>>> the way the calling program dictates. In addition of ACCEPT, you could
>>>> have ACCEPT-NUM, ACCEPT-FLOAT, ACCEPT-DOUBLE. For a little more effort,
>>>> you could write a GET-NUM that accepts a number type and a digit count
>>>> as input parameters (The one I can't give away allows editing the
>>>> displayed number via the cursor, and rejects unacceptable keys.)
>>>
>>>
>>>
>>> If I'm going to do that, why not just write it in C? Would be harder to
>>> use, but wouldn't be as intimidating to some people...
>>
>>
>>
>> Because C would be harder to use (according to you).
>
>
> The sort of Forth style you are advocating would make the application as
> hard to use as an application in C.
I don't see why the program's defining a number as floating point makes
it harder to use than requiring the user to do it. When the input will
be construes as floating point no matter what the user does, the program
should accept the number in any form and change only its type, not its
value.
>>>> I think it's unreasonable to expect users to respect the difference
>>>> between 5. , 5 , and 5e . That's the program's job. It's fine is source
>>>> code, but not for user input.
>>>
>>>
>>>
>>> In a scriptable system, user input *is* source code. There is no
>>> distinction. That's a crucial advantage of Forth over many other
>>> approaches. If I were to give that up, I would abandon Forth for this
>>> kind of application.
>>
>>
>>
>> The script is essentially one-time user input.
>
>
> Eh? Absolutely not!
We mean different things by "script", then. I took it to mean something
like a DOS batch file or a UNIX shell script.
> A simple command like:
>
> readout
>
> is also a script. One could addreviate it as:
>
> r : readout
>
> if that's handy. Then there are more complex commands/scripts like:
>
> 5.5 s3 !v
>
> The dialect I use is a concatenative language with flow control, so:
>
> 5. s3 !v readout 4. s3 !v readout repeat
>
> is a perfectly reasonable command/script that alternates readouts with
> different s3 settings. Script != definition. One might slap a name and a
> colon in front of it to make it a definition if that's handy, but that's
> not necessary.
>
> Remember, I use a STOIC-descended dialect of Forth. In a STOIC dialect,
> the command language is the full compiled language, not an abridged
> interpreted pidgin as in a traditional Forth. Smart users exploit this
> advantage. This also makes it easy to get users into programming what
> they need: a definition is just a command with a name and a colon in
> front of it. The programming language and the command language are the
> same. Is this why traditional Forth users have trouble understanding the
> power of the Forth approach here? I'd think that an over reaction:
> traditional Forth is hobbled, but it's not completely crippled.
If the Forth you're using can't take the burden of formatting input
numbers from the users, I think the less of it.
>> The numbers are put in
>> repeatedly. I'm discussing number entry here.
So am I. Repeated operations should be the computer's burden.
> A command is just a line of code. It might include one or more literal
> numbers. If number entry is special, commands become distinct from other
> definitions, and a barrier appears between the users and writers of
> commands.
For repeated operations, it becomes appropriate to help, rather than
educate, the user. This is Forth. There has to be a way.
Jerry Avins
...
> I think you're missing the point, Jerry. It's useful to write a
> package that is extensible by users, and that extensibility is Forth.
> So, if there is a command, it's quite reasonable to allow you as a
> user to define a word of your own that uses the command. Or, you may
> write a script that calls the word in the usual way, passing args on
> the stack.
Sure. In the process of extending, the user becomes programmer and needs
to exercise the same care that any programmer does. Not only entering
numbers in the form that the program will use them -- cell, double
cell, float, and maybe double float -- but also testing.
> From the very beginnings of Forth, this technique has been used to
> provide "open" (as opposed to "sealed" applications to users. Open
> Boot is an example of such a Forth application.
Certainly, but users of such systems have no beef when they input '5'
instead of '5.' or '5e' and the system crashes (or worse!) as a result.
> Forth isn't so very bad as an application language.
:-)
Andrew Haley
> Andrew Haley wrote:
> ...
>> I think you're missing the point, Jerry. It's useful to write a
>> package that is extensible by users, and that extensibility is Forth.
>> So, if there is a command, it's quite reasonable to allow you as a
>> user to define a word of your own that uses the command. Or, you may
>> write a script that calls the word in the usual way, passing args on
>> the stack.
> Sure. In the process of extending, the user becomes programmer and needs
> to exercise the same care that any programmer does. Not only entering
> numbers in the form that the program will use them -- cell, double
> cell, float, and maybe double float -- but also testing.
Correct.
>> From the very beginnings of Forth, this technique has been used to
>> provide "open" (as opposed to "sealed" applications to users. Open
>> Boot is an example of such a Forth application.
> Certainly, but users of such systems have no beef when they input '5'
> instead of '5.' or '5e' and the system crashes (or worse!) as a result.
Exactly. "Don't do that, then." :-)
Andrew.
Jerry Avins
Don't do what? Use the keyboard interpreter to input numbers in an
application? Ought one check the ranges of user-input array accesses?
John Passaniti
> John Passaniti wrote:
>> I'm not sure about the dividing line you're drawing between "technique"
>> and "paradigm." Object orientation can clearly be talked about both as
>> a practical technique and as a way to view and solve problems.
> A technique you can apply to any language existing. A paradigm means
> there is no escape. Pure object orientation adds any method possible to
> any item there is. I don't like floats that have add, substract,
> multiply, divide, sine, sqrt etc. methods added to it.
I have no idea what you mean by "there is no escape." Last time I
checked, my brain was functioning, and I can freely pick and choose from
any paradigm that makes sense to my application. In the current project
I'm working on, I have some object orientation, and some state machines,
some plain procedural code, and it's all wrapped by a scripting
interface. I am freely picking and choosing paradigms as I see fit, and
my choice of languages doesn't in any way "force" me into doing anything.
I think you need to provide a clear example of what you mean, because it
doesn't make any sense to me.
As for the bizarre notion of "pure object orientation," I have yet to
find any language that magically injects methods into fundamental data
types that don't make sense. What language are you thinking about where
your last two sentences make sense?
>> Your statement that object oriented is not the way people communicate is
>> very wrong. When I asked the lady this morning to make my chai latte, I
>> didn't give her a step-by-step procedural list of things to do in order
>> to make my drink. When I asked my nephew to pick up the baseball and
>> toss it to me, I didn't describe in detail the process needed to do
>> those two commands.
> Then you *ASSUME* that she knows how to make it. [...]
I have no idea what your point is. Your original statement was that
people don't communicate in an object oriented sense, and I provided a
couple examples to show your statement was false. Human interaction is
fundamentally object oriented.
What if the lady who made my drink doesn't understand my request? Just
like in most object oriented systems, she will issue an exception. She
will tell me that she doesn't know how to respond to my request.
Yes, I assume she will be able to respond to my request because of
context. I walked into the store, saw a chai latte on their menu, and
assumed that was a method that was understood.
> MILK COFFEE ADD
>
> or
>
> COFFEE MILK ADD
>
> is much more comprehensible to me. And finally:
>
> COFFEE ME BRING
>
> Is much more logical and natural to me than:
>
> Me.bring()
>
> Whatever that may be.
You're confusing syntax for the underlying concepts. I have no idea
what this portion of your reply was supposed to illustrate other than
you can juggle nouns and verbs around. The basic premise-- that human
interaction is fundamentally object oriented-- doesn't change just
because you struggle to find syntax to represent it.
>> In both cases, I issued a message describing an outcome I wanted (my
>> drink, a ball tossed to me), but I didn't specify the procedure to do
>> so. I relied on the person (object) to take my command (message) and
>> perform it however made sense to them. *THAT* is the heart of what
>> object orientation is about, and is in fact why object orientation is
>> often talked about using anthropomorphic terms-- because it is very much
>> how humans communicate with each other.
> Object orientation assumes that everything is part of a larger thing.
False. Class-based object orientation assumes that. Prototype-based
objects do not. Do you even understand the difference? Do you
understand that classes are just one way to model objects?
> Obviously, this is not true. The world is a giant network. There are
> very few natural hierarchies and most things happen because things
> interact, not because things have the methods to do the things
> themselves. [...]
This makes no sense to me. The world is *filled* with natural
hierarchies. I am now looking at a door. It is subordinate to the
frame it exists in. That frame is part of a wall. That wall is part of
a building. That building is part of a street. That street is part of
a city. That city...
Everything I look at-- natural or man-made-- can easily be expressed in
terms of some hierarchy. But instead of me simply iterating the
universe to me, why don't you provide an example of something--
anything-- that can't be broken down or put inside some hierarchy.
> Next time I'll tell my beer:
>
> beer.open()
>
> But I'm sure it won't arrive without an opener. Still, I can use a
> lighter to do it. Still, the lighter doesn't do it by itself, it still
> needs me.
Presto-- you just created a chain of objects that interact. There is a
hierarchy to the action of opening-- you control the opener which
attaches to the lid which is attached to the bottle. The objects
themselves don't need to be part of the same hierarchy. Object oriented
systems aren't simply about hierarchy, but also about interactions
between cooperative objects.
You have some bizarre ideas about what object orientation is. I suspect
you were exposed to it through some horrific language (let me guess,
C++) and now that experience has colored your world.
>> Moving away from people and now to software, when I tell a window object
>> to draw itself, I am not telling it "okay, iterate over every child
>> window and invoke each child's draw command." I tell the top-level
>> window object to draw itself and rely on behavior embedded in the window
>> object.
> GUIs are often used as OO example, because that is the place where OO
> makes sense. It doesn't in a lot of other areas, like DBs.
Nobody has ever said that object orientation makes sense in all
contexts. That is a straw-man argument.
As far as databases go, I assume you are talking about a specific type--
probably a relational database. The "impedance mismatch" between
relational databases and object orientation is well understood, and
there are plenty of ways to express a relational database in terms of
objects. Frameworks such as Ruby on Rails, ASP.NET, and the endless
Java-based systems that represent relational databases as objects are
plenty popular in their domains. But even if that wasn't the case,
there are object oriented databases that are perfectly happy to express
objects and their relationships in a natural way.
>> The Lua community simply doesn't have the kind of dumb discussions I've
>> seen in comp.lang.forth regarding object orientation. People use it
>> when it makes sense, and don't when it doesn't. The language doesn't
>> dictate any particular model for objects, and allows programmers to do
>> whatever makes sense to them.
> I don't consider OO discussions dumb because it opposed to the
> "general" view. I don't want any "particular model for objects" because
> I can create objects from low level structures when I see fit. BTW, X
> did that in C (so did 4tH in its I/O model).
Yep, using structures is just one way to construct objects. It's a
technique (in C and other languages) that has existed for years. In
case you expected surprise that objects can be modeled in non-object
oriented languages, it might interest you that the earliest Smalltalk
interpreter was written in BASIC.
So now that you've gotten the typical "I can do objects with structures"
out of your system and found a resounding "yeah, so what" from the
peanut gallery here, can we move on?
>> I think there is a lesson in there for Forth. In my opinion, all Forth
>> needs is to bless a simple standard for primitive object semantics,
>> possibly with some syntactic sugar for the interpreter to encourage (but
>> not enforce) some consistency. Start there, and let the Forth community
>> build up from that. Standards can then evolve from practical use.
> Forth should first get a proper STRUCT/END-STRUCT standard before it
> starts to wander in the realm of objects. Personally, when that is
> done, I won't need objects anymore, apart from an operator that
> executes a xt in a field.
I don't see it as an either/or thing. Maybe that's my problem. So many
people in this newsgroup seem convinced that the world is composed of
sets of disjoint choices, and I see the world as a playground where I
can pick and choose what makes sense.
But don't worry-- even though I can't imagine any serious future Forth
standard mandating objects in the core, you feel free to identify
yourself as someone who is irrationally against technologies you're not
forced to use (or apparently understand). The rest of us will quietly
enjoy the facilities, use what we like and ignore what we don't.
John Doty
> Andrew Haley wrote:
>>From the very beginnings of Forth, this technique has been used to
>>provide "open" (as opposed to "sealed" applications to users. Open
>>Boot is an example of such a Forth application.
>
>
> Certainly, but users of such systems have no beef when they input '5'
> instead of '5.' or '5e' and the system crashes (or worse!) as a result.
From a programmer's perspective, they've got no beef. But they aren't
programmers. They have problems that have many tricky pieces, some of
poorly understood cutting edge technology. They can't concentrate on the
minutiae of programming the way a programmer can. But they still need
powerful tools.
I can't profit by blaming my customers for not being programmers. I can
profit by helping them get their jobs done as efficiently as possible.
If in some cases that means silently correcting trivial input mistakes,
I'll do it.
I was on a telecon yesterday with a couple of these folks. They're using
one of my systems with a sensor whose characteristics are rather
different than anything I coded for. I guess they've been doing some
programming...
>>Forth isn't so very bad as an application language.
No, it's excellent, but Forthers' dogmatism hurts Forth's reputation
here. The Forth methodology supports flexibility and pragmatism, but
programmers have a hard time even conceptualizing what these mean to users.
Jerry Avins
> Jerry Avins wrote:
>
>> Andrew Haley wrote:
>
>
>
>>> From the very beginnings of Forth, this technique has been used to
>>> provide "open" (as opposed to "sealed" applications to users. Open
>>> Boot is an example of such a Forth application.
>>
>>
>>
>> Certainly, but users of such systems have no beef when they input '5'
>> instead of '5.' or '5e' and the system crashes (or worse!) as a result.
>
>
> From a programmer's perspective, they've got no beef. But they aren't
> programmers. They have problems that have many tricky pieces, some of
> poorly understood cutting edge technology. They can't concentrate on the
> minutiae of programming the way a programmer can. But they still need
> powerful tools.
>
> I can't profit by blaming my customers for not being programmers. I can
> profit by helping them get their jobs done as efficiently as possible.
> If in some cases that means silently correcting trivial input mistakes,
> I'll do it.
We're in agreement then. Why do we seem not to be?
> I was on a telecon yesterday with a couple of these folks. They're using
> one of my systems with a sensor whose characteristics are rather
> different than anything I coded for. I guess they've been doing some
> programming...
>
>>> Forth isn't so very bad as an application language.
>
>
> No, it's excellent, but Forthers' dogmatism hurts Forth's reputation
> here. The Forth methodology supports flexibility and pragmatism, but
> programmers have a hard time even conceptualizing what these mean to users.
You seem to be dogmatic about using the text interpreter to get numbers
from users and thereby saddle users with programmer's burdens. As with
the meaning of "script", do we have a language problem?
John Doty
> You seem to be dogmatic about using the text interpreter to get numbers
> from users and thereby saddle users with programmer's burdens. As with
> the meaning of "script", do we have a language problem?
I mean scripting in pretty much the Unix shell sense:
(1) Almost any interactive command or sequence may have a name bound to
it, allowing it to be used in a script.
(2) Almost all "scripting" facilities like flow control and expression
evaluation are available in interactive commands in the same form they
are used in scripts.
Some Unix commands "correct" their arguments. Few, if any, are touchy
about the trailing / that strictly should appear in a directory name: if
they need to check if something is a directory they stat() it. Often
they will accept deprecated argument usage, or usage from some other
flavor of Unix. Of course, users *should* use the correct forms (but
they won't, and get mad if the form they know stops working or
malfunctions for some picayune reason).
How would you get all of the following forms to behave in the same way,
while processing numbers from the user in the application (assuming !v
and s3 are defined)?
5. s3 !v
: t5 5. s3 !v ;
t5
3. 2. f+ s3 !v
Trying to be ANS in these examples, but of course ANS is seriously
flawed for this kind of thing in general: it fails criterion (2) above
rather badly.
Elizabeth D Rather
news:i7WdnfCvbIO2WBjZ...@rcn.net...>> ...
>>>Certainly, but users of such systems have no beef when they input '5'
>>>instead of '5.' or '5e' and the system crashes (or worse!) as a result.
>>
>>
>> Exactly. "Don't do that, then." :-)
>
> Don't do what? Use the keyboard interpreter to input numbers in an
> application? Ought one check the ranges of user-input array accesses?
Check user input? Gee, what a concept!
One of the golden rules of application-writing is to always check user
input. If a program has been debugged reasonably it won't "develop" bugs,
but users (even experienced ones) can be counted on to enter stuff wrong
sooner or later. I'm not a big advocate of internal bounds-checking, but
user input should always be checked.
Cheers,
Elizabeth
John Doty
> One of the golden rules of application-writing is to always check user
> input. If a program has been debugged reasonably it won't "develop"
> bugs, but users (even experienced ones) can be counted on to enter stuff
> wrong sooner or later. I'm not a big advocate of internal
> bounds-checking, but user input should always be checked.
So Forth should not be used as a command language by users? What a
terrible restriction! For me, that would make Forth nearly useless...
Jerry Avins
I understand that. (I even checked user input in every way I could
manage in order to protect my demo programs from myself.) What I don't
understand is how experienced programmers can believe it's unimportant.
Jerry Avins
I don't know. Especially about the last one. It's possible to have s3 do
a check for a float and D>F if not, but that will likely screw up too
often. I have taken the path of suffering the consequences of dictating
the form of numeric input (with overrides) because allowing free-form
input exposes risks that I find unacceptable. With 8080 PolyForth, I
didn't use floating Point, but forces all input to double, and provided
application words that converted stack entries to singles. The user's
'+' was : + D>S SWAP D>S + 2 3 + ; . To add doubles, one used D+ .
Messy, but whatever it takes. Hoe could one provide numeric format
protection in any language that allowed more than one form?
...
John Doty
> Elizabeth D Rather wrote:
>>Check user input? Gee, what a concept!
>>
>>One of the golden rules of application-writing is to always check user
>>input. If a program has been debugged reasonably it won't "develop"
>>bugs, but users (even experienced ones) can be counted on to enter stuff
>>wrong sooner or later. I'm not a big advocate of internal
>>bounds-checking, but user input should always be checked.
>
>
> I understand that. (I even checked user input in every way I could
> manage in order to protect my demo programs from myself.) What I don't
> understand is how experienced programmers can believe it's unimportant.
If a word gets its input from the stack, how does the word tell if it's
user input? If the word explicitly grabs input from the keyboard, how do
you use it when its input should come from elsewhere? Separate
vocabularies for users and programmers are not acceptable in a
scriptable system.
My answer is to check when the word is a high level word likely to be
used as a user command, and not to check at lower levels. Not perfect,
pragmatic. In general, my hardware is designed to the "Boughan
criterion": "It should be impossible to break the hardware from the
keyboard" (Ed Boughan, MIT Center for Space Research, ~1996).
It is helpful in my LSE64 system that a command can reasonably reliably
recognize an integer constant mistakenly passed to it in place of a
float and repair the error. I guess this would be very hard in ANS. And
if you type "5. 5 +" I figure you're on your own...
John Doty
> Hoe could one provide numeric format
> protection in any language that allowed more than one form?
It gets back to Julian's suggestion of a type stack. You'll find that's
where this subthread started...
C. G. Montgomery
>
> I've considered an *all* floating point version of Forth (like an HP
> calculator) for this kind of thing. On a workstation CPU the performance
> penalty is small, and it would certainly be nice to get rid of data
> types completely...
>
That's one characteristic of a Forth-like language called COD put together
by someone at NASA Goddard.
http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node32.html
I don't know whether anyone uses it these days.
regards cgm
Jerry Avins
> Jerry Avins wrote:
>
>> Hoe could one provide numeric format
>> protection in any language that allowed more than one form?
>
>
> It gets back to Julian's suggestion of a type stack. You'll find that's
> where this subthread started...
That's a fine way, but it's probably harder to build into an existing
Forth than other possible approaches. It would be a strong feature in a
Forth intended especially for extensible applications that don't
restrict keyboard input to ACCEPTed input.
Jerry Avins
> Jerry Avins wrote:
>
>> Elizabeth D Rather wrote:
>
>
>>> Check user input? Gee, what a concept!
>>>
>>> One of the golden rules of application-writing is to always check user
>>> input. If a program has been debugged reasonably it won't "develop"
>>> bugs, but users (even experienced ones) can be counted on to enter stuff
>>> wrong sooner or later. I'm not a big advocate of internal
>>> bounds-checking, but user input should always be checked.
>>
>>
>>
>> I understand that. (I even checked user input in every way I could
>> manage in order to protect my demo programs from myself.) What I don't
>> understand is how experienced programmers can believe it's unimportant.
>
>
> If a word gets its input from the stack, how does the word tell if it's
> user input?
It can't tell.
> If the word explicitly grabs input from the keyboard, how do
> you use it when its input should come from elsewhere?
If it should come from elsewhere, why is the word grabbing it from the
keyboard?
> Separate vocabularies for users and programmers are not acceptable
> in a scriptable system.
What's wrong with some separate words for writing scripts -- those parts
that jet keyboard input -- and using them?
> My answer is to check when the word is a high level word likely to be
> used as a user command, and not to check at lower levels. Not perfect,
> pragmatic. In general, my hardware is designed to the "Boughan
> criterion": "It should be impossible to break the hardware from the
> keyboard" (Ed Boughan, MIT Center for Space Research, ~1996).
>
> It is helpful in my LSE64 system that a command can reasonably reliably
> recognize an integer constant mistakenly passed to it in place of a
> float and repair the error. I guess this would be very hard in ANS. And
> if you type "5. 5 +" I figure you're on your own...
Detection and repair is one way; coercion is another. Whatever works. If
ANS can't do it -- but that would surprise me, since one could write a
Forth in BASIC that can -- use something else.
On my last DOS system (and a few before that) typing "format c:" at the
keyboard elicited the response "Your photograph has been forwarded to
the proper authorities for whatever action is deemed appropriate" and
the system returned to "prompt" state. Nevertheless, there was a way --
"format.com c:" -- to format the hard disk that bypassed the intervening
shell. One could do as much for '5' as for 'format'.
John Doty
Interesting. QDP is popular among my customers, but I hadn't realized
there was a Forth-like language underneath it. However, those who think
all is hunky-dory in the Forth world at NASA might consider the
following opinion:
http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
Discouraging, I think, but consistent with other opinions I've heard lately.
Elizabeth D Rather
news:XrqdnVg95fThdRjZ...@wispertel.com...
> Elizabeth D Rather wrote:
>
>
>> One of the golden rules of application-writing is to always check user
>> input. If a program has been debugged reasonably it won't "develop"
>> bugs, but users (even experienced ones) can be counted on to enter stuff
>> wrong sooner or later. I'm not a big advocate of internal
>> bounds-checking, but user input should always be checked.
>
> So Forth should not be used as a command language by users? What a
> terrible restriction! For me, that would make Forth nearly useless...
Where did I say that?
There are, obviously, various kinds of users. One is the kind you were
speaking of, who wish to get involved to the extent of understanding some
Forth plus application words and tinkering with the program, even though
they don't think of themselves as professional programmers. These are the
folks we were working with in the very early days of Forth, and they form a
lively and active minority of our user base today. However, for many
applications all the users want is to enter values to a "black box" and have
something useful happen. They are casual users, with neither the
inclination nor the opportunity to learn to use Forth as a command language
or to write & modify scripts.
A major strength of Forth is that applications can be tailored to serve the
needs of both types of users, even though their needs are quite different.
It's up to the application programmer to determine what kind of user the
program is to serve, and provide suitable user interfaces with appropriate
amounts and types of validity checking. However, I find with both types of
users, a command that will commonly be typed with one or more parameters
should check those parameters for reasonableness. That doesn't prevent such
a command from being used in a user word or script.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Trey Boudreau
> C. G. Montgomery wrote:
>
>> John Doty wrote:
>>
>> That's one characteristic of a Forth-like language called COD put together
>> by someone at NASA Goddard.
>>
>> http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node32.html
>>
>> I don't know whether anyone uses it these days.
>>
>> regards cgm
>
> Interesting. QDP is popular among my customers, but I hadn't realized
> there was a Forth-like language underneath it. However, those who think
> all is hunky-dory in the Forth world at NASA might consider the
> following opinion:
>
> http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
>
> Discouraging, I think, but consistent with other opinions I've heard lately.
>
"In addition, it is the author's opinion that more people know about
HP calculators and Postscript, then about Forth."
I've emailed the author with appropriate grammatical corrections.
-- Trey
John Doty
> There are, obviously, various kinds of users. One is the kind you were
> speaking of, who wish to get involved to the extent of understanding
> some Forth plus application words and tinkering with the program, even
> though they don't think of themselves as professional programmers.
I'm thinking of the kind who *don't* wish to get involved in
programming, indeed strongly wish not to, but must. Why must they?
Because they're dealing with cutting edge technology that they don't
understand very well (but nobody understands it better than they do). In
particular, they don't understand it well enough to tell a programmer
what they need. I can help them, I have some pretty broad experience
with this kind of stuff, but I'm far from omniscient. I really need to
see what they try, even if it isn't very good code. It's much easier to
clean up a good idea badly coded than a bad idea well coded. But they
have to try.
> A major strength of Forth is that applications can be tailored to serve
> the needs of both types of users, even though their needs are quite
> different.
A major weakness of ANS Forth is that it is really two different
languages, unlike, say, the Unix shell. That makes it harder for
nonprogrammers to learn and use. ANS Forth's design priority seems to me
to have been slick metaprogramming, not straightforward coding.
> It's up to the application programmer to determine what kind
> of user the program is to serve, and provide suitable user interfaces
> with appropriate amounts and types of validity checking. However, I
> find with both types of users, a command that will commonly be typed
> with one or more parameters should check those parameters for
> reasonableness. That doesn't prevent such a command from being used in
> a user word or script.
I agree. That's my approach.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>
>> There are, obviously, various kinds of users. One is the kind you were
>> speaking of, who wish to get involved to the extent of understanding some
>> Forth plus application words and tinkering with the program, even though
>> they don't think of themselves as professional programmers.
>
> I'm thinking of the kind who *don't* wish to get involved in programming,
> indeed strongly wish not to, but must. Why must they? Because they're
> dealing with cutting edge technology that they don't understand very well
> (but nobody understands it better than they do). In particular, they don't
> understand it well enough to tell a programmer what they need. I can help
> them, I have some pretty broad experience with this kind of stuff, but I'm
> far from omniscient. I really need to see what they try, even if it isn't
> very good code. It's much easier to clean up a good idea badly coded than
> a bad idea well coded. But they have to try.
Yes, we have some of those, too.
>> A major strength of Forth is that applications can be tailored to serve
>> the needs of both types of users, even though their needs are quite
>> different.
>
> A major weakness of ANS Forth is that it is really two different
> languages, unlike, say, the Unix shell. That makes it harder for
> nonprogrammers to learn and use. ANS Forth's design priority seems to me
> to have been slick metaprogramming, not straightforward coding.
Well, that's where I disagree. I don't in any way see it as "two different
languages," and I find non-programmers pick up what they need quite easily.
John Passaniti
> Interesting. QDP is popular among my customers, but I hadn't realized
> there was a Forth-like language underneath it. However, those who think
> all is hunky-dory in the Forth world at NASA might consider the
> following opinion:
>
> http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
>
> Discouraging, I think, but consistent with other opinions I've heard
> lately.
I know nothing about QDP and COD, but I fail to see what is discouraging
about that statement. It says that instead of Forth, the model they are
choosing to use is functions from an HP48. Sounds to me like someone is
building a domain-specific language and has found that the model
provided by HP48 functions provide a better fit for those applications
than Forth does.
What's discouraging about that? Forth is a great language to build
domain-specific languages.
Elizabeth D Rather
news:r1thg.10177$3B....@twister.nyroc.rr.com...
What I find discouraging in this article is this statement: "Although there
is no standard stack-oriented language, when compared to HP calculator
language, and even to Postscript the deficiencies/limitations of Forth are
serious."
I wish he had enumerated these "deficiencies/limitations".
Andreas Kochenburger
<j...@virginia.edu> wrote:
>I vote against more states. Even if you call them environments.
That's an interesting statement. In this light the presence or absence
of wordsets are states. F. ex. the environmental query S" EXCEPTION"
ENVIRONMENT? responds with a flag. It's truly a state because the
semantic of ABORT is totally different between the two states of this
flag.
So Forth is already abundantly full of states. Consequently it does
not really matter to put in a few more that are really useful. Like
BASE which is usually set to decimal as default at system start, other
"environments" or "states" can be set to default values in order to
make behave the system in the current standard way.
IMO the sequence [ 5.5 1 1e + + ] should be unambiguous whether base
is decimal or hex or whether the double wordset ot the float wordset
are included or not. When it can't be processed, then an exception
should be raised. That is much more important than to "count" the
number fo internal system states.
Andreas
-------
Dead men have no pockets.
Andreas Kochenburger
<j...@whispertel.LoseTheH.net> wrote:
>Interesting. QDP is popular among my customers, but I hadn't realized
>there was a Forth-like language underneath it. However, those who think
>all is hunky-dory in the Forth world at NASA might consider the
>following opinion:
>
>http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
>
>Discouraging, I think, but consistent with other opinions I've heard lately.
It seems that this statement is also from 1990 when the QDP manual was
written, and before the Forth standard appeared.
The fact that QDP is still alive and popular proves that the above
statement should not be taken too seriously.
Andrew Haley
> Andrew Haley wrote:
>> Jerry Avins <j...@ieee.org> wrote:
>>
>>>Andrew Haley wrote:
>>
>>>>From the very beginnings of Forth, this technique has been used to
>>>>provide "open" (as opposed to "sealed" applications to users. Open
>>>>Boot is an example of such a Forth application.
>>
>>>Certainly, but users of such systems have no beef when they input '5'
>>>instead of '5.' or '5e' and the system crashes (or worse!) as a result.
>>
>> Exactly. "Don't do that, then." :-)
> Don't do what?
You said the user inputted '5' instead of '5.' or '5e' and the system
crashed. I said "don't do that, then".
> Use the keyboard interpreter to input numbers in an application?
> Ought one check the ranges of user-input array accesses?
You said "using the Forth interpreter to accept keystrokes and from
them put numbers on the stack -- either stack -- is bad practice",
thereby damning a way of using Forth that has been productive for many
people.
I think you're making an unnecessary split between "user" and
"programmer". In some systems it may be useful to make such a
distinction, but not always. I'm disagreeing with your opinion that
it is _always_ wrong to allow the user of an application program to
interact by using the keyboard interpreter in the usual way.
Andrew.
Charles Melice
"Doug Hoffman" <dhof...@talkamerica.net> a écrit dans le message de
news: 1149098752....@c74g2000cwc.googlegroups.com...
>
> Andreas Kochenburger wrote:
> [snip]
>> So I am dreaming of the day where some people pull together their
>> courage and time just to propose an OO scheme (damn that zelotic
>> discussion of object-method or method-object followers) ...
>
> I have very recently tried, apparently in spectacular failure, to
> further the efforts of Andrew McKewan's work towards getting a
> standardized OOP scheme. Near as I can tell Forth will never have a
> standard here. It seems to be a religious thing. It certainly isn't
> performance (object-method or method-object) or popularity of use, or
> existence and quality/quantity of class libraries.
I also followed and participated in this history (I developed 4
different OOF variants)
I think that the absence of consensus is justified: no solution
seems to offer all the wanted features.
Worse: from the analysis of the various solutions,
it emerges that the lacks of a model X are the price
to be paid to solve the problems of a model Y.
It is possible to develop a satisfactory model provided that
it is completely dynamic, thus slow.
I think now that one possible solution to have the effective
class model is to modify the COMPILE, word to enable early
binding when it's possible.
One solution is to provide a model, a slow implementation and
the COMPILE, variation that will make the compiled code faster.
The goal is to have:
obj Method
Where 'obj' not a parsing word, not immediate.
'Method' not a parsing word, not immediate.
Charles
Andreas Kochenburger
>I think now that one possible solution to have the effective
>class model is to modify the COMPILE, word to enable early
>binding when it's possible.
>
>One solution is to provide a model, a slow implementation and
>the COMPILE, variation that will make the compiled code faster.
>
>The goal is to have:
>
> obj Method
>
>Where 'obj' not a parsing word, not immediate.
> 'Method' not a parsing word, not immediate.
Well, Forth will never be a "true" OO language. Therefore an early
binding OO concept will suffice. IMO it should also be a logical
extension of the CREATE DOES> concept. So method obj comes naturally
(method just puts an index or xt on the stack, which is consumed by
the object that knows its own data address). That's as fast as it can
be.
So far some mini-oof enhanced by some simple data storage management
with allocate/free could also be a solution (cluttering object data
into the dictionary space with comma or COMPILE, is unacceptable for
large and time-variant numbers of object instances). Inheritance is a
must. Encapsulation (hiding method names) and error checking can
remain "implementation defined".
Doug Hoffman
Andreas Kochenburger wrote:
> Well, Forth will never be a "true" OO language. Therefore an early
> binding OO concept will suffice.
I presume you mean that early binding should be used where it can be
used, such as when defining methods in terms of other class messages
(factoring). Late binding must be an inherent part of the model or you
haven't got OOP. Hopefully this is what you meant.
> IMO it should also be a logical
> extension of the CREATE DOES> concept. So method obj comes naturally
> (method just puts an index or xt on the stack, which is consumed by
> the object that knows its own data address). That's as fast as it can
> be.
>
> So far some mini-oof enhanced by some simple data storage management
> with allocate/free could also be a solution
I hope you don't mean something like Bernd's mini-oof. As clever as it
is, it is woefully inadequate as a serious object model. I think it is
useful for embedded programming.
> Inheritance is a
> must.
Yes.
> Encapsulation (hiding method names) and error checking can
> remain "implementation defined".
Agreed. I don't find the ability to make message names private to be
particularly useful. An object's data, however, absolutely must be
hidden. This is one important cornerstone of object programming, IMHO.
Regards,
-Doug
John Passaniti
> What I find discouraging in this article is this statement: "Although
> there is no standard stack-oriented language, when compared to HP
> calculator language, and even to Postscript the deficiencies/limitations
> of Forth are serious."
>
> I wish he had enumerated these "deficiencies/limitations".
I don't think it would be difficult to make an educated guess. Since
the author feels that the HP48 programming model is a better fit than
Forth, one should only have to review the differences between the HP48
and Forth.
My guess-- and it's only a guess based on what I know of the HP48-- is
that the author values a typed stack. The main way that I'm aware the
HP48 is different form Forth is that values have types (real, complex,
string, array, list, program, graphic objects, etc.) and some operators
work intelligently with those types.
If that turns out to be a concept the author values for his
domain-specific language, then Forth *is* deficient or limited in that
sense. Postscript is also mentioned, and it also has typed values on
the stack.
I can point to lots of ways Forth is deficient or limited in a variety
of domains. Why is this a surprise to anyone? Isn't the predominate
model of programming in Forth usually stated as "create an
application-specific language to solve the problem?" If an
out-of-the-box Forth needs to be extended by creating an
application-specific language, then Forth is in that sense deficient or
limited. Abstract away from a specific application and now look at
domains, and the same thing holds.
I still fail to see why this is a big deal.
John Passaniti
> Agreed. I don't find the ability to make message names private to be
> particularly useful. An object's data, however, absolutely must be
> hidden. This is one important cornerstone of object programming, IMHO.
I disagree. Privacy of data is certainly a useful feature sometimes
(specifically when objects from multiple sources need to "play nice"),
but it is not so universally important that all applications need to be
burdened with it.
When you look at how objects are implemented in some other languages
(such as Lua), privacy is is usually implemented by naming convention--
for example, the programmer may prefix a symbol with an underscore. If
such a convention is accepted and understood by the community, then that
is completely sufficient to implement privacy. People who value privacy
will respect the convention, and those who don't are free to access the
object's fields however and whenever they like.
Andreas Kochenburger
<dhof...@talkamerica.net> wrote:
>I hope you don't mean something like Bernd's mini-oof. As clever as it
>is, it is woefully inadequate as a serious object model.
No I don't. A small OOF should at least have destructors and offer
inheritance. But for a small and fast OO-Forth, browsable class trees
for late binding are IMO somewhat overengineered. I need to be able to
create new objects at runtime though. But that can be done by cloning
existing objects (assuming that its memory representation consists
solely of data and xts). And for this I don't need the dictionary i.e.
the outer interpreter with PARSE, FIND et al.
Of course it is a limited scheme. But "early binding plus late
clone&destroy" is ok for me and all that I would expect from Forth.
Forth is not Smalltalk after all.
Andrew Haley
> I don't find the ability to make message names private to be
> particularly useful. An object's data, however, absolutely must be
> hidden. This is one important cornerstone of object programming,
> IMHO.
Alan Kay would certainly agree with that. From a practical point of
view it is very nice to be able to remodel an object's layout without
changing any of its clients, and this is one of the big advantages of
an object-oriented design. The only counter-argument is efficiency,
and then it's a matter of designing an implementation that doesn't
penalize the use of access methods.
Andrew.
Coos Haak
> On Tue, 06 Jun 2006 15:44:19 -0600, John Doty
> <j...@whispertel.LoseTheH.net> wrote:
>>Interesting. QDP is popular among my customers, but I hadn't realized
>>there was a Forth-like language underneath it. However, those who think
>>all is hunky-dory in the Forth world at NASA might consider the
>>following opinion:
>>
>>http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
>>
>>Discouraging, I think, but consistent with other opinions I've heard lately.
>
> It seems that this statement is also from 1990 when the QDP manual was
> written, and before the Forth standard appeared.
What standard? ANS/ISO is from a later date, but Forth-83 and Forth-79
existed long before 1990 ;-)
> The fact that QDP is still alive and popular proves that the above
> statement should not be taken too seriously.
Of course not.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
John Doty
> On Tue, 06 Jun 2006 15:44:19 -0600, John Doty
> <j...@whispertel.LoseTheH.net> wrote:
>
>>Interesting. QDP is popular among my customers, but I hadn't realized
>>there was a Forth-like language underneath it. However, those who think
>>all is hunky-dory in the Forth world at NASA might consider the
>>following opinion:
>>
>>http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
>>
>>Discouraging, I think, but consistent with other opinions I've heard lately.
>
>
> It seems that this statement is also from 1990 when the QDP manual was
> written, and before the Forth standard appeared.
But ANS Forth is not much changed from the Forths of 3 decades ago.
>
> The fact that QDP is still alive and popular proves that the above
> statement should not be taken too seriously.
The widespread success of an application based on a nonstandard Forth
dialect like COD certainly shows that there's still life in the Forth
*idea* (and I wouldn't be here if I didn't agree). But the fact that the
author feels the need to deny his dialect is based on Forth indicates
how badly tarnished the name "Forth" is. In astronomy, where it began.
John Doty
>> A major weakness of ANS Forth is that it is really two different
>> languages, unlike, say, the Unix shell. That makes it harder for
>> nonprogrammers to learn and use. ANS Forth's design priority seems to
>> me to have been slick metaprogramming, not straightforward coding.
>
>
> Well, that's where I disagree. I don't in any way see it as "two
> different languages," and I find non-programmers pick up what they need
> quite easily.
Easily relative to what? You've previously stated that it takes days of
training to get the hang of the differences between interpretation and
compilation. But a unified language doesn't need days: it doesn't even
need minutes. Put a name and a colon in front of your command, and now
it's a definition. Or take part of a definition and test it as a
command. No need to master dozens of behavioral differences: they don't
exist.
John Doty
> "John Passaniti" <put-my-firs...@JapanIsShinto.com> wrote in
> message news:r1thg.10177$3B....@twister.nyroc.rr.com...
>
>> John Doty wrote:
>>
>>> Interesting. QDP is popular among my customers, but I hadn't realized
>>> there was a Forth-like language underneath it. However, those who
>>> think all is hunky-dory in the Forth world at NASA might consider the
>>> following opinion:
>>>
>>> http://heasarc.gsfc.nasa.gov/docs/software/ftools/others/qdp/node37.html
>>>
>>> Discouraging, I think, but consistent with other opinions I've heard
>>> lately.
>>
>>
>> I know nothing about QDP and COD, but I fail to see what is
>> discouraging about that statement. It says that instead of Forth, the
>> model they are choosing to use is functions from an HP48. Sounds to
>> me like someone is building a domain-specific language and has found
>> that the model provided by HP48 functions provide a better fit for
>> those applications than Forth does.
>>
>> What's discouraging about that? Forth is a great language to build
>> domain-specific languages.
>
>
> What I find discouraging in this article is this statement: "Although
> there is no standard stack-oriented language, when compared to HP
> calculator language, and even to Postscript the deficiencies/limitations
> of Forth are serious."
>
> I wish he had enumerated these "deficiencies/limitations".
You know what they are. You've certainly heard them all (and more)
described. You're the expert. You'll never admit to knowing them. If he
enumerated them, you'd just dismiss them. But they will remain.
There are no universal solutions.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>
>>> A major weakness of ANS Forth is that it is really two different
>>> languages, unlike, say, the Unix shell. That makes it harder for
>>> nonprogrammers to learn and use. ANS Forth's design priority seems to me
>>> to have been slick metaprogramming, not straightforward coding.
>>
>> Well, that's where I disagree. I don't in any way see it as "two
>> different languages," and I find non-programmers pick up what they need
>> quite easily.
>
> Easily relative to what? You've previously stated that it takes days of
> training to get the hang of the differences between interpretation and
> compilation.
When did I ever say such a thing? The only two things that are difficult
about learning Forth are stack management, which is not a skill other
languages require, and acquiring mastery of a useful number of words from
Forth's vast command set. The first of these is just a matter of practice,
and is a "knack" like learning to ride a bicycle. After just a couple of
days of practice with useful problem sets they "get" it, and are fine
thereafter. And acquiring vocabulary is just a matter of time and access to
good documentation. Neither of these issues have anything to do with
"differences between interpretation and compilation".
> But a unified language doesn't need days: it doesn't even need minutes.
> Put a name and a colon in front of your command, and now it's a
> definition. Or take part of a definition and test it as a command. No need
> to master dozens of behavioral differences: they don't exist.
If you're referring to compiler directives, there are relatively few of
them, certainly not "dozens". And although stack management is a new skill
for folks who have had some prior exposure to programming, the concept of a
compiler directive is familiar and straightforward. I've never had a
student troubled by this.
John Doty
> I can point to lots of ways Forth is deficient or limited in a variety
> of domains. Why is this a surprise to anyone? Isn't the predominate
> model of programming in Forth usually stated as "create an
> application-specific language to solve the problem?" If an
> out-of-the-box Forth needs to be extended by creating an
> application-specific language, then Forth is in that sense deficient or
> limited. Abstract away from a specific application and now look at
> domains, and the same thing holds.
Well, this author was constrained to use C or Fortran as his foundation
by the ftools coding standards. Why? Because these have historically
been freely and universally available on architectures commonly used for
scientific data reduction. There was certainly no point to basing a
simple Forth dialect on a more complicated one in this situation.
>
> I still fail to see why this is a big deal.
That the author chose to emphasize that his language is not based on
Forth (when it should be reasonably considered a Forth dialect) is
significant.
John Doty
I'm referring to every flow control construct (does IF work in the
interpreter?). Every kludge like [CHAR]. How many words are there that
only have "compilation semantics" or "interpretation semantics" but not
both? Why is state-smartness a frequent theme of discussion? In a
unified language this complexity disappears.
Jerry Avins
Let's back up. How do you ensure correct functioning of a Forth program
that receives the inputs 2.5, 3, 3.5, 4, ... in succession and the
intent is to treat all these numbers in the same way? How do you produce
6 when the interpreter is presented with [8.5 2.5 -]? Do you tell the
user he ought to have used D- D>S instead? Sometimes, certainly. Do you
say all the time?
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Doug Hoffman
John Passaniti wrote:
> Doug Hoffman wrote:
> > Agreed. I don't find the ability to make message names private to be
> > particularly useful. An object's data, however, absolutely must be
> > hidden. This is one important cornerstone of object programming, IMHO.
>
> I disagree. Privacy of data is certainly a useful feature sometimes
> (specifically when objects from multiple sources need to "play nice"),
> but it is not so universally important that all applications need to be
> burdened with it.
First, it isn't a burden (or much of one). I can give an example using
the Neon model if you like. Second, encapsulation provides very real
benefits. If we *know* that the only way an object's data can be
changed is via messaging, then we have an excellent layer of protection
against having the data mistakenly changed willy-nilly by any code in
the program using direct-access. Third, what if we later make a design
change to the object's internal data structure? Had we stayed with the
message interface then all we need do is change code in ONE place in
our entire program ( the method definition in the class). The
free-wheeling access style will force many changes through-out the
program. I know Forth favors the "no-restrictions" style of
programming but this encapsulation is genuiinely a good thing.
Complaining that it is restrictive is akin to complaining that the lack
of GOTOs in Forth restricts our ability to do some things.
> When you look at how objects are implemented in some other languages
> (such as Lua), privacy is is usually implemented by naming convention--
> for example, the programmer may prefix a symbol with an underscore. If
> such a convention is accepted and understood by the community, then that
> is completely sufficient to implement privacy. People who value privacy
> will respect the convention, and those who don't are free to access the
> object's fields however and whenever they like.
I don't think that the honor-system scheme is anywhere as good as
simply implementing encapsulation in the object extension. It is not
hard to do.
Regards,
-Doug
Julian V. Noble
> Elizabeth D Rather wrote:
>> What I find discouraging in this article is this statement: "Although
>> there is no standard stack-oriented language, when compared to HP
>> calculator language, and even to Postscript the
>> deficiencies/limitations of Forth are serious."
>>
>> I wish he had enumerated these "deficiencies/limitations".
>
> I don't think it would be difficult to make an educated guess. Since
> the author feels that the HP48 programming model is a better fit than
> Forth, one should only have to review the differences between the HP48
> and Forth.
>
> My guess-- and it's only a guess based on what I know of the HP48-- is
> that the author values a typed stack. The main way that I'm aware the
> HP48 is different form Forth is that values have types (real, complex,
> string, array, list, program, graphic objects, etc.) and some operators
> work intelligently with those types.
>
> If that turns out to be a concept the author values for his
> domain-specific language, then Forth *is* deficient or limited in that
> sense. Postscript is also mentioned, and it also has typed values on
> the stack.
>
It is exceedingly easy to put typed values on a stack, and to have
the operators and functions "know" what to do with them. I describe
this (and used it for years under HS/FORTH) in my book.
--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
Julian V. Noble
> Elizabeth D Rather wrote:
[ deleted ]
>> If you're referring to compiler directives, there are relatively few
>> of them, certainly not "dozens". And although stack management is a
>> new skill for folks who have had some prior exposure to programming,
>> the concept of a compiler directive is familiar and straightforward.
>> I've never had a student troubled by this.
>
> I'm referring to every flow control construct (does IF work in the
> interpreter?). Every kludge like [CHAR]. How many words are there that
> only have "compilation semantics" or "interpretation semantics" but not
> both? Why is state-smartness a frequent theme of discussion? In a
> unified language this complexity disappears.
>
Personally I prefer (and use) state-smart words. There is no law
against them, AFIK. But then I have never been bitten by the prob-
lems they cause under certain circumstances because my kind of pro-
gramming does not involve those circumstances. The reason F83 and
ANS tended to eschew state-smartness (and why Anton Ertl has inveighed
against it very convincingly) is the bugs it can cause. I no longer
recall the kinds of problem where it is bad, but I am sure those
who have had the bugs will never forget them.
Actually ANS Forth has reduced the number of kludges, particularly
with POSTPONE replacing both [COMPILE] and COMPILE .
Julian V. Noble
No fair, you deleted my beautiful, rational, well-argued case for
not having a switch to tell the system to interpret every number
as a float. I have worked with a system that did this and was
always getting hung up because I could not recall whether I had
said "floats" (or was it "alley-alley-home-free") or whatever
the incantation was. If you want to implement such a thing that
puts a highlighted F at the bottom of the screen to remind you
that all numbers are being accepted as floats, that would be fine.
But unless you are willing to do that extra work, I can live with
3 3.5 and 3.5e meaning different things, because I can see what I
am doing.
John Passaniti
>> I still fail to see why this is a big deal.
>
> That the author chose to emphasize that his language is not based on
> Forth (when it should be reasonably considered a Forth dialect) is
> significant.
It's no more significant than the Postscript authors saying their
language doesn't derive from Forth.