Request for interpretation answered
Elizabeth D Rather
interpretation" dealing with the issue of compiling while in interpret
state, which was so contentious here a few months ago. This was submitted
with a proposed answer to the TC as a letter ballot, which has passed with a
vote of 15/0/1/5 (yes/no/abstain/not voting). We are grateful to Philip for
his concise statement of the issue.
The ballot, including Philip's question and the TCs response, follows:
_____________________P R O P O S A L _______________________
Ratify the following Interpretation:
===== 1. Q99-027 as received. ======
From: Philip Preston [phi...@preston20.freeserve.co.uk]
Sent: Sat 17 Oct 98 14:44
To: gr...@minerva.com
Subject: RFI
Request for interpretation:
Recent discussions on comp.lang.forth indicate there is a body of opinion
which holds that one or both the following are implied by the ANSI Forth
Standard:
1. It is an ambiguous condition for a program to perform compilation
semantics in the interpretation state.
2. It is an ambiguous condition for a program to append semantics to the
current definition in the interpretation state.
For the avoidance of confusion could you please adjudicate on whether either
or both of these propositions are correct?
Note: "Performing compilation semantics" and "appending semantics to the
current definiton" frequently occur together but it is possible to have
either one without the other, hence the need to distinguish between them.
For example:
: (S POSTPONE ( ; IMMEDIATE
Execution of (S involves performing the compilation semantics of ( but does
not involve appending semantics to the current definition.
: APPEND-DUP ['] DUP COMPILE, ;
Execution of APPEND-DUP involves appending the execution semantics of DUP to
the current definition but does not involve performing compilation
semantics.
Thank you,
Philip Preston.
20 Warren Streeet, London W1P 5DD, U.K.
=========== 2. TC Reply to Q99-027. ===========
The answer to question (1.) is Yes.
The answer to question (2.) is Yes.
Brief discussion:
The TC recognizes that the terminology it used in 1994 to circumscribe
the usage of the Forth compiler by a standard program has led to some
significant misinterpretations of TC intent. The above answers state
the intent of the TC. The TC has plans to modify its terminology in
an effort to avoid future misinterpretations of this sort.
Since that plan exists, the TC does not wish to split hairs about the
meaning of "compilation semantics" at this time, expecting that issue
to become moot when that plan is implemented. The TC does, however,
with to state categorically that its original intent was to make it
clear that standard programs without environmental dependencies shall
not assume access to functions specific to the Forth compiler except
while actually in the compilation state. This remains the intent of
the TC today.
_________________ E N D P R O P O S A L ___________________
Regards to all,
Elizabeth D. Rather
Chair, NCITS/J14
Anton Ertl
A new numbering scheme? The answer probably also answers RFI 9 posed
by Bernd Paysan.
> 1. It is an ambiguous condition for a program to perform compilation
> semantics in the interpretation state.
>
> 2. It is an ambiguous condition for a program to append semantics to the
> current definition in the interpretation state.
...
> =========== 2. TC Reply to Q99-027. ===========
>
>
> The answer to question (1.) is Yes.
>
> The answer to question (2.) is Yes.
For those of us whose programs have been outlawed (de-ANSified,
acquired an environmental dependency, or whatever euphemisms the TC
chooses to use) by this decision, the simplest way to relegitimize
these programs is to include repair.fs from
http://www.complang.tuwien.ac.at/forth/combined.zip at the start of
the program.
I intend to check (and, if necessary, refine) this package with
respect to the new situation (originally, it was intended to fix
broken (now possibly standard-compliant) implementations).
> The TC recognizes that the terminology it used in 1994 to circumscribe
> the usage of the Forth compiler by a standard program has led to some
> significant misinterpretations of TC intent. The above answers state
> the intent of the TC. The TC has plans to modify its terminology in
> an effort to avoid future misinterpretations of this sort.
I found the current terminology enlightening. The problem is not the
terminology, but the fact that the TC did not put its intent in
writing. But it has now, so a change in terminology is unnecessary.
> Since that plan exists, the TC does not wish to split hairs about the
> meaning of "compilation semantics" at this time,
So the TC thinks that the meaning of "compilation semantics" is
unclear? Then what is the meaning of the question 1 and its answer?
> The TC does, however,
> with to state categorically that its original intent was to make it
> clear that standard programs without environmental dependencies shall
> not assume access to functions specific to the Forth compiler except
> while actually in the compilation state.
"Functions specific to the Forth compiler"? That's extremely
unclear. Please supply a definition.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Elizabeth D Rather
>> The TC recognizes that the terminology it used in 1994 to circumscribe
>> the usage of the Forth compiler by a standard program has led to some
>> significant misinterpretations of TC intent. The above answers state
>> the intent of the TC. The TC has plans to modify its terminology in
>> an effort to avoid future misinterpretations of this sort.
>
>I found the current terminology enlightening. The problem is not the
>terminology, but the fact that the TC did not put its intent in
>writing. But it has now, so a change in terminology is unnecessary.
>
>> Since that plan exists, the TC does not wish to split hairs about the
>> meaning of "compilation semantics" at this time,
>
>So the TC thinks that the meaning of "compilation semantics" is
>unclear? Then what is the meaning of the question 1 and its answer?
The TC thought at the time we wrote it it was very clear, but the fact
that this controversy arose and went on so long revealed to us that
it was flawed. It was our intent that "semantics" be a somewhat
more technical synonym for behavior. Therefore, what we mean
is that behavior that is defined as "compilation semantics" for
those definitions that have it is behavior that is supposed to take
place in compilation state (only).
>> The TC does, however,
>> with to state categorically that its original intent was to make it
>> clear that standard programs without environmental dependencies shall
>> not assume access to functions specific to the Forth compiler except
>> while actually in the compilation state.
>
>"Functions specific to the Forth compiler"? That's extremely
>unclear. Please supply a definition.
Functions described as "compilation semantics," meaning behavior
intended to occur only in compilation state.
Cheers,
Elizabeth
Charles Esson
Anton Ertl wrote:
> In article <7eluqb$hb0$1...@oak.prod.itd.earthlink.net>,
> "Elizabeth D Rather" <era...@forth.com> writes:
> > ===== 1. Q99-027 as received. ======
>
> A new numbering scheme? The answer probably also answers RFI 9 posed
> by Bernd Paysan.
>
> > 1. It is an ambiguous condition for a program to perform compilation
> > semantics in the interpretation state.
> >
> > 2. It is an ambiguous condition for a program to append semantics to the
> > current definition in the interpretation state.
> ...
> > =========== 2. TC Reply to Q99-027. ===========
> >
> >
> > The answer to question (1.) is Yes.
> >
> > The answer to question (2.) is Yes.
>
> For those of us whose programs have been outlawed (de-ANSified,
> acquired an environmental dependency, or whatever euphemisms the TC
> chooses to use) by this decision, the simplest way to relegitimize
> these programs is to include repair.fs from
> http://www.complang.tuwien.ac.at/forth/combined.zip at the start of
> the program.
>
> I intend to check (and, if necessary, refine) this package with
> respect to the new situation (originally, it was intended to fix
> broken (now possibly standard-compliant) implementations).
>
> > The TC recognizes that the terminology it used in 1994 to circumscribe
> > the usage of the Forth compiler by a standard program has led to some
> > significant misinterpretations of TC intent. The above answers state
> > the intent of the TC. The TC has plans to modify its terminology in
> > an effort to avoid future misinterpretations of this sort.
>
> I found the current terminology enlightening. The problem is not the
> terminology, but the fact that the TC did not put its intent in
> writing. But it has now, so a change in terminology is unnecessary.
>
> > Since that plan exists, the TC does not wish to split hairs about the
> > meaning of "compilation semantics" at this time,
>
> So the TC thinks that the meaning of "compilation semantics" is
> unclear? Then what is the meaning of the question 1 and its answer?
>
> > The TC does, however,
> > with to state categorically that its original intent was to make it
> > clear that standard programs without environmental dependencies shall
> > not assume access to functions specific to the Forth compiler except
> > while actually in the compilation state.
>
> "Functions specific to the Forth compiler"? That's extremely
> unclear. Please supply a definition.
>
Anton Ertl
> >> Since that plan exists, the TC does not wish to split hairs about the
> >> meaning of "compilation semantics" at this time,
> >
> >So the TC thinks that the meaning of "compilation semantics" is
> >unclear? Then what is the meaning of the question 1 and its answer?
>
>
> that this controversy arose and went on so long revealed to us that
> it was flawed.
It arose because the text of the standard did not reflect the intent
of the TC. Many people thought that the TC could not mean what the
text said (they were right). Some tried to find interpretations of
the text that would better reflect the intent of the TC, but none were
successful.
It went on so long because the TC took so long to answer the RFI (and
then the TC did not answer the original RFI (9), but a reformulated
version).
I don't see that this has anything to do with a flaw in the
terminology.
> Therefore, what we mean
> is that behavior that is defined as "compilation semantics" for
> those definitions that have it is behavior that is supposed to take
> place in compilation state (only).
...
> Functions described as "compilation semantics," meaning behavior
> intended to occur only in compilation state.
I take it that you mean that as a restriction of how compilation
semantics can be used in a standard program, not a new definition of
the term, overriding of the present definition of compilation
semantics (as present in 3.4.3.3 and various glossary entries).
Anton Ertl
Charles Esson <char...@cvs.com.au> writes:
> I have just one question Anton. Why don't you join the TC?
I don't live in the USA, and I spend too much time over the Atlantic
already. I probably would have, if an exclusively electronic
participation would be possible.
BTW, you don't need to quote the whole of my posting for that.
BobSmith4
and a member of the ANS Forth effort, I thought
that I was a nit-picker. After reading the numerous entries on this newsgoup,
I realize that I was just a piker, or babe-in-the-woods.
OTOH, I think it is a very good thing that you are all doing all the fine
detailed work at this point. It was frequently difficult to get people to put
the effort in the past.
Bob
Charles Esson
Anton Ertl wrote:
> In article <37113050...@cvs.com.au>,
> Charles Esson <char...@cvs.com.au> writes:
> > I have just one question Anton. Why don't you join the TC?
>
> I don't live in the USA, and I spend too much time over the Atlantic
> already. I probably would have, if an exclusively electronic
> participation would be possible.
Well I live in Australia, and I am still willing to put in the effort, and
rest assured the one trip to the US required will be far from the only reason I
visit the states this year ( and it takes 17 hours just to get to LA). Further
the meetings are being scheduled around interesting events.
Peter Knaggs lives in england.
No from where I sit, pretty lame.
Kindest regards
Charles Esson
Charles Esson
and are very capable. The TC is the place to slug it out. Not after the event.
It is my own view that FORTH should be tied down more. The issue in question
has been debated at length, but my final conclusion was simple, if the standard
was left as some had interpreted it, the value of STATE was considerable
reduced. There may or may not of been work arounds for all cases but that was
not the issue. You could not write a word and assume STATE was true when adding
to the dictionary unless the TC ruled as it did. But I accept it is the view of
one person, that's why there is a TC, so the outcome is dependent on the views
of many.
And I strongly agree with the TC the wording needs to be improved. But the same
problem with the ALGOL standard was the reason BNF was invented. It is
unfortunate there is no formal algebra for the concepts expressed by the FORTH
standard, but to my knowledge that is the way it is.
Anton Ertl wrote:
> In article <37113050...@cvs.com.au>,
> Charles Esson <char...@cvs.com.au> writes:
> > I have just one question Anton. Why don't you join the TC?
>
> I don't live in the USA, and I spend too much time over the Atlantic
> already. I probably would have, if an exclusively electronic
> participation would be possible.
>
> BTW, you don't need to quote the whole of my posting for that.
On this issue you can't keep people happy, some complain if you do some if you
don't.
The song with the verse:
I went to a garden party
I leant my lesson well
You can't please every one
So you might as well please yourself.
Sums up my sentiments well.
Regards Charles Esson
Anton Ertl
Charles Esson <char...@cvs.com.au> writes:
> It is my own view that FORTH should be tied down more. The issue in question
> has been debated at length, but my final conclusion was simple, if the standard
> was left as some had interpreted it, the value of STATE was considerable
> reduced.
The value of STATE in user programs is negative. See
@InProceedings{ertl98,
author = {M. Anton Ertl},
title = {\texttt{State}-smartness --- Why it is Evil and How
to Exorcise it},
booktitle = {EuroForth'98 Conference Proceedings},
year = {1998},
address = {Schlo\ss{} Dagstuhl},
url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
abstract = {\texttt{State}-smart words provide a number of unpleasant
surprises to their users. They are applied in two
contexts, and they fail in both: 1) for providing an
arbitrary combination of interpretation and
compilation semantics; 2) for optimizing with a
special implementation of the (default) compilation
semantics. This paper discusses these issues and
shows programmers and system implementors how to
avoid \texttt{state}-smart words. It also reports our
experiences in converting the \texttt{state}-smart
words in Gforth into a clean solution: little work
and few problems.}
}
> There may or may not of been work arounds for all cases but that was
> not the issue. You could not write a word and assume STATE was true when adding
> to the dictionary unless the TC ruled as it did.
So what? Give an example that shows that this is a problem.
> And I strongly agree with the TC the wording needs to be improved. But the same
> problem with the ALGOL standard was the reason BNF was invented. It is
> unfortunate there is no formal algebra for the concepts expressed by the FORTH
> standard, but to my knowledge that is the way it is.
The stack effect notation is at least as powerful as BNF:
@InProceedings{poeial94,
author = "Jaanus P{\"o}ial",
title = "Forth and Formal Language Theory",
crossref = "euroforth94",
pages = "47--52",
annote = "Shows that the stack effect notation is at least as
powerful as context-free grammars and that it is better
suited for specifying the syntax of Forth."
}
> Anton Ertl wrote:
> > BTW, you don't need to quote the whole of my posting for that.
>
> On this issue you can't keep people happy, some complain if you do some if you
> don't.
Nobody has asked me yet to post full quotes after my text, but I have
seen several complaints about this practice (and I have also written
some myself). Actually I don't remember anybody complaining about the
way I cite, so it seems I can keep people happy.
I also have not seen anybody complain yet about line lengths between
60 and 72 characters.
Charles Esson
Anton Ertl wrote:
> In article <37123F34...@cvs.com.au>,
> Charles Esson <char...@cvs.com.au> writes:
> > It is my own view that FORTH should be tied down more. The issue in question
> > has been debated at length, but my final conclusion was simple, if the standard
> > was left as some had interpreted it, the value of STATE was considerable
> > reduced.
>
> The value of STATE in user programs is negative. See
>
> @InProceedings{ertl98,
> author = {M. Anton Ertl},
> title = {\texttt{State}-smartness --- Why it is Evil and How
> to Exorcise it},
> booktitle = {EuroForth'98 Conference Proceedings},
> year = {1998},
> address = {Schlo\ss{} Dagstuhl},
> url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
> abstract = {\texttt{State}-smart words provide a number of unpleasant
> surprises to their users. They are applied in two
> contexts, and they fail in both: 1) for providing an
> arbitrary combination of interpretation and
> compilation semantics; 2) for optimizing with a
> special implementation of the (default) compilation
> semantics.
I seem to have no trouble. But I will read what you wrote before commenting. To my
mind the solution is to optimize an intermediate image, or as I have done the machine
code. But perhaps you have seen something I have not.
> This paper discusses these issues and
> shows programmers and system implementors how to
> avoid \texttt{state}-smart words. It also reports our
> experiences in converting the \texttt{state}-smart
> words in Gforth into a clean solution: little work
> and few problems.}
I can avoid pointers in C also, and there are those that would applaud me for my
efforts. Still doesn't change the underlying principle. Like it or not, STATE is part
of the language. The way I see it; you interpreted the spec in a particular way and
then started campaigning for language alterations that suited your interpretation.
I like STATE simple to use, simple to understand, Ok it's my view.
I will read the paper with interest. I just wish it was a HTML file instead of
.ps.gz. If ghostview can't read it I won't be able to take a look.
>
> }
>
> > There may or may not of been work arounds for all cases but that was
> > not the issue. You could not write a word and assume STATE was true when adding
> > to the dictionary unless the TC ruled as it did.
>
> So what? Give an example that shows that this is a problem.
There are areas in ANSI FORTH that cause far more problems that the lack or existence
of STATE. And I would be willing to wager that the set of problems that can be solved
with STATE available and STATE not available is pretty close.
I noted in you paper abstract you added the words "few problems" which would indicate
you are well aware of what the problems are and I don't have to waste time finding
them.
But it is not the issue, STATE is part of the language. As it is, and as you
obviously see the problems it causes if you interpreted the spec as you did, I have
another question.
Why did you interpret the language as you did and then start campaigning for the
removal of STATE, an obvious change to the intent of the specification?
I think it fair to say the original specification was not consistent, that should of
rang alarm bells.
>
>
> > And I strongly agree with the TC the wording needs to be improved. But the same
> > problem with the ALGOL standard was the reason BNF was invented. It is
> > unfortunate there is no formal algebra for the concepts expressed by the FORTH
> > standard, but to my knowledge that is the way it is.
>
> The stack effect notation is at least as powerful as BNF:
Yes.....and...... The problem; there is no formal algebra to define the areas where
FORTH treads and other language fear to go. The BNF specification for FORTH being
what it is, is next to useless.
A stack description of the keywords of most other languages would also be next to
useless ( and add unneeded constraints on implementation method).
Why the comment? I was noting the invention of BNF to define ALGOL. BNF is a very
elegant way to define ALGOL. We do not have a formal algebra to define FORTH, the
standard is a collection of english sentences that can be misinterpreted. Just as the
original ALGOL spec was misinterpreted.
>
>
> @InProceedings{poeial94,
> author = "Jaanus P{\"o}ial",
> title = "Forth and Formal Language Theory",
> crossref = "euroforth94",
> pages = "47--52",
> annote = "Shows that the stack effect notation is at least as
> powerful as context-free grammars and that it is better
> suited for specifying the syntax of Forth."
It would be an interesting read. Unfortunately writing something doesn't maker it
fact. The abstract basically say's calculus is at least as powerful as geometry, and
calculus is more suited to the manipulation of equations.
calculus and geometry deal with different problems.
BNF and stack descriptions deal with different problems.
I think however I am starting to see the direction of your argument.
BNF defines ALGOL well
Stack descriptions are as powerful as BNF .
therefor
Stack description define FORTH well.
Interesting.
Unfortunately I don't have access to the paper so I can't take it further. It would
be interesting to see how he compared the apple with the orange and came to that
conclusion that the apple is as useful as the orange.
Regards Charles
<snip irrelevent stuff>
Julian V. Noble
> Philip Preston submitted to NCITS/J14, the TC for ANS Forth, a "Request for
> interpretation" dealing with the issue of compiling while in interpret
> state, which was so contentious here a few months ago. This was submitted
> with a proposed answer to the TC as a letter ballot, which has passed with a
> vote of 15/0/1/5 (yes/no/abstain/not voting). We are grateful to Philip for
> his concise statement of the issue.
>
> The ballot, including Philip's question and the TCs response, follows:
>
> _____________________P R O P O S A L _______________________
>
> Ratify the following Interpretation:
>
>
> Sent: Sat 17 Oct 98 14:44
> To: gr...@minerva.com
> Subject: RFI
>
> Request for interpretation:
>
> Recent discussions on comp.lang.forth indicate there is a body of opinion
> which holds that one or both the following are implied by the ANSI Forth
> Standard:
>
> semantics in the interpretation state.
>
> 2. It is an ambiguous condition for a program to append semantics to the
> current definition in the interpretation state.
>
> or both of these propositions are correct?
>
> Note: "Performing compilation semantics" and "appending semantics to the
> current definiton" frequently occur together but it is possible to have
> either one without the other, hence the need to distinguish between them.
> For example:
>
> : (S POSTPONE ( ; IMMEDIATE
> Execution of (S involves performing the compilation semantics of ( but does
> not involve appending semantics to the current definition.
>
> : APPEND-DUP ['] DUP COMPILE, ;
> Execution of APPEND-DUP involves appending the execution semantics of DUP to
> the current definition but does not involve performing compilation
> semantics.
>
> Thank you,
>
> Philip Preston.
> 20 Warren Streeet, London W1P 5DD, U.K.
>
>
>
>
> The answer to question (1.) is Yes.
>
> The answer to question (2.) is Yes.
>
>
> The TC recognizes that the terminology it used in 1994 to circumscribe
> the usage of the Forth compiler by a standard program has led to some
> significant misinterpretations of TC intent. The above answers state
> the intent of the TC. The TC has plans to modify its terminology in
> an effort to avoid future misinterpretations of this sort.
>
> to become moot when that plan is implemented. The TC does, however,
> clear that standard programs without environmental dependencies shall
> not assume access to functions specific to the Forth compiler except
> the TC today.
> _________________ E N D P R O P O S A L ___________________
>
> Regards to all,
> Elizabeth D. Rather
> Chair, NCITS/J14
IMMEDIATE "appends semantics to a definition while in interpretation
state". Is this illegal or ambiguous?
More to the point, however, is the ability to split CREATE and DOES>
into separate words, as suggested by Morgenstern in a FD about 7 or 8
years ago, now ambiguous or illegal? I found it useful and easier to
define a jump-table compiler via
\ code to create jump tables
: | ' , ; \ add xt to data field
: case: create ;
: ;case does> swap cells + @ execute ;
used in the form
case: test | + | - | * | / ;case
32 4 0 test . 36 ok
32 4 1 test . 28 ok
32 4 2 test . 128 ok
32 4 3 test . 8 ok
Admittedly it would be easy to eliminate | and put everything into
one long, overly complicated word using an indefinite loop, but why
is that necessary or preferable?
So I guess I am asking whether the TC decision now invalidates
IMMEDIATE, not to mention factoring out the action of DOES>. So far
I have not found an ANS Forth that the latter causes a problem with, but
I am sure there is one... :-(
If I have correctly understood their reply to this RFI I would say the
new ukase states that IMMEDIATE and the factored DOES> are ambiguous,
although I find them clear.
It would be nice to know what language the TC will use to replace
"appends semantics" (which I interpret to mean, "the word does
something different now"). I would also like to know why it is
bad to "append semantics" during interpretation, which I believe
means "while STATE is set to FALSE".
--
Julian V. Noble
j...@virginia.edu
"Elegance is for tailors!" -- Ludwig Boltzmann
Anton Ertl
Charles Esson <char...@cvs.com.au> writes:
>
> Anton Ertl wrote:
> > This paper discusses these issues and
> > shows programmers and system implementors how to
> > avoid \texttt{state}-smart words. It also reports our
> > experiences in converting the \texttt{state}-smart
> > words in Gforth into a clean solution: little work
> > and few problems.}
> I can avoid pointers in C also, and there are those that would
> applaud me for my efforts.
If we want to compare to C, a comparable feature to STATE, both in
the ease and the benefit of avoiding it, is gets().
> Like it or not, STATE is part of the language.
So what? QUERY is part of the language, too. Still, you are wise to
avoid it.
> The way I
> see it; you interpreted the spec in a particular way and then
> started campaigning for language alterations that suited your
> interpretation.
I suggest reading what I wrote (search DejaNews for postings by me
containing "STATE-smart"). I don't want to redo the whole discussion
again.
As for campaigning for alterations, I would have been perfectly
satisfied if the answer to the RFI had just reaffirmed what the text
of the standard already said. However, I understood the concerns wrt
traditional implementations and proposed changes that would allow
STATE-smart implementations of S" and TO.
> I will read the paper with interest. I just wish it was a HTML file
> instead of .ps.gz. If ghostview can't read it I won't be able to
> take a look.
It can.
> > > There may or may not of been work arounds for all cases but that was
> > > not the issue. You could not write a word and assume STATE was true when adding
> > > to the dictionary unless the TC ruled as it did.
> >
> > So what? Give an example that shows that this is a problem.
> There are areas in ANSI FORTH that cause far more problems that the
> lack or existence of STATE.
Yes. The mere existence of STATE is not a problem. It's its use in
STATE-smart words.
And yes, e.g., BASE causes more problems, but the problems of
STATE-smartness are more insidious.
> And I would be willing to wager that the
> set of problems that can be solved with STATE available and STATE
> not available is pretty close.
Yes. Which is why your comparison with pointers in C was not
appropriate.
> I noted in you paper abstract you added the words "few problems"
> which would indicate you are well aware of what the problems are and
> I don't have to waste time finding them.
The "problems" in the abstract refer to those things that needed to be
changed when I changed all the STATE-smart stuff to cleaner
alternatives, but did not catch on the first pass. The most common
problem was the decision to report an error when ticking compile-only
words, and that change is not tied to eliminating STATE-smartness.
> Why did you interpret the language as you did and then start
> campaigning for the removal of STATE, an obvious change to the
> intent of the specification?
I did not campaign for the removal of STATE.
My interpretation followed from the text of the standard. Apparently
the TC agrees with this, because, in contrast to earlier answers, they
do not cite standard text in their answer to the RFI, but refer to the
committee's intent.
> I think it fair to say the original specification was not
> consistent, that should of rang alarm bells.
The original specification is consistent in this area. Gforth is an
example implementation of the original specification. However, the
original specification obviously does not reflect the intent of the
TC; that's why they changed it.
> > The stack effect notation is at least as powerful as BNF:
> Why the comment? I was noting the invention of BNF to define
> ALGOL. BNF is a very elegant way to define ALGOL. We do not have a
> formal algebra to define FORTH, the standard is a collection of
> english sentences that can be misinterpreted. Just as the original
> ALGOL spec was misinterpreted.
The stack effect notation is a formal algebra. It describes a part of
Forth. If we look at the portion of the language described formally,
it is larger for Forth than for Algol. Or at least it would be, if
the type rules were worked out better.
> > @InProceedings{poeial94,
> > author = "Jaanus P{\"o}ial",
> > title = "Forth and Formal Language Theory",
> > crossref = "euroforth94",
> > pages = "47--52",
> > annote = "Shows that the stack effect notation is at least as
> > powerful as context-free grammars and that it is better
> > suited for specifying the syntax of Forth."
> It would be an interesting read. Unfortunately writing something
> doesn't maker it fact. The abstract basically say's calculus is at
> least as powerful as geometry, and calculus is more suited to the
> manipulation of equations.
This is not the abstract, these are my annotations. Since you
probably have a hard time getting at the paper, here's what he does
(among other things): He shows how to transform a context-free grammar
into stack effect notation. Maybe you can reach him at
jaa...@cs.ut.ee, and he may be able to provide the paper.
> calculus and geometry deal with different problems.
> BNF and stack descriptions deal with different problems.
I thought so, too, until I read that paper.
<netcop>
You are getting pretty good at quoting, now how about attacking the
line length problem? I had to reformat your stuff manually to make it
readable.
</netcop>
Anton Ertl
j...@node4.unix.Virginia.EDU (Julian V. Noble) writes:
> "Elizabeth D Rather" writes:
> > 1. It is an ambiguous condition for a program to perform compilation
> > semantics in the interpretation state.
> >
> > 2. It is an ambiguous condition for a program to append semantics to the
> > current definition in the interpretation state.
> > The answer to question (2.) is Yes.
> I must say I am confused rather than enlightened. To me, the word
> IMMEDIATE "appends semantics to a definition while in interpretation
> state". Is this illegal or ambiguous?
I am not a TC member, so take my answer with a grain of salt:
No. The TC is referring to those places in the standard where it says
"append ... semantics to the current definition". I.e., the execution
semantics of "COMPILE,", the default compilation semantics of words,
and various other compilation semantics. Since compilation semantics
are already caught by 1., 2. is just there to outlaw code like:
: compile-this-and-that ( xt -- )
... compile, ... ;
: foo
... [ ' bar compile-this-and-that ] ... ;
> More to the point, however, is the ability to split CREATE and DOES>
> into separate words, as suggested by Morgenstern in a FD about 7 or 8
> years ago, now ambiguous or illegal?
No.
> I would also like to know why it is
> bad to "append semantics" during interpretation, which I believe
> means "while STATE is set to FALSE".
That's a good question. I have asked them several times to name an
implementation that has problems with this, but IIRC none was
mentioned.
Charles Esson
Anton Ertl wrote:
>
> I did not campaign for the removal of STATE.
>
I apologize but I am confused:
I say the TC had to rule as it did otherwise STATE has no meaning.
You say, so what STATE has no value.
I would like to ask another question. Why do you think the TC specified so carefully
which words could alter STATE, if there intent was to create something of little value?
And I do agree if you are allowed to compile when STATE is false it has little value.
Philip Preston
>> I think it fair to say the original specification was not
>> consistent, that should of rang alarm bells.
>
>The original specification is consistent in this area. Gforth is an
>example implementation of the original specification. However, the
>original specification obviously does not reflect the intent of the
>TC; that's why they changed it.
As far as I can see a consequence of this RFI response is that the
Standard is no longer consistent in this area. However this need not be
a cause of ambiguity since it is reasonable to infer that the RFI
response should take precedence over any statement in the main text of
the Standard that it appears to contradict.
Philip Preston.
Anton Ertl
Charles Esson <char...@cvs.com.au> writes:
> I say the TC had to rule as it did otherwise STATE has no meaning.
But you do not support this claim with arguments.
The meaning of STATE was and still is to determine whether the text
interpreter performs the interpretation or the compilation semantics
when it encounters a word.
This reminds me of another unsupported claim by you
(in <37123F34...@cvs.com.au>):
> You could not write a word and assume STATE was true when adding
> to the dictionary unless the TC ruled as it did.
This is interesting in that it claims that there are programs that
become standard by this decision of the TC. Until now I (and AFAIK
most others) thought that this question is one of legitimizing
systems/implementations at the cost of outlawing programs.
I challenged you to give an example, but you evaded the challenge. So
let me repeat: Please give an example of such a program, preferably
from real code, but something contrived would also bring light into
the issue.
> You say, so what STATE has no value.
More precisely, I wrote: The value of STATE in user programs is
negative. This refers to defining STATE-smart words.
> I would like to ask another question. Why do you think the TC
> specified so carefully which words could alter STATE, if there
> intent was to create something of little value?
Once we have STATE, we have to define explicitly which words change
it, just as with other global states.
So why did they provide STATE? Ask them. Probably for continuity.
Moreover, they may have a different idea of the value of STATE than I
do.
Ewald Pfau
JVN> I must say I am confused rather than enlightened. To me, the word
JVN> IMMEDIATE "appends semantics to a definition while in
JVN> interpretation state". Is this illegal or ambiguous?
I guess there is no reason for confusion in this point. IMMEDIATE
changes something, but does not append.
For your example: ...
JVN> : case: create ;
JVN> : ;case does> swap cells + @ execute ;
... I guess, it should not be under the hood of the recent RFI response
neither. It boils down to the question of the position where DOES> may
appear. Now, as it is part of the definition of ";case", so it occurs
when compiling.
Notation this way, or the other way:
: create-case: create DOES> swap cells + @ execute ;
lead both to the same question as you pose it. Performing ";case" (or
"create-case:") will neither append to a definition, nor perform
compilation semantics (as the RFI was about). Instead, DOES> has already
performed its compilation semantics while building of the definition
";case" (or "create-case:"). There-with, an 'initiation semantics' was
appended, when taking the ANS wording.
Ewald Pfau
to answer with 'yes' both of:
"DR> 1. It is an ambiguous condition for a program to perform
"DR> compilation semantics in the interpretation state.
"DR> 2. It is an ambiguous condition for a program to append
semantics
"DR> to the current definition in the interpretation state.
Since focussing on the result, this makes amongst others that point
clear, so that interpretation restrictions should not be by-passed by
mere redefinitions.
When recalling some recent debates, I see some points left, which maybe
cannot be solved with the precision as required in a standards
specification (plus merging all paths of interests and traditions):
An implementation may have compile-only words, plus words with different
behaviour for compilation and interpretation. Those may be completely
different words. An application written for the implementation may only
have immediate words. The same level of distinction as given to the
implementation may not be achieved. With state-smart words, one may go
half the way (on a path which has often be called ugly here). Maybe one
might recover the word RESTRICT again, which has been long in use (or
COMPILE-ONLY as input more recently).
The RFI wording has already 'append semantics to the current definition'
in it. But still, 'compilation state' is not coupled to any 'current
definition'. As a consequence, compilation state may be switched on
somewhere in the desert, any produced nonsense this way is not regarded
to be accessible, but this way of compilation is ok, though.
If this hole were closed, so there were other way round room for the
state of 'temporarily switched to interpretation state while appending
to a current definition', which is a slightly different kind than
'interpretation state' in general.
At least, the exception could hold then for COMPILE, (compile-comma) -
it looks reasonable in all instances, to allow to append to a current
definition with COMPILE, when in 'temporary interpretation state'. Now,
this were against the (nicely) clear wording in that response.