In discussions about STATE and STATE-smart words, some participants
have wanted to use STATE as an indicator that there is a current colon >definition, and sometimes even claimed that these two concepts are >indistinguishable.
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
In article <2023Jul3...@mips.complang.tuwien.ac.at>
logging-data="3388010"; mail-complaints-to="ab...@eternal-september.org"; posting-account="U2FsdGVkX19U9e2GCi3j0Kqk85RvPmu8",
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
In discussions about STATE and STATE-smart words, some participantsI am a proponent of diminishing the ubiquitiness of STATE.
have wanted to use STATE as an indicator that there is a current colon >definition, and sometimes even claimed that these two concepts are >indistinguishable.
There is no reason STATE should be inspected in number, or string
or character or lambda denotations (although I do it at present in
ciforth) for they signal their presence by leaving something
on the stack.
As an alternative [ ] are only used to inform the INTERPRET word to do interpreting or compiling. As soon as a word (e.g. a prefix & that
leaves a character ) leaves something on the stack in compile state
INTERPRET detects this and compiles it as a literal.
Obviously a word can only leave something on the stack while
compiling, if that word is immediate. The data stack can no
longer be used as a compilation stack, so the compilation
stack has to be separate.
So ] [ are messages to the INTERPRET object. If the word STATE
exists, it is only present in the implementation of these three
words.
Those ideas has inspired ciforth to restrict STATE to
] [ INTERPRET LITERAL DLITERAL
none albert schrieb am Montag, 31. Juli 2023 um 16:45:46 UTC+2:
In article <2023Jul3...@mips.complang.tuwien.ac.at>
logging-data="3388010"; mail-complaints-to="ab...@eternal-september.org"; posting-account="U2FsdGVkX19U9e2GCi3j0Kqk85RvPmu8",
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
In discussions about STATE and STATE-smart words, some participantsI am a proponent of diminishing the ubiquitiness of STATE.
have wanted to use STATE as an indicator that there is a current colon
definition, and sometimes even claimed that these two concepts are
indistinguishable.
There is no reason STATE should be inspected in number, or string
or character or lambda denotations (although I do it at present in
ciforth) for they signal their presence by leaving something
on the stack.
As an alternative [ ] are only used to inform the INTERPRET word to do
interpreting or compiling. As soon as a word (e.g. a prefix & that
leaves a character ) leaves something on the stack in compile state
INTERPRET detects this and compiles it as a literal.
Obviously a word can only leave something on the stack while
compiling, if that word is immediate. The data stack can no
longer be used as a compilation stack, so the compilation
stack has to be separate.
So ] [ are messages to the INTERPRET object. If the word STATE
exists, it is only present in the implementation of these three
words.
Those ideas has inspired ciforth to restrict STATE to
] [ INTERPRET LITERAL DLITERAL
IMO the standard over-restricts STATE to be a binary flag.
It is trivial to extend it to an integer i.e. a multi-value flag
and encode different compilation environments of [ or ] et al
This would be somewhat similar to "messages to the interpreter".
In discussions about STATE and STATE-smart words, some participants
have wanted to use STATE as an indicator that there is a current colon definition, and sometimes even claimed that these two concepts are indistinguishable. The existence of [ and ] means that you can have
interpret state while there is a current definition, and you can have
compile state while there is no current colon definition. E.g.
: foo [ ' + compile, ] ;
] + [
The first line compiles "+" in interpret state while the definition of
FOO is current.
The second line compiles "+" while there is no current colon
definition.
In development Gforth the system now knows whether there is a current
colon definition, and produces warnings accordingly:
: foo [ ' + compile, ] ; ok
] + [
*terminal*:3:3: warning: Compiling outside a definition ok
Gforth still compiles code in the latter case, so you cannot use
create bar ] + - [
instead of
create bar ' + , ' - ,
as in the ITC days (except if you use gforth-itc).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023
none albert schrieb am Montag, 31. Juli 2023 um 16:45:46 UTC+2:mail-complaints-to="ab...@eternal-september.org"; >posting-account="U2FsdGVkX19U9e2GCi3j0Kqk85RvPmu8",
In article <2023Jul3...@mips.complang.tuwien.ac.at>
logging-data="3388010";
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
In discussions about STATE and STATE-smart words, some participantsI am a proponent of diminishing the ubiquitiness of STATE.
have wanted to use STATE as an indicator that there is a current colon >>>> definition, and sometimes even claimed that these two concepts are
indistinguishable.
There is no reason STATE should be inspected in number, or string
or character or lambda denotations (although I do it at present in
ciforth) for they signal their presence by leaving something
on the stack.
As an alternative [ ] are only used to inform the INTERPRET word to do
interpreting or compiling. As soon as a word (e.g. a prefix & that
leaves a character ) leaves something on the stack in compile state
INTERPRET detects this and compiles it as a literal.
Obviously a word can only leave something on the stack while
compiling, if that word is immediate. The data stack can no
longer be used as a compilation stack, so the compilation
stack has to be separate.
So ] [ are messages to the INTERPRET object. If the word STATE
exists, it is only present in the implementation of these three
words.
Those ideas has inspired ciforth to restrict STATE to
] [ INTERPRET LITERAL DLITERAL
IMO the standard over-restricts STATE to be a binary flag.
It is trivial to extend it to an integer i.e. a multi-value flag
and encode different compilation environments of [ or ] et al
This would be somewhat similar to "messages to the interpreter".
Anyone who has developed a forth will likely have an idea or two how
things could be improved. The TC restricted many things with the aim
of securing general support. ISTM this leaves prospective designers
with two options: risk fragmenting what support still exists for a
standard - or leave for the sake of it and their own sanity.
In article <uacgle$3udtr$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
On 2/08/2023 4:42 am, minforth wrote:I hope it is clear that I want to go on the other direction.
none albert schrieb am Montag, 31. Juli 2023 um 16:45:46 UTC+2:mail-complaints-to="ab...@eternal-september.org";
In article <2023Jul3...@mips.complang.tuwien.ac.at>
logging-data="3388010";
posting-account="U2FsdGVkX19U9e2GCi3j0Kqk85RvPmu8",
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
In discussions about STATE and STATE-smart words, some participantsI am a proponent of diminishing the ubiquitiness of STATE.
have wanted to use STATE as an indicator that there is a current colon >>>>> definition, and sometimes even claimed that these two concepts are
indistinguishable.
There is no reason STATE should be inspected in number, or string
or character or lambda denotations (although I do it at present in
ciforth) for they signal their presence by leaving something
on the stack.
As an alternative [ ] are only used to inform the INTERPRET word to do >>>> interpreting or compiling. As soon as a word (e.g. a prefix & that
leaves a character ) leaves something on the stack in compile state
INTERPRET detects this and compiles it as a literal.
Obviously a word can only leave something on the stack while
compiling, if that word is immediate. The data stack can no
longer be used as a compilation stack, so the compilation
stack has to be separate.
So ] [ are messages to the INTERPRET object. If the word STATE
exists, it is only present in the implementation of these three
words.
Those ideas has inspired ciforth to restrict STATE to
] [ INTERPRET LITERAL DLITERAL
IMO the standard over-restricts STATE to be a binary flag.
It is trivial to extend it to an integer i.e. a multi-value flag
and encode different compilation environments of [ or ] et al
This would be somewhat similar to "messages to the interpreter".
Anyone who has developed a forth will likely have an idea or two how
things could be improved. The TC restricted many things with the aim
of securing general support. ISTM this leaves prospective designers
with two options: risk fragmenting what support still exists for a
standard - or leave for the sake of it and their own sanity.
In the ciforth model STATE is absolutely standard, but its use
is discouraged. The last thing I want to do is assign other functions
to STATE.
The main reason we want to have STATE is ABORT" ." and some such.
The splitting of ." into ." and .(
and CHAR into CHAR and [CHAR]
and CTRL into CTRL and [CTRL]
S" is a pitfall.
The solution is to have strings delimited by double quotes that are
valid in execution and compilation mode, similar to what we are accustomed
to with numbers, and compatible with every sane computer language. Fortunately they have made it into the 2012 standard.
In discussions about STATE and STATE-smart words, some participants
have wanted to use STATE as an indicator that there is a current colon definition, and sometimes even claimed that these two concepts are indistinguishable. The existence of [ and ] means that you can have interpret state while there is a current definition, and you can have compile state while there is no current colon definition. E.g.
: foo [ ' + compile, ] ;
] + [
The first line compiles "+" in interpret state while the definition of
FOO is current.
The second line compiles "+" while there is no current colon
definition.
In my opinion, state is really for the compiler decide which action to carry out
next ie execute or compile.
No one foresaw that in the future someone would think ] + [ should produce an >answer.
I think such code falls under the umbrella of undefined behaviour anyway.
Should state mean there's a current definition being compiled ?
But given that Anton's asking I feel its a trick question.
NN <novembe...@gmail.com> writes:
In my opinion, state is really for the compiler decide which action to carry outIn a standard system it actually tells the text interpreter whether to perform the interpretation or compilation semantics of the
next ie execute or compile.
text-interpreted word.
The difference between what I wrote and what you wrote (or some other positions) has been the source of many discussions over the years.
No one foresaw that in the future someone would think ] + [ should produce anIt's not clear which future you have in mind. The technique
answer.
of writing
| create bar ] + - [
|
|instead of
|
| create bar ' + , ' - ,
has been used in indirect-threaded code systems and has been thought
of an explicitly rejected by Forth-94 ff.
I think such code falls under the umbrella of undefined behaviour anyway.In standard Forth, "ambiguous condition". But a high-quality Forth
system should still behave sensibly. A recent case, which actually
inspired this thread, uncovered that the following sequence
] drop [ : foo 100 ;
resulted in a corrupt FOO (in gforth-fast):
123 foo .s <1> 100
I.e., the "] drop [" influenced what is compiled in the colon
definition. Despite this (and the case that made us find the problem)
being ambiguous conditions, we still considered Gforth's behaviour a
bug, fixed it, and, in addition, added a warning when compiling code
outside a colon definition.
Should state mean there's a current definition being compiled ?No. Admittedly in most cases the compilation semantics of a word
compiles some code, so performing them outside a colon definition is
an ambiguous condition, but:
1) There are also standard words whose compilation semantics do not
compile some code, and you can add more such words. E.g.:
: foo ." foo" ; immediate
] foo [ \ prints "foo"
2) Just because we are in interpretation state does not mean that no
code is being compiled:
: bar postpone drop ;
bar
But given that Anton's asking I feel its a trick question.It seems to me that you were asking. I discussed and demonstrated the difference between the concepts, and your question has inspired me to
some more discussion and demonstrations.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023
IMO, this whole problem goes away if the input is always compiled, and then only executed if a word was not defined.4tH either compiles or executes. It doesn't have a dictionary. A program is like one huge word.
Of course, this approach is probably not "ANSI Compliant", but it works for me.I feel you, brother. But you can come pretty close.
In this world, there is no need for a STATE at all.Correct. There isn't even a STATE word in 4tH.
(I expect some people will have a problem with this ...).. tell me about it <sigh>..
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (3 / 13) |
Uptime: | 44:29:25 |
Calls: | 6,710 |
Calls today: | 3 |
Files: | 12,243 |
Messages: | 5,354,110 |