IF..ELSE..THEN *is* natural
M.L.Gassanenko
Suddenly I have come to understanding that the Forth IF..ELSE..THEN
syntax is quite natural, and, probably, THEN is the best word to be in
that place:
: FOO ( n -- )
dup 0< 0= \ If n is positive or 0,
if
200 + \ add 200,
else
-200 + \ else add -200.
then
. \ Then, print the result.
;
The Concise Oxford Dictionary says:
then [@en] adv., adj., & n. --adv.
_1 at that time; at the time in question (...).
_2 _a next, afterwards; after that (then he told me to come in).
_b and also (then, there are the childen to consider).
_c after all (it is a problem, but then that is what we are here for).
_3 _a in that case; therefore; it follows that (...).
_b if what you say is true (...)
_c (...) if you must have it so (...)
_d used parenthetically to resume a narrative etc. (...).
--adj. that or who was such at the time in question (the then Duke).
--n. that time (until then).
So, Forth THEN means "after that".
How can native speakers comment this?
--
M.L.Gassanenko
m...@iias.spb.su g...@agspbu.spb.su
Dirk Zoller
: then
: . \ Then, print the result.
: So, Forth THEN means "after that".
Not being a native speaker I always felt the same and never found
"THEN" in that place unnatural.
--
d...@roxi.rz.fht-mannheim.de <Dirk Zoller>
Dave Kenny
:
: Suddenly I have come to understanding that the Forth IF..ELSE..THEN
: syntax is quite natural, and, probably, THEN is the best word to be in
: that place:
: So, Forth THEN means "after that".
: How can native speakers comment this?
Quite right, IMHO. Yes, in my capacity as a native speaker of
UnitedStatesianEnglish, I would be inclined to say that the sense
you point out is in fact the PRIMARY one. In real life, time
relationships are much more important than logical implication.
(First you put your socks on, THEN you put your shoes on...)
I suspect the real problem for people is just that it "looks funny".
I have met programmers who are deeply uncomfortable with the idea of
indexing arrays from zero (0) instead of (1) because "nobody counts
starting with ZERO!" They are impervious to the fact that computing
array indices this way is MESSY. Similarly, they want local variables,
infix operators, lexical scoping and such simply because that is what
they are used to.
FORTH is a little like the 'vi' editor in Unix: "Hard to learn but
easy to use." (Peter Norton's summary of vi).
Bruce R. McFarling
>
>Suddenly I have come to understanding that the Forth IF..ELSE..THEN
>syntax is quite natural, and, probably, THEN is the best word to be in
>that place:
..
>So, Forth THEN means "after that".
>
>How can native speakers comment this?
That's precisely the point that my ... ?THEN ...
THEN idea was intending to address: to make THEN read
naturally, people *use* the 'after that' sense of the
word *instead of* the "if ... then ..." sense of the
word. So the dissonance is not that this is an
inappropriate use of the word "then", but only that it
is *not* the use of the word "then" that goes together
with "if". So the above replaces the if, and takes it
all the way into the 'then this happened' sense -- with
a condition and an absolute "then this might happen"
(?THEN) "and then this does happen" (THEN). And
unlike the replacement by IF ... THEN ... ELSE ... ENDIF,
IF{ ... ?THEN ... ELSE ... }END is entirely compatible
with ... IF ... ELSE .... THEN source. It's a
modification without renaming ... kinda more like
an ANS style suggestion than a Forth 83 style suggestion.
8-)#
Virtually,
Bruce R. McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
Jonah Thomas
d...@roxi.rz.fht-mannheim.de (Dirk Zoller) writes:
>M.L.Gassanenko (m...@iias.spb.su) wrote:
>: then
>: . \ Then, print the result.
>: So, Forth THEN means "after that".
>Not being a native speaker I always felt the same and never found
>"THEN" in that place unnatural.
I find it natural in this context. The trouble is that a lot of people
have learned Fortran or Basic which uses THEN in the other context, and
they tend to see it only that way as a result. it's a question of
perceptions, not realities.
Zsoter Andras
>: then
>: . \ Then, print the result.
>: So, Forth THEN means "after that".
>Not being a native speaker I always felt the same and never found
>"THEN" in that place unnatural.
Except that that "then" is another word. ;-)
Andras
Andrew Haley
: : then
: : . \ Then, print the result.
: : So, Forth THEN means "after that".
: Not being a native speaker I always felt the same and never found
: "THEN" in that place unnatural.
Quite so. As an English speaker of English, "then" at the end of a
conditional is fine. The only problem is with people who have used
things like Pascal where "then" is used to separate the conditional
from the body.
Andrew.
Elizabeth Rather
>
> Suddenly I have come to understanding that the Forth IF..ELSE..THEN
> that place:
>
> : FOO ( n -- )
> dup 0< 0= \ If n is positive or 0,
> if
> 200 + \ add 200,
> else
> -200 + \ else add -200.
> . \ Then, print the result.
>
> The Concise Oxford Dictionary says:
>
> then [@en] adv., adj., & n. --adv.
> _1 at that time; at the time in question (...).
> _2 _a next, afterwards; after that (then he told me to come in).
> _b and also (then, there are the childen to consider).
> _c after all (it is a problem, but then that is what we are here for).
> _3 _a in that case; therefore; it follows that (...).
> _b if what you say is true (...)
> _c (...) if you must have it so (...)
> _d used parenthetically to resume a narrative etc. (...).
> --adj. that or who was such at the time in question (the then Duke).
> --n. that time (until then).
>
>
That's why the word was chosen for this use in the first place!
--
Elizabeth D. Rather
FORTH, Inc. Products and services for
111 N. Sepulveda Blvd. professional Forth programmers
Manhattan Beach, CA 90266 since 1973. See us at:
310-372-8493/fax 318-7130 http://www.forth.com
Keith Wootten
<d...@winternet.com> writes
[snip]
>Quite right, IMHO. Yes, in my capacity as a native speaker of
>UnitedStatesianEnglish, I would be inclined to say that the sense
>you point out is in fact the PRIMARY one. In real life, time
>relationships are much more important than logical implication.
>(First you put your socks on, THEN you put your shoes on...)
But in Forth:
: Shoes_Yet? \ -- ;
Are_Your_Socks_on?
not If
Well_Put_Them_On_Or_You'll_Catch_Your_Death_Of_Cold
Then
Put_Your_Shoes_On
;
or
: Put_Shoes_On? \ -- ;
Begin
Socks_On?
Until
Put_Your_Shoes_On
;
Or as I prefer it in dont-just-hang-up...do-something! RTX code
(time critical but not safety critical)
: Shoes_At_All_Costs \ -- ;
9 For \ ten chances
Socks_On?
If
0 r! \ = r> drop 0 >r as defined in RTX code
Else
Wait_In_Case_He's_Still_Trying_To_Find_A_Matching_Pair
Then
Next
Put_Your_Shoes_On_Regardless
;
IMO it's not really English or any other human language. Personally I
feel happier with 'Endif' meaning 'this marks the end of the If
construct'. However, I wouldn't be prepared to die for this principle.
Chow for Niao
--
Keith Wootten
Bernd Paysan
>
> M.L.Gassanenko (m...@iias.spb.su) wrote:
>
> : then
> : . \ Then, print the result.
>
>
> Not being a native speaker I always felt the same and never found
> "THEN" in that place unnatural.
Pascal "native speaker" have problems, but since C is widespread now
(and C doesn't have a "THEN"), we should hear out.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
Zsoter Andras
>That's why the word was chosen for this use in the first place!
: FOO IF blah, blah, blah THEN ;
Where is an "after that" part in here????
: FOO IF blah, blah, blah ENDIF ;
At least shows what it does, even though "ENDIF" is not an English word.
IMHO this "after that" interpretation is hogwash.
Andras
Bruce R. McFarling
>M.L.Gassanenko wrote:
>> The Concise Oxford Dictionary says:
>>
>> then [@en] adv., adj., & n. --adv.
>> _1 at that time; at the time in question (...).
>> _2 _a next, afterwards; after that (then he told me to come in).
>> _b and also (then, there are the childen to consider).
>> _c after all (it is a problem, but then that is what we are
>> here for).
vvvvvvvvvvvvvv the Pascal / Basic sense vvvvvvvvvvvvvvvv
>> _3 _a in that case; therefore; it follows that (...).
>> _b if what you say is true (...)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Notice (b): if (a < 3) then ...
>> _c (...) if you must have it so (...)
>> _d used parenthetically to resume a narrative etc. (...).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
One of the most common ways to make the Forth
one sound sensible.
>> How can native speakers comment this?
>That's why the word was chosen for this use in the first place!
That's not what y'all were saying in the early 1980's.
The common line treated the Pascal names for the different
points in the standard control structures as operations,
and then put them where they worked with RPN. Which was
silly then and silly now: the structures *are* structures,
and the individual bits implement the structures.
Test it: use 'if' in a sentence, followed by 'then',
and you have to twist real hard to move from 3b to 3d. Leave
the 'if' out, and it's easy to use 'then' in the 3d sense.
Paul Shirley
In article <4qvvlu$4...@sjx-ixn4.ix.netcom.com>, Jonah Thomas
<JETh...@ix.netcom.com> writes
>
>>: then
>>: . \ Then, print the result.
>
>>: So, Forth THEN means "after that".
>
>>Not being a native speaker I always felt the same and never found
>>"THEN" in that place unnatural.
>
>have learned Fortran or Basic which uses THEN in the other context, and
>they tend to see it only that way as a result. it's a question of
>perceptions, not realities.
>
Linguistically correct maybe, I just don't feel completely comfortable
trying to make a programming language look like English... it just leads
to confusion and mistakes, they are very different things.
Consider: would you rather trust a flight safety system programmed in
English or a specialised programming language?
--
Paul Shirley
Bernd Paysan
Andrew Haley wrote:
> Quite so. As an English speaker of English, "then" at the end of a
> conditional is fine. The only problem is with people who have used
> things like Pascal where "then" is used to separate the conditional
> from the body.
Quite ok. I'm not a native speaker (of English), but since german
wenn...dann grammar is quite similar, you can even formulate the
socks-shoes-condition: "If your socks aren't on, put them on, then put
you shoes on." I would not feel that a then belongs before "put them
on", but it certainly belongs before "put your shoes on".
The only condition where a german wenn...dann realy requires "dann" is
the temoral case ("wenn" in the sence of "when"): "When it rains then
it's time to saw".
Elizabeth Rather
Bruce R. McFarling wrote:
[re THEN being "natural" English usage
>>That's why the word was chosen for this use in the first place!
> That's not what y'all were saying in the early 1980's.
I'm not sure which "y'all" you're referring to. Chuck originally built
the IF...ELSE...THEN structure the way it is because it "felt" natural
based on English usage (he never, to my knowledge, wrote anything in
Pascal and certainly never emulated it). I attended the FORTH-77, -78,
-79 and -82 standards meetings, and although the subject of ENDIF came
up once or twice (from European attendees who, it seemed to me, were
more concerned with Computer Science usage than English usage) but was
never considered seriously.
Elizabeth Rather
Zsoter Andras wrote:
>
> >That's why the word was chosen for this use in the first place!
>
>
> Where is an "after that" part in here????
In this case, "after that" you execute ; (return to the calling routine).
Bruce R. McFarling
Elizabeth Rather <era...@forth.com> wrote:
>Bruce R. McFarling wrote:
[THEN as continuation...]
>>>That's why the word was chosen for this use in the first place!
>> That's not what y'all were saying in the early 1980's.
>I'm not sure which "y'all" you're referring to.
If I was sure, I would have had a name to put in there.
I distinctly remember Forth being touted in several places as
having all the standard structures of structured programming fame,
and since it seems to be pretty much a 1-1 correspondence between
the names Wirth (of self-same structured programming fame 8-)#
used to delineate the structures, and the functions those markers
have *if* implemented as prefixes, then at the very least the
correspondence seems a pretty stunning coincidence. And it may
well be. But I remember having the difference between prefix
and postfix and why that meant that the IF has to come after
instead of before the test explained to me patiently in the
pages of FD, so in my prior Forth newbie incarnation there
was at least someone in FIG who thought it was just the
standard control structure 'operations' turned around to make
them RPN operations.
If I still had the FD that my letter appeared in,
I could tell you who, but after this long there's no way
I could remember.
> Chuck originally built the IF...ELSE...THEN structure the
> way it is because it "felt" natural based on English usage
Between the two of us, there is obviously one who
knows 100% more along those lines than the other, so I'll
trust your word on that. Of course, going back to definitions
3b and 3d, he was wrong, but Forth in backwards talking enough
can do that to a person.
Jonah Thomas
In <4+MpbEAy...@chocolat.foobar.co.uk> Paul Shirley
<Pa...@chocolat.foobar.co.uk> writes:
>In article <4qvvlu$4...@sjx-ixn4.ix.netcom.com>, Jonah Thomas
><JETh...@ix.netcom.com> writes
>>In <1996Jun27.1...@roxi.rz.fht-mannheim.de>
>>d...@roxi.rz.fht-mannheim.de (Dirk Zoller) writes:
>>>M.L.Gassanenko (m...@iias.spb.su) wrote:
>>>: So, Forth THEN means "after that".
>>>Not being a native speaker I always felt the same and never found
>>>"THEN" in that place unnatural.
>>I find it natural in this context. The trouble is that a lot of people
>>have learned Fortran or Basic which uses THEN in the other context, and
>>they tend to see it only that way as a result. it's a question of
>>perceptions, not realities.
>Linguistically correct maybe, I just don't feel completely comfortable
>trying to make a programming language look like English... it just leads
>to confusion and mistakes, they are very different things.
I don't see that there's a problem with that, provided people remember
they're programming and not writing in English. You learn how to use a
programming language and use it, and save the discussions about how it
compares to English for winter evenings sitting with brandy in front of a
fireplace, or summer evenings eating ice cream.
There could be a problem if a language is so much like English that
people think they can jump in and program without learning. I don't
think Forth has that problem. 8-)
>Consider: would you rather trust a flight safety system programmed in
>English or a specialised programming language?
It depends on the language. There are probably some languages I wouldn't
trust any better than English. I can't think of any offhand. But then,
when you get on a plane they don't tell you what language the safety
systems were programmed in....
Nicolas Tamburri Sun - Design Technology and Verification
In article <31D3BD...@forth.com>, Elizabeth Rather <era...@forth.com> writes:
|> M.L.Gassanenko wrote:
|> >
|> > Suddenly I have come to understanding that the Forth IF..ELSE..THEN
|> > syntax is quite natural, and, probably, THEN is the best word to be in
|> > that place:
|> > : FOO ( n -- )
|> > dup 0< 0= \ If n is positive or 0,
|> > if
|> > 200 + \ add 200,
|> > else
|> > -200 + \ else add -200.
|> > . \ Then, print the result.
|> >
|> > The Concise Oxford Dictionary says:
|> >
|> > then [@en] adv., adj., & n. --adv.
|> > _b if what you say is true (...)
|> > _d used parenthetically to resume a narrative etc. (...).
|> >
|> >
|>
While I am glad that Mr. Gassanenko has found some way to rationalize
this syntactical abomination, and with all due respect to Elizabeth
Rather, 2 comments:
1. The fact that there had to suddenly be reach enlightenment to see the
naturalness of the syntax implies that the syntax is not naturally
obvious.
2. If we really want to use THEN to imply "after that", then the
closest definition that fits is 3d. But the programming language
demands that it be used as 3a or 3b, that is, to follow an IF
clause.
To use THEN as a paranthetically means I can sprinkle it
anywhere:
: FOO 2 THEN 4 THEN + ;
should be perfectly reasonable, but we know it isn't.
IF we want to use "THEN" in the context of 3a or 3b, and retain
its naturalness, THEN "THEN" should precede the conditional clause,
as in this sentence.
We cannot mix the modes without causing confusion. Given Forth's
stack orientation, the control structures cannot always be bent
to the English language, nor any other presumably. In this case,
IF ... ENDIF was a solution that fit the programming language, had
precedence in other languages (notably PL1,) while retaining
compatible usage; in both cases, they enclose the conditional
execution block.
THEN on the other hand not only cannot be justified as following
a natural language syntax, but requires constant recalibration
for people who use multiple languages; In Forth, it encloses the
conditional execution block, in all other languages THEN precedes it.
IMHO, coming from FIG-FORTH, replacing ENDIF with THEN was a fix to
something that wasn't broken. I assumed one of 2 reasons why this
should have been done:
1. Someone wanted to give Forth a "common language" feel, while
retaining the postfix notation.
2. There was a wildly dialect of the language that the standard
wanted to be compatible with.
Either way, I adapted, but I still prefer the FIG/F79 syntax.
Just my $.02.
/nt
Bruce R. McFarling
Bernd Paysan <pay...@informatik.tu-muenchen.de> wrote:
>Quite ok. I'm not a native speaker (of English), but since german
>wenn...dann grammar is quite similar, you can even formulate the
>socks-shoes-condition: "If your socks aren't on, put them on, then put
>you shoes on." I would not feel that a then belongs before "put them
>on", but it certainly belongs before "put your shoes on".
..
Just what I was saying. The confusion is where 'if'
goes. For example, redefine forth if as -- and make if the
original structured programming 'start of structure' mark.
IF <your socks aren't on>
-- <put them on>
THEN <put your shoes on>
Is clear enough. Since there is something to take
the place of the "if then" sense of then, the 'first this
then that' sense can come through. And there really isn't
anything wrong with using the 'first this then that' sense
of THEN in Forth, because that's the kind of language
Forth is, mostly just one damn thing after another. 8-)#
In the natural language example, the structure is given by:
IF <conditional>, <consequence> THEN <unconditional>
but Forth already uses , for something else.
And the argument that IF is a test so it has
to go where Forth puts it is still silly. There
should be a test there, but why call it "IF" if that's
confusing (Sorry: why call it "IF" that's confusing if).
The only reason to call the test IF is because prefix
languages do -- which is a hysterical raison if there
ever was one.
Regnirps
Well, for the last twenty years I have thought of it like this:
IF
do this stuff
ELSE
do this stuff
THEN
reads as
IF true
do this stuff
ELSE
do this stuff
THEN continue
Charlie Springer
Andrew Haley
Nicolas Tamburri Sun - Design Technology and Verification (tamb...@anarky.NoSubdomain.NoDomain) wrote:
: THEN on the other hand not only cannot be justified as following
: a natural language syntax, but requires constant recalibration
: for people who use multiple languages; In Forth, it encloses the
: conditional execution block, in all other languages THEN precedes it.
THEN is not used at all in many languages. Besides, I don't think
that "other languages do it differently" is a good design criterion.
After all, you could say the same about RPN.
: IMHO, coming from FIG-FORTH, replacing ENDIF with THEN was a fix to
: something that wasn't broken. I assumed one of 2 reasons why this
: should have been done:
Your history is broken. fig-FORTH changed THEN to ENDIF for reasons
known only to Bill Ragsdale. The original Forths all used THEN to
terminate a conditional clause.
Many people on this group seem to think that FIG was the original
Forth, and that things different from fig-FORTH are departures from
the "original". I do not know why this is.
Andrew.
: 1. Someone wanted to give Forth a "common language" feel, while
Nicolas Tamburri Sun - Design Technology and Verification
In article <4rauv3$e...@majipoor.cygnus.com>, a...@phal.cygnus.co.uk (Andrew Haley) writes:
|> Nicolas Tamburri Sun - Design Technology and Verification (tamb...@anarky.NoSubdomain.NoDomain) wrote:
|>
|> THEN is not used at all in many languages.
AFAIK the languages that use THEN, do so consistently in the form
IF <test>
THEN <true clause>
To my knowledge, no language uses THEN as a FORTRAN CONTINUE statement,
that is to say, a NO-OP that can be placed anywhere, but comes particularly
handy in certain situations.
|> Besides, I don't think
|> that "other languages do it differently" is a good design criterion.
|> After all, you could say the same about RPN.
Agreed, but that doesn't mean we can't learn anything from other
languages, or throw things out just because they originated in other
languages.
|> : IMHO, coming from FIG-FORTH, replacing ENDIF with THEN was a fix to
|> : something that wasn't broken. I assumed one of 2 reasons why this
|> : should have been done:
|>
|> Your history is broken. fig-FORTH changed THEN to ENDIF for reasons
|> known only to Bill Ragsdale.
I would guess that Bill Ragsdale saw how much more readable
IF ... ELSE ... ENDIF is over IF ... ELSE ... THEN.
Actually I did know about previous Forths, but my post was munged just
before I sent it, and one of the casualties was reason 2 below. See
the corrected version.
|> The original Forths all used THEN to
|> terminate a conditional clause.
Were there others besides polyFORTH?
|> Many people on this group seem to think that FIG was the original
|> Forth, and that things different from fig-FORTH are departures from
|> the "original". I do not know why this is.
I know better than to think fig-FORTH was the original Forth.
But since many people (myself included,) cut their teeth on either
fig-FORTH, or some value-added system based on fig-FORTH, it is
perfectly understandable as to why the system is thought of as
the original.
In the late 70's when BYTE and Dr. Dobbs still published Forth
articles and programs, the dialect used was fig-FORTH, or its
close cousin FORTH-79. Every system sold to hobbyists was touted
as an "extended fig-FORTH". Extended usually meant it incorporated
FORTH-79 features. I can see why people view fig-FORTH as original
or "traditional" or "classic" Forth. For us, poly-Forth may as
well have been non-existent.
|> : 2. There was a wildly dialect of the language that the standard
^^^^^^
(I meant to say "widely used". Sorry for the confusion.)
|> : wanted to be compatible with.
|> Andrew.
/nt
W.Baden
Nicolas Tamburri Sun - Design Technology and Verification (tamb...@anarky.NoSubdomain.NoDomain) wrote:
> Either way, I adapted, but I still prefer the FIG/F79 syntax.
There are those who dislike ENDIF more than THEN.
The three principal ways to name something are Purpose,
Means, Syntax. They are to be preferred in that order.
ENDIF is syntax. I think it's worse than FI even.
THEN in Pascal is used for syntax. It's a keyword
to help parse the condition from the action.
The use in Forth is similar.
Unless referring to time, THEN in english is used to
separate thought-groups.
CONTINUE would have been the most appropriate, but
loses because of too many other associations.
SO could be a good choice.
Would anyone like to try GO-ON instead?
Someone should point out that ELSE is not English either.
We say OR ELSE or OTHERWISE in English.
The use of THEN and ELSE in programming languages is not
natural language. So what?
--
Procedamus in pace. Wil Baden Costa Mesa, California
Tom Zimmer
W.Baden wrote:
>
> Would anyone like to try GO-ON instead?
>
> Someone should point out that ELSE is not English either.
>
> We say OR ELSE or OTHERWISE in English.
>
I loke the OTHERWISE Wil, how about
IF
OTHERWISE
EVENTUALLY or SOMEDAY or THEREFORE or IFWEHAVETIME or WHY or BECAUSE
Tom Zimmer
Regnirps
Someone said THEN is not used as a continue in English.
"If you get a flat tire, replace it with the spare, then drive to the
nearest service station and have the flat fixed."
Andrew Haley
Nicolas Tamburri Sun - Design Technology and Verification (tamb...@anarky.NoSubdomain.NoDomain) wrote:
: |> Nicolas Tamburri Sun - Design Technology and Verification (tamb...@anarky.NoSubdomain.NoDomain) wrote:
: |>
: |> THEN is not used at all in many languages.
: AFAIK the languages that use THEN, do so consistently in the form
: IF <test>
: THEN <true clause>
That's true. However, the Forth equivalent would be be an IF that
does nothing, a THEN that replaces the existing IF, and an ENDIF that
replaces the existing THEN. I'm opposed to introducing words that
have no action!
[ ... ]
: |> Besides, I don't think
: |> that "other languages do it differently" is a good design criterion.
: |> After all, you could say the same about RPN.
: Agreed, but that doesn't mean we can't learn anything from other
: languages, or throw things out just because they originated in other
: languages.
Yes, but some things from other languages don't fit very well. IMHO
this is one of them.
[ ... ]
: |> The original Forths all used THEN to
: |> terminate a conditional clause.
: Were there others besides polyFORTH?
Sure. Originally they were just called Forth, then there was
miniFORTH and microFORTH and then polyFORTH. The language evolved
over a long period. Conditionals were terminated by THEN on every one
of these that I have seen.
[ ... ]
: In the late 70's when BYTE and Dr. Dobbs still published Forth
: articles and programs, the dialect used was fig-FORTH, or its
: close cousin FORTH-79. Every system sold to hobbyists was touted
: as an "extended fig-FORTH". Extended usually meant it incorporated
: FORTH-79 features. I can see why people view fig-FORTH as original
: or "traditional" or "classic" Forth. For us, poly-Forth may as
: well have been non-existent.
That may well be true, but FORTH, Inc's products were in use in many
industrial areas by then: the hobbyists were often unaware of the
industrial users, and vice versa. This is still true today.
fig-FORTH was basically a clone of the microFORTH systems of the time,
but with a few changes. These were:
Variable length names.
Compiler security.
No multitasking.
No target compiler.
and a few other things (like ENDIF). fig-FORTH was designed with
portability in mind rather than performance, and did a few truly
hideous things. My favourite:
: - NEGATE + ;
: = - 0= ;
This was truly stupid, when : = XOR 0= ; would have been twice as
fast! It's unfortunate that this is still thought of as "classical"
Forth, because it was intended as a bootstrap to a full Forth. It's
too bad that many vendors didn't bother to fix things.
Andrew.
Simon Read
N: (Nicolas Tamburri Sun - Design Technology and Verification)
N>
N> I would guess that Bill Ragsdale saw how much more readable
N> IF ... ELSE ... ENDIF is over IF ... ELSE ... THEN.
N>
-->
I don't see why IF ELSE ENDIF is any more readable.
All the points on this thread are fixated on comparisons with
the English language. English isn't the only human language!
Most programmers speak languages other than English as their
native tongue.
French puts its adjectives (mostly) after the noun. English puts
them before the noun. German tends to save up its verbs to the
very end of the sentence. Chinese... well, it's got thousands
of years of culture embedded in it, so it is semantically simple
but metaphorically very complex, because simple phrases often
have cultural references, without which the words would make no
sense.
IF ELSE THEN is simple and unambiguous. It works.
There is _no_need_ for it to resemble the detailed structure of
English.
Simon
Zsoter Andras
Simon Read (s.r...@cranfield.ac.uk) wrote:
>All the points on this thread are fixated on comparisons with
>the English language. English isn't the only human language!
>Most programmers speak languages other than English as their
>native tongue.
For that matter my mothertongue, Hungarian, has separate worrds for
"then" meaning the same as in IF ... THEN ... and "then" meaning
"after that".
I decipher this "feature" of the English language as a bug. (Which
are just two names for the same thing since MS-DOS. ;-)
Actually the overloadedness of the English words is a very big problem
when pseudo-English is used to communicate with computers.
[Well, probably Chinese would make the best computer language, but how
many people are willing to learn it? ;-)]
Andras
Elizabeth Rather
This entire thread is about 20 years too late. Chuck picked THEN in the
late '60s or early '70s. It was in widespread use via both FORTH, Inc.
commercial systems as well as PD systems spread through the astronomical
community (where Chuck's original work was done) well before FIG was
founded.
For whatever reasons, figFORTH used ENDIF. This innovation was soundly
rejected by the first standards conference to consider it (FORTH79) and
has never been accepted by any standards body, nor is it the prevalent
usage.
There are a lot of things in Forth that might have been done
differently. For example, Chuck now says that DO ... LOOP was a
"terrible mistake" and FOR ... NEXT is preferable. One can argue these
things, but there's really no point, because the language is what it is,
there are millions of lines of code and thousands of programmers that
use it that way, and it isn't likely to change.
Nicolas Tamburri
In article <wilbadenD...@netcom.com>, wilb...@netcom.com (W.Baden) writes:
|> There are those who dislike ENDIF more than THEN.
|>
|> The three principal ways to name something are Purpose,
|> Means, Syntax. They are to be preferred in that order.
|>
|> ENDIF is syntax. I think it's worse than FI even.
I'm not sure I agree. ENDIF is purpose as well as syntax. It is
an artificially coined word whose spelling clearly defines its purpose;
It defines the end of an IF conditional. I believe (that is IMHO,) that
is it much preferrable to something like FI because it is at least
somewhat mnemonic, whereas FI is merely contrived.
|> THEN in Pascal is used for syntax. It's a keyword
|> to help parse the condition from the action.
|>
|> The use in Forth is similar.
It is not similar. In Forth THEN comes at the end of a conditionally
executed clause. In Pascal it is used to seperate the the condition
from its consequential clause. That is similar to THEN's use in English.
Pascal picked THEN as a keyword because when coupled
with IF, it has a definite meaning familiar to most people. Forth
usage demands that it be coupled with IF, but uses it merely as syntax.
If we use English keywords to define syntax, then they
should be in keeping with English usage, otherwise they merely become
confusing. If it is impossible to come up with an English-like
syntax that is not confusing, then we should probably just coin
a keyword that makes sense in the context in which it is used.
|> Unless referring to time, THEN in english is used to
|> separate thought-groups.
Unless it is coupled with IF, in which case it is meant to define
the consequence of the IF. That is to say, it puts a condition
on whether a thought group occurs or not. For example:
"Get a haircut THEN go to the store THEN buy some bread."
is a perfectly valid sentence. If I add an IF clause like this:
"IF my hair is long THEN Get a haircut THEN go to the store THEN
buy some bread."
then the first THEN not only seperates thought groups, but also
defines whether that group is valid or not.
|> The use of THEN and ELSE in programming languages is not
|> natural language. So what?
So Forth's conditionals are confusing because THEN already has
common English meanings and Forth does not use any of them.
ELSE I won't touch.
More to the point, look at the subject line. Someone went
through a whole lot of trouble to justify the use of THEN in Forth
as being a natural extension of its English meaning. I wanted to
respectfully register my disagreement. For all other languages that
implement the THEN keyword, this thread is unnecessary.
/nt
\ My opinions do not reflect those of Sun Microsystems Inc.
John O Comeau
M.L.Gassanenko (m...@iias.spb.su) wrote:
: Suddenly I have come to understanding that the Forth IF..ELSE..THEN
: syntax is quite natural, and, probably, THEN is the best word to be in
: that place:
: So, Forth THEN means "after that".
: How can native speakers comment this?
I, for one, have been enlightened by Mr. Gassanenko's post, and now am as
confortable with THEN as I am with ENDIF. To people who program in BASIC
and/or DCL, FORTH's THEN can be hard to grok.
The Holy War was fun to watch, too. 8^) - John
--
jco...@world.std.com aka John Otis Lene Comeau
Home page: http://world.std.com/~jcomeau/
Disclaimer: Don't risk anything of value based on my advice.
"Anybody can do the difficult stuff. Call me when it's impossible."
Ed Borasky
Quoth the Elizabeth Rather (era...@forth.com):
>There are a lot of things in Forth that might have been done
>differently. For example, Chuck now says that DO ... LOOP was a
>"terrible mistake" and FOR ... NEXT is preferable. One can argue these
>things, but there's really no point, because the language is what it is,
>there are millions of lines of code and thousands of programmers that
>use it that way, and it isn't likely to change.
Are there really millions of lines of code and thousands of programmers?
My impression is that there are maybe a few hundred good Forth programmers in
the world, and that most of them get hired to port a few thousand lines of
Forth to the equivalent few hundred thousand lines of "C" :-).
Now, don't all you Forth programmers speak up and say, "I'm good, and I've
got 11,000 friends who are, too!" Even if you count hobbyists like me, I don't
think there are "thousands" of you, but just the same, don't turn
"comp.lang.forth" into a census just to prove me wrong :-).
--
M. Edward Borasky
How to Stop A Folksinger Cold # 2
"Are you going to Scarborough Fair?..."
No.
Bruce R. McFarling
a...@phal.cygnus.co.uk (Andrew Haley) wrote:
>That's true. However, the Forth equivalent would be be an IF that
>does nothing, a THEN that replaces the existing IF, and an ENDIF that
>replaces the existing THEN. I'm opposed to introducing words that
>have no action!
You are overspecifying when you say "the" Forth equivalent.
"A" Forth equivalent does those things (that's exactly how I defined
it in my letter to the editor of FD way back in the early 80's).
"Another" Forth equivalent would distinguish between the THEN that says
'proceed with the following action" and the THEN that seperates a
conditional and a consequence. Notice that in the English usage, THEN
is a seperator in the IF ... THEN construct, and IF is just a notifier
that a conditional will follow.
You may say that there is no need in Forth for such a
notifier. But doesn't THENS have a problem if ANS Forth doesn't
distinguish between orig's and dest's dropped by different
structure control words? So that's how my proposal works this
time: no do-nothing words, conditional-seperator THEN distinguished
from unconditional-seperator THEN, and support for conditional cascades
without requiring terminator counting.
<test-state> ?THEN <conditional-act> THEN <unconditional-act>
IF{ <test-state> ?THEN <conditional-act>
ELSE <test-state> ?THEN <conditional-act>
ELSE <test-state> ?THEN <conditional-act>
...
}ENDIF
[other languages do it discussion ...]
>Yes, but some things from other languages don't fit very well.
>IMHO this is one of them.
The whole 'other languages do it' has the whole thing
half backwards. Whether or not intentionally, Forth *does*
'do' "IF" the way other languages 'do' it: "IF" jumps over a
specific conditional action if the result of a test state is
false. The argument is that this is 'doing what other languages
do' at the wrong level of abstraction: control structures are
structures. A purely artificial construct will simply be learned
as it stands, since there is no basis of comparison (APL's "<-"
for example). A part artificial, part natural language construct
that uses the natural language part the way that the natural
language does is straighforward: C & AWK's "if(condition)expression".
And English *is* an overloading language -- as well as a lnaguage
that grows by coining neologisms, so borrowing from English implies
some leeway.
Implication: THEN is OK as it stands (def. 3d), ELSE is OK
(a fairly unambiguious neologism). But IF ... THEN ... conveys
a different meaning to THEN. A 'different kind of THEN" to
disambiguate solves that problem. And really, that different
kind of THEN is what we now call IF, because for simple
conditionals Forth doesn't require a marker that 'a test is
coming up': generating a test is not a special type of action
in Forth and the only reason for such a marker is for extending
the structure.
Ergo, ?THEN equals and is defined by the current IF.
Finally, the 20 years too late point. I hope Forth will
be around for more than 20 more. In the above proposal, IF can
be retained as a synonym for ?THEN with only a minor dictionary
space hit. Or legacy code could be translated mechanically. And
I would argue that for some of its advantages, we ought to expect
Forth to be more successful in the next phase of the current
economic long wave than in the current phase. And removing this
dialect interference can only improve matters. So its by no
means too late.
Peter Gallasch
Elizabeth Rather wrote:
>
> This entire thread is about 20 years too late. Chuck picked THEN in the
> late '60s or early '70s.
In my opinion, the words IF and THEN were chosen because they are used in
other programming languages. It happend that THEN has the discussed two
meanings, and an IF-statement in Forth can be read natural like in other
languages. But I think, the real reason for the placement of THEN at the end
of the statement is the RPN pragma of Forth, which puts the operator after
the operand. And thats a thing whith which you have to become familiar
anyway.
--
Peter Gallasch mailto:g...@adv.magwien.gv.at ___ __o
MA14-ADV Rathausstr. 1, A-1082 Wien, Austria ____ _'\<,_
phone +43-1-4000-98633 fax +43-1-4000-7141 (*)/ (*)
Mike Coughlin
In article <4rauv3$e...@majipoor.cygnus.com>,
Andrew Haley <a...@phal.cygnus.co.uk> wrote:
>Many people on this group seem to think that FIG was the original
>Forth, and that things different from fig-FORTH are departures from
>the "original". I do not know why this is.
This is an easy question to answer. The versions of Forth
that existed before the fig model were known to an extremely
small number of people. After fig Forth was written, many
more people could use it and find out what it was and how
it worked. When most Forth users try to think of what the
oldest version of Forth was like, they can only think of
fig Forth.
--
Michael Coughlin mi...@gnu.ai.mit.edu Cambridge, MA USA
Andrew Haley
Elizabeth Rather (era...@forth.com) wrote:
: This entire thread is about 20 years too late. Chuck picked THEN in the
: community (where Chuck's original work was done) well before FIG was
: founded.
I don't think it's too late to discuss these things. If people are
unhappy about a language feature, it's important to discuss the issues
with them even if certain features are cast in stone. After all, they
can always : ENDIF [POSTPONE] THEN ; .
The purpose of this thread is to talk bout something that newcomers
(and even some experienced users) find genuinely unsettling.
Andrew.
M.L.Gassanenko
:-))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Well, all you are right, let's stop this.
I can see that, *independently* on being or not being a native English
speaker, about 50% c.l.f. read/writers were thinking that
IF..ELSE..THEN is natural without any explanations, while other 50%
were considering it unnatural.
Probably, it has changed now (let us not argue about the digits).
Yes, we can argue about that, preferrably eating the ice-cream.
Yes, this could be done differently.
Yes, the standard THEN will not be changed.
Yes, the use of the word "then" in Forth may be rationalized.
What is important *now*:
1. The use of the word "then" is Forth *needs* rationalization (because
the word is used by other languages in a different sense).
2. We could recommend to book writers to explain why THEN is used this
way. Probably, even ANS Forth Rationale could mention it.
3. Probably, whis may be included into FAQ because even if 30% of people
have negative emotions because they cannot understand "but why THEN ?!",
it is worthy doing.
AFAIK, almost all Forth novices ask "why THEN comes in the end?"
------------
Less important:
I myself first learned PL/1, other Algol-derivatives, then Forth
and only then English at a reasonable level. I saw native English
speakers who found Forth THEN unnatural.
The only explanation I could think out before The Enlightement :-))))))))
was that first it was an RPN-style structure: <condition> IF <actions> THEN,
then appeared ELSE (which compiled a new forwards branch and resolved the
old branch), but IF and THEN were not renamed.
Linguistics:
"do-this, THEN do-that, THEN do-thaat" sounds natural.
"IF something, do-this, THEN do-that, THEN do-thaat" also sounds natural
(at least for those who does not try to associate THEN with IF and ignore
'do-this' -- how many people do this?; the if's scope is unclear, though).
Only "IF something, THEN do-this, THEN do-that, THEN do-thaat" sounds
unnatural because THEN is used in 2 different meanings.
I've got it(linguistics) right, didn't I?
---
M.L.Gassanenko
m...@iias.spb.su g...@agspbu.spb.su
Jonah Thomas
In <4rgksh$8...@majipoor.cygnus.com> a...@phal.cygnus.co.uk (Andrew Haley)
writes:
>I don't think it's too late to discuss these things. If people are
>unhappy about a language feature, it's important to discuss the issues
>with them even if certain features are cast in stone. After all, they
>can always : ENDIF [POSTPONE] THEN ; .
Yes. Synonyms are cheap. They don't particularly involve Forth, only
the programmer interface. More radical changes are harder. I figure
it's a different language when you redefine IF as a no-op.
>The purpose of this thread is to talk bout something that newcomers
>(and even some experienced users) find genuinely unsettling.
There's a problem. If you come up with a version of Forth that has more
than a very few features that are improved for newcomers, you've got a
new language. You're practically starting from scratch as far as
getting people interested is concerned.
Computer languages seem to have a mass effect, a certain economy of
scale. 100,000 programmers can produce a lot of library routines and
test each other's stuff and make bug reports. Forth is hanging on
because it gets such great results without much economy of scale at all.
But it would be hard to start over with an improved language, starting
with _no_ such economies.
To some extent we're restricted by our own ironbound traditions, tiny
community though we be. And to some extent we can change things around
as if we were Forth programmers. And maybe some we learn to communicate
better. Telling someone new to Forth that THEN means AFTERWARDS might
be a useful teaching tool.
Another teaching tool which unfortunately seems to come a little bit out
of order, would be to get them to redefine the names for themselves,
something like:
: IF-SO-THEN POSTPONE IF ; IMMEDIATE
: OTHERWISE POSTPONE ELSE ; IMMEDIATE
: AFTERWARDS POSTPONE THEN ; IMMEDIATE
Not that they'd write much code that way, but that it would make the
meanings clearer and also demonstrate that they can make the language
work for them. Too bad it wouldn't make sense at that point because of
the POSTPONE and IMMEDIATE .
Ewald Pfau
wilb...@netcom.com (W.Baden) wrote:
WB> ENDIF is syntax. I think it's worse than FI even.
[..]
WB> SO could be a good choice.
Yes.
Did it rain?
IF SO the street may be wet.
ELSEWISE probably not.
SO THEN let's go for a walk anyway.
Fine greetings to all native speakers. :)
Every language should have an expressability of this kind of 'stack' logic with
many different idioms. The question is the one for the most general form, which
fits to all sentences.
The expression for sure is natural. The reduced terms IF..ELSE..THEN are
technical ones.
Ewald
Bernd Paysan
Zsoter Andras wrote:
> Actually the overloadedness of the English words is a very big problem
> when pseudo-English is used to communicate with computers.
> [Well, probably Chinese would make the best computer language, but how
> many people are willing to learn it? ;-)]
The ambiguosity of a typical chinese spoken word is much higher (without
context you know nothing). The ambiguosity of written chinese language
is not as high (words that are spoken identically are written
different), but typcially still higher than english, because it's
grammar that fixes the meaning. And even then, you can introduce almost
arbitrarly ambiguosity by leaving out words. Yet, using the proper
words, you certainly can form almost unambiguous sentences in chinese,
but this is not usually done.
BTW: According to my dictinary, there is no chinese word for conditional
"then", but about five or six for (different) temporal "then", so a
chinese translation for Forth IF..ELSE..THEN is easy
(ruguo..ciwai..houlai), and certainly Forth's use forms the same bad
sentence as in english ("ruguo" what - the condition has to follow, and
"houlai" what if nothing or only ; follows).
One property of chinese is special, it is AFAIK the first language that
could be successfully syntax-checked by computers.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
Bruce R. McFarling
JETh...@ix.netcom.com (Jonah Thomas) wrote:
>Yes. Synonyms are cheap. They don't particularly involve Forth, only
>the programmer interface. More radical changes are harder. I figure
>it's a different language when you redefine IF as a no-op.
But since the real structured-control IF is not
necessary in the simplest case, it is unecessary to redefine
IF as no-op. It can be left in for importing standard
source and used to define the preferred name for the
marker intervening between the state test and the
conditional operations when exporting standard source.
And for more complex cases where an explicit conditional
execution control block *is* useful, there is no harm
making it 'if-like' as long as it is not exactly "IF".
Zsoter Andras
Andrew Haley (a...@phal.cygnus.co.uk) wrote:
>I don't think it's too late to discuss these things. If people are
>unhappy about a language feature, it's important to discuss the issues
>with them even if certain features are cast in stone. After all, they
>can always : ENDIF [POSTPONE] THEN ; .
I have seen this claim many times, but there is some inconvenience in this
approach. Every time you define ENDIF you have to check if it is already
defined.
Why should we not simply require a standard system to provide BOTH:
THEN and ENDIF with the same meaning so everyone can take the existence
of both as granted?
Andras
Jonah Thomas
In <4ri675$3...@seagoon.newcastle.edu.au> "Bruce R. McFarling"
<ec...@cc.newcastle.edu.au> writes:
>JETh...@ix.netcom.com (Jonah Thomas) wrote:
Yes. If you leave the existing structures alone you can import standard
code, and you can redefine the names to do whatever you want.
And you can come up with brand-new control structures. If you can write
them in standard Forth they'll be portable to standard systems.
At some point it's worthwhile to stop fine-tuning the language and write
some applications. And it's good if the applications are easy to
maintain, by someone else. At that point we have a trade-off between
getting it better and keeping something a lot of people already know.
It's funny to think of it like that, but the logic is the same whether
it's 1000 fellow programmers or 100,000. Unless you want to train them
yourself, you want to stay with what they already know. And in that
circumstance you're left trying not to do anything too unusual -- unless
there's a compelling advantage.
I'm not sure where that logic really leads, but I suspect it leads to
programming projects that have a much better chance of commercial
success and also aren't nearly so much fun.
Jonah Thomas
>Andrew Haley (a...@phal.cygnus.co.uk) wrote:
Because we'd like to allow very small embedded Forth's to be standard. We
already have 133 words in the Core, if you want to do a standard byte-code
Forth your token space is already more than half full before you start your
application. We could put ENDIF into the Core Extension wordset, but that
wouldn't guarantee it would be present and you'd still have to check if it's
already defined.
Would it be useful to have a simple library routine that checks whether a
word is present and skips the following definition if it is?
Zsoter Andras
Jonah Thomas (JETh...@ix.netcom.com) wrote:
>Because we'd like to allow very small embedded Forth's to be standard. We
Why?
An embedded program which runs on some exotic hardware on a washing machine
is very likely to be non-portable anyway. What is the point in making
it standard?
>already have 133 words in the Core, if you want to do a standard byte-code
>Forth your token space is already more than half full before you start your
>application. We could put ENDIF into the Core Extension wordset, but that
>wouldn't guarantee it would be present and you'd still have to check if it's
>already defined.
>Would it be useful to have a simple library routine that checks whether a
>word is present and skips the following definition if it is?
Something of that sort. If you want to check if something is defined by
using standard words only you get clumsy ugly-looking lines.
But if you need such facility you still have to add one word to CORE
so you will end up with 134. ;-)
Andras
Anton Ertl
In article <AAuYz...@ttpl.iias.spb.su>, M.L.Gassanenko <m...@iias.spb.su> writes:
|> 2. We could recommend to book writers to explain why THEN is used this
|> way.
Well, the Gforth manual has had such an explanation since early 1994.
|> 3. Probably, whis may be included into FAQ because even if 30% of people
|> have negative emotions because they cannot understand "but why THEN ?!",
|> it is worthy doing.
Ok, I have added the following section to the general FAQ:
4.4. Why does THEN finish an IF structure?
Some people find the way THEN is used in Forth unnatural, others do
not.
According to Webster's New Encyclopedic Dictionary, then" (adv.) has
the following meanings:
2b: following next after in order ... 3d: as a necessary
consequence (if you were there, then you saw them).
Forth's THEN has the meaning 2b, whereas THEN in Pascal and other
programming languages has the meaning 3d.
If you don't like to use THEN in this way, you can easily define ENDIF
as a replacement:
______________________________________________________________________
: ENDIF POSTPONE THEN ; IMMEDIATE
______________________________________________________________________
(The Webster version looks better than the Oxford version, because the
Forth meaning comes first:-)
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Elizabeth Rather
Jonah Thomas wrote:
>
> At some point it's worthwhile to stop fine-tuning the language and write
> some applications. And it's good if the applications are easy to
> maintain, by someone else. At that point we have a trade-off between
> getting it better and keeping something a lot of people already know.
> It's funny to think of it like that, but the logic is the same whether
> it's 1000 fellow programmers or 100,000. Unless you want to train them
> yourself, you want to stay with what they already know. And in that
> circumstance you're left trying not to do anything too unusual -- unless
> there's a compelling advantage.
Hear! Hear! Another of the main motivations behind developing the Standard was
"programmer portabiity", the ability of programmers to work productively on more than
one Forth system. This is only practical if we stick to a common usage that everyone
can learn. So long as you have to explain to your new programmer that even though
everyone else uses IF...ELSE...THEN because it's standard, your company uses this
other syntax because you like it ever so much better, it will be harder to achieve
this goal.
> I'm not sure where that logic really leads, but I suspect it leads to
> programming projects that have a much better chance of commercial
> success and also aren't nearly so much fun.
Depends upon your idea of fun. In the 23 years I've worked with Forth, the greatest
fun for me has been moving in to new application domains, solving important problems
for customers, getting paid for it, and moving on. I've come to learn in detail how
many things are done, from manufacturing zippers to controlling airport functions to
air-conditioning a very large plant in Tennessee to tracking packages to
manufacturing food products to managing telephone switchboards to processing "smart"
credit cards (to give just a few examples). This diversity of applications has, to
me, been far more fun than pondering yet another syntax for conditionals.
Leo Wong
When I write Forth, I like to hear Forth.
IF...ELSE...THEN sounds like Forth to me.
This too: BEGIN...WHILE...WHILE...REPEAT...THEN .
But if you don't agree, use ENDIF then.
-
LEO WONG MAB...@prodigy.com
New York State Department of Civil Service
Albany, NY 12239
Jonah Thomas
>Jonah Thomas (JETh...@ix.netcom.com) wrote:
>>Because we'd like to allow very small embedded Forth's to be standard.
>Why?
>An embedded program which runs on some exotic hardware on a washing machine
>is very likely to be non-portable anyway. What is the point in making
>it standard?
You could be right. But then, what's the point of requiring a lot of
syntactic sugar, when the CORE could be smaller? Forth has a niche in small
systems. One reason to have a standard is to improve our marketing of Forth,
and there's no point in excluding our major existing niche from that.
And an embedded program which documents its nonstandard requirements can be
standard. An embedded system which includes the CORE can be standard, and can
import standard programs, provided they aren't too large.
This latter could have some importance. It might be possible to write a
standard program (for washing machines or whatever) with a few special plugs
to handle special drivers. Move to a new processor and the program runs.
Optimise it for each processor as much as it needs or as you can budget the
time. It runs (slowly) from the start on the new systems, so you find out
quickly what needs to be optimised. I understand that you can do that now
with various commercial systems, but if you can do it with standard systems
then you aren't locked into one vendor. Even if there were only two vendors
that could give you this capability, *it would still fly better with
management*. Being able to second-source a compiler is a good thing. You
know the old story about how a single lawyer can't survive in a small town,
but two can make very good business -- it isn't like that the same way for
vendors, but there could be something similar.
>>already have 133 words in the Core, if you want to do a standard byte-code
>>Forth your token space is already more than half full before you start your
>>application. We could put ENDIF into the Core Extension wordset, but that
>>wouldn't guarantee it would be present and you'd still have to check if it's
>>already defined.
>>Would it be useful to have a simple library routine that checks whether a
>>word is present and skips the following definition if it is?
>Something of that sort. If you want to check if something is defined by
>using standard words only you get clumsy ugly-looking lines.
Well, but it only has to be written once. Something like:
: :?
>IN @ BL WORD FIND
IF
[CHAR] ; WORD 2DROP
ELSE
DROP >IN ! ;
THEN
;
This isn't quite good enough, it only allows 1-line definitions. But it could
be done easily enough.
>But if you need such facility you still have to add one word to CORE
>so you will end up with 134. ;-)
It doesn't have to be CORE, it could be written with standard words and put in
a library. Assume that the user has this one already, and include in the
documentation where to find it.
And anyone who doesn't want to use it, can edit the source code by hand to
remove the definitions he doesn't need.
Paul E. Bennett
In article <4rj0qv$1...@dfw-ixnews6.ix.netcom.com>
JETh...@ix.netcom.com "Jonah Thomas" writes:
[mucho snippo]
> At some point it's worthwhile to stop fine-tuning the language and write
> some applications.
That's right, you have got to earn sufficent beer tokens to continue playing.
> And it's good if the applications are easy to maintain, by someone else.
> At that point we have a trade-off between getting it better and keeping
> something a lot of people already know.
This starts to sound like an argument for concrete standardisation where
whatever you want you can't have unless it's standard. Goes against the
philosophy of Forth somewhat.
> It's funny to think of it like that, but the logic is the same whether
> it's 1000 fellow programmers or 100,000. Unless you want to train them
> yourself, you want to stay with what they already know. And in that
> circumstance you're left trying not to do anything too unusual -- unless
> there's a compelling advantage.
Just remember, the sort of documentation you provide can make all the
difference to whether or not someone else will understand your code. In my line
of producing trusted systems I produce a mass of documentation that is not even
part of the code. This is a functional requirements specification which takes
into accoun the functional analysis, task analysis, data flow analysis and
control flow analysis. Assumptions are recorded and decisions at every stage
are logged. Finally I'll end up with a fully reviewed technical requirements
specifcation. From here it is relatively straight forward to code up the
software without too much effort in commenting. Even forgetting the issue of
certification, it is well worth ensuring that you write some form of
maintenance manual for the product. Often this can be just a copy of the full
technical specification document. Whatever you use, review it for it's
suitability for purpose.
> I'm not sure where that logic really leads, but I suspect it leads to
> programming projects that have a much better chance of commercial
> success and also aren't nearly so much fun.
Projects that are a commercial success can be quite radical, can be a whole
lotta fun and usually pay real dividends in terms of job satisfaction. If
you're lucky it may even be financially profitable.
There is nothing wrong in producing a radical solution if it fits the needs of
the project. Just remeber that if it is out of the normal then document the
technique, approach or method very thoroughly so that even you have a chance 10
years later when someone asks that awkward question.
--
Paul E. Bennett <p...@transcontech.co.uk>
Transport Control Technology Ltd.
Tel: +44 (0)117-9499861
Going Forth Safely
Bruce R. McFarling
h929...@hkuxa.hku.hk (Zsoter Andras) wrote:
>Jonah Thomas (JETh...@ix.netcom.com) wrote:
>> Would it be useful to have a simple library routine that checks
>> whether a word is present and skips the following definition if
>> it is?
>
> Something of that sort. If you want to check if something is
> defined by using standard words only you get clumsy ugly-looking
> lines.
>
> But if you need such facility you still have to add one word to
> CORE so you will end up with 134. ;-)
Better 1 new word than all the new words that would
be introduced if multiple names for the same thing are included
in the CORE.
Bruce R. McFarling
Elizabeth Rather <era...@forth.com> wrote:
> This is only practical if we stick to a common usage that
> everyone can learn. So long as you have to explain to your
> new programmer that even though everyone else uses
> IF...ELSE...THEN because it's standard, your company uses
> this other syntax because you like it ever so much better,
> it will be harder to achieve this goal.
First, it's the same syntax, except for the IF{ }ENDIF
part. ?THEN ... ELSE ... THEN is just different naming.
Perhaps an easier naming to explain quickly to someone who may
be unaccustomed to program languages in general, which is
important in reducing the sugar coating that must be added
for scripting and macro definition applications of Forth.
And that's where my hobby interest is at the moment, so I care
about that right now.
On the other hand, for my professional interest, one
of the freedoms of being an academic is the ability to program
in ... ?THEN ... THEN until the thing works, and then use
the old search-and-replace to make it standard before it gets
published. So for that, the naming issue doesn't really matter:
I'll avoid the Forth naming for control structures as I've always
done, and the beauty of Forth is that, even as the opposite of
an expert, I can. That may be the real advantage of Forth for
the academic market: it's said that getting academics to agree
on something is like trying to herd cats.
Zsoter Andras
Jonah Thomas (JETh...@ix.netcom.com) wrote:
>Well, but it only has to be written once. Something like:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ;-)))
>: :?
> >IN @ BL WORD FIND
> IF
> [CHAR] ; WORD 2DROP
> ELSE
> DROP >IN ! ;
> THEN
>;
>This isn't quite good enough, it only allows 1-line definitions. But it could
>be done easily enough.
The problem is that now you have to check if :? is defined or not, so you
did not gain anything!
This is just postponing the problem one level up.
In DOOF I use the word DEFINED ( "name" -- xt | 0 ) which
works like ' but if the word is not found it leaves a 0 on the stack.
So:
DEFINED FOO 0=
[IF]
: FOO ............. ;
[THEN]
does the job.
>>But if you need such facility you still have to add one word to CORE
>>so you will end up with 134. ;-)
>It doesn't have to be CORE, it could be written with standard words and put in
>a library. Assume that the user has this one already, and include in the
>documentation where to find it.
See above.
Andras
Jonah Thomas
In <4rl793$8...@hkusuc.hku.hk> h929...@hkuxa.hku.hk (Zsoter Andras) writes:
>Jonah Thomas (JETh...@ix.netcom.com) wrote:
>>Well, but it only has to be written once. Something like:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ;-)))
>The problem is that now you have to check if :? is defined or not, so you
>did not gain anything!
>This is just postponing the problem one level up.
Yes, but it saves you a lot of typing. And at some point you have to
consider just how much portability you need. This word is a convenience,
and if somebody wants to run a tiny system which doesn't have it, and they
want to import your code, they can either load the word or they can check
by hand each optional definition and edit your source code. An obvious way
to do that is to first rewrite the choosing word to say to always compile,
and note the words which are redefined. Then check that the new versions
do the same things the older ones do.
>In DOOF I use the word DEFINED ( "name" -- xt | 0 ) which
>works like ' but if the word is not found it leaves a 0 on the stack.
>So:
>DEFINED FOO 0=
>[IF]
>: FOO ............. ;
>[THEN]
>does the job.
That looks good. It uses [IF] and [THEN] which are optional.
>>>But if you need such facility you still have to add one word to CORE
>>>so you will end up with 134. ;-)
>>It doesn't have to be CORE, it could be written with standard words and
>>put in a library. Assume that the user has this one already, and include
>>in the documentation where to find it.
>See above.
How much is it worth to you to be portable to every possible standard
system? How much is it worth to run correctly the first time on every
possible standard system? You can define DEFINED at the beginning of each
portable program and be sure it's there (but maybe redefined, so the user
can comment it out if they want) or you can assume they have it and let
them load it otherwise.
You could propose adding it as an optional word (which would have a much
better chance of acceptance than a new CORE word). Then the name would be
standardized and we'd be less likely to have different people making their
own varying versions. But somewhere along the line we're going to have to
start using libraries instead of tinkering with the standard. This is
perhaps analogous to writing applications in place of tinkering with the
compiler. 8-)
Zsoter Andras
Jonah Thomas (JETh...@ix.netcom.com) wrote:
>You could propose adding it as an optional word (which would have a much
>better chance of acceptance than a new CORE word). Then the name would be
>standardized and we'd be less likely to have different people making their
>own varying versions. But somewhere along the line we're going to have to
>start using libraries instead of tinkering with the standard. This is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>perhaps analogous to writing applications in place of tinkering with the
>compiler. 8-)
This is why checking the existence (definedness ;-) of a word is
important. When I include a header file in C I can use a few
#ifdef-s to check if the header has already been included in some
earlier point and process it only at the first time.
There is no short (is the proper word "handy"?) and plausible way
to do such things in standard Forth.
IMHO something like DEFINED is far more useful than ENVIRONMENT?
[who invented that beast?].
Andras
Peter J Knaggs
M.L.Gassanenko wrote:
>
> 2. We could recommend to book writers to explain why THEN is used this
We have included a full description of this in the notes that go along
with the FATWIN system back in 1988. Note: FATWIN was later developed
into
Forth++ (1990), but the updated notes continues to include a full
description
of THEN and its derivation.
--
Peter J Knaggs
p...@paisley.ac.uk
Zsoter Andras
Peter J Knaggs (p...@paisley.ac.uk) wrote:
>We have included a full description of this in the notes that go along
>with the FATWIN system back in 1988. Note: FATWIN was later developed
>into
>Forth++ (1990), but the updated notes continues to include a full
^^^^^^^^^^^^^^^^^^
Is there an implementation called Forth++ after all?
Any pointers please!
Andras
Anton Ertl
In article <4rnoj8$q...@hkusuc.hku.hk>, h929...@hkuxa.hku.hk (Zsoter Andras) writes:
|> This is why checking the existence (definedness ;-) of a word is
|> important. When I include a header file in C I can use a few
|> #ifdef-s to check if the header has already been included in some
|> earlier point and process it only at the first time.
No, you cannot. The usual convention is to check in the included file
whether a certain preprocessor symbol is defined, and to define this
symbol while loading the file. I.e.,
#ifdef ALREADY_LOADED_FOO
#define ALREADY_LOADED_FOO
...
include file definitions
...
#endif
This approach makes the compilation quite a bit slower than it already
is, because the preprocessor might have to scan the same file for
dozens of times, doing something useful only the first time.
If the author of the included file does not follow this convention,
users of the file are in trouble, because they have to make sure that
the file is included only once, otherwise the compiler will
complain. This is especially problematic when include files include
other include files.
Many Forth systems, OTOH, have a word like NEEDS <file> or
REQUIRE <file> that load the file only when it is not already loaded,
avoiding all this trouble. Too bad such a word is not standard.
|> There is no short (is the proper word "handy"?) and plausible way
|> to do such things in standard Forth.
|> IMHO something like DEFINED is far more useful than ENVIRONMENT?
You can write DEFINED yourself. However, it has its own
pitfalls. E.g., PFE defines UNDER+ with a different meaning from Wil
Baden's UNDER+. In the competition last winter one entry checked
whether UNDER+ was defined, and if yes, assumed it was defined with
Wil Baden's meaning. Of course, this program did not work with PFE.
So DEFINED is only useful, when there is a standardized meaning for
the name you are checking for.
Zsoter Andras
Anton Ertl (an...@a0.complang.tuwien.ac.at) wrote:
>No, you cannot. The usual convention is to check in the included file
>whether a certain preprocessor symbol is defined, and to define this
>symbol while loading the file. I.e.,
>#ifdef ALREADY_LOADED_FOO
>#define ALREADY_LOADED_FOO
>...
>include file definitions
>...
>#endif
Yes. But in Forth you do not even have that one.
>This approach makes the compilation quite a bit slower than it already
>is, because the preprocessor might have to scan the same file for
>dozens of times, doing something useful only the first time.
Well, it is true. But better to have something slow than not to have
such facilities at all.
>Many Forth systems, OTOH, have a word like NEEDS <file> or
>REQUIRE <file> that load the file only when it is not already loaded,
>avoiding all this trouble. Too bad such a word is not standard.
My point: There is NO standard word for doing it in a non-clumsy way.
>You can write DEFINED yourself. However, it has its own
>pitfalls. E.g., PFE defines UNDER+ with a different meaning from Wil
>Baden's UNDER+. In the competition last winter one entry checked
>whether UNDER+ was defined, and if yes, assumed it was defined with
>Wil Baden's meaning. Of course, this program did not work with PFE.
A word so wildly used as UNDER+ should have only one meaning.
On the other hand DEFINED is really more useful in (D)OOF type of systems
where the user is encouraged to createe lots of small VOCABULARY-es
so in a bigger library the chances are that the same word does
not appear in the same name space.
>So DEFINED is only useful, when there is a standardized meaning for
>the name you are checking for.
Yes. On the other hand if there are two different words with the
same name they should not be in the same name space otherwise
they cannot really meaningfully re-used within the same program.
Andras
Achim Gratz
>>>>> "Anton" == Anton Ertl <an...@a0.complang.tuwien.ac.at> writes:
Anton> No, you cannot. The usual convention is to check in the
Anton> included file whether a certain preprocessor symbol is
Anton> defined, and to define this symbol while loading the
Anton> file. I.e.,
#ifdef ALREADY_LOADED_FOO
#define ALREADY_LOADED_FOO
include-file definitions ...
#endif
Anton> This approach makes the compilation quite a bit slower than
Anton> it already is, because the preprocessor might have to scan
Anton> the same file for dozens of times, doing something useful
Anton> only the first time.
[...]
This is not really needed and good implementations avoid it. The
preprocessor can quite easily recognise these guards and doesn't even
need to look at the file when it encounters the next #include<foo.h>
while the preprocessor symbol ALREADY_LOADED_FOO is still defined. If
you want to be standard conforming you need to check that the include
file didn't change in the meantime (quite a pathological case anyway),
depending on the OS this would mean you may have to open the file, but
you still don't need to scan it fully.
--
Achim Gratz.
--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW: http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gr...@ite.inf.tu-dresden.de
Phone: +49 351 4575 - 325
W.Baden
Anton Ertl (an...@a0.complang.tuwien.ac.at) wrote:
: You can write DEFINED yourself. However, it has its own
: pitfalls. E.g., PFE defines UNDER+ with a different meaning from Wil
: Baden's UNDER+. In the competition last winter one entry checked
: whether UNDER+ was defined, and if yes, assumed it was defined with
: Wil Baden's meaning. Of course, this program did not work with PFE.
It's not _my_ UNDER+ -- it's Chuck Moore's. He extols it in
Brodie's _Thinking Forth_.
Would someone be so kind to tell me PFE's definition? PFE is not
portable to my Mac.
For some time I thought the name should be +UNDER to follow
the pattern of +! and to allow other members of the family
to follow the same pattern.
But UNDER+ has priority and others are not so useful
--
Let us go forth in peace. Wil Baden Costa Mesa, California
Skip Carter
In article <4rtip8$7...@hkusuc.hku.hk>, h929...@hkuxa.hku.hk (Zsoter Andras) writes:
|> Anton Ertl (an...@a0.complang.tuwien.ac.at) wrote:
|>
|> >No, you cannot. The usual convention is to check in the included file
|> >whether a certain preprocessor symbol is defined, and to define this
|> >symbol while loading the file. I.e.,
|>
|> >#ifdef ALREADY_LOADED_FOO
|> >#define ALREADY_LOADED_FOO
|> >...
|> >include file definitions
|> >...
|> >#endif
|>
|> Yes. But in Forth you do not even have that one.
|>
Here is how I handle this problem with a LARGE Forth project
that I am working on, and it is ANS:
: DEFINED ( c-addr -- t/f ) \ returns definition status of
FIND SWAP DROP \ a word
;
: ~DEFINED ( c-addr -- t/f ) \ returns definition status of
DEFINED 0= \ a word
;
TRUE VALUE verbose_file? \ true to echo comment string on load
WORDLIST CONSTANT <file-list> \ all file names go to their own wordlist
: FILE:
<file-list> SET-CURRENT CREATE FORTH DEFINITIONS
\ the following stuff is to make version/configuration management easier
\ it can be left out if you REALLY want to
[CHAR] ) WORD
verbose_file? IF COUNT DUP IF CR TYPE ELSE 2DROP THEN
ELSE DROP THEN
;
: ~INCLUDED ( c-addr -- t/f )
COUNT <file-list> SEARCH-WORDLIST
IF DROP FALSE ELSE TRUE THEN
;
Now my source files all look like:
C" filename" ~INCLUDED [IF]
FILE: filename $Workfile$ $Revision$ $Date$ $Author$ )
( .... file contents .... )
[THEN]
The $ delimited stuff are version manager keywords which are optional
as far as FILE: is concerned
--
Everett (Skip) Carter Phone: 408-641-0645 FAX: 408-394-5561
Taygeta Scientific Inc. INTERNET: sk...@taygeta.com
1340 Munras Ave., Suite 223 UUCP: ...!uunet!taygeta!skip
Monterey, CA. 93940 WWW: http://www.taygeta.com/skip.html
Ewald Pfau
an...@a0.complang.tuwien.ac.at (Anton Ertl) wrote:
AE> Many Forth systems, OTOH, have a word like NEEDS <file> or
AE> REQUIRE <file> that load the file only when it is not already
AE> loaded, avoiding all this trouble. Too bad such a word is not
AE> standard.
Filenames need not be stored internally. After opening, creating or including a
file, the filename may be unknown inside the Forth machine.
Wouldn't it be more intuitive for Forth use, to have marker names plus the
DEFINED you mention? Marker names could be MARKERs as well.
Ewald
Zsoter Andras
In the examples which come with my DOOF there are marker words, although
they are not MARKERs.
The latter idea is not so useful as it seems to be at the first glance
as a good marker words stands after ALL the useful definitions.
In other words, if any of the words is FORGET-ed the marker word will be
missing from the dictionary, which indicates that the file should be
reloaded.
Andras
M.L.Gassanenko
h929...@hkuxa.hku.hk (Zsoter Andras) wrote:
> >Because we'd like to allow very small embedded Forth's to be standard. We
>
> Why?
> An embedded program which runs on some exotic hardware on a washing machine
> is very likely to be non-portable anyway. What is the point in making
> it standard?
>
> >application.
The point is that you can find a cheaper/better hardware and
wish to use it instead of the old one. You will use a different Forth
for that hardware.
> In DOOF I use the word DEFINED ( "name" -- xt | 0 ) which
> works like ' but if the word is not found it leaves a 0 on the stack.
>
> So:
> DEFINED FOO 0=
> [IF]
> : FOO ............. ;
> [THEN]
>
> does the job.
Why do you think that xt cannot be 0?
In my system ' NOOP is 0 , which is convenient e.g. for DEFER initialization,
or makes [ ' DUP , ] work even though xt's are 16-bit while cells are 32-bit.
---
Michael L. Gassanenko
m...@iias.spb.su
M.L.Gassanenko
JETh...@ix.netcom.com (Jonah Thomas) writes:
...
> Another teaching tool which unfortunately seems to come a little bit out
> of order, would be to get them to redefine the names for themselves,
> something like:
>
> : IF-SO-THEN POSTPONE IF ; IMMEDIATE
> : OTHERWISE POSTPONE ELSE ; IMMEDIATE
> : AFTERWARDS POSTPONE THEN ; IMMEDIATE
>
> Not that they'd write much code that way, but that it would make the
> meanings clearer and also demonstrate that they can make the language
> work for them. Too bad it wouldn't make sense at that point because of
> the POSTPONE and IMMEDIATE .
It is a very good teaching example.
You explain that control structure do not compile into the definition,
but execute instead. To compile them into a definition, you need a
special word-- POSTPONE . When you have created a definition
that _executes_ a control structure word (normally words execute code
generated by control structure words, but our definition executes a
control structure word itself), you want it to also be a control structure
word and execute when Forth compiles a new definition. So you mark it
as IMMEDIATE . Immediate words execute in compilation state.
Non-immediate words get compiled.
At one, the novice learns more about compilation (he does not want to
understand the exact mechanics, bu he imagines what sort of things happens
there).
---
M.L.Gassanenko
m...@iias.spb.su g...@agspbu.spb.su
Zsoter Andras
M.L.Gassanenko (m...@iias.spb.su) wrote:
>> In DOOF I use the word DEFINED ( "name" -- xt | 0 ) which
>> works like ' but if the word is not found it leaves a 0 on the stack.
>>
>> So:
>> DEFINED FOO 0=
>> [IF]
>> : FOO ............. ;
>> [THEN]
>>
>> does the job.
>Why do you think that xt cannot be 0?
Well, on DOOF an xt is ain't 0.
>In my system ' NOOP is 0 , which is convenient e.g. for DEFER initialization,
?????????????????????????????
>or makes [ ' DUP , ] work even though xt's are 16-bit while cells are 32-bit.
We could agree on a non-zero value which cannot be a token, and give
it a name (so we need one name which finds a token but does not
THROW and exception if the name is not defined, and a name for the
"undefined" token, well it seems that things are getting complicated
so I would vote for " all xt <> 0 ").
BTW: Why is it essential that [ ' DUP , ] should work with 16-bit tokens
and 32-bit cells????
The program is not standard anyway and I don't really see why is it more
useful than DUP in compilation mode.
Andras
W.Baden
Skip Carter (sk...@taygeta.com) wrote:
> Here is how I handle this problem with a LARGE Forth project
> that I am working on:
Here is a solution using PLEASE. Since there is no recursion, you
can write it in Standard Forth.
WORDLIST CONSTANT LOADED
: --> PARSE-WORD >PAD 2DUP 2DUP PLEASE
| S" ~" LOADED SEARCH-WORDLIST 0= ?DUP AND
[IF] ELECTIVE ~ INCLUDED LOADED: ~ [THEN] | ;
: LOADED: LOADED SET-CURRENT CREATE FORTH-WORDLIST SET-CURRENT ;
Interpretative use:
--> source_file_id
The source_file_id is usually taken from the name of the principal
definition within the source file or is otherwise descriptive.
`ELECTIVE name' is a house macro that converts `name' to a string
for a full pathname, as needed for your environment.
For instance,
: ELECTIVE PARSE-WORD >PAD PLEASE
| S" $HOME/Forth/applib/~.4th" | ; IMMEDIATE
LOADED wordlist is also used for VIEW/LOCATE, but has an
implementation dependency on the ability to traverse a wordlist,
and assuming user xt's are assigned in monotonic sequence.
I believe that these do everything you want. Would someone
convert them to Standard Forth?
--
Procedamus in pace. Wil Baden Costa Mesa, California
Jonah Thomas
In <AAEqu...@ttpl.iias.spb.su> M.L.Gassanenko <m...@iias.spb.su>
writes:
>Why do you think that xt cannot be 0?
>In my system ' NOOP is 0 , which is convenient e.g. for DEFER
>initialization, or makes [ ' DUP , ] work even though xt's are 16-bit
while cells are 32-bit.
I've on occasion found it very convenient to assume that an xt can't be
zero. Nice to have an xt that can serve as a flag also.
I know this will fail on a system like yours where an xt can be zero.
Any time you send NOOP it will think it's a flag and likely quit or
something. But it's _so convenient_ I did it that way anyway.
Zsoter Andras
W.Baden (wilb...@netcom.com) wrote:
>Here is a solution using PLEASE. Since there is no recursion, you
>can write it in Standard Forth.
What is PLEASE ?
Andras
Peter J Knaggs
Yes. Contact Bill Stoddart or Dick Miller for more information.
Bill Stoddart bi...@scm.tees.ac.uk
Dick Miller dmi...@im.lcs.mit.edu
Bill Stoddart. "Forth++ and the Mach-1 board". In euroFORML'90
Conference
Proceedings.
Dick Miller. "The MACH1 In-PC Board, and Forth++ New Options for
Using the RTX-2000/1 Chip". In Proceedings of the Rochester Forth
Conference, 1990.
Forth++ Works on both the PC and the RTX. Both Bill and I have been
using
it for undergraduate projects for many years now.
> Andras
Michael Kalus
JEThomas wrote
> (...)
> people making their own varying versions. But somewhere along the
> line we're going to have to start using libraries instead of
> applications in place of tinkering with the compiler. 8-)
Did you try HOLON on 2 PCs? Its a compiler for easy use *only*.
No tinkering :-)
mka
## CrossPoint v3.02 ##
W.Baden
Zsoter Andras (h929...@hkuxa.hku.hk) wrote:
> What is PLEASE ?
PLEASE is the instrument used for macro expansion.
1 : --> PARSE-WORD >PAD 2DUP 2DUP PLEASE
2 | S" ~" LOADED SEARCH-WORDLIST 0= ?DUP AND
3 [IF] ELECTIVE ~ INCLUDED LOADED: ~ [THEN] | ;
Line 1 picks up the next word in the input stream. It
triplicates it because it is going to be used three times in the
expansion. PLEASE then takes the next non-space character as the
delimiter for the macro pattern. Each occurrence of the
parameter place holder ~ will be replaced by a parameter string.
The expanded text is put back in the input stream. E.g., given
`--> QKSORT', the result will be _exactly_ as though the
following was the input
S" QKSORT" LOADED SEARCH-WORDLIST 0= ?DUP AND
[IF] S" $HOME/Forth/applib/QKSORT.4th" INCLUDED LOADED: QKSORT [THEN]
PLEASE is trivial to implement, but it cannot be done in Standard Forth.
[From _OLD_ ThisForth Documentation.]
INPUT and OUTPUT
----------------
What distinguishes ThisForth is the approach to input and output.
Logically there is just one input device and one output device. These
can be dynamically reassigned, but ThisForth sees all input source as
one single sequence of characters, with no awareness of the origin.
There are Forth words to insert textfiles indirectly (`STREAM')
or character strings directly (`PLEASE') into the logical
input source. ThisForth sees the result as one single sequence
of characters. That is how macros are implemented.
MACROS
------
A macro is a word that inserts a character string into the
logical input source. The character string may have slots that
are filled by string parameters. The character string will be
processed by the next Forth word(s) that consume input source.
A _word_ -- a sequence of visible characters -- is the
fundamental lexical unit in all Forths. In ThisForth
successive invisible characters are filtered out of the input
source. When a visible character is encountered characters are
collected until a character that is not visible is encountered.
The collected characters form a word which is then treated by
Forth's text interpreter.
There are no lines, records, blocks, or files, recognized in
this process. There is no concept of input buffer.
RE-SCANNING INPUT
-----------------
In most traditional implementations the value at >IN can be
modified so the input source will be re-scanned. The input
source itself must not be changed. In ThisForth text that has
just been read can be modified, expanded, and re-inserted in the
logical input source. The file is not changed.
PLEASE <spaces><char><text><char>
---------------------------------
PLEASE is the word used by macros to insert a character string
or section of a character string into the input source. The
character " or ' or | is usually the character <char> used as
the delimiter.
A complete implementation of the Eaker CASE structure in ThisForth :
: CASE PLEASE " [ 0 ] " ; IMMEDIATE
: OF PLEASE " OVER = IF DROP " ; IMMEDIATE
: ENDOF PLEASE " ELSE " ; IMMEDIATE
: ENDCASE PLEASE " DROP THENS " ; IMMEDIATE
: THENS ?DUP IF PLEASE " THEN THENS " THEN ; IMMEDIATE
[This presumes, as it is in ThisForth and most other systems,
that the data stack is used for the control-flow stack, and 0
can't be the top cell of a dest or org.]
The character ~ (swung dash, but usually called tilde) can be
used as a parameter place holder within <text>. For each `~'
PLEASE takes a character string as an argument, which is
consumed by PLEASE.
[To pick up the next word on the line as a parameter PARSE-WORD
is used.]
: ABORT" [CHAR] " PARSE >PAD PLEASE ' IF ." ~ " ABORT THEN ' ; IMMEDIATE
: PARSE-LINE -1 PARSE ; ( Get the rest of the line. )
: ?? PARSE-WORD >PAD PLEASE " IF ~ THEN " ; IMMEDIATE
( Used: ?? EXIT ?? LEAVE ?? NEGATE ?? CHAR+ and so on. )
: LOOPS PARSE-LINE >PAD PLEASE " 0 ?DO ~ LOOP " ; IMMEDIATE
( Used: 5 LOOPS rest-of-the-line )
: ['] PARSE-WORD >PAD PLEASE " [ ' ~ ] LITERAL " ; IMMEDIATE
: POSTPONE PARSE-WORD >PAD PLEASE " ['] ~ EXECUTE " ; IMMEDIATE
: TH PARSE-WORD >PAD PLEASE " CELLS ~ + " ; IMMEDIATE
: VALUE CREATE , IMMEDIATE DOES> (.) PLEASE " ~ @ " ;
: TO PARSE-WORD >PAD PLEASE " ['] ~ >BODY ! " ; IMMEDIATE
A ~ can occur more than once in <text>, with each occurrence being
replaced by a character string parameter.
( Candy coating. Used: `SET variablename rest-of-the-line'. )
: SET ( "<spaces><name><rest-of-the-line>" -- )
PARSE-WORD >PAD ( variablename .)
GET-LINE >PAD ( variablename . rest-of-the-line .)
2SWAP PLEASE " ~ ~ ! " ( )
; IMMEDIATE
The following lines will be seen by the interpreter/compiler as
identical.
0 COLUMN !
SET COLUMN 0
0 SET COLUMN
(Instead of GET-LINE you might want to use `[CHAR] ; PARSE' to
have SET more than once on a line.)
Anton Ertl
In article <4rtip8$7...@hkusuc.hku.hk>, h929...@hkuxa.hku.hk (Zsoter Andras) writes:
|> Anton Ertl (an...@a0.complang.tuwien.ac.at) wrote:
|> >#ifdef ALREADY_LOADED_FOO
|> >#define ALREADY_LOADED_FOO
|> >...
|> >include file definitions
|> >...
|> >#endif
|>
|> Yes. But in Forth you do not even have that one.
Of course I have. I have [IF] and I have FIND.
: defined ( "name" -- flag )
bl word find IF
drop true
ELSE
false
THEN ;
And then
defined ALREADY_LOADED_FOO [IF]
create ALREADY_LOADED_FOO
...
[THEN]
But then, it's much better to define and use NEEDS.
Anton Ertl
In article <4ru6og$n...@ite127.inf.tu-dresden.de>, gr...@ite.inf.tu-dresden.de (Achim Gratz) writes:
|> >>>>> "Anton" == Anton Ertl <an...@a0.complang.tuwien.ac.at> writes:
|> #ifdef ALREADY_LOADED_FOO
|> #define ALREADY_LOADED_FOO
|> include-file definitions ...
|> #endif
|>
|> Anton> This approach makes the compilation quite a bit slower than
|> Anton> it already is, because the preprocessor might have to scan
|> Anton> the same file for dozens of times, doing something useful
|> Anton> only the first time.
|> [...]
|>
|> This is not really needed and good implementations avoid it.
Can you name one? I only know no-good implementations then.
Achim Gratz
>>>>> "Anton" == Anton Ertl <an...@a0.complang.tuwien.ac.at> writes:
Anton> Can you name one? I only know no-good implementations then.
From the GNU CPP info file [C-h i m cpp g once-only]:
Once-Only Include Files
-----------------------
Very often, one header file includes another. It can easily result
that a certain header file is included more than once. This may lead
to errors, if the header file defines structure types or typedefs, and
is certainly wasteful. Therefore, we often wish to prevent multiple
inclusion of a header file.
The standard way to do this is to enclose the entire real contents
of the file in a conditional, like this:
#ifndef FILE_FOO_SEEN
#define FILE_FOO_SEEN
THE ENTIRE FILE
#endif /* FILE_FOO_SEEN */
The macro `FILE_FOO_SEEN' indicates that the file has been included
once already. In a user header file, the macro name should not begin
with `_'. In a system header file, this name should begin with `__' to
avoid conflicts with user programs. In any kind of header file, the
macro name should contain the name of the file and some additional
text, to avoid conflicts with other header files.
The GNU C preprocessor is programmed to notice when a header file
uses this particular construct and handle it efficiently. If a header
file is contained entirely in a `#ifndef' conditional, then it records
that fact. If a subsequent `#include' specifies the same file, and the
macro in the `#ifndef' is already defined, then the file is entirely
skipped, without even reading it.
There is also an explicit directive to tell the preprocessor that it
need not include a file more than once. This is called `#pragma once',
and was used *in addition to* the `#ifndef' conditional around the
contents of the header file.
[...]
With the advent of C++ and it's proliferation of header files this was
noticed by many peoples, who then went on to request an #import like
Objective-C has. This proposal was turned down on the fact that
there's already an idiom and there are implementation(s) that make
efficient use of it. GNU did implement #import as well as #pragma
once, but these are now obsolete (#import of course is still used by
the Objective-C incarnation of gcc).
It should also be noted that none of the standard and system header
files need to exist physically or have any intelligible contents from
the standard's point of view. The Profi-C compiler on the C64 didn't
have any system header files, but you still could #include <> things.
Even if they are there, the compiler is not required to actually look
at the content. I seem to remember a Vax compiler that surprised
programmers by just doing that (you could change things in those
files, but it was never noticed unless you used some obscure
switches).
Andrew Haley
Anton Ertl (an...@a0.complang.tuwien.ac.at) wrote:
: In article <4ru6og$n...@ite127.inf.tu-dresden.de>, gr...@ite.inf.tu-dresden.de (Achim Gratz) writes:
: |> >>>>> "Anton" == Anton Ertl <an...@a0.complang.tuwien.ac.at> writes:
: |> #ifdef ALREADY_LOADED_FOO
: |> #define ALREADY_LOADED_FOO
: |> include-file definitions ...
: |> #endif
: |>
: |> Anton> This approach makes the compilation quite a bit slower than
: |> Anton> it already is, because the preprocessor might have to scan
: |> Anton> the same file for dozens of times, doing something useful
: |> Anton> only the first time.
: |> [...]
: |>
: |> This is not really needed and good implementations avoid it.
: Can you name one? I only know no-good implementations then.
There's some code in gcc which does this. If a file has already been
included it doesn't include it again during the compilation. gcc does
a few checks to make sure that there isn't some change in the
preprocessor state which means that the user really meant to include
the file twice.
Andrew.
W.Baden
Anton Ertl (an...@a0.complang.tuwien.ac.at) wrote:
> Of course I have. I have [IF] and I have FIND.
>
> : defined ( "name" -- flag )
> bl word find IF
> drop true
> ELSE
> false
> THEN ;
For 17 years I've called this HAVE, with DEFINED for the
alternative with stack effect ( c_addr u -- flag ). This
is how several implementations in the 80s did it as well.
`HAVE foo [IF]' and `S" foo" DEFINED [IF]' read smoother IMO.
> And then
>
> defined ALREADY_LOADED_FOO [IF]
> create ALREADY_LOADED_FOO
> ...
> [THEN]
This should be--
defined ALREADY_LOADED_FOO [IF]
...
create ALREADY_LOADED_FOO
[THEN]
-- so the `cookie' won't be defined unless the load was successful.
> But then, it's much better to define and use NEEDS.
I know that it can be done (I did it myself once upon a time) but
I've forgotten how. Would someone be so kind as to show how
NEEDS can be implemented in Standard Forth? I keep blocking myself.
--
Let us go forth in peace. Wil Baden Costa Mesa, California
W.Baden
( For ThisForth change 0 to 1 in next line. )
0 [IF]
( For installations where the source-files of an application
are kept in one directory, WORDLIST and PLEASE give an
elegant solution to problem of file inclusion.
)
: --> PARSE-WORD >PAD 2DUP 2DUP PLEASE
| S" ~" LOADED SEARCH-WORDLIST 0= ?DUP AND
[IF] S" ~" >ELECTIVE INCLUDED LOADED: ~ [THEN] |
;
( --> may be named NEED or NEEDS.
When interpreting, `--> foo' is _exactly_ the same as--
S" foo" LOADED SEARCH-WORDLIST 0= ?DUP AND
[IF] ELECTIVE foo INCLUDED LOADED: foo [THEN]
where--
)
WORDLIST CONSTANT LOADED
: LOADED: LOADED SET-CURRENT CREATE FORTH-WORDLIST SET-CURRENT ;
CREATE SOURCES 256 CHARS ALLOT
( `ELECTIVE foo' turns a source-file keyword into a fully
qualified path-name for a source-file. The path to source-
files is placed in character-string holder SOURCES, and
may be global for your installation or initialized in the
first load-file of an application.
)
: ELECTIVE ( "name" -- c_addr u )
SOURCES COUNT PARSE-WORD >PAD PLEASE | S" ~~.fo" |
; IMMEDIATE
( This allows programmers to move their own applications
between environments/installations with minimum modification.
)
[ELSE]
( Eliminating PLEASE to move this to Standard Forth raises
an immediate problem for which I don't have a satisfactory
solution.
The problem is the ephemeral nature of interpreted character
strings and constructed character strings.
You cannot rely on a character string to be still valid
after including a source file.
The following will work most of time, but is not robust.
Can anyone show what to do about it?
Standard definitions for string catenation S+ and for 3DROP
and PARSE-WORD are presumed to be within your competency.
)
WORDLIST CONSTANT LOADED
: LOADED: LOADED SET-CURRENT CREATE FORTH-WORDLIST SET-CURRENT ;
: >LOADED S" LOADED: " 2SWAP S+ EVALUATE ; ( c_addr u -- )
CREATE SOURCES 256 CHARS ALLOT
: >ELECTIVE ( c_addr u -- c_addr2 u2 )
SOURCES COUNT 2SWAP S+ S" .fo" S+
;
: NEEDED ( c_addr u -- )
2DUP LOADED SEARCH-WORDLIST IF 3DROP
ELSE 2DUP >ELECTIVE INCLUDED >LOADED THEN
;
: NEED PARSE-WORD NEEDED ; Ê( "name" -- )
[THEN]
Michael Kalus
## Originalempfaenger: /comp/lang/forth
Well, the IF..ELSE..THEN thread has come to rest.
The "HOLY WAR was fun to whatch" (John O Comeau)...
But then I went back to studied THE BOOK (Leo Brodie, 1984,
"Thinking Forth"), and there was this headake again: Unresolved
Marks, Questionmarks?
M.L. Gassanenko wrote:
> "Suddenly I have come to understanding that the Forth IF..ELSE..
>THEN syntax is quite natural, and, probably, THEN is the best word
>to be in that place:
>
>: FOO ( n -- )
> dup 0< 0= \ If n is positive or 0,
> if 200 + \ add 200,
> else -200 + \ else add -200.
> then . ; \ Then, print the result.
>(...)
>So, Forth THEN means 'after that'.
>(...)
>How can native speakers comment this?"
Leo Brodie wrote: "A name should express 'what' is happening, not
'how' this is done." If we use this rule on IF...ELSE...THEN we find
- IF does not realy tell us what is happening there, but does hide
how it is done.
- ELSE is telling us to proceede here if the test failes, and it
does hide how it is done too. So its OK to Leo.
- THEN does not tell us at all what is happening here. But it also
hides how this is done.
M.L.G then wrote:
>The Concise Oxford Dictionary says:
>
>then [@en] adv., adj., & n. --adv.
>_1 at that time; at the time in question (...).
>_2 _a next, afterwards; after that (then he told me to come in).
> _b and also (then, there are the childen to consider).
> _c after all (it is a problem, but then that is what we are here for).
>_3 _a in that case; therefore; it follows that (...).
> _b if what you say is true (...)
> _c (...) if you must have it so (...)
> _d used parenthetically to resume a narrative etc. (...).
>--adj. that or who was such at the time in question (the then Duke).
>--n. that time (until then).
>
>(...)"
*What* does THEN do?
It resolves a forward reference in a structured conditional branch
definition, doesn't it? So to my feeling of the english language I
would use definition _1 "at that time" to interprete THEN.
<test> IF <do_this_and_resolve_forward_reference> THEN
But when I saw this, I felt even stronger it shoud be:
<test> IF <do_this_and> RESOLVE
We could eliminate THEN then. *Is* Forth one of those languages
not realy using a THEN in structured conditional branching?
Yours sincerly Michael Kalus
Grüße aus Bad Malente, Michael
## CrossPoint v3.02 ##