You can restrict knowledge of STATE to the read/interpret loop.
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
--
Ruvim
In article <tkffsc$1ntf$1...@dont-email.me>, Ruvim <ruvim...@gmail.com> wrote:
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a wordYou can add a word COMPILATION? to the interpret object.
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean, >without the word "state").
That would be an addition to the kernel and require recompilation.
That is cheating, so no.
In article <tkffsc$1ntf$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
You can add a word COMPILATION? to the interpret object.
That would be an addition to the kernel and require recompilation.
That is cheating, so no.
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
none albert schrieb am Mittwoch, 9. November 2022 um 11:03:07 UTC+1:
In article <tkffsc$1ntf$1...@dont-email.me>, Ruvim <ruvim...@gmail.com> wrote:
On 2022-11-08 11:45, albert wrote:You can add a word COMPILATION? to the interpret object.
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
That would be an addition to the kernel and require recompilation.
That is cheating, so no.
Kill STATE and you have to recompile as well.
Let COMPILATION? check whether there is a colon-sys on stack.
On 09/11/2022 06:03, Ruvim wrote:[...]
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
One solution
0 value st
: compilation -1 to st s" 0 to st" evaluate st ; immediate
On 09/11/2022 06:03, Ruvim wrote:[...]
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
One solution
0 value st
: compilation -1 to st s" 0 to st" evaluate st ; immediate
Yes! Though, I mean an ordinary word (particularly, not immediate).
A variant without an additional variable:
: compilation ( -- flag )
-1 s" 0" evaluate dup if ['] drop compile, exit then nip
;
Probably, according to the next version of the standard it should be
wrapped by "catch", since a system will be obligated to throw an
exception if a program appends something to an absent current definition
(due to the "remove ambiguous conditions" movement).
: compilation ( -- flag )
[: -1 s" 0" evaluate dup if ['] drop compile, exit then nip ;]
catch if -1 then
\ actually, a particular throw code should be tested
;
There is another standard-compliant solution.
And yet another solution based on a system-specific method of creating >dual-semantics words (if any).
----
Ruvim
In article <tkja0s$iqu2$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
On 2022-11-10 12:19, Gerry Jackson wrote:
On 09/11/2022 06:03, Ruvim wrote:[...]
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
One solution
0 value st
: compilation -1 to st s" 0 to st" evaluate st ; immediate
Yes! Though, I mean an ordinary word (particularly, not immediate).
A variant without an additional variable:
: compilation ( -- flag )
-1 s" 0" evaluate dup if ['] drop compile, exit then nip
;
Probably, according to the next version of the standard it should be
wrapped by "catch", since a system will be obligated to throw an
exception if a program appends something to an absent current definition
(due to the "remove ambiguous conditions" movement).
: compilation ( -- flag )
[: -1 s" 0" evaluate dup if ['] drop compile, exit then nip ;]
catch if -1 then
\ actually, a particular throw code should be tested
;
There is another standard-compliant solution.
And yet another solution based on a system-specific method of creating
dual-semantics words (if any).
Very clever. Now make a state smart word with that.
Such as:
: ."
POSTPONE " STATE @ IF
['] TYPE COMPILE, ELSE TYPE THEN
; IMMEDIATE
I admit that you come close at detecting the compilation state of Forth.
[My point was that you don't need the STATE variable at all, not start
a puzzle marathon.]
On 2022-11-10 17:51, albert wrote:
In article <tkja0s$iqu2$1@dont-email.me>, Ruvim
<ruvim.pinka@gmail.com> wrote:
On 2022-11-10 12:19, Gerry Jackson wrote:
On 09/11/2022 06:03, Ruvim wrote:
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean, >>>>> without the word "state").
I admit that you come close at detecting the compilation state of Forth.
[My point was that you don't need the STATE variable at all, not start
a puzzle marathon.]
Literally, your said that one *can* restrict knowledge of STATE to the read/interpret loop.
And I have demonstrated that it's technically impossible to hide this knowledge from a program (i.e., the knowledge whether the system in interpretation state on in compilation state).
Gerry Jackson also has provided a solution. It seems, some people here
like Forth-puzzles, after all :)
On 2022-11-10 12:19, Gerry Jackson wrote:
On 09/11/2022 06:03, Ruvim wrote:[...]
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
One solution
0 value st
: compilation -1 to st s" 0 to st" evaluate st ; immediate
Yes! Though, I mean an ordinary word (particularly, not immediate).
A variant without an additional variable:
: compilation ( -- flag )
-1 s" 0" evaluate dup if ['] drop compile, exit then nip
;
Probably, according to the next version of the standard it should be
wrapped by "catch", since a system will be obligated to throw an
exception if a program appends something to an absent current definition
(due to the "remove ambiguous conditions" movement).
: compilation ( -- flag )
[: -1 s" 0" evaluate dup if ['] drop compile, exit then nip ;]
catch if -1 then
\ actually, a particular throw code should be tested
;
There is another standard-compliant solution.
On 10/11/2022 16:48, Ruvim wrote:
On 2022-11-10 12:19, Gerry Jackson wrote:
On 09/11/2022 06:03, Ruvim wrote:[...]
On 2022-11-08 11:45, albert wrote:
You can restrict knowledge of STATE to the read/interpret loop.
In Forth, it's always possible to define a word
compilation ( -- flag )
that returns a flag whether the system in compilation state (I mean,
without the word "state").
One solution
0 value st
: compilation -1 to st s" 0 to st" evaluate st ; immediate
Yes! Though, I mean an ordinary word (particularly, not immediate).
Well you didn't state that :)
A non-immediate word won't pass the test I did - it won't even compile
: foo compilation literal . ;
So to be useful a non-immediate COMPILATION has to be called inside an immediate word that tests the output of COMPILATION such as your later definition of ." (similarly CS-PICK and CS-ROLL have to be called in an immediate word).
Removing IMMEDIATE from my definition of COMPILATION also works in your definition of ."
A variant without an additional variable:
: compilation ( -- flag )
-1 s" 0" evaluate dup if ['] drop compile, exit then nip
;
Yes that's a better definition
Probably, according to the next version of the standard it should be
wrapped by "catch", since a system will be obligated to throw an
exception if a program appends something to an absent current
definition (due to the "remove ambiguous conditions" movement).
: compilation ( -- flag )
[: -1 s" 0" evaluate dup if ['] drop compile, exit then nip ;]
catch if -1 then
\ actually, a particular throw code should be tested
;
That suggests another standard-compliant solution (abusing the CATCH ... THROW concept!):
: compilation [: s" 99 throw" evaluate ;] catch 0= ;
: foo compilation ; immediate
: bar foo [ . ] ; -1 ok
foo . 0 ok
Although, when interpreting, some systems (e.g. SwiftForth) display "99 throw" as an error.
That seems to me undesirable if not non-standard
behaviour when a program handles the THROW code.
There is another standard-compliant solution.
Is that the above solution?
...
Literally, your said that one *can* restrict knowledge of STATE to the read/interpret loop.
And I have demonstrated that it's technically impossible to hide this knowledge from a program (i.e., the knowledge whether the system in interpretation state on in compilation state).
Gerry Jackson also has provided a solution. It seems, some people here like Forth-puzzles, after all :)
On 10/11/2022 16:48, Ruvim wrote:
Probably, according to the next version of the standard it should be
wrapped by "catch", since a system will be obligated to throw an
exception if a program appends something to an absent current
definition (due to the "remove ambiguous conditions" movement).
: compilation ( -- flag )
[: -1 s" 0" evaluate dup if ['] drop compile, exit then nip ;]
catch if -1 then
\ actually, a particular throw code should be tested
;
That suggests another standard-compliant solution (abusing the CATCH ... THROW concept!):
: compilation [: s" 99 throw" evaluate ;] catch 0= ;
: foo compilation ; immediate
: bar foo [ . ] ; -1 ok
foo . 0 ok
Although, when interpreting, some systems (e.g. SwiftForth) display "99 throw" as an error.It should be so on any system. Since this "compilation" produces a side effect for the current definition in compilation state, it appends the execution semantics of "99 throw".
So, this variant is incorrect.
That seems to me undesirable if not non-standardIn compilation state it is not handled (caught), but compiled. So this
behaviour when a program handles the THROW code.
"bar" is equivalent to:
: bar 99 throw ;
There is another standard-compliant solution.
Is that the above solution?I thought about a totally different solution, that does not employ
"evaluate" or alike.
6.1.2250 says:
| Only the following standard words alter the value in STATE:
| : (colon), ; (semicolon), ABORT, QUIT, :NONAME, [ (left-bracket),
| ] (right-bracket).
And 15.6.2.2250 adds that ";CODE" also alter STATE.
So, it's enough to redefine these words (except "abort") in a standard program:
variable s
: compilation ( -- flag ) s @ ;
: ] ] s on ;
: :noname :noname s on ;
: : : s on ;
: [ s off postpone [ ; immediate
: ; s off postpone ; ; immediate
: quit s off quit ;
[defined] ;code [if]
: ;code s off postpone ;code ; immediate
[then]
Concerning "abort" — if the corresponding exception is caught by a
program, the STATE is not changed. If it is not caught, the program
loses control (i.e., it's effectively terminated).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 39:05:29 |
| Calls: | 6,708 |
| Calls today: | 1 |
| Files: | 12,241 |
| Messages: | 5,353,638 |