colon-sys and ANS
dat...@my-deja.com
the opinion of more people concerning standards compliance. I have seen
many postings about how to define custom defining words that can be
ended with the standard semicolon ;. My interpretation of the ANS
standard is that colon and colon-noname place the xt on the stack and
on top of it colon-sys, which can be anything and as many cells as the
implementation wants. The difference is that in the case of defining a
named word, colon will create a dictionary entry and store the xt in
that entry consuming the xt, while colon-noname leaves the xt on TOS.
Thinking that way, I tried to define the following defining word:
: anon:
depth >r \ depth of the stack before colon-noname modifies the stack
postpone :noname
depth \ depth of the stack after colon-noname modifies the stack
r> - \ number of items placed on the stack by colon-noname
1- roll \ to bring the xt to TOS
\ store the xt in a data structure, code not shown
;
My question is: is this standard? I think it complies with the
description of colon-noname, but the Quartus Forth implementation
didn't contemplate this possibility, though Neal Bridges agreed with me.
I would appreciate comments on my approach.
Regards,
Douglas
Sent via Deja.com http://www.deja.com/
Before you buy.
jonah thomas
> My interpretation of the ANS
>standard is that colon and colon-noname place the xt on the stack and
>on top of it colon-sys, which can be anything and as many cells as the
>implementation wants. The difference is that in the case of defining a
>named word, colon will create a dictionary entry and store the xt in
>that entry consuming the xt, while colon-noname leaves the xt on TOS.
>Thinking that way, I tried to define the following defining word:
>: anon:
>depth >r \ depth of the stack before colon-noname modifies the stack
>postpone :noname
>depth \ depth of the stack after colon-noname modifies the stack
>r> - \ number of items placed on the stack by colon-noname
>1- roll \ to bring the xt to TOS
> \ store the xt in a data structure, code not shown
>;
>My question is: is this standard?
It is standard with environmental dependencies.
Here is the problem: You can't depend on : or :NONAME to leave the xt on
the stack followed by further items. Some systems will do that and some
won't. All the "coloy-sys" means, is that you can't depend on it *not* to,
which means you can't assume that anything you left on the stack before you
do :NONAME will be available to you again before you do ; . Which is of
course why you rightly pushed your data onto the return stack.
A system my choose to leave all the colon-sys data in some data structure
for ; to drag out. It could even choose to leave the xt in some data
structure, and a smart ; notices whether it was : or :NONAME and stores it
or leaves it on the stack.
I guess you've noticed, we have a standard that lets you say your program is
standard, and it lets vendors say that a lot of systems are standard that
your program won't run on. You're supposed to say what special abilities
you need from a Forth system.
So, you're ROLLing the xt. Your idea will work on systems that save all the
rest of the colon-sys data somewhere else, provided :NONAME leaves the xt
on the stack. So that will extend the number of systems it works on.
Possibly you might extend it some more by using PICK in place of ROLL .
Maybe there are some systems that *need* the xt to still be there for ; and
when you remove it they might have problems. You could run on them too
if you copy the data and DROP it after you do the ; .
Your code won't run everywhere, but it might run on the systems you care
about. If you want a version that will run everywhere you might look for
ways to put off needing the xt until after the ; . It's going to be
available on all systems that have :NONAME then. (Of course, :NONAME
is a Core Extension word and isn't required to be present on all systems.
But you probably don't care about porting your code to a system that lacks
:NONAME . No telling what else it will lack.)
Oh, I just thought of a way to implement :NONAME . It's crude but it should
sort of work.
VARIABLE NONAME?
: :NONAME ( -- colon-sys )
S" : FOO" EVALUATE NONAME? ON ;
: ; ( colon-sys -- xt| )
POSTPONE ; :NONAME? @ IF S" ' FOO" EVALUATE THEN ; IMMEDIATE
: : ( -- colon-sys )
NONAME? OFF : ;
This is likely to give you a "FOO not unique" message every time you use
:NONAME but it ought to usually run. There are probably ways it could fail,
for example if the CURRENT wordlist isn't in the search order at the moment,
' FOO may not find anything or worse may find the wrong thing.
Anton Ertl
dat...@my-deja.com writes:
>: anon:
>depth >r \ depth of the stack before colon-noname modifies the stack
>postpone :noname
>depth \ depth of the stack after colon-noname modifies the stack
>r> - \ number of items placed on the stack by colon-noname
>1- roll \ to bring the xt to TOS
> \ store the xt in a data structure, code not shown
>;
You should leave away the POSTPONE to get the effect you want.
>My question is: is this standard?
Without use, certainly. And the corrected version is also standard
for a use like this:
variable foo
anon: [ foo ! ] ." foo" ;
foo @ execute
Your reasoning is correct.
I wouldn't expect the following to work, though:
anon: [ execute
- 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
Philip Preston
[snip]
>
>: anon:
>depth >r \ depth of the stack before colon-noname modifies the stack
>postpone :noname
>depth \ depth of the stack after colon-noname modifies the stack
>r> - \ number of items placed on the stack by colon-noname
>1- roll \ to bring the xt to TOS
> \ store the xt in a data structure, code not shown
>;
>
>description of colon-noname, but the Quartus Forth implementation
>didn't contemplate this possibility, though Neal Bridges agreed with me.
>I would appreciate comments on my approach.
I assume what you want to do is write definitions like
ANON: ." Hello World" ;
... and end up with the xt in your data structure rather than on the stack.
If so you shouldn't have POSTPONE before :NONAME (because :NONAME has
default compilation semantics and all you want to do is compile it into the
definition of ANON: ).
With this change to the definition I'm not sure whether it's standard or
not. Colon-sys goes on the control-flow stack. The last sentence of section
3.2.3.2 says "Since the control-flow stack may be implemented using the data
stack, items placed on the data stack are unavailable to a program after
items are placed on the control-flow stack and remain unavailable until the
control-flow stack items are removed". If the "Since ... data stack," part
wasn't there it would be unequivocal that your definition of ANON: is
non-standard. But as it stands, who can tell? I guess it's one of those
"original intent of the TC" questions.
But standard or not it won't compile on systems which treat a change of
stack depth between the start and end of a definition as an error, and such
systems are quite common. If you want to write a portable definition (rather
than just explore the limits of the standard) you could change ROLL to
PICK and put up with having an extra copy of the xt left on the stack which
will have to be DROPped at the end of the definition. Or you could start
your definitions with :NONAME and end them with ;ANON ...
: ;ANON ( C: colon-sys -- , S: xt -- )
POSTPONE ;
\ store the xt in a data structure, code not shown
; IMMEDIATE
Regards,
Philip.
m_l...@my-deja.com
even if you assume that the standard allows your approach
(which is not true, I've been discussing this issue with the TC),
you cannot assume that all systems comply to your reading of
the standard (example: WIN32FOR ).
It may be recommended to, instead of hacking the implementation
which has not yet been seen, define a system-dependent word
START: ( -- colon-sys xt )
It will be easier to rewrite this definition
: START: :NONAME SWAP ;
: START: :NONAME >R !CSP R> ;
: START: :NONAME ;
,etc. than to realize what your ROLLs were expected to do.
[end brief answer]
In general, this is one of the most unclear places in the standard.
The standard says that the control flow stack may not exist
physically, but it does not say how then it may exist
(answer: only logically). (unclear issues and my answers:
http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#qna )
dat...@my-deja.com wrote:
>
> I have discussed this issue with Neal Bridges, but I would like to ask
> the opinion of more people concerning standards compliance. I have seen
> many postings about how to define custom defining words that can be
> ended with the standard semicolon ;. My interpretation of the ANS
> standard is that colon and colon-noname place the xt on the stack and
> on top of it colon-sys, which can be anything and as many cells as the
> implementation wants. The difference is that in the case of defining a
> named word, colon will create a dictionary entry and store the xt in
> that entry consuming the xt, while colon-noname leaves the xt on TOS.
> Thinking that way, I tried to define the following defining word:
>
> : anon:
> depth >r \ depth of the stack before colon-noname modifies the stack
> postpone :noname
> depth \ depth of the stack after colon-noname modifies the stack
> r> - \ number of items placed on the stack by colon-noname
> 1- roll \ to bring the xt to TOS
> \ store the xt in a data structure, code not shown
> ;
>
> My question is: is this standard? I think it complies with the
> description of colon-noname, but the Quartus Forth implementation
> didn't contemplate this possibility, though Neal Bridges agreed with me.
> I would appreciate comments on my approach.
> Regards,
> Douglas
This is one of the issues discussed at
http://www.forth.org.ru/~mlg/Apocrypha/Apocrypha.html (table of
contents),
namely, in http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html
At first, whether or not your definition complies to the standard
(we may argue how one should read the standard), your
definition is not portable because it is not compatible with the
FIG-Forth
model (it uses !CSP and ?CSP).
At second, here is the description of the FIG-Forth model in terms of
the ANS Forth standard.
citation[ http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#ex4 ]{
4) The FIG-Forth implementation of the control-flow stack.
The depth and contents of the control-flow stack are defined by the
following rules:
- Outside a colon definition, the control-flow stack is empty.
- Inside a colon definition, the bottom-most element of the control-flow
stack is the value in the variable CSP.
- The value in the variable CSP describes the data stack depth at the
moment before creation of the colon definition.
- All other elements of the control flow stack are the ones placed on
the data stack above the elements which were there before creation of
the colon definition.
This specification corresponds to only three lines of system-dependent
Forth code (the word SP@ ( -- x ) reads the data stack pointer):
VARIABLE CSP
\ initialize control-flow stack and leave colon-sys on it
: !CSP SP@ CSP ! ;
\ consume colon-sys at the control-flow stack top
: ?CSP SP@ CSP @ XOR ABORT" unfinished control structure" ;
The word !CSP is called from the word : (colon), it initiates the
control-flow stack, and the word ?CSP is called from the word ;
(semi-colon), it checks if there are no unconsumed control-flow stack
elements.
}citation
The document also states that the standard permits the control-flow
stack top to be the data stack bottom
http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#ex3 .
IMO, the right (unequivocal) formulation of the section 3.2.3.2
Control-flow stack would be:
http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#propo .
Regards, Michael.
Philip Preston
[snip]
>The document also states that the standard permits the control-flow
>stack top to be the data stack bottom
>http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#ex3 .
This appears to conflict with the specification of :NONAME , which says
"If the control-flow stack is implemented using the data stack, colon-sys
shall be the topmost item on the data stack".
>
>IMO, the right (unequivocal) formulation of the section 3.2.3.2
>Control-flow stack would be:
>http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#propo .
The trouble with this (and a possible interpretation of the existing text)
is that it prohibits too much, namely accessing the data stack, after items
have been placed on the control-flow stack but not yet removed, without
altering its depth (for example if ROLL were changed to PICK in the
definition of ANON: ). Is there an implementation where this would fail? If
not, why should standard programs be even more restricted than is necessary
in this respect?
It's worth remembering that the restriction on stack depth change between
the start and end of a definition is not the necessary consequence of a
particular implementation technique but a deliberately introduced (and IMO
ill judged) "feature". I would prefer to see it disallowed in standard
systems. AFAIK Forth Inc. have never found it necessary to include it in any
of their products and their users do not seem to have suffered as a result.
And for those implementors who feel that some kind of safety net needs to be
provided to assist novice or careless programmers, Roedy Green showed a much
better way of doing it in BBL in the mid eighties. A stack depth change
caused a warning message to be issued but it was not treated as an error.
Additionally a word was provided (IIRC it was called ALLOW or something
similar) which could be used to suppress the warning (and document the
source code) wherever a stack imbalance was deliberate. This provides a
level of support similar to that of the FIG-Forth approach but without
imposing arbitrary restrictions on programs.
Regards,
Philip.
m_l...@my-deja.com
>
> m_l...@my-deja.com wrote in message <38A4366F...@my-deja.com>...
> [snip]
> >The document also states that the standard permits the control-flow
> >stack top to be the data stack bottom
> >http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#ex3 .
>
> This appears to conflict with the specification of :NONAME , which says
> "If the control-flow stack is implemented using the data stack, colon-sys
> shall be the topmost item on the data stack".
Indeed. Well, let colon-sys be at the top and all other control-flow
stack elements go to the data stack bottom.
Now better?
>
> >
> >IMO, the right (unequivocal) formulation of the section 3.2.3.2
> >Control-flow stack would be:
> >http://www.forth.org.ru/~mlg/Apocrypha/CFStack.html#propo .
>
> The trouble with this (and a possible interpretation of the existing text)
> is that it prohibits too much, namely accessing the data stack, after items
> have been placed on the control-flow stack but not yet removed, without
> altering its depth (for example if ROLL were changed to PICK in the
> definition of ANON: ). Is there an implementation where this would fail? If
> not, why should standard programs be even more restricted than is necessary
> in this respect?
This is a flagrant misinterpretation of the text of the Standard and
TC's intent. The Standard is vendor's standard. Users are not
allowed to read the standard as if it allows the things they want
is some particular way, and the implementor had to choose namely
that way. Your reading of the standard will not make implementors
choose your way, because it's already in the past, implemenotrs
have already written their code, isn't it?
The Standard allows you to realize what is portable and what is not
portable. If the Standard is unclear about something, then it is
not portable. Why? Because the implementors never carry out such
scholastic disputes before writing code, they just write code, they are
busy people having to yearn money. Therefore, different implementors
may take different approaches, and one implementor will not care about
the approach of the other implementor. Now, if you write code making
assumptions about the implementors' decisions, will your code be
portable?
No, even if your were reading the standard for a year before making
these assumptions.
>it prohibits too much
The Standard does not prohibit "accessing the data stack, after items
have been placed on the control-flow stack but not yet removed",
it just states that there is no portable way to access it.
---
Well, seriously, when I saw an article in FD about "portable" swapping
of colon-sys and xt returned by :NONAME , I made an RFI for the reason
that the 1st impression from reading the standard is deceptive.
My question was:
is colon-sys allowed to contain information about the data stack depth?
and TC chairs sent an immediate "yes" to me (colon-sys is allowed to
contain *any* information the implementor wants, including information
about the data stack depth, which is a degenerate case, but still *is*
allowed) and asked me to withdraw this RFI.
When I have realized that the above question is not the right
question, I have withdrawn the RFI
and wrote a proposal which should go under the "clarifications"
agenda item. The proposal did not go, that is, it got stuck under
the mentioned agenda item.
Now, if you find this issue important, you are welcome to write your
own RFI.
> It's worth remembering that the restriction on stack depth change between
> the start and end of a definition is not the necessary consequence of a
> particular implementation technique but a deliberately introduced (and IMO
> ill judged) "feature". I would prefer to see it disallowed in standard
> systems.
The intent of TC was to *prohibit* access to the data stack elements
while control-flow stack elements may-or-may-not be found above them.
I can tell you at least one reason for namely such approach: to
allow access to data stack items means to open the way for a
stream of RFIs, with no guarantee that no contradiction would happen.
> AFAIK Forth Inc. have never found it necessary to include it in any
> of their products and their users do not seem to have suffered as a result.
> And for those implementors who feel that some kind of safety net needs to be
> provided to assist novice or careless programmers, Roedy Green showed a much
> better way of doing it in BBL in the mid eighties.
And Practice shows that it was not accepted.
Most people never had problems with :NONAME because they do not
use :NONAME . But if they will begin to change their code to accept
somebody's solution to the problem which they never had, they
definitely will have problems with their compilers and unstandard
extensions to them.
In addition, there always is code that used to work ok some years ago
and was not touched since then. May be, it will be useful in the future,
maybe, it will not. Must this code be re-tested and re-debugged?
I summarize: currently there is no chance that any particular
approach to implementation of the control-flow stack
will be commonly accepted.
> A stack depth change
> caused a warning message to be issued but it was not treated as an error.
> Additionally a word was provided (IIRC it was called ALLOW or something
> similar) which could be used to suppress the warning (and document the
> source code) wherever a stack imbalance was deliberate. This provides a
> level of support similar to that of the FIG-Forth approach but without
> imposing arbitrary restrictions on programs.
>
> Regards,
> Philip.
Regards, Michael
---
To avoid misinterpretation of the Standard,
do not write standard programs, write Standard Systems!
----
:-)
P.S.
[DISCLAIMER: due to cultural differences, you may not interpret
my text right. In Russian, there is such thing as absurdity
[cynism, shockingness, etc.] meaning negation. But it is not
necessarily negation, there are many degrees between assertion
and full negation. My answer is shocking straightforward, but it
is absurd to be so straightforward, therefore, this aspect has
no relation to what I meant. It rather means that such view
would be too straightforward.]
In plain text: make an RFI, it is an important issue and it must be at
least resolved.
BTW, ask TC if the phrase
> "If the control-flow stack is implemented using the data stack, colon-sys
> shall be the topmost item on the data stack".
is *intended* to mean that *whole* colon-sys must be the topmost item on
the data stack.
(that is, that no auxiliary structure is allowed to contain a part of
colon-sys).
Maybe, TC wanted introduce restrictions on implementing
the control-flow satck using the data stack? Maybe, the !CSP/?CSP
approach must not be considered standard?
===
P.P.S.
Let us, the Forth community, use the word
START: ( -- colon-sys xt ) (name is still a question);
if it becomes common practice, we will be able to propose it
for the next standard.
David N. Williams
>
>
> BTW, ask TC if the phrase
> > "If the control-flow stack is implemented using the data stack,
> > colon-sys
> > shall be the topmost item on the data stack".
> is *intended* to mean that *whole* colon-sys must be the topmost
> item on
> the data stack.
> (that is, that no auxiliary structure is allowed to contain a part
> of
> colon-sys).
My interpretation is that by definition colon-sys is *whatever* is
on the data stack, with no implication of a restriction against
auxiliary information held elsewhere.
> Maybe, TC wanted introduce restrictions on implementing
> the control-flow satck using the data stack? Maybe, the !CSP/?CSP
> approach must not be considered standard?
Following the same interpretation, CSP is allowed in the
implementation. No?
--David
_ _________________________________________________________________
(_\(__
_|__) David N. Williams Phone: 1-(734)-764-5236
__|___ University of Michigan Fax: 1-(734)-763-2213
\ |:-) Physics Department Email: David.N....@umich.edu
\| Ann Arbor, MI 48109-1120 Office: 3421 Randall Laboratory
Anton Ertl
"m_l...@my-deja.com" <m_l...@my-deja.com> writes:
>[Brief answer:]
>
>even if you assume that the standard allows your approach
>(which is not true, I've been discussing this issue with the TC),
>you cannot assume that all systems comply to your reading of
>the standard (example: WIN32FOR ).
If a program is standard, all standard systems have to process it
correctly. If a system does not process a standard program, the
system is non-standard (or, for spin, "has an environmental
restriction").
Being on the TC seems to have a brain-washing effect: everyone seems
to start thinking that every Forth system is standard, and if there is
a conflict with standard programs and/or the standard text, the
programs and/or the text have to be declared non-standard.
>In general, this is one of the most unclear places in the standard.
>The standard says that the control flow stack may not exist
>physically, but it does not say how then it may exist
>(answer: only logically).
However, wrt Douglas ?'s code, the only important issue is whether it
exists on the data stack or not; and his code works on a standard
system in both cases (except for the sentence in 3.2.3.2 pointed out
by Philip Preston).
>At first, whether or not your definition complies to the standard
>(we may argue how one should read the standard), your
>definition is not portable because it is not compatible with the
>FIG-Forth
>model (it uses !CSP and ?CSP).
fig-Forth is not a standard system, and I don't think people claim
that it is even if they have been on the TC for a decade.
If Douglas ?'s code is standard, systems using !CSP and ?CSP simply
are not (but that's extremely easy to fix).
m_l...@my-deja.com
> Being on the TC seems to have a brain-washing effect: everyone seems
> to start thinking that every Forth system is standard, and if there is
> a conflict with standard programs and/or the standard text, the
> programs and/or the text have to be declared non-standard.
> brain-washing
Anton, please, re-read the disclaimer in that message.
I am joking and serious at the same time.
> every Forth system is standard
And, at second, if this happens regularly, why don't you
assume that this has been the primary intent?
> >In general, this is one of the most unclear places in the standard.
> >The standard says that the control flow stack may not exist
> >physically, but it does not say how then it may exist
> >(answer: only logically).
>
> However, wrt Douglas ?'s code, the only important issue is whether it
> exists on the data stack or not; and his code works on a standard
> system in both cases (except for the sentence in 3.2.3.2 pointed out
> by Philip Preston).
Seriously: the standard is not well-written.
There is absolutely no guarantee that scholastic disputes
like this one and others will lead us to meaningful
conclusion. ( Anton, remember your : :-( POSTPONE ( ;)
Therefore there is no reason to carefully-read carelessly-written
document. (One more example, another pitfall of the standard:
the terms used in the standard are not well-suited for
describing words that are outside the scope of the standard,
remember restoration of the input stream specification
mentioned in THROW but performed by INCLUDE. There is a
problem with describing relations between THROW and
unstandard words that do not restore the input source.)
If you are a programmer, there is no use to say
that your code is standard (especially in the area
of cross-compilers) because somebody can say:
"ANS Forth is red herring, you cannot even define IF
in ANS Forth, how your cross-compiler source may be
standard?". (One more scholastic question: what will happen
if a vendor selling a standard system comes to a company
where manager has heard such opinion from his
not-worst programmers.)
This is reality. The standard is not perfect.
You may call it 'bad', or 'good enough', or
'reasonably good', or 'reasonably good and reasonably bad'.
Therefore, if we get out of the scholastic space
of various approaches to standardness, we get:
1) real life implementors
2) portability across real life systems
And here, in the real life space, we realize that the
standard is not as much useful as we would like it to be.
If your code is standard or unstandard depending on the reading
of the standard, it is not portable.
And if you read the standard enough carefully, you may invent
programs that are standard but are not portable.
(You did this not once, IIRC).
I can cite George Shepelev (fido7.su.forth):
>MG> ... nel'zya pereopredelyat' IF i t.p.
>Plyun' i zabud'.
(-- "[...cannot redefine IF etc." -- "[ANS 4th's] red herring, [just]
forget [it].")
>
> >At first, whether or not your definition complies to the standard
> >(we may argue how one should read the standard), your
> >definition is not portable because it is not compatible with the
> >FIG-Forth
> >model (it uses !CSP and ?CSP).
>
> fig-Forth is not a standard system, and I don't think people claim
> that it is even if they have been on the TC for a decade.
The FIG-Forth approach lives, e.g. in Win32For which is ANS-claimed.
see :
DEFER : IS
: _: PARMS-INIT HEADER HIDE DOCOL , !CSP ] ; ok
(BTW, do you like the term 'ANS-claimed' ?)
I use the word 'model' to denote not some particular system, but
the set of desing decisions that determine the internal structure
of the system.
> If Douglas ?'s code is standard, systems using !CSP and ?CSP simply
> are not (but that's extremely easy to fix).
>
No. It is extremely easy to fix systems, but it is
too risky to fix code of all cross-compilers built
upon these systems.
At second, as I said above, for somebody they are standard,
for somebody they are not. This depends :-)
Regards, Michael.
Jonah Thomas
>Anton Ertl wrote:
>> every Forth system is standard
>And, at second, if this happens regularly, why don't you
>assume that this has been the primary intent?
I can think of examples in which systems were declared nonstandard.
For example, it is not allowed for ] to nest. When you start
compiling, you don't call a compiling loop from inside an interpreting
loop. ; cannot do R> DROP to quit compiling and start interpreting.
This decision made several systems nonstandard.
While it's legal for the standard-defined compiling words (like IF )
to be defined in a separate compiling wordlist that is searched first
while compiling and not first while interpreting (provided the special
wordlists are hidden from application code that uses GET-ORDER and
SET-ORDER ), the restrictions that the standard puts on this are so
overwhelming that it isn't particularly plausible that anybody would
do it. By making compiling wordlists effectively unusable several
existing Forths were made nonstandard and must remain nonstandard
unless their implementors rip out the interpreter/compilers and
replace them with something new.
I can't think of any other examples right now, but probably with some
effort I could remember more.
dat...@my-deja.com
Just to explain better, I was trying to define a defining word that could
be matched against ; and at the same time could do the cleanup part that
a custom ;ANON would be supposed to do, like popping the xt off the stack
before its code was compiled.
My reasoning around the standard was that
if colon-sys is the topmost item on the data stack and the xt is left
there after ; then this is how the stack would be: ( ... xt colon-sys )
and getting the depth of ... and then the depth of all of it, I could
figure out exactly where the xt was and as such take it off without ;
noticing (in a : definition, ; doesn't see any xt because : creates an
entry in the dictionary and consumes the xt, is it right?). Perhaps it
will be easier and more certainly standard to leave plain :NONAME as the
start of definition and redefine ; to do what I want.
BTW, I didn't understand very well why I should eliminate the POSTPONE
from my ANON: definition. I was trying to achieve the effect of compiling
the :NONAME inside my ANON: so that it executes exactly after getting the
DEPTH and pushing it >R. I think that eliminating the POSTPONE would get
:NONAME executed when I defined the ANON: word.
BTW, I don't quite like global variables as helpers to store intermediate
data of definitions, because they are exposed implementation details of
my ANON: definition and someone can try to use the same name for another
purpose.
Regards,
Douglas ? (Douglas Atique, in fact :-)
m_l...@my-deja.com
>
> "m_l...@my-deja.com" <m_l...@my-deja.com> wrote:
> >Anton Ertl wrote:
>
> >> every Forth system is standard
>
> >And, at second, if this happens regularly, why don't you
> >assume that this has been the primary intent?
>
> I can think of examples in which systems were declared nonstandard.
>
The pathetic universal quantifier, even if implicit, always
leads to such things -- you show me that I exaggerate.
Yes, a bit, but not much.
There is a **balance** between what implementors *must provide*
and what programmers (=users) may *reckon upon*.
With ANS Forth-94, users did not have much, but it looked
meaningful to write standard code. Now, users have even less.
It is not possible to write a cross-compiler in ANS Forth-2000.
The standard always favoured implementors and now the balance
is going to change (see about dual-wordlist compilers below)
so that it will favour them even more.
Is it good or bad?
It is good.
Goodbye, illusions.
Let us write good code rather than standard code.
Let us mention the standard only when it does not get in our way.
(BTW, now I believe that this way of using
ANS Forth is what was intended by the TC).
> For example, it is not allowed for ] to nest. When you start
> compiling, you don't call a compiling loop from inside an interpreting
> loop. ; cannot do R> DROP to quit compiling and start interpreting.
> This decision made several systems nonstandard.
>
Yes. This was the most flagrant example of incompatibility.
And TC did the right thing when chose only one of the two.
> While it's legal for the standard-defined compiling words (like IF )
> to be defined in a separate compiling wordlist that is searched first
> while compiling and not first while interpreting (provided the special
> wordlists are hidden from application code that uses GET-ORDER and
> SET-ORDER ), the restrictions that the standard puts on this are so
> overwhelming that it isn't particularly plausible that anybody would
> do it. By making compiling wordlists effectively unusable several
> existing Forths were made nonstandard and must remain nonstandard
> unless their implementors rip out the interpreter/compilers and
> replace them with something new.
Not exacly.
TC withdraws this one by introducing "syntactic elements"
(reserved words) that cannot be even redefined.
[NB: unlike the previous case, TC is willing the standard to permit
both approaches.]
When I asked _why_ it must not be possible to redefine IF ,
the answer was that because it is not portable.
('not portable'=="not portable across the class of systems
that must be standard", as I understand it.)
They also told me that this has always been the intent of
the TC to allow dual-wordlist implementations.
Two years ago, I was believing that dual-wordlist implementations
must be
either made compatible with single-wordlist ones,
or declared as having environmental restrictions.
It seems, you are still believing in it.
But the reality has changed.
If you write cross-compilers, it is not possible to
say that you write in ANS Forth (in ANS Forth, you
cannot even redefine IF), but it has become much
easier to claim that you implement ANS Forth.
> I can't think of any other examples right now, but probably with some
> effort I could remember more.
Yes, please.
---
Regards, Michael
DO NOT WRITE STANDARD pROGRAMS, write Standard Systems!
Tom Zegub
Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>
>fig-Forth is not a standard system, and I don't think people claim
>that it is even if they have been on the TC for a decade.
>
Since ANS strives to include as many Forth systems as possible, why
would Fig-Forth be an exception? Any Forth system can be made ANS
compliant in theory and with system dependencies it's almost assured in
practice.
--
Tom Zegub tze...@dhc.net
WasteLand http://www.dhc.net/~tzegub
|_|_|_|_
| | | | http://www.dhc.net/~tzegub/fop.htm
m_l...@my-deja.com
> Thanks for all your comments.
> Just to explain better, I was trying to define a defining word that could
> be matched against ; and at the same time could do the cleanup part that
> a custom ;ANON would be supposed to do, like popping the xt off the stack
> before its code was compiled.
"trying to define a defining word that ..."
is not the same as
"trying to define in ANS Forth a defining word that ..."
I think that if you write a system-dependent definition, you will
get more reusable code than in the case of
a) hacking the standard
b) re-defining : (colon) ; (semi-colon) :NONAME ;CODE
Why?
In the 'a)' case, it's evident. Implementors may read the standard not
in the same way that you do.
In the 'b)' case, you will have no problems if you use only standard
code.
But you cannot guarantee that your redefinitions will be compatible
with the extensions -- unstandard words provided by implementors.
For example, I often use the words
START: ( "name" -- colon-sys xt ) -- the same as your ANON:
and
OP: ( "name" -- colon-sys ) -- define a "virtual operation"
for the current virtual message table.
And, again, remember the standard word ;CODE . Many assemblers
perform initialization actions that include memorizing the
current stack depth. (The standard does not mention this issue
because I believe TC did not want accuracy in the area
where compatibility ends.)
So, you cannot portably redefine ;CODE .
NB: this reasoning applies to redefinitions that change the
stack effect of compiling words. Redefinitions with side
effects are not expected to suffer from stack effect
incompatibility.
> My reasoning around the standard was that
> if colon-sys is the topmost item on the data stack and the xt is left
> there after ; then this is how the stack would be: ( ... xt colon-sys )
> and getting the depth of ... and then the depth of all of it, I could
> figure out exactly where the xt was and as such take it off without ;
> noticing (in a : definition, ; doesn't see any xt because : creates an
> entry in the dictionary and consumes the xt, is it right?). Perhaps it
> will be easier and more certainly standard to leave plain :NONAME as the
> start of definition and redefine ; to do what I want.
Consider
OP: virtual-op-name ..... ;
Your code is standard, portable, but not much reusable because it is not
compatible with unstandard extensions.
You cannot even download two libraries each defining such extensions
one on top of another!
If my code defines OP: and your code defines ANON: using this technique
[redefinition of ; (semi-colon) etc. so that a different colon-sys
is used], we cannot use both OP: and ANON:
because the package that defines OP: did not foresee that ; will be
redefined again, and the package that defines ANON: and redefines ;
does not know that OP: must also be redefined.
Don't Do That --- Universal Advice.
> BTW, I didn't understand very well why I should eliminate the POSTPONE
> from my ANON: definition. I was trying to achieve the effect of compiling
> the :NONAME inside my ANON: so that it executes exactly after getting the
> DEPTH and pushing it >R. I think that eliminating the POSTPONE would get
> :NONAME executed when I defined the ANON: word.
You wrote:
> : anon:
> depth >r \ depth of the stack before colon-noname modifies the stack
> postpone :noname
> depth \ depth of the stack after colon-noname modifies the stack
> r> - \ number of items placed on the stack by colon-noname
> 1- roll \ to bring the xt to TOS
> \ store the xt in a data structure, code not shown
> ;
The word :NONAME usually begins execution when the system is
interpreting;
therefore, it may be either IMMEDIATE or non-IMMEDIATE.
The standard requires it to behave like if it is non-IMMEDIATE (namely,
to compile itself). Therefore, your POSTPONE :NONAME means:
"append to the current definition code that compiles the action of
:NONAME"
while you intended
"append to the current definition the action of :NONAME".
The latter (=desired) is performed when the word :NONAME (without
POSTPONE ) is encountered in compilation state.
> BTW, I don't quite like global variables as helpers to store intermediate
> data of definitions, because they are exposed implementation details of
> my ANON: definition and someone can try to use the same name for another
> purpose.
If they will use a variable, they most likely will define it first;
at least, they should.
Your variable will be redefined but not misused.
But the best choice IMO would be adding a non-standard word.
It will be simpler and more readable and maintainable.
There will be no chance that two extension packages interfere,
and that bugs from one package affect the other package.
Regards, Michael
Jonah Thomas
>Jonah Thomas wrote:
>> "m_l...@my-deja.com" <m_l...@my-deja.com> wrote:
>> >Anton Ertl wrote:
>> >> every Forth system is standard
>> >And, at second, if this happens regularly, why don't you
>> >assume that this has been the primary intent?
>> I can think of examples in which systems were declared nonstandard.
>The pathetic universal quantifier, even if implicit, always
>leads to such things -- you show me that I exaggerate.
>Yes, a bit, but not much.
Yes. 8-)
>There is a **balance** between what implementors *must provide*
>and what programmers (=users) may *reckon upon*.
>With ANS Forth-94, users did not have much, but it looked
>meaningful to write standard code. Now, users have even less.
>It is not possible to write a cross-compiler in ANS Forth-2000.
Unfortunate. Ah, are you sure?
It's always been impossible to write completely portable
cross-compilers, since they have hardware dependencies. But
if, say, your cross-compiler output is sent to a file as a
sequence of bytes, it should be possible to get equivalent
output over a broad range of systems.
>> For example, it is not allowed for ] to nest. When you start
>> compiling, you don't call a compiling loop from inside an interpreting
>> loop. ; cannot do R> DROP to quit compiling and start interpreting.
>> This decision made several systems nonstandard.
>Yes. This was the most flagrant example of incompatibility.
>And TC did the right thing when chose only one of the two.
Yes. For one thing it allows POSTPONE ;
Now, suppose that they had allowed this. Code that requires
POSTPONE ; or that otherwise depends on the return stack depth
not changing with [ or ] and STATE not changing with return stack
depth changes, would have an environmental dependency. Application
programmers would have one more thing to document, and several more
Forth systems could be labeled standard. It wouldn't really make
much difference.
>> While it's legal for the standard-defined compiling words (like IF )
>> to be defined in a separate compiling wordlist that is searched first
>> while compiling and not first while interpreting (provided the special
>> wordlists are hidden from application code that uses GET-ORDER and
>> SET-ORDER ), the restrictions that the standard puts on this are so
>> overwhelming that it isn't particularly plausible that anybody would
>> do it. By making compiling wordlists effectively unusable several
>> existing Forths were made nonstandard and must remain nonstandard
>> unless their implementors rip out the interpreter/compilers and
>> replace them with something new.
>Not exacly.
>TC withdraws this one by introducing "syntactic elements"
>(reserved words) that cannot be even redefined.
Can't be redefined? Ouch. So that means, if you want to redefine IF
you have to write your own interpreter? I'm losing track. If you can
POSTPONE IF then you can get its compilation behavior in another word.
What's to keep you from naming the new word IF ? Do we have a set of
reserved keywords now?
>[NB: unlike the previous case, TC is willing the standard to permit
>both approaches.]
>When I asked _why_ it must not be possible to redefine IF ,
>the answer was that because it is not portable.
>('not portable'=="not portable across the class of systems
>that must be standard", as I understand it.)
>They also told me that this has always been the intent of
>the TC to allow dual-wordlist implementations.
It's still such a bother to handle IMMEDIATE words properly in
a dual-wordlist system, that I wouldn't bother. Although now
that I think of it, it *could* be done simply. You just need
a (nonportable) way to remove a word from a wordlist. When you
define a new word in one wordlist you delete the old version from
the other wordlist. I don't know why I didn't think of that years
ago.
>Two years ago, I was believing that dual-wordlist implementations
>must be either made compatible with single-wordlist ones,
>or declared as having environmental restrictions.
>It seems, you are still believing in it.
>But the reality has changed.
What programming practices have been lost? Anton spent years
explaining that we had an undocumented conflict, that when IF
can be defined as a state-smart word you can't be sure what
its xt will do. So now they say you can't be sure what its
xt will do. If you have code that finds an xt for IF and uses
it, your code is still as portable as it ever was -- only you
have to document what you're depending on from the system. Which
you should have documented before too, since different standard
systems did it different ways then.
>If you write cross-compilers, it is not possible to
>say that you write in ANS Forth (in ANS Forth, you
>cannot even redefine IF), but it has become much
>easier to claim that you implement ANS Forth.
I've lost track what the problem is. Is it that if you write
your own interpreter, you can't dependably use FIND to get an
xt for IF ? I don't see why you can't document that you need
FIND to do what you want, and be portable only to the systems
that do it. But if you want to be more portable than that,
couldn't you do it yourself? Instead of writing a compiler
that does
get word
get xt and flag
if immediate, execute
else compile
if no xt, interpret as number, compile literal
if not a number, do error routine
couldn't you do
get word
if word is on reserved list, POSTPONE word
get xt and flag
etc....
It's an extra step but it lets you run your code on weird standard
systems, assuming you really care about those systems.
>> I can't think of any other examples right now, but probably with some
>> effort I could remember more.
>Yes, please.
I haven't thought of any more yet. Maybe tomorrow.
Bruce McFarling
>My reasoning around the standard was that
>if colon-sys is the topmost item on the data stack and the xt is left
>there after ; then this is how the stack would be: ( ... xt colon-sys )
>and getting the depth of ... and then the depth of all of it, I could
>figure out exactly where the xt was and as such take it off without ;
>noticing
>(in a : definition, ; doesn't see any xt because : creates an
>entry in the dictionary and consumes the xt, is it right?).
Why do you assume that an xt was created in the first place. Maybe it
was, maybe it wasn't.
The thing is that you are trying to program the ANS model for
compilation, when there isn't any ANS model for compilation -- simply
a collection of characteristics that the various definition words must
comply with.
>Perhaps it will be easier and more certainly standard to leave plain :NONAME
> as the start of definition and redefine ; to do what I want.
>BTW, I didn't understand very well why I should eliminate the POSTPONE
>from my ANON: definition. I was trying to achieve the effect of compiling
>the :NONAME inside my ANON: so that it executes exactly after getting the
>DEPTH and pushing it >R. I think that eliminating the POSTPONE would get
>:NONAME executed when I defined the ANON: word.
Why would it? Why would NONAME: be immediate when you aren't allowed
to assume that you can nest definitions? : and NONAME: are normal
words: they execute when interpreted and compile when compiled..
>BTW, I don't quite like global variables as helpers to store intermediate
>data of definitions, because they are exposed implementation details of
>my ANON: definition and someone can try to use the same name for another
>purpose.
The name space conflict only comes up if the other name is defined
prior to yours, and then is attempted to be used afterwards. If you
want to manage the name space conflict, put the variables in their own
wordlist.
(
----------
Virtually,
Bruce McFarling, Newcastle,
ec...@cc.newcastle.edu.au
)
Elizabeth D. Rather
>
> On 12 Feb 2000 13:23:46 GMT,
> Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>
> >
> >fig-Forth is not a standard system, and I don't think people claim
> >that it is even if they have been on the TC for a decade.
> >
> Since ANS strives to include as many Forth systems as possible, why
> would Fig-Forth be an exception? Any Forth system can be made ANS
> compliant in theory and with system dependencies it's almost assured in
> practice.
Because Fig-Forth itself is a particular model or de-facto standard. FORTH-79
and FORTH-83 both present different models; Fig-Forth (which preceded both) is
not compliant with either, just as it cannot be compliant with ANS Forth and
still be a true Fig-Forth.
You could certainly start with a Fig-Forth and make an ANS-compliant system, but
it would no longer be Fig-Forth, it would just retain whatever implementation
features it chose to retain.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
m_l...@my-deja.com
the FIG-Forth approach to checking correctness
(completeness) of control structures within a colon
definition is compatible with the ANS standard.
That is, an ANS Forth system can use FIG-Forth's
!CSP and ?CSP in : (colon) and ; (semi-colon)
to detect unfinished control structures.
I believe that the intent of the TC was to
1) classify !CSP and ?CSP as implementation details;
2) state that ANS Forth programs must not depend
on whether !CSP and ?CSP are used;
3) permit !CSP and ?CSP in ANS systems so that
the people did not have to rewrite their extensions
of *their* systems;
4) not to prohibit the use of !CSP and ?CSP but to
require to document such use.
I believe that TC mistakingly assumed that if they say
that it is possible to write programs as before
releasing the standard, people will do it.
Instead, people take the standard as a logical formula,
as a scripture, as a definition of the language,
while it is a definition of the inteface between
a system-that-supports-one-unknown-language and
a program written in some-other-unknown-language.
But the people carry out endless inferences,
scholastic disputes, write programs as if the
standard specifies a language, and probably will
do it however TC tries to prevent it.
Personally I would like to make the standard more
suited for such use; nevertheless, I realize that
this may require more time than TC can afford.
"Elizabeth D. Rather" wrote:
>
> Tom Zegub wrote:
> >
> > On 12 Feb 2000 13:23:46 GMT,
> > Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
> >
> > >
> > >fig-Forth is not a standard system, and I don't think people claim
> > >that it is even if they have been on the TC for a decade.
> > >
> > Since ANS strives to include as many Forth systems as possible, why
> > would Fig-Forth be an exception? Any Forth system can be made ANS
> > compliant in theory and with system dependencies it's almost assured in
> > practice.
>
> Because Fig-Forth itself is a particular model or de-facto standard. FORTH-79
> and FORTH-83 both present different models; Fig-Forth (which preceded both) is
> not compliant with either, just as it cannot be compliant with ANS Forth and
> still be a true Fig-Forth.
>
> You could certainly start with a Fig-Forth and make an ANS-compliant system, but
> it would no longer be Fig-Forth, it would just retain whatever implementation
> features it chose to retain.
>
Yes, such system is what I meant.
This is why I wrote "FIG-Forth model" and not "FIG-Forth".
Probably, I had to write "[trick with COLON-SYS-SIZE ROLL] is not
compatible with the FIG-Forth style of implementation".
> Cheers,
> Elizabeth
Regards, Michael
Philip Preston
[snip]
>This is a flagrant misinterpretation of the text of the Standard and ...
I was commenting on *your* interpretation, not presenting one of my own.
By "it prohibits too much" I meant "it makes non-standard more than is
necessary for portability" (sorry if it was not clear).
Regards,
Philip.
m_l...@my-deja.com
>
> m_l...@my-deja.com wrote in message <38A513EC...@my-deja.com>...
> [snip]
> >This is a flagrant misinterpretation of the text of the Standard and ...
In each joke there is a bit of joke.
Well, I see that the disclaimer in that message did not help at all.
If I wrote
"The standard already contains an answer to your question, but you
must make inferences in the right direction :-)"
there probably would be no problem.
And the difference between these two is that the first one
also shows that phrases like "please, interpret the
standard in *the right* way" do not really help much.
I did not want to offend anybody; I apoligize if
somebody took this as an attack against him personally.
And let us close this issue; if something still shocks ,etc.
anybody, please don't mind, it was a sort of humor.
> I was commenting on *your* interpretation, not presenting one of my own.
> By "it prohibits too much" I meant "it makes non-standard more than is
> necessary for portability" (sorry if it was not clear).
I believe that TC was willing to allow both !CSP/?CSP, colon-sys
as a value left on the data stack, and no checking.
I agree that access to items left on the stack could be
allowed by the standard. But what then?
There would be two approaches to accessing xt generated by :NONAME .
The first one is via using bad but standard (it would be standard) code,
the second one is via using good but system-dependent code.
"Good" and "standard" would become antonyms for this case.
In addition, the problem of accessing xt generated by :NONAME is
artificial: :NONAME was invented by the TC, and the problem
exists only due to its specification for the case of
unknown standard system, on each particular system
it is not a problem.
[begin("what 'artificial problem' means")]
What "exists only due to its specification" means.
There are many possible ways to define an unnamed
procedure. For example, with
:UNNAMED ( C: -- colon-sys ) start an unnamed colon definition
IT ( -- xt ) return the xt of last definition
instead of
:NONAME blah blah blah ;
IS foo
we would write
:UNNAMED blah blah blah ;
IT IS foo
The problem of passing data into a colon definition
in the general case (not only the xt of unnamed procedure)
may be resolved by using an auxiliary data structure
(a variable, an array, a stack).
Therefore, it does not benefit from allowing access
to stack items that were there before placing colon-sys.
[end("what 'artificial problem' means")]
SUMMARY: The standard does not permit PICK access to
stack items underneath the control-flow stack items
because this is ugly. And unstandard is better than ugly.
-----------------
I think, the most significant pitfall of the ANS Forth
standard is that it looks like a language definition.
It makes people focus on thinking what is standard
instead of thinking about their problems.
(And if you focus on your problem, everything gets
just unstandard.) The standard distracts programmer's
attention from his problem and leads to creation of
code monsters.
Maybe, this is because there is no such things as
"more standard" and "less standard" while there
certainly are such things as
"more portable" and "less portable".
Any idea how this pitfall may be compensated?
Regards, Michael.
Anton Ertl
"m_l...@my-deja.com" <m_l...@my-deja.com> writes:
>Anton Ertl wrote:
>> Being on the TC seems to have a brain-washing effect: everyone seems
>> to start thinking that every Forth system is standard, and if there is
>> a conflict with standard programs and/or the standard text, the
>> programs and/or the text have to be declared non-standard.
>> every Forth system is standard
>And, at second, if this happens regularly, why don't you
>assume that this has been the primary intent?
Because the standard is not written that way; if they just wanted to
standardize every possible implementation without regard for programs,
they could have done it in two sentences instead of 200+ pages: "There
are no standard programs; everything is a standard system".
Anyway, what strikes me as strange is that people who otherwise seem
to care for the balance between programs and systems, and/or are quite
literal-minded, don't argue with standard text, but with systems that
are either clearly non-standard (like FIG-Forth), or entirely
hypothical, when discussing whether a program is standard or not. If
that is the criterion for the standardness of the program or system,
then we get the result above.
>Seriously: the standard is not well-written.
I disagree.
>There is absolutely no guarantee that scholastic disputes
>like this one and others will lead us to meaningful
>conclusion. ( Anton, remember your : :-( POSTPONE ( ;)
I do. What point are you trying to make?
>Therefore there is no reason to carefully-read carelessly-written
>document.
The document reads carefully-written. My impression is that the
claims of badness of the text coming out of the TC have more to do
with the changing constituency in the TC.
> (One more example, another pitfall of the standard:
>the terms used in the standard are not well-suited for
>describing words that are outside the scope of the standard,
>remember restoration of the input stream specification
>mentioned in THROW but performed by INCLUDE. There is a
>problem with describing relations between THROW and
>unstandard words that do not restore the input source.)
Putting the input source restoration into THROW is probably a bug in
the standard text; so, yes, there are some weak spots. But does the
TC try to change this? The only thing I have read from them is "QUERY
is going away, so there is no problem".
What they do try to change is an extremely clear (almost divinely
inspired) and well-analysed part of the standard by replacing it with
a mediocre, more complicated description with unknown bugs (Mitch
Bradleys Q5-7-8-9 proposal).
>Therefore, if we get out of the scholastic space
>of various approaches to standardness, we get:
>1) real life implementors
>2) portability across real life systems
I don't need a standard document, TC and all for that.
And if somebody asks explicitly about standardness of the program and
mentions that there is one supposedly-standard system where the
program does not work as expected, he is probably interested in the
scholastic answer, because he knows the real-world answer already.
And as system implementor, who sees more in the standard than just a
marketing label, I am also often more interested in a scholastic
answer than in an answer that says: if a program does not run on a
system, the program is non-standard; because as a system implementor
that gives me no useful information.
>(BTW, do you like the term 'ANS-claimed' ?)
It sounds clumsy but it gets the meaning across.
>> If Douglas ?'s code is standard, systems using !CSP and ?CSP simply
>> are not (but that's extremely easy to fix).
>>
>No. It is extremely easy to fix systems, but it is
>too risky to fix code of all cross-compilers built
>upon these systems.
How are they affected by removing ?CSP from ";"?
Anton Ertl
dat...@my-deja.com writes:
>BTW, I didn't understand very well why I should eliminate the POSTPONE
>from my ANON: definition. I was trying to achieve the effect of compiling
>the :NONAME inside my ANON:
When the text interpreter interprets :NONAME in compile STATE, it
compiles :NONAME into the current definition (in this case, ANON:).
With POSTPONE, ANON: would try to compile (not perform) :NONAME when
ANON: is executed.
Anton Ertl
"Tom Zegub" <tze...@dhc.net> writes:
>On 12 Feb 2000 13:23:46 GMT,
>Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>
>>
>>fig-Forth is not a standard system, and I don't think people claim
>>that it is even if they have been on the TC for a decade.
>>
> Since ANS strives to include as many Forth systems as possible, why
>would Fig-Forth be an exception?
Just of the top of my head:
Comparisons return 0 and 1 instead of 0 and all-bits-set (and
many other differences between Forth-83 and what came before).
You cannot do things like
: foo
begin ... while ... until ... else ... then ;
FIND does something like ' does now. ' does something like ' >BODY
and is STATE-smart.
> Any Forth system can be made ANS
>compliant in theory and with system dependencies it's almost assured in
>practice.
Certainly. The question here is whether making it standard involves
removing ?CSP or not. Citing fig-Forth does not support the second
viewpoint, because it is pretty far from the standard anyway.
Tom Zegub
Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>In article <397ADF11C3370C7F.A6A923BF...@lp.airnews.net>,
> "Tom Zegub" <tze...@dhc.net> writes:
>>On 12 Feb 2000 13:23:46 GMT,
>>Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>>
>>>
>>>fig-Forth is not a standard system, and I don't think people claim
>>>that it is even if they have been on the TC for a decade.
>>>
>> Since ANS strives to include as many Forth systems as possible, why
>>would Fig-Forth be an exception?
>
>Just of the top of my head:
>
>Comparisons return 0 and 1 instead of 0 and all-bits-set (and
>many other differences between Forth-83 and what came before).
>
>You cannot do things like
>
>: foo
> begin ... while ... until ... else ... then ;
>
>FIND does something like ' does now. ' does something like ' >BODY
>and is STATE-smart.
>
>> Any Forth system can be made ANS
>>compliant in theory and with system dependencies it's almost assured in
>>practice.
>
>Certainly. The question here is whether making it standard involves
>removing ?CSP or not. Citing fig-Forth does not support the second
>viewpoint, because it is pretty far from the standard anyway.
>
FIG-Forth just as any F83 or FPC can be made ANS compliant by loading
ANS extensions. In FIG-Forth such extensions would change TRUE from 1
to -1, redefine tic, add >BODY and etc. . When all is done, you have
an ANS system that has CSP. ANS does not forbid CSP because it is a
portability standard not a model (language) standard and doesn't
specify the underlying structure nor should it as that's not its
purpose in life. But because ANS is referred to just as 'The Forth
Standard' without qualifier instead of 'A Forth Portability Standard'
(or better 'A Forth Cross-Platform Development Standard') the
misreference causes a common misconception of just where ANS applies,
resulting in people expecting more from it or trying to do more with
it than it was intended for.
Maybe at this point instead of trying to expand the role of the ANS
standard (leave well enough alone although contrary to the nature of
engineers), effort should be placed on making a standard set of models
which would address the needs of people wanting to build
cross-compilers. Are there any other real needs?
Elizabeth D Rather
news:C3BA28FF9D973F4D.C0ED5AC4...@lp.airnews.net...
> FIG-Forth just as any F83 or FPC can be made ANS compliant by loading
> ANS extensions. In FIG-Forth such extensions would change TRUE from 1
> to -1, redefine tic, add >BODY and etc. . When all is done, you have
> an ANS system that has CSP. ANS does not forbid CSP because it is a
> portability standard not a model (language) standard and doesn't
> specify the underlying structure nor should it as that's not its
> purpose in life. But because ANS is referred to just as 'The Forth
> Standard' without qualifier instead of 'A Forth Portability Standard'
> (or better 'A Forth Cross-Platform Development Standard') the
> misreference causes a common misconception of just where ANS applies,
> resulting in people expecting more from it or trying to do more with
> it than it was intended for.
All the ANSI Standards I know of are "portability standards" (C, Fortran,
etc.). None specify how to write a compiler, only its required behavior
(and, conversely, entitlements of programmers writing applications in the
language being standardized). Since some of the early Forth standards did
incorporate model specifications (e.g., 16-bit cells, indirect threading)
it's understandable that some in the Forth community might expect a model
standard, but such would be way outside the mainstream of standards
development. In my opinion, it would also limit Forth's field of
applicability unacceptably.
> Maybe at this point instead of trying to expand the role of the ANS
> standard (leave well enough alone although contrary to the nature of
> engineers), effort should be placed on making a standard set of models
> which would address the needs of people wanting to build
> cross-compilers. Are there any other real needs?
At least the engineers on the TC are all too happy to leave well-enough
alone, as nobody pays us to do this and for many of us it's quite expensive
(in terms of lost income) as well as tedious and thankless work. It's all
we can do to get members to work on the several proposals we currently have
pending.
By all means write a "model standard" if you want to (your effort, not
mine). Given the diversity of views on Forth implementations expressed in
this forum, how many systems do you think might conform to it?
Cheers,
Elizabeth
Tom Zegub
Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>In article <C3BA28FF9D973F4D.C0ED5AC4...@lp.airnews.net>,
> "Tom Zegub" <tze...@dhc.net> writes:
>>FIG-Forth just as any F83 or FPC can be made ANS compliant by loading
>>ANS extensions. In FIG-Forth such extensions would change TRUE from 1
>>to -1, redefine tic, add >BODY and etc. . When all is done, you have
>>an ANS system that has CSP.
>
>It certainly has CSP. But does it call ?CSP in ";"? If it does, is
>it a standard system?
>
>For comparison, the extensions certainly must do something about the
>calls to ?PAIRS in THEN etc. to allow full-blown ANS Forth control
>structures. They may have to do similar things about ?CSP in ";".
>
The aim of a cross-system development standard is achieved by playing
to the lowest common denominator of the range of member systems. It is
not unexpected to find some standard features to be less than the
'full-blown' features of any one individual system. As to just what is
a _full-blown ANS_ Forth control structure, I know of no such
definition in the standard.
>F-PC appears to be a harder case than fig-Forth, as its "]" contains
>an interpreter loop, and you have to replace the whole text
>interpreter. That's the one thing that Ulrich Hoffmann's ANS library
>for F-PC doesn't do.
>
>> ANS does not forbid CSP because it is a
>>portability standard not a model (language) standard and doesn't
>>specify the underlying structure nor should it as that's not its
>>purpose in life.
>
>Just because ANS Forth does not prescribe an implementation model does
>not make all implementation models standard.
>
>I just thought about a simple way to avoid the ?CSP errors in ";",
>without patching ";":
>
>: ; !CSP [COMPILE] ; ; immediate ( untested )
>
>So yes, you can even use ?CSP in ";", but maybe not in the originally
>intended way.
>
Fundamental to ANS is the concept that at the system level anything
is allowed, no holds barred, as long as it presents to the program the
specified facade. So if the underlying structure, which is of no
business to the the programs, chooses to use CSP or call FEDX
to deliver colon-sys from ':' to ';' then so be it. To ANS the system
layer is a black box. ANS specifies only the interface between the
system and program. Any discussion of what may or may not be
internal to the system is an encroachment into territory not subject
to ANS interdictions.
jonah thomas
> The aim of a cross-system development standard is achieved by playing
>to the lowest common denominator of the range of member systems. It is
>not unexpected to find some standard features to be less than the
>'full-blown' features of any one individual system. As to just what is
>a _full-blown ANS_ Forth control structure, I know of no such
>definition in the standard.
ANS Forth includes control structures that weren't allowed in FIG Forth,
notably BEGIN WHILE WHILE REPEAT ELSE THEN and
BEGIN WHILE UNTIL THEN .
In this particular case they didn't play to the lowest common denominator,
they thought the functionality was useful enough to require it even though
many standard systems didn't provide it -- yet.
Anton Ertl
jeth...@ix.netcom.com (jonah thomas) writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>In the posting that started this thread Douglas Atique showed us a way
>>to get something out from under a colon-sys with DEPTH and ROLL.
>>Actually I think this way has been discussed before by others for
>>getting a value that's on the stack before ":" usable in the colon
>>definition (but in that case there are also other ways). His way
>>would work whatever the size of colon-sys is, even if it changes or is
>>(partially or fully) elsewhere.
>
>This assumes that : does not change the data-stack pointer to a new location
>to create a control-flow stack that all the usual stack manipulation words
>work with.
Inventing hypothetical systems again? The standard specifies:
---
6.2.0455 :NONAME ( C: -- colon-sys ) ( S: -- xt )
...
If the control-flow stack is implemented using the data stack,
colon-sys shall be the topmost item on the data stack.
---
No mention of changing the data stack pointer to a new location.
However the system does it, a standard program should not be able to
tell the difference between the system you propose and what the
standard describes.
Douglas Atique's program can tell the difference; which brings us back
to the question of whether the program is standard. This question
cannot be answered by discussing hypothetical systems.
The standard mainly talks about what standard programs are and what
they do. It does not say much directly about systems. So we cannot
answer questions about the standardness of a program by discussing
systems, and we usually have to answer questions concerning the
standardness of systems by discussing programs.
>>Douglas Atique found a way around the boulder.
>
>That way will work on most systems. I believe it isn't guaranteed to work
>on all systems. However, if you are willing to take a path around the
>boulder instead of digging a tunnel under the boulder, you can get an
>equivalent result. Move the data you want to the return stack or to some
>other data structure before you do : and then you can get at it whenever you
>want.
Does not work for the xt produced by :NONAME, the case that started
this thread.
Anton Ertl
"Elizabeth D. Rather" <era...@forth.com> writes:
>Anton Ertl wrote:
>> The only thing in the standard text that might make Douglas Atique's
>> technique non-standard is the last sentence in 3.2.3.2, but that
>> sounds informative rather than normative.
>
>Everything in the sections 1-17 is intended to be normative. We tried
>very hard to confine all informative information in the Annexes A....
The normative sections contain a lot of informative material, e.g.,
|3.2.3.2
|...
|See: A.3.2.3.2 Control-flow stack
No normative content here. Or look at all the "Note:"s in 13.6.1.0086
(too long to reproduce here). (But some "Note:"s are normative, e.g.,
in 13.6.1.2295).
Now, if someone intends to write a normative sentence for disallowing
access to data stack items below colon-sys, he usually uses a sentence
like:
#Items placed on the data stack are unavailable to a program after
#items are placed on the control-flow stack and remain unavailable
#until the control-flow stack items are removed.
OTOH, if someone does not consider the interaction of DEPTH and
PICK/ROLL, and tries to make an informative sentence, the outcome
might be this:
|Since the control-flow stack may be implemented using the data stack,
|items placed on the data stack are unavailable to a program after
|items are placed on the control-flow stack and remain unavailable
|until the control-flow stack items are removed.
The latter sentence is present in 3.2.3.2. That's why I write that it
sounds informative. And if the interaction did not exist, this
sentence really would be just informative; but since the interaction
does exist, it can be
a) intended informative but wrong.
b) normative (although curiously worded).
c) because of a), defaulting to b).
jonah thomas
> jeth...@ix.netcom.com (jonah thomas) writes:
>>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>>In the posting that started this thread Douglas Atique showed us a way
>>>to get something out from under a colon-sys with DEPTH and ROLL.
>>This assumes that : does not change the data-stack pointer to a new location
>>to create a control-flow stack that all the usual stack manipulation words
>>work with.
>Inventing hypothetical systems again?
Yes. Here's why -- if we can't imagine a system that the construction fails
on, then it will probably be quite portable regardless what the committee
decides is standard. If it takes a rather implausible system to make the
code fail, then the code will probably be very portable. So imagining a
system where the failure occurs at least shows that the question isn't
completely bogus -- although it can still be mostly bogus.
>The standard specifies:
>---
>6.2.0455 :NONAME ( C: -- colon-sys ) ( S: -- xt )
>....
>If the control-flow stack is implemented using the data stack,
>colon-sys shall be the topmost item on the data stack.
>---
>No mention of changing the data stack pointer to a new location.
>However the system does it, a standard program should not be able to
>tell the difference between the system you propose and what the
>standard describes.
>Douglas Atique's program can tell the difference; which brings us back
>to the question of whether the program is standard. This question
>cannot be answered by discussing hypothetical systems.
If any hypothetical system that made the code fail was completely
ridiculous, then I wouldn't worry about whether the program is standard.
>>>Douglas Atique found a way around the boulder.
>>That way will work on most systems. I believe it isn't guaranteed to work
>>on all systems. However, if you are willing to take a path around the
>>boulder instead of digging a tunnel under the boulder, you can get an
>>equivalent result. Move the data you want to the return stack or to some
>>other data structure before you do : and then you can get at it whenever you
>>want.
>Does not work for the xt produced by :NONAME, the case that started
>this thread.
Notice the standard:
>6.2.0455 :NONAME ( C: -- colon-sys ) ( S: -- xt )
There isn't any guarantee that the xt will be sitting under the colon-sys.
It will just work on the systems it happens to work on.
Anton Ertl
"Tom Zegub" <tze...@dhc.net> writes:
> As to just what is
>a _full-blown ANS_ Forth control structure, I know of no such
>definition in the standard.
What I mean by this are control structures like
: foo
begin ... while ... until ... else ... then ;
See A.3.2.3.2 for more examples and a deeper discussion.
>Fundamental to ANS is the concept that at the system level anything
>is allowed, no holds barred, as long as it presents to the program the
>specified facade. So if the underlying structure, which is of no
>business to the the programs, chooses to use CSP or call FEDX
>to deliver colon-sys from ':' to ';' then so be it. To ANS the system
>layer is a black box. ANS specifies only the interface between the
>system and program. Any discussion of what may or may not be
>internal to the system is an encroachment into territory not subject
>to ANS interdictions.
A very good point. Unfortunately some people start discussing real or
imaginary systems when discussing whether a program is standard. They
claim without proof that the system is standard, and the program
therefore cannot be standard. In the present case Michael Gassanenko
did this with systems employing the !CSP...?CSP approach (and he
increase confusion by calling this "fig-Forth model", which has many
other implications).
m_l...@my-deja.com
>
> In article <E19A68DD04DD20CD.69601B49...@lp.airnews.net>,
> "Tom Zegub" <tze...@dhc.net> writes:
>
> >Fundamental to ANS is the concept that at the system level anything
> >is allowed, no holds barred, as long as it presents to the program the
> >specified facade. So if the underlying structure, which is of no
> >business to the the programs, chooses to use CSP or call FEDX
> >to deliver colon-sys from ':' to ';' then so be it. To ANS the system
> >layer is a black box. ANS specifies only the interface between the
> >system and program. Any discussion of what may or may not be
> >internal to the system is an encroachment into territory not subject
> >to ANS interdictions.
>
> A very good point. Unfortunately some people start discussing real or
> imaginary systems when discussing whether a program is standard. They
> claim without proof that the system is standard, and the program
> therefore cannot be standard.
Indeed, does the standard state anywhere that:
1) if a program is standard, it will run on any standard system
2) if a system is standard, it will run any standard program
3) it is not possible that a standard system cannot run a standard
program?
{ :-) }*0.5
The reason for inventing imaginary systems is trying to understand
the intent of the text. The text is not perfect; it is unclear
whether some sentences are normative, or informative, or in some
other modality.
> In the present case Michael Gassanenko
> did this with systems employing the !CSP...?CSP approach
With the text of the standard, it is possible to state both that
?CSP (I mean the approach) is standard and unstandard, according
to your taste.
Any reader upon the 1st reading understands that ?CSP is
disallowed, but an interpretation of the text of the standard
exists according to which: the compilation stack is what is
above (the pointer stored in) CSP, and if you ROLL an element
from under CSP, you just get the control-flow-stack-underflow
error. (Well, this does not mean that either the system or
the program is unstandard. ;-)
The truth lies besides the text of the standard:
1) a program incompatible with ?CSP is not portable
because ?CPS *is* used in real systems
2) the *intent* of TC was to declare non-portable the
techniques that would fail on ?CPS systems.
PS Anton, it took a while for me to understand that your probably
believe
that smile ":-)" is always strictly postfix.
Tom Zegub
jonah thomas <jeth...@ix.netcom.com > wrote:
>
>ANS Forth includes control structures that weren't allowed in FIG Forth,
>notably BEGIN WHILE WHILE REPEAT ELSE THEN and
>BEGIN WHILE UNTIL THEN .
>
>In this particular case they didn't play to the lowest common denominator,
>they thought the functionality was useful enough to require it even though
>many standard systems didn't provide it -- yet.
>
Extending the basic control structures may have been nice but far
from being necessary. For a cross-system standard to be widely
applicable necessity not niceness is the criteria. Other features many
times more useful, ie. using the return stack for flow control, have
already been excluded. Not having extended control structures would
have paled in comparison.
At this point it's just spilled milk and no doubt most people would
rather have the extensions even if added development is required.
Anton in a following post gives reference to where ANS specifies the
usage requirements. It doesn't prevent FIG-Forth from complying but
adds to the work to make it do so.
Tom Zegub
Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>In article <E19A68DD04DD20CD.69601B49...@lp.airnews.net>,
> "Tom Zegub" <tze...@dhc.net> writes:
>> As to just what is
>>a _full-blown ANS_ Forth control structure, I know of no such
>>definition in the standard.
>
>What I mean by this are control structures like
>
>: foo
> begin ... while ... until ... else ... then ;
>
Yes that's the kind of mixing of control structures I had in mind.
I've seen it in some postings but I question if it's required
that way by the standard.
>See A.3.2.3.2 for more examples and a deeper discussion.
>
And the answer seems to be yes. Thanks :(
Wil Baden
> And the answer seems to be yes. Thanks :(
The ANS control structures were already established in Forth.
In _Thinking Forth_, 1984, Chuck Moore is quoted:
" Many times conditionals are used to get out of loops. That
particular use can be avoided by having loops with multiple
exit points.
This is a live topic, because of the multiple WHILE
construct which is in polyFORTH but hasn't percolated up to
FORTH '83. It's a simple way of defining multiple WHILE's
in the same REPEAT."
In time immemorial the data stack was used for control flow.
figFORTH introduced two values on the stack for "compiler
security". F83 used two values. Classical Forth used only
one value.
Let's use the British spelling SWOP for 2SWAP in figFORTH
and SWAP in classical Forth.
Effectively:
In figFORTH,
: WHILE [COMPILE] IF ; IMMEDIATE
: REPEAT SWOP [COMPILE] AGAIN [COMPILE] THEN ;
In polyFORTH,
: WHILE [COMPILE] IF SWOP ; IMMEDIATE
: REPEAT [COMPILE] AGAIN [COMPILE] THEN ; IMMEDIATE
In ANS Forth, with SWOP for `1 CS-ROLL`,
: WHILE POSTPONE IF SWOP ; IMMEDIATE
: REPEAT POSTPONE AGAIN POSTPONE THEN ; IMMEDIATE
So it is easy to redefine WHILE and REPEAT in figFORTH.
While I was active in ANS, I found out how to have compiler
security with only one value for the stack.
Thus for Forth in Forth, I expect the data stack to be the
control flow stack and to use single values.
(
--
Wil Baden Costa Mesa, California WilB...@Netcom.com
)
Tom Zegub
Wil Baden <wilb...@netcom17.netcom.com> wrote:
>Tom Zegub <tze...@dhc.net> wrote:
>> And the answer seems to be yes. Thanks :(
>
>The ANS control structures were already established in Forth.
>In _Thinking Forth_, 1984, Chuck Moore is quoted:
>
>" Many times conditionals are used to get out of loops. That
> particular use can be avoided by having loops with multiple
> exit points.
>
Something was avoided?
> This is a live topic, because of the multiple WHILE
> construct which is in polyFORTH but hasn't percolated up to
> FORTH '83. It's a simple way of defining multiple WHILE's
> in the same REPEAT."
>
Simple but odd.
In general programming multiple WHILE's can be found
in BEGIN REPEAT as well as BEGIN UNTIL structures.
Having to append THEN's is a Forth flavor.
Case 1 (common):
BEGIN ... WHILE ... WHILE ... REPEAT
Case 2 (ANS):
BEGIN ... WHILE ... WHILE ... REPEAT THEN
WHILE _was_ in essence a special purpose IF . When
conditions failed it (they) passed control to a specific location,
the _next_ one past REPEAT or UNTIL. Now in ANS Forth WHILE appears as
two kinds. The last WHILE in a BEGIN REPEAT structure has the nature of
the _ideal_ WHILE ('ideal' in the classical Greek sense) . The others
have the nature of a general IF .
Case 3 (ANS):
BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT ... THEN ... THEN
Case 4 (ideal):
BEGIN ... IF ... IF ... WHILE ... REPEAT ... THEN ... THEN
Case 3, ANS, is equivalent to case 4 in effect but case 4 maintains
integrity of concepts:
4a) THEN close IF structures
4b) WHILE on false exit at structure's end
Case 5 (ANS):
BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT THEN ... THEN
Case 6 (ideal):
BEGIN ... IF ... WHILE ... WHILE ... REPEAT ... THEN
Maybe cases 5 & 6 show better the subtle difference between ANS
WHILE's and ideal WHILE's.
Simple code provided 100% of the desired functionality; however,
with slight change in WHILE's connotation. Do a little more or
differently to preserve purity of concept? No, it's natural for
programmers to bend concepts to fit code. But for a standard I
would have leaned to Yes. Se la vie.
>In time immemorial the data stack was used for control flow.
>figFORTH introduced two values on the stack for "compiler
>security". F83 used two values. Classical Forth used only
>one value.
>
I assume you mean an address plus tag for the two values
and address alone for the one value?
>Let's use the British spelling SWOP for 2SWAP in figFORTH
>and SWAP in classical Forth.
>
>Effectively:
>
>In figFORTH,
>
> : WHILE [COMPILE] IF ; IMMEDIATE
> : REPEAT SWOP [COMPILE] AGAIN [COMPILE] THEN ;
>
>In polyFORTH,
>
> : WHILE [COMPILE] IF SWOP ; IMMEDIATE
> : REPEAT [COMPILE] AGAIN [COMPILE] THEN ; IMMEDIATE
>
>In ANS Forth, with SWOP for `1 CS-ROLL`,
>
> : WHILE POSTPONE IF SWOP ; IMMEDIATE
> : REPEAT POSTPONE AGAIN POSTPONE THEN ; IMMEDIATE
>
>So it is easy to redefine WHILE and REPEAT in figFORTH.
>
Almost that easy. In addition, WHILE being a special case of IF was
tagged differently. Now some WHILE's are IF exactly and so it works out
better if they are not tagged differently.
>While I was active in ANS, I found out how to have compiler
>security with only one value for the stack.
>
How much security, depth checks only?
>
>Thus for Forth in Forth, I expect the data stack to be the
>control flow stack and to use single values.
>
I would caution against expecting something to be sufficient in
general based only on it having been sufficient for specific cases.
There could be more compelling reasons for doing as you suggest but
I don't know what values you are discarding. If they are tags, I know
of pro's and con's. But such is irrelevant at this point. You're
already in trouble if you're expecting the control flow stack to be
made up in a way that's not spelled out in the standard. I would
expect the makeup of the control flow stack to be a system prerogative.
Elizabeth D. Rather
> Simple but odd.
> In general programming multiple WHILE's can be found
> in BEGIN REPEAT as well as BEGIN UNTIL structures.
> Having to append THEN's is a Forth flavor.
>
> Case 1 (common):
> BEGIN ... WHILE ... WHILE ... REPEAT
>
> Case 2 (ANS):
> BEGIN ... WHILE ... WHILE ... REPEAT THEN
>
> WHILE _was_ in essence a special purpose IF . When
> conditions failed it (they) passed control to a specific location,
> the _next_ one past REPEAT or UNTIL. Now in ANS Forth WHILE appears as
> two kinds. The last WHILE in a BEGIN REPEAT structure has the nature of
> the _ideal_ WHILE ('ideal' in the classical Greek sense) . The others
> have the nature of a general IF .
Careful, here. The compile-time stack (control flow stack) is very
precisely described in the Standard:
IF ( C: -- orig )
WHILE ( C: dest -- orig dest )
The 'dest' in the WHILE structure is presumed to have been left by
BEGIN, and both addresses will be consumed by REPEAT ( C: orig dest --
).
Thus, your Case 2 requires the THEN to consume the extra orig. There is
only ever one "kind" of WHILE in ANS Forth, and it differs significantly
from IF because IF leaves 'orig' on top whereas WHILE leaves 'dest' on
top.
> >In time immemorial the data stack was used for control flow.
> >figFORTH introduced two values on the stack for "compiler
> >security". F83 used two values. Classical Forth used only
> >one value.
Not sure what you mean by "classical Forth" in this context. All Forth
before FigForth, and all FORTH, Inc. systems to this day, had/have _no_
control flow stack items for "compiler security", only the necessary
addresses. In my personal experience, "compiler security" is as
un-Forthlike as strong data typing ;-) But it is certainly true that
ANS Forth allows it.
For a while in the 80's we had a special version of polyFORTH for
beginning courses that did extensive checking of this kind, but we
abandoned it because we found that students learned more slowly (it was
easy to ignore all those error messages, but much harder to ignore a
crash caused by an incomplete structure).
> >So it is easy to redefine WHILE and REPEAT in figFORTH.
> >
> Almost that easy. In addition, WHILE being a special case of IF was
> tagged differently. Now some WHILE's are IF exactly and so it works out
> better if they are not tagged differently.
WHILE cannot be "IF exactly" since its control flow stack is different.
>...
> >Thus for Forth in Forth, I expect the data stack to be the
> >control flow stack and to use single values.
> >
> I would caution against expecting something to be sufficient in
> general based only on it having been sufficient for specific cases.
> There could be more compelling reasons for doing as you suggest but
> I don't know what values you are discarding. If they are tags, I know
> of pro's and con's. But such is irrelevant at this point. You're
> already in trouble if you're expecting the control flow stack to be
> made up in a way that's not spelled out in the standard. I would
> expect the makeup of the control flow stack to be a system prerogative.
In some respects the "makeup" of the control flow stack can be a system
prerogative (e.g., whether it's the data stack or not), but the cfstack
behavior of all structure words is very explicitly specified.
Wil Baden
> I assume you mean an address plus tag for the two values
> and address alone for the one value?
Compiler Security with Single Value
-----------------------------------
In Forths compiled by Forth.
For the IF and BEGIN families, compiler security with single
values on the control flow stack is easy.
When IF and AHEAD (used by ELSE) partially compile a forward
branch, the portion for the future address can be made an
impossible code value -- an illegal instruction or illegal
address. The address of the address of the future address is
pushed on the control flow stack.
In threaded code, 0 is a good choice for the impossible
code value.
When ELSE or THEN is resolved, it can check that the contents
of orig is properly illegal. AGAIN and UNTIL and REPEAT can
check that the contents of dest is not illegal. THEN as a
component of REPEAT will test orig.
The validity of multiple `WHILE`s can be checked. Every
control flow operator must be balanced. REPEAT balances
two operators.
An orig is the address of impossible code. A dest is the
address of possible code.
DO and ?DO can contrive. One way is to invert the leading bit
of the address pushed on the control flow stack. `HERE - 0<`
can be used to identify which control flow word put the
address on the control flow stack.
An "address" of 0 can be used for CASE.
The depth of the control flow stack can be used to check
for completeness.
This will check that all Standard control flow words are
syntactically correct.
The "standard" WHILE and REPEAT have been used for at least
17 years. It is not an innovation.
In practice, multiple `WHILE`s are not often used. It is
often better to write `IF ... EXIT THEN`.
Multiple `WHILE`s can be nice in loops returning success or
failure, especially when followed by common clean-up.
--
Wil WilB...@Netcom.com
Tom Zegub
1. Nothing prevents REPEAT form consuming all orig's other than
specifications.
2. One coding of WHILE but when used in multiple fashion it projects
two natures.
3. An ANS WHILE is an IF that begins within a BEGIN structure.
With care I go forth. But please note, it is strong in your
mind how ANS defined WHILE and the reasons for doing so. Such a strong
image can easily obscure what is being stated especially when the
familiar is being taken in an unaccustomed direction.
Please re-read the paragraph immediately following case 2 above.
The subject is the conceptional differences between a common (apart
from Forth) WHILE and the ANS Forth WHILE . The discussion at that
point is in the realm of concept not realization. If WHILE ever
contains any IF code is immaterial. But WHILE has a _conceptual_
relationship with IF apart from anything to do with Forth.
The ANS specification of WHILE that you give helps to explain how
ANS WHILE evolved its peculiar nature. But the how is of little
concern to the topic. The theme that developed was that ANS made a
choice (knowingly or not) when it specified WHILE which in effect
bends the common (ideal) concept of WHILE to fit a particular
implementation. The choice not taken was to take the 'ideal' concept
and build to it.
>> >In time immemorial the data stack was used for control flow.
>> >figFORTH introduced two values on the stack for "compiler
>> >security". F83 used two values. Classical Forth used only
>> >one value.
>
>Not sure what you mean by "classical Forth" in this context. All Forth
>before FigForth, and all FORTH, Inc. systems to this day, had/have _no_
>control flow stack items for "compiler security", only the necessary
>addresses. In my personal experience, "compiler security" is as
>un-Forthlike as strong data typing ;-) But it is certainly true that
>ANS Forth allows it.
>
Personally, I've found data typing to be more of a nuisance than help
and in general never cared much for any kind of hand slapping.
However, compiler security has been an exceptions. I get my hands
slapped on a regular basis and glad its there. It may not be of much
use to people doing careful design, but most of my time is spent in
hack mode.
Tags are not needed for standard control structures as defined nor
for other control structures that are constructed in a similar manner
allowing for successional reordering of the control flow stack. If
they are ever essential may be questionable to some people. But they
are convenient for building hardened, self reliant control structures
independent of stack ordering. Tags with selective filtering turn
placid the most turbulent of chaotic stack ordering. It nice to see
structures intermingle in ways not intended and have them still play.
When depended on positioning you can count on disaster when operating
outside of design bounds.
>For a while in the 80's we had a special version of polyFORTH for
>beginning courses that did extensive checking of this kind, but we
>abandoned it because we found that students learned more slowly (it was
>easy to ignore all those error messages, but much harder to ignore a
>crash caused by an incomplete structure).
>
>> >So it is easy to redefine WHILE and REPEAT in figFORTH.
>> >
>> Almost that easy. In addition, WHILE being a special case of IF was
>> tagged differently. Now some WHILE's are IF exactly and so it works out
>> better if they are not tagged differently.
>
>WHILE cannot be "IF exactly" since its control flow stack is different.
>
I should have said from ELSE and THEN point of view. The difference in
control flow stack only accounts for the difference in an IF outside
the BEGIN structure from one (WHILE) within.
IF
BEGIN ... WHILE-IF ... WHILE-IF ... WHILE ... REPEAT ...
THEN ... THEN ...
THEN
Since some WHILE's are now _seen_ closed with a THEN maybe an
alias WHILE-IF could help with the conception. Not suggesting this
needs to be done.(the above shows each WHILE-IF matched with a THEN,
ignore the visual suggestion of a wrong matching order)
<Recap>
In case the details and sidetrackings of the discussion caused anyone
to loose track of the central idea I will recap here a little:
1) The ideal BEGIN loop
A BEGIN REPEAT or BEGIN UNTIL structure with multiple WHILE's has the
ideal form of the following:
BEGIN ... WHILE ... WHILE ... ... WHILE ... REPEAT
The WHILE's on false condition provide exit from the loop by passing
control the next location past the end of the structure.
2) Additional feature
As an additional feature exit from the ideal BEGIN loop can be made by
an IF THEN structure which is allowed to begin within the loop and
span the loop boundary to any outside location:
BEGIN ... IF ... WHILE ... WHILE ... REPEAT ... THEN
Users who wished to adhere to strict structuring principles would not
want to use the additional feature but the capability is allowed for
those who wish it.
This form and feature of the BEGIN loop does not correspond to
ANS specification. It is presented only to show what was possible if
the goal had been to maintain integrity of concept and build to it.
By not doing so has no detrimental effects in capability or
performance. The only adverse effect known is making the Forth peculiar
looking in its description showing THEN's as appendages to the BEGIN
loop. In usage these peculiarities are often hardly noticeable, either
the appended THEN's are lost in the noise of other code or are hidden
altogether by placement in macros.
</recap>
While this may seem much ado about nothing it is at the literal level
of this topic. However, it is part of a larger topic being developed
which deals with how problems are caused by ignoring conceptual
details. But before such can be discussed groundwork has to be laid to
raise the level of awareness to issues and workings not commonly dealt
with.
Tom Zegub
Wil Baden <wilb...@netcom2.netcom.com> wrote:
Putting the tag in the address place holder is a good idea for a way
to save putting the tag on the cfstack. You confirm your point that
for standard controls as they are defined you can provide full
compiler security without, if you wish, putting the tags on the stack.
However, the value of the savings is not obvious neither is the
possibility of locking structures into a stack ordering dependency.
Off hand it seems that it won't be if for every address on the stack
there is a memory location with the tag. One could expect checking
memory at each address found on the stack would be equivalent to
checking a tag on the stack which precedes each address value. But I
know of controls that had values on the stack that were not memory
addresses, for instance a count. Perhaps, they could be designed
differently if needed to. But with tags on the stack there is no
question of problem. I know they make life easy. But I'm not sure
if I can rely on having available memory positions for all stack
values.
>The "standard" WHILE and REPEAT have been used for at least
>17 years. It is not an innovation.
>
>In practice, multiple `WHILE`s are not often used. It is
>often better to write `IF ... EXIT THEN`.
>
>Multiple `WHILE`s can be nice in loops returning success or
>failure, especially when followed by common clean-up.
>
>--
Performance and capability were not in question, only its odd
appearance when described. The bending of concept gave birth to a
small imp which seems fairly harmless. At its worst it can only cause
unnecessary distractions to an audience that already thinks Forth is
strange.
Andrew Haley
: While this may seem much ado about nothing it is at the literal level
: which deals with how problems are caused by ignoring conceptual
: details.
This is such utter nonsense it is almost beyond belief. You have
provided no evidence, not the tiniest bit, that the approach taken by
FORTH, Inc ignored conceptual details.
On the contrary, I regard the looping structures designed for
polyFORTH II (I think) as a work of genius. With a few simple words,
they provide the most expressive and flexible set of control
structures that I have ever encountered.
One of the most useful of all (not in ANS, IIRC) is:
DO ... WHILE ... LOOP ... ELSE ... THEN
which provides a simple way to do a linear search with separate
actions for successful and unsuccessful searches.
Multiple whiles have their uses, but another extremely useful
construct is:
BEGIN ... WHILE ... REPEAT ... ELSE ... THEN
which has similar properties to the DO construct above.
Certainly, these structures look odd to people unused to Forth. But
no more odd than RPN, and these structures are far more useful and
powerful than those of many (most?) other languages.
: But before such can be discussed groundwork has to be laid to raise
: the level of awareness to issues and workings not commonly dealt
: with.
Heh.
Andrew.
jonah thomas
>1. Nothing prevents REPEAT form consuming all orig's other than
>specifications.
>2. One coding of WHILE but when used in multiple fashion it projects
>two natures.
>3. An ANS WHILE is an IF that begins within a BEGIN structure.
The ANS WHILE works very well. It's a good system. There are other
possible good systems, some of them incompatible with that.
> Personally, I've found data typing to be more of a nuisance than help
>and in general never cared much for any kind of hand slapping.
>However, compiler security has been an exceptions. I get my hands
>slapped on a regular basis and glad its there. It may not be of much
>use to people doing careful design, but most of my time is spent in
>hack mode.
A standard system can do compiler security, but it isn't required to. It
might be a good idea to develop on a system that has that security, and then
once the code is correct it can compile on systems that lack security too.
>I should have said from ELSE and THEN point of view. The difference in
>control flow stack only accounts for the difference in an IF outside
>the BEGIN structure from one (WHILE) within.
> IF
> BEGIN ... WHILE-IF ... WHILE-IF ... WHILE ... REPEAT ...
> THEN ... THEN ...
> THEN
>Since some WHILE's are now _seen_ closed with a THEN maybe an
>alias WHILE-IF could help with the conception. Not suggesting this
>needs to be done.(the above shows each WHILE-IF matched with a THEN,
>ignore the visual suggestion of a wrong matching order)
That should be possible. The following code should work on the vast
majority of standard systems:
: WHILE-IF POSTPONE WHILE ; IMMEDIATE
You can use WHILE-IF in your code and port it to standard systems.
But BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT ... ( no THENs)
will not run correctly on many standard systems, the extra WHILEs require
THENs and usually not having them will cause problems of one sort or
another.
>1) The ideal BEGIN loop
>A BEGIN REPEAT or BEGIN UNTIL structure with multiple WHILE's has the
>ideal form of the following:
> BEGIN ... WHILE ... WHILE ... ... WHILE ... REPEAT
>The WHILE's on false condition provide exit from the loop by passing
>control the next location past the end of the structure.
I don't see that this is ideal. The standard way is more flexible, it lets
you do things that are hard with this approach. You can have different
ending code for each exit. To do that with your method you'd need to
repeat the tests
.. ?DUP 0= IF 1ST-EXIT-STUFF THEN WHILE ... ?DUP 0= IF 2ND-EXIT-STUFF THEN
WHILE ... etc
or pass a flag
.. DUP 1 AND WHILE DROP ... DUP 2 AND WHILE DROP ... REPEAT
CASE 1 OF 1ST-EXIT-STUFF ENDOF 2 OF 2ND-EXIT-STUFF ENDOF ...
while their way you can do
WHILE
... WHILE
... WHILE
...
REPEAT
LAST-EXIT-STUFF ELSE
2ND-EXIT-STUFF THEN ELSE
1ST-EXIT-STUFF THEN
You have to remember to do the extra THENs in the simple case (and on most
systems that will have no runtime penalty at all) but in exchange you get
more control from your control structures.
Tom Zegub
Andrew Haley <a...@cygnus.remove.co.uk > wrote:
>
>Certainly, these structures look odd to people unused to Forth. But
>no more odd than RPN, and these structures are far more useful and
>powerful than those of many (most?) other languages.
>
That thought crossed my mind; however, I don't support
an attitude that says, "Don't bother with how it looks, if it's
strange it won't be any different than RPN."
Soon you'll have people intentionally making something look strange
just so it will be more Forth-like.
Tom Zegub
jonah thomas <jeth...@ix.netcom.com > wrote:
>The ANS WHILE works very well. It's a good system. There are other
>possible good systems, some of them incompatible with that.
>
Performance was never an issue, only appearance in description.
Since it was going into a standard maybe it should get a little more
attention, a dotting the last 'i'. Was there a way to create a
cleaner image.
>
>A standard system can do compiler security, but it isn't required to. It
>might be a good idea to develop on a system that has that security, and then
>once the code is correct it can compile on systems that lack security too.
>
Agreed. Just as with other aspects-- threading type, code
optimization, optional wordsets used, and etc.-- the mix and
flavor of Forth's makeup can be tuned to where it's being applied.
>But BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT ... ( no THENs)
>will not run correctly on many standard systems, the extra WHILEs require
>THENs and usually not having them will cause problems of one sort or
>another.
>
Right, do not expect that form to be compatible with standard systems.
That was a design choice not taken.
>>1) The ideal BEGIN loop
>>A BEGIN REPEAT or BEGIN UNTIL structure with multiple WHILE's has the
>>ideal form of the following:
>
>> BEGIN ... WHILE ... WHILE ... ... WHILE ... REPEAT
>
>>The WHILE's on false condition provide exit from the loop by passing
>>control the next location past the end of the structure.
>
>I don't see that this is ideal.
Our usage of the word ideal is a little different. By ideal I'm
referring to it's concept as it is defined in the mind. The aim was
to start with a pure concept and then build to it. The above was
the concept of a BEGIN loop with multiple WHILE's in its pure form
before it is made manifest (realized) in Forth, C or the structure
macros in my MASM assembly.
>The standard way is more flexible, it lets
>you do things that are hard with this approach. You can have different
>ending code for each exit. To do that with your method you'd need to
>repeat the tests
>
You were comparing only the ideal form without IF's with
the ANS loop structure which has the composite nature of a loop plus
if's. In the original the ideal form was shown in conjunction with
spanning IF's to be functionally equivalent to the ANS structure. In
the recap the IF's were separated from the loop so not to distract
from the image.
Philip Preston
[snip]
>Multiple whiles have their uses, but another extremely useful
>construct is:
>
> BEGIN ... WHILE ... REPEAT ... ELSE ... THEN
>
>which has similar properties to the DO construct above.
Should be UNTIL rather than REPEAT surely?
Regards,
Philip.
jonah thomas
>Andrew Haley wrote in message <8988mb$7p4$1...@korai.cygnus.co.uk>...
>> BEGIN ... WHILE ... REPEAT ... ELSE ... THEN
>>which has similar properties to the DO construct above.
>Should be UNTIL rather than REPEAT surely?
Yes, of course.
I like to indent these things. I indent 2 spaces for the code after an IF
and the same two spaces after an ELSE, 2 spaces after a BEGIN and 2 more
spaces after a WHILE.
For UNTIL I unindent 2 spaces and for REPEAT I unindent 4.
BEGIN
... WHILE
... WHILE
...
REPEAT
... ELSE
...
THEN
If the code is very simple I might put the whole structure on one line. If
it's too complicated I like to factor the stuff inside the branches and make
it at least look simpler.
The nesting is unambiguous. To have REPEAT resolve its loop while leaving
unresolved IFs that were started after the BEGIN would be strange
structuring.
Tom Zegub
jonah thomas <jeth...@ix.netcom.com > wrote:
>
>BEGIN
> ... WHILE
> ... WHILE
> ...
> REPEAT
> ... ELSE
> ...
>THEN
>
The following is also allowed by the standard:
BEGIN
... WHILE
... WHILE
...
REPEAT
... OTHER-than-the-last-WHILE
...
END-BEGIN
For standard code with less anomaly use this:
BEGIN
... PERHAPS
... WHILE
...
REPEAT
... PERHAPS-NOT
...
END-BEGIN
Andrew Haley
: On 26 Feb 2000 10:08:11 GMT,
: Andrew Haley <a...@cygnus.remove.co.uk > wrote:
: >Certainly, these structures look odd to people unused to Forth. But
: >no more odd than RPN, and these structures are far more useful and
: >powerful than those of many (most?) other languages.
: That thought crossed my mind; however, I don't support an attitude
: that says, "Don't bother with how it looks, if it's strange it won't
: be any different than RPN."
Of course, such an attitude would be silly and self defeating. But
no-one has such an attitude, do they?
Andrew.
Andrew Haley
: For me, the problem here is not whether the code is portable,
: or whether compiler security is possible, but whether the source
: code reads well. However well laid out, the cascade of tests and
: exit actions are difficult to read, and hence to maintain without
: extensive commenting, especially if you have to write code
: for non guru programmers.
That will always be true, more or less irrespective of the design of
the looping structures, because multiple nested loops are inherently
complex. This is where the "one or two lines long" rule comes to the
rescue; it simply isn't possible to have a complicated system of
nested loops in one or two lines.
: I'd be interested to know if someone can find a loop structure that
: can be implemented by BEGIN and friends that cannot be implemented
: by CASE ... NEXTCASE. I should admit that I start from a position
: in which I find the Eaker CASE statement to be an essential
: component.
Mmm. The only really nasty thing about this structure is that it
mixes up comparison and testing, so you'd end up with
begin
foo? true case endcase
bar? true case endcase
nextcase
which doesn't seem very nice. Presuambly
begin
foo? if endcase
bar? if endcase
nextcase
would work just as well.
Andrew.
Andrew Haley
: "Philip Preston" <phi...@preston20.freeserve.co.uk> wrote:
: >Andrew Haley wrote in message <8988mb$7p4$1...@korai.cygnus.co.uk>...
: >> BEGIN ... WHILE ... REPEAT ... ELSE ... THEN
: >>which has similar properties to the DO construct above.
: >Should be UNTIL rather than REPEAT surely?
: Yes, of course.
Well, both are looping structures with an early exit in the middle.
In that sense they have similar properties. That's all I meant.
Andrew.
Philip Preston
>jonah thomas (jeth...@ix.netcom.com) wrote:
>: "Philip Preston" <phi...@preston20.freeserve.co.uk> wrote:
>: >Andrew Haley wrote in message <8988mb$7p4$1...@korai.cygnus.co.uk>...
>
>: >> BEGIN ... WHILE ... REPEAT ... ELSE ... THEN
>
>: >>which has similar properties to the DO construct above.
>
>: >Should be UNTIL rather than REPEAT surely?
>
>: Yes, of course.
>
>Well, both are looping structures with an early exit in the middle.
Not so. With REPEAT :
a) you get cf stack underflow at compile time
b) if despite this you manage to compile the structure without fatally
corrupting some other part of the system, you get a loop with its *only*
exit in the middle.
Regards,
Philip.
Stephen Pelc
>Mmm. The only really nasty thing about this structure is that it
>mixes up comparison and testing, so you'd end up with
You are correct. I hope you meant:
case
foo? true of ... endof
bar? true of ... endof
...
nextcase
Since your code was meaningless to me. There has been a common
usage of ?OF to perform a test, where ?OF may be a synonym for IF
plus syntax checking, which reduces your example to:
case
foo? ?of ... endof
bar? ?of ... endof
...
nextcase
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)2380 631441, fax: +44 (0)2380 339691
web: http://www.mpeltd.demon.co.uk - free ProForth downloads!
Jerry Avins
Jerry
P.S. Somewhere in my junk, I may have some MAYBE gates. Shall I look for
them? Of course, you remember the perhapsatron!
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Tom Zegub wrote:
>
> On Sun, 27 Feb 2000 00:24:42 GMT,
> jonah thomas <jeth...@ix.netcom.com > wrote:
>
> >
> >BEGIN
> > ... WHILE
> > ... WHILE
> > ...
> > REPEAT
> > ... ELSE
> > ...
> >THEN
> >
> The following is also allowed by the standard:
> BEGIN
> ... WHILE
> ... WHILE
> ...
> REPEAT
> ... OTHER-than-the-last-WHILE
> ...
> END-BEGIN
>
> For standard code with less anomaly use this:
> BEGIN
> ... PERHAPS
> ... WHILE
> ...
> REPEAT
Anton Ertl
jeth...@ix.netcom.com (jonah thomas) writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> jeth...@ix.netcom.com (jonah thomas) writes:
>>>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>>>>In the posting that started this thread Douglas Atique showed us a way
>>>>to get something out from under a colon-sys with DEPTH and ROLL.
>
>>>This assumes that : does not change the data-stack pointer to a new location
>>>to create a control-flow stack that all the usual stack manipulation words
>>>work with.
>
>>Inventing hypothetical systems again?
>
>Yes. Here's why -- if we can't imagine a system that the construction fails
>on, then it will probably be quite portable regardless what the committee
>decides is standard.
We already know some (non-hypothetial) systems where the construction
fails, and the only question was whether the construction is standard
(i.e., are the systems where it fails non-standard?). So discussing
hypothetical systems in this context does not help.
>Notice the standard:
>
>>6.2.0455 :NONAME ( C: -- colon-sys ) ( S: -- xt )
>
>There isn't any guarantee that the xt will be sitting under the colon-sys.
There is, a little further on:
|If the control-flow stack is implemented using the data stack,
|colon-sys shall be the topmost item on the data stack.
- anton
Anton Ertl
"Tom Zegub" <tze...@dhc.net> writes:
>On 20 Feb 2000 21:17:08 GMT,
>Anton Ertl <an...@mips.complang.tuwien.ac.at > wrote:
>
>>In article <E19A68DD04DD20CD.69601B49...@lp.airnews.net>,
>> "Tom Zegub" <tze...@dhc.net> writes:
>>> As to just what is
>>>a _full-blown ANS_ Forth control structure, I know of no such
>>>definition in the standard.
>>
>>What I mean by this are control structures like
>>
>>: foo
>> begin ... while ... until ... else ... then ;
>>
>Yes that's the kind of mixing of control structures I had in mind.
>I've seen it in some postings but I question if it's required
>that way by the standard.
>
>>See A.3.2.3.2 for more examples and a deeper discussion.
>>
Note that A.3.2.3.2 is informative. The normative parts of the
standard that allow this to programs/require this from systems are the
glossary entries of the basic control control flow words, in
particular their stack effects.
Anton Ertl
"m_l...@my-deja.com" <m_l...@my-deja.com> writes:
>Indeed, does the standard state anywhere that:
>1) if a program is standard, it will run on any standard system
>2) if a system is standard, it will run any standard program
>3) it is not possible that a standard system cannot run a standard
>program?
>{ :-) }*0.5
Generally, that's the point of programming language standards. So,
looking at sections 1.1 and especially 1.2 of the standard, they imply
the points above, in particular the sentence: "This Standard specifies
an interface between a Forth System and a Forth Program ...".
Another sentence that may be worth remembering, is:
|The purpose of this Standard is to promote the portability of Forth
|programs for use on a wide variety of computing systems, ...
>Any reader upon the 1st reading understands that ?CSP is
>disallowed, but an interpretation of the text of the standard
>exists according to which: the compilation stack is what is
>above (the pointer stored in) CSP, and if you ROLL an element
>from under CSP, you just get the control-flow-stack-underflow
>error.
If the ?CSP-approach is standard, it follows from 3.2.3.2, last
sentence. Without this sentence, the ?CSP-approach seems clearly
non-standard to me, and your reasoning is flawed: If there is a
separate control-flow stack, ROLL should have no influence on it;
OTOH, if the control-flow stack items reside on the data stack, ROLL
as used by Douglas Atique does not underflow the data stack.
>1) a program incompatible with ?CSP is not portable
>because ?CPS *is* used in real systems
That was not the question, so it's a red herring; I wonder why TC
member are so keen on using it.
>2) the *intent* of TC was to declare non-portable the
>techniques that would fail on ?CPS systems.
Please send me the intent-of-the-TC in HTML form so I can look up such
things myself.
Anton Ertl
"Tom Zegub" <tze...@dhc.net> writes:
>Our usage of the word ideal is a little different. By ideal I'm
>referring to it's concept as it is defined in the mind. The aim was
>to start with a pure concept and then build to it.
The concepts for control-flow in ANS Forth are very pure. Your
problem is probably that the concepts you use for these words are
different for the ones in ANS Forth. So here are the basic concepts
in ANS Forth:
forward backward
unconditional branch AHEAD AGAIN
conditional branch IF UNTIL
branch target THEN BEGIN
With CS-ROLL and CS-PICK to get the right pairs to match.
Anton Ertl
jeth...@ix.netcom.com (jonah thomas) writes:
>I like to indent these things. I indent 2 spaces for the code after an IF
>and the same two spaces after an ELSE, 2 spaces after a BEGIN and 2 more
>spaces after a WHILE.
>
>For UNTIL I unindent 2 spaces and for REPEAT I unindent 4.
>
> ... WHILE
> ... WHILE
> ...
> REPEAT
> ...
>THEN
I.e., you indent according to control-flow stack depth.
Great idea! I always wondered how to deal with WHILE; I want to put
it at the end of the line, but also want the reader to notice easily
where it is. Your way solves this problem.
BTW, why did you want us to followup to alt.angst (ignored)?
Andrew Haley
: Andrew Haley wrote in message <89c7uk$n0$2...@korai.cygnus.co.uk>...
: >Mmm. The only really nasty thing about this structure is that it
: >mixes up comparison and testing, so you'd end up with
: You are correct. I hope you meant:
: case
: foo? true of ... endof
: bar? true of ... endof
: ...
: nextcase
Yes, of course. I've never used the Eaker case structure, so I got it
wrong.
: Since your code was meaningless to me. There has been a common
: usage of ?OF to perform a test, where ?OF may be a synonym for IF
: plus syntax checking
: case
: foo? ?of ... endof
: bar? ?of ... endof
: ...
: nextcase
Yep. That fully answers my objection. But what's the point of ?OF
rather than IF ? When teaching someone, you'd have to say "IF is used
for testing a truth value in a conditional, unless the test is part of
a CASE structure in which case you must use ?OF ."
Andrew.
Anton Ertl
"Stephen Pelc" <s...@mpeltd.demon.co.uk> writes:
>The common problem is the multiple-exit loop with associated
>exit conditions. There have been several proposed solutions to
>this problem, but the one I like best is the amended Eaker
>CASE ... NEXTCASE solution, in which NEXTCASE lays
>an unconditional branch back to the CASE, and ENDOF
>lays a forward branch to just after the NEXTCASE.
>
>CASE ...
> OF ... ENDOF
> OF ... ENDOF
> ...
>NEXTCASE
>
>This has the advantage that the tests and exit actions
>are next to each other, and only one extra word is
>introduced. The changes to the Eaker CASE structure
>are trivial, and there is no need for CS-PICK and CS-ROLL.
>If you want to implement this structure using the ANS control
>flow words, you will find that implementing ENDCASE
>requires the missing CS-DROP to dispose of the dest
>introduced by CASE.
: dest-drop
POSTPONE ahead 1 cs-roll POSTPONE again POSTPONE then ;
A sophisticated compiler could notice that AGAIN is dead, not generate
any code for it, and then notice that AHEAD jumps over no code and not
generate any code for AHEAD ... THEN, either (gcc does such things).
>I'd be interested to know if someone can find a loop
>structure that can be implemented by BEGIN and friends
>that cannot be implemented by CASE ... NEXTCASE.
Multi-entry loops:
... IF
... BEGIN
... [ 1 cs-roll ] THEN
...
Another thing that I might miss is easy ways to enter the next
iteration from an OF ... ENDOF subconstruction (should be easy to add,
though).
Somehow your CASE reminds me of Dijkstra's guarded commands. But they
work the other way round: if a guard is satisfied, it's command is
executed and another iteration of the loop is performed; if none of
the guards are satisfied, the loop is exited.
Stephen Pelc
>Yep. That fully answers my objection. But what's the point of ?OF
>rather than IF ? When teaching someone, you'd have to say "IF is
used
>for testing a truth value in a conditional, unless the test is part of
>a CASE structure in which case you must use ?OF ."
because ?OF seems to be more in line with common practice.
Stephen Pelc
Anton Ertl wrote in message <89gkk8$ouh$1...@news.tuwien.ac.at>...
>Multi-entry loops:
[snip]
>Somehow your CASE reminds me of Dijkstra's guarded commands.
I'm shocked! You mention "multiple entry loops" and "Dijkstra" in
the same post!
Elizabeth D. Rather
>
> In article <9201B3BDAEB6243D.2C92BB4A...@lp.airnews.net>,
> "Tom Zegub" <tze...@dhc.net> writes:
> >Our usage of the word ideal is a little different. By ideal I'm
> >referring to it's concept as it is defined in the mind. The aim was
> >to start with a pure concept and then build to it.
>
> The concepts for control-flow in ANS Forth are very pure. Your
> problem is probably that the concepts you use for these words are
> different for the ones in ANS Forth. So here are the basic concepts
> in ANS Forth:
>
> forward backward
> unconditional branch AHEAD AGAIN
> conditional branch IF UNTIL
> branch target THEN BEGIN
>
> With CS-ROLL and CS-PICK to get the right pairs to match.
Nice, concise summary. In addition, I'd like to point out that an
important component of "ideal" or "pure" in most Forth philosophy is
that of context-independence. The notion of a WHILE whose behavior is
context-dependent as Tom suggests is, to me, appalling, not ideal.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
jonah thomas
>>>6.2.0455 :NONAME ( C: -- colon-sys ) ( S: -- xt )
>>There isn't any guarantee that the xt will be sitting under the colon-sys.
>There is, a little further on:
>|If the control-flow stack is implemented using the data stack,
>|colon-sys shall be the topmost item on the data stack.
The stack diagram doesn't show ( C: -- xt colon-sys ) . So it isn't
claiming that the xt is sitting under the colon-sys. I strongly doubt that
a system that put the xt on the stack when ; executes, would be declared
nonstandard.
m_l...@my-deja.com
> The stack diagram doesn't show ( C: -- xt colon-sys ) . So it isn't
> claiming that the xt is sitting under the colon-sys. I strongly doubt that
> a system that put the xt on the stack when ; executes, would be declared
> nonstandard.
You are right.
1) "xt logically belongs to the data stack, but is temporarily
physically unavailable" sounds ok, isn't it?
2) neither police nor mafia would come and declare the system
unstandard; neither the author will do it. ;-)
Anton Ertl
jeth...@ix.netcom.com (jonah thomas) writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> jeth...@ix.netcom.com (jonah thomas) writes:
>
>>>>6.2.0455 :NONAME ( C: -- colon-sys ) ( S: -- xt )
>
>>>There isn't any guarantee that the xt will be sitting under the colon-sys.
>
>>There is, a little further on:
>
>>|If the control-flow stack is implemented using the data stack,
>>|colon-sys shall be the topmost item on the data stack.
>
Certainly, the xt does not reside on the control-flow stack.
> So it isn't
>claiming that the xt is sitting under the colon-sys.
xt is on the data stack. If colon-sys is on the data stack, it must
be topmost, and xt must sit beneath it.
> I strongly doubt that
>a system that put the xt on the stack when ; executes,
I'm getting tired of hypothetical systems.
> would be declared
>nonstandard.
I declare that system non-standard. Satisfied?
jonah thomas
>> I strongly doubt that
>>a system that put the xt on the stack when ; executes,
>I'm getting tired of hypothetical systems.
OK. Let me put it this way. From the draft standard:
----------------
3.1.5.1 System-compilation types
These data types denote zero or more items on the control-flow stack (see
3.2.3.2). The possible presence of such items on the data stack means that
any items already there shall be unavailable to a program util the
control-flow-stack items are consumed.
-----------------
"Shall be unavailable" says directly that a standard program cannot access
them. If you use a trick to access them anyway, you have at best an
environmental dependency and your code is not guaranteed to run on all
standard systems.
Still, code that does that can be quite portable, as most of the systems it
will fail on are hypothetical.
Anton Ertl
jeth...@ix.netcom.com (jonah thomas) writes:
>OK. Let me put it this way. From the draft standard:
>
>----------------
>3.1.5.1 System-compilation types
>
>These data types denote zero or more items on the control-flow stack (see
>3.2.3.2). The possible presence of such items on the data stack means that
>any items already there shall be unavailable to a program util the
>control-flow-stack items are consumed.
>-----------------
Yes, that's the kind of argument that makes sense.
>"Shall be unavailable" says directly that a standard program cannot access
>them.
Yes, if the sentence said just that, there would be no doubt.
However, this is also written like an informative sentence ("X means
that Y", "Since X, Y"), so there is some doubt. If such sentences are
intended as normative, it would be clearer to write them that way
(i.e., "Y"). In the present case, that would mean replacing
|The possible presence of such items on the data stack means that
|any items already there shall be unavailable to a program util the
|control-flow-stack items are consumed.
with
|Any items on the data stack shall be unavailable to a program until
|the control-flow-stack items are consumed.
- anton
jonah thomas
>>----------------
>>3.1.5.1 System-compilation types
>>These data types denote zero or more items on the control-flow stack (see
>>3.2.3.2). The possible presence of such items on the data stack means that
>>any items already there shall be unavailable to a program util the
>>control-flow-stack items are consumed.
>>-----------------
>Yes, that's the kind of argument that makes sense.
>>"Shall be unavailable" says directly that a standard program cannot access
>>them.
>Yes, if the sentence said just that, there would be no doubt.
>However, this is also written like an informative sentence ("X means
>that Y", "Since X, Y"), so there is some doubt.
The way Elizabeth Rather explained it to me (restated in my own words),
standards language uses a special meaing for "shall". When a standard says
"may" it means the event is allowed to happen. You can do it if it's
something for you to do, or you can't depend on it to happen or not happen
if it's something somebody else does. When a standard says "shall" then
it's required -- you can't assume the other way at all, if it's something
for you to do then you mustn't do it.
My oh-so-reasonable interpretation here is that standard systems are not
actually required to make the xt unavailable because standard programs are
not allowed to get it. "It doesn't matter whether you show me provided I
don't look."
Now, I see two types of nonstandard code. There's code that requires a
nonstandard system to run. If you need DUP to actually execute DROP then
you can't do it with a system that's standard at the moment. Then there's
code that requires system behavior that the standard doesn't specify one way
or the other. If you do an interpreted IF then your program is nonstandard
but it will run on some systems but not others.
This looks like the second sort to me. If you simply assume that "sys" data
is not on the stack, your code will run on some systems. If you check the
depth and PICK your data from the right spot, your code will run on more
systems. If you wait until ; removes the colon-sys then this particular
standards issue goes away completely.
So if the issue is portability as opposed to splitting hairs about the
standard, the DEPTH technique is very portable and routines that use it have
an environmental dependency. If somebody went to court about whether it was
standard code and the standards committee got called as witnesses to decide,
I'm not sure whether they'd say it was an environmental dependency or
nonstandard code, but the portability question comes out the same either
way.
Anton Ertl
jeth...@ix.netcom.com (jonah thomas) writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>Yes, if the sentence said just that, there would be no doubt.
>>However, this is also written like an informative sentence ("X means
>>that Y", "Since X, Y"), so there is some doubt.
>
>The way Elizabeth Rather explained it to me (restated in my own words),
>standards language uses a special meaing for "shall".
> When a standard says "shall" then
>it's required -- you can't assume the other way at all, if it's something
>for you to do then you mustn't do it.
Yes, I know about that.
My point was this: It might be required (a) in an axiomatic way, or it
might be required because (b) it follows from some other requirement.
Now a sentence like "X means that Y" (where Y may contain "shall")
reads like a case of (b); because if you want (a), you write the
sentence like this: "Y".
In the present case Y does not follow from X. The whole sentence may
just be an error; the author may have thought that Y follows from X
and that might have been why he/she wrote "X means that Y", but he/she
was wrong. So this leaves doubt whether Y holds, even if it contains
"shall".
>My oh-so-reasonable interpretation here is that standard systems are not
>actually required to make the xt unavailable
Certainly. On the contrary, since there is doubt, a system
implementor could make sure his system is standard by avoiding ?CSP
and other implementation techniques that do not work with programs
that use Douglas Atique's technique.
> If somebody went to court about whether it was
>standard code and the standards committee got called as witnesses to decide,
>I'm not sure whether they'd say it was an environmental dependency or
>nonstandard code, but the portability question comes out the same either
>way.
They might even say that it is standard code. Statements by some TC
members make me doubtful, but it wouldn't be the first time that a TC
member said one thing and the TC said another thing.
m_l...@my-deja.com
>
> In article <89rglv$rg_...@ix.netcom.com>,
> jeth...@ix.netcom.com (jonah thomas) writes:
> >an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >>Yes, if the sentence said just that, there would be no doubt.
> >>However, this is also written like an informative sentence ("X means
> >>that Y", "Since X, Y"), so there is some doubt.
> >
> >The way Elizabeth Rather explained it to me (restated in my own words),
> >standards language uses a special meaing for "shall".
> ...
> > When a standard says "shall" then
> >it's required -- you can't assume the other way at all, if it's something
> >for you to do then you mustn't do it.
>
> Yes, I know about that.
>
> My point was this: It might be required (a) in an axiomatic way, or it
> might be required because (b) it follows from some other requirement.
> Now a sentence like "X means that Y" (where Y may contain "shall")
> reads like a case of (b); because if you want (a), you write the
> sentence like this: "Y".
>
> In the present case Y does not follow from X. The whole sentence may
> just be an error; the author may have thought that Y follows from X
> and that might have been why he/she wrote "X means that Y", but he/she
> was wrong. So this leaves doubt whether Y holds, even if it contains
> "shall".
I agree.
Can we formulate it in the form
"A standard program shall not access ..."?
(We should, but a rake lies here:
"A standard program shall not access data stack items that might be
buried
beneath control-flow stack items on a system which uses the data stack
to implement the contro-flow-stack" [as if these data stack items
are actually buried beneath them or lifted ( DEPTH 1- -ROLL ) by them]
I know that there is no such modality in the standard language as
"might"
or "as if".
"A standard program shall not access data stack items above (or below)
which control-flow-stack elements may be placed on a system that
uses the data stack to implement the contro-flow-stack until these
control-flow stack elements are consumed."
"These data types denote zero or more items on the control-flow stack.
The possible presence of such items on the data stack means that any
items already there shall be unavailable to a program until the
control-flow-stack items are consumed."
BTW, the standard says nothing about
: ha-ha! IF [ 5 ] THEN LITERAL ;
According to the standard, the above definition must be allowed
and equivalent to DROP 5 .
(presence of data items above control-flow stack items is
not mentioned.)
"These data types denote zero or more items on the control-flow stack.
The items that logically belong to the control-flow stack and
to the data stack may physically reside on the same stack.
A standard program shall not access items of one sort when the
state of this stack may be changed by placing items of the other
sort onto it.
The items of the first sort that were available before placing
the items of the other sort on the stack will be again available
when the items of the other sort are consumed".
)
Any idea?
>
> >My oh-so-reasonable interpretation here is that standard systems are not
> >actually required to make the xt unavailable
>
> Certainly. On the contrary, since there is doubt, a system
> implementor could make sure his system is standard by avoiding ?CSP
> and other implementation techniques that do not work with programs
> that use Douglas Atique's technique.
A system implementor may be a group of people that have lots of
application code that uses CSP. Which one do you think they
will choose:
a) compatibility with hypothetical systems, or
b) compatibility with their own code?
(Rhetorical question, in the typical case the_answer=b)
Neal Bridges
"m_l...@my-deja.com" <m_l...@my-deja.com> wrote:
> BTW, the standard says nothing about
>
> : ha-ha! IF [ 5 ] THEN LITERAL ;
>
> According to the standard, the above definition must be allowed
> and equivalent to DROP 5 .
> (presence of data items above control-flow stack items is
> not mentioned.)
That is not an allowable construct.
Here are the two relevant quotes:
"3.2.3.2 ... If [the control-flow stack] does exist, it may be, but need
not be, implemented using the data stack."
"6.1.2270 THEN CORE
...
Compilation: ( C: orig -- )"
THEN must find 'orig' on top of the control-flow stack, if the
control-flow stack exists. Because the control-flow stack may exist in
a Standard implementation, and because it may be implemented using the
data stack, placing additional items on the data stack as per your
example would in such cases block the 'orig', and so your construct is
not allowed by the Standard. There may be systems on which it would
work, but a Standard program cannot assume it.
--
Neal Bridges
<http://www.quartus.net/> Quartus Handheld Software!
Sent via Deja.com http://www.deja.com/
Before you buy.
m_l...@my-deja.com
:3.1.5.1
: System-compilation types
:These data types denote zero or more items
:on the control-flow stack (see 3.2.3.2). The
:possible presence of such items on the data
:stack means that any items already there shall
:be unavailable to a program until the
:control-flow-stack items are consumed.
: ha! [ 5 ] IF THEN ; CONSTANT five
Below I show the stack states; "D" labels the
data stack states, "C" is for control-flow stack,
and "C=D" is what may be on a system where
both stacks are the same.
: ( C: "<spaces>name" -- colon-sys )
\ C: colon-sys
\ C=D: colon-sys
[ 5 ] ( -- 5 )
\ C: colon-sys
\ D: 5
\ C=D: colon-sys 5
IF ( C: -- orig )
"any items already there" (namely, 5)
"shall be unavailable
to a program until the control-flow-stack
items are consumed"
*** a standard system shall stash 5 below the
*** first control-flow stack item
\ C: colon-sys orig
\ D: 5
\ C=D: 5 colon-sys orig
THEN ( C: orig -- )
\ C: colon-sys
\ D: 5
\ C=D: 5 colon-sys
; ( C: colon-sys -- )
\ C:
\ D: 5
\ C=D: 5
CONSTANT five
\ C:
\ D:
Neal Bridges wrote:
>
> In article <38C35F99...@my-deja.com>,
> "m_l...@my-deja.com" <m_l...@my-deja.com> wrote:
> > BTW, the standard says nothing about
> >
> > : ha-ha! IF [ 5 ] THEN LITERAL ;
>
> That is not an allowable construct.
PS My system, which I believe is standard, does not
allow it. I am trying to show that this
unclear place actually requires something that
could not be really intended.
What do you think, if we do not know
what most Forths are, do I interpret the text of
the standard correctly?
It is absurd from the common sense viewpoint,
but is it formally correct?
Neal Bridges
Here's where I stop following you. I do not understand 3.1.5.1 to in any
way mean that a Standard system will somehow float all control-flow stack
items up from under whatever you happen to have arbitrarily dumped on top of
them. That is a strange interpretation indeed. If you were right, then
: foo [ 5 ] ;
would at any rate fail on any system where the control-flow stack is shared
with the data stack; the difference in this example being that there is no
additional control-flow item (such as an IF) which would, in your
interpretation, make the system magically float the colon-sys to the top of
the stack for the semicolon to resolve.
If you truly believe that your interpretation might be valid, I suggest you
appeal directly to the TC for a clarification.
If you have some need to generate data on the data-stack during a
definition, and have it available after that definition terminates, stuff it
in a variable during the definition.
VARIABLE x
: strange IF [ 5 x ! ] THEN ; x @ .
This technique will work consistently on any Standard system.
--
Neal Bridges
<http://www.quartus.net> Quartus Handheld Software!
m_l...@my-deja.com
|3.1.5.1
| System-compilation types
|These data types denote zero or more items on
|the control-flow stack (see 3.2.3.2). The
|possible presence of such items on the data
|stack means that any items already there shall
|be unavailable to a program until the
|control-flow-stack items are consumed.
is bad, because:
1) It is unclear that the !CSP ... ?CSP approach
is valid. (Before telling me that you disagree,
and colon-sys is in no way CSP , please, read
the following item).
2) It is unclear that colon-sys may be bound to
some specific stack depth and may become invalid
when the stack depth changes.
3) It is possible to understand
"until *the* control-flow-stack items are consumed" as
"until *all* control-flow-stack items are consumed".
In fact, this interpretation,
"the" = "all"
is more natural than something else, including the
intended interpretation
"the" = "only those placed above the mentioned data stack item(s)".
Let us be brief; I delete the rest of my reply.
Neal Bridges
The intent of the TC is clear to me here; they are not suggesting some
complicated operation wherein data stack items are levitated from below
each time a control-flow item is placed on the data stack.
For systems where the data stack is also the control-flow stack, it is
not transparently so; control-flow stack items are in the way until they
are consumed. That is the point of this section of the Standard, to
make it clear that when the stack is shared, the items are intermingled
in last-in-first-out order -- it is not transparent to the developer.
Stated more simply, if you put a number on the data-stack, and then put
a control-flow stack item on the stack (by starting a control
structure), the number is unavailable to a Standard application until
the control-flow stack item is consumed. Not "all control-flow stack
items", just the ones in the way.
If you're desperate to get at numbers below control-flow stack items,
you can do so in painful fashion by recording the stack depth at the
time you place the items there, and PICK them when you need them. This
would be awkward and ugly, however, and I cannot think of a situation
where it would be either necessary or desireable.
Again, if you question the TC's intent in this matter, apply for a
clarification.
Anton Ertl
"m_l...@my-deja.com" <m_l...@my-deja.com> writes:
>Anton Ertl wrote:
>BTW, the standard says nothing about
>
>: ha-ha! IF [ 5 ] THEN LITERAL ;
|6.1.2270 THEN
|...
|Compilation: ( C: orig -- )
|...
Since the orig can reside on the data stack, THEN could find 5 instead
of the orig.
However, I think this would be easier to explain if the standard used
a unified notation; moreover, that would also simplify the formulation
of ":NONAME": ( -- xt colon-sys ) (no need for "If the control-flow
stack is implemented using the data stack").
There would be some restrictions necessary to allow implementation on
other stacks, though.
>> Certainly. On the contrary, since there is doubt, a system
>> implementor could make sure his system is standard by avoiding ?CSP
>> and other implementation techniques that do not work with programs
>> that use Douglas Atique's technique.
>
>A system implementor may be a group of people that have lots of
>application code that uses CSP. Which one do you think they
>will choose:
>a) compatibility with hypothetical systems, or
I don't think that's the question. The question for a system
implementor is whether his system is compatible with programs.
>b) compatibility with their own code?
Their own code using CSP will generally have no problem if the
system's ";" does not call ?CSP anymore, so the system would stay
compatible with such code when doing that change.