On 2021-04-25 11:32, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com
>> If you implement some tool (i.e. a word) with "state-smart" property,
>> you don't have any problem just because of this property, when you use
>> this word directly — i.e., when this word is encountered by the Forth
>> text interpreter.
> The implementor of a state-smart word has no problem. The users of a
> state-smart word sometimes have problems.
>> You can only face a problem when you apply Tick or POSTPONE to this
>> word. Most probably, POSTPONE.
> Also with tick and [COMPILE].
After the recent discussion about [COMPILE], I suggest to forget the
[COMPILE] word and never mention this word as an argument anymore :-)
This A0007 clarification shows (proves) that a standard *ordinary* word
(a word with default interpretation semantics and default compilation
semantics) cannot be implemented as in immediate word.
It's true, and nobody suggest such a thing for ordinary words.
But we talks about words that are *not ordinary*. So A0007 is not
relevant to our case.
Among non ordinary words, Tick is applicable to the only words that are
known to be immediate (the exception concerning S" is debated), and it
works as expected. So we don't have any problem with Tick, I think.
>> The reason is that you expect that POSTPONE guarantees compilation state
>> when the appended compilation semantics are performed. But your POSTPONE
>> doesn't guarantee that.
>> And the standard doesn't guarantees that. And according to the
>> clarifications, you may perform compilation semantics only in
>> compilation state (even if these semantics are a part of execution
>> semantics by means of POSTPONE).
> Which clarifications?
You should know, it was discussed many times. It's the official reply to
RFI by Philip Preston, Q99-027 [1,2]
The question was concerning correctness of the following propositions:
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.
TC Reply to Q99-027
The answer to question (1.) is Yes.
The answer to question (2.) is Yes.
The grounds for this decision are clear to me now.
The model of a standard Forth system is an abstraction over many
different implementations (see also the section C.4 of the standard,
concerning "inclusive nature of the standard").
Therefore the standard allows such implementations of some standard
words, and such implementations of immediate user defined words, that
it's just impossible to perform compilation semantics in interpretation
state in some cases.
And hence, a standard program, to work on any allowed implementation,
should fit all of them in the same time.
For example, the standard allows to implement "COMPILE," as the following
: compile, ( xt -- )
state @ if xt, exit then -14 throw ;
\ -14 "interpreting a compile-only word"
It's obvious that in such a system even the default compilation
semantics cannot be performed in interpretation state.
> I have certainly performed compilation semantics in interpret state,
> and I have seen code posted by others that performs compilation
> semantics in interpret state.
It works as expected in some conditions, and doesn't work in other
conditions. And it's why it's ambiguous. And some examples when it
doesn't work as expected were shown by me too.
> There is no good reason to disallow it.
It was always disallowed for a standard program since Forth-94.
But I think, we can allow it (and standardize) in some cases, by
eliminating ambiguity (and with guarantee of the same results).
>> So why not to just implement POSTPONE in such a way in your system to
>> meet the expectation?
> No common practice (actually no practice that I am aware of).
If some approach can be only implemented when it has common practice,
nothing new will be ever implemented.
OTOH, I implement POSTPONE in this way.
> Does not solve the ticking problem.
> And we have better ways
> that solve both ticking and POSTPONEing of S".
I don't see any problem with S"
See my point concerning expected and actual behaviour of POSTPONE
Concerning ticking S" — I proved that your interpretation is incorrect
(at lest, you didn't answer anything yet).
> Those that don't want to adopt these ways typically think that
> the problems of state-smart S" are of no practical concern and
> don't merit any effort at solving them
> (and apparently not even the effort of proposing that ticking and
> POSTPONEing S" become non-standard).
You know, there is a proposal that makes ticking S" non-standard via
introducing a general rule.
Concerning applying POSTPONE to S" — my point is that is should remain
standard, and the current exclusions re POSTPONE should be removed.
POSTPONE should be applicable to any word with defined compilation
>> Yet another tool for NDCS words is Recognizer API.
>> It provides you a way to create a word that POSTPONE or Tick are not
>> applicable to at all.
> Actually the recognizer proposal is designed to allow POSTPONEing (but
> not ticking) recognized things. In particular, you can
> POSTPONE "bla"
> whereas you cannot
> POSTPONE S" bla"
But you can
It impossible to make POSTPONE applicable to both 'S"' and 'S" bla"'