Digest #114 2020-09-01
Contributions
The is no separator between the last two links in the "See" section, making them look like one long, weird link.
Replies
proposal - Wording: declare undefined interpretation semantics for locals
Now locals cannot be ticked
One more effect of the proposed changes.
Before these changes the locals may be ticked and executed (but only in compilation state). It means, that they shall be implemented as immediate words. Also, it seems the following code is standard (from a formal point of view):
: [e] execute ; immediate
variable local-x
: foo {: x :} [ ' x local-x ! ] x . ;
: bar [ local-x @ ] [e] . ;
1 foo bar
Obviously, this code is ambiguous. E.g., in some implementations the definition for x isn't available after creating foo, and trying to execute it can cause memory access violation.
After these changes the locals are not allowed to be ticked, and they may be implemented in any way.
proposal - Wording: declare undefined interpretation semantics for locals
I agree that the current wording is flawed and that your wording better reflects the intent.
As you point out in a later answer, there are several places where this would have to be fixed, so maybe the description of the local should be factored out and fixed there.
I think that instead of defining execution semantics for name, we should define compilation semantics that refers to run-time semantics; these run-time semantics would have the specification of the current "name execution". (This is just one instance of execution semantics without interpretation semantics; several of them should get this treatment, and the rest should get defined interpretation semantics).
that's why most words with explicitly defined interpretation and compilation semantics have no defined execution semantics.
It seems, the fact is that the different systems had the different execution semantics that is returned for these words (due to the different implementation approaches), but they implemented the same interpretation semantics and the same compilation semantics. That's why the execution semantics for such words cannot not be standardized. That's why execution semantics for them cannot be a standard vehicle for defining interpretation or compilation semantics. That's why default compilation semantics (that is based on interpretation semantics or on compilation semantics) cannot be specified in the standard.
If execution semantics for them would be specified, it restricts implementation options and makes some system non standard. I also wrote on this in length in the message news:qn0hfp$25u$1@dont-email.me "Semantics rethinking " (point 3), on 2019-09-02.
assume we introduce a
name>execution. What would you use it for? Can these uses not be accomplished withname>interpretandname>compile?
I wanted to recognize only an ordinary word in the actual context. For that, I tried to implement token>xt? ( k*x td -- xt td-xt | k*x td 0 ) that extract xt of an ordinary word, or returns false otherwise (see news:rdpu54$pfn$1@dont-email.me. For that I tried to implement the name>xt? word in the following way:
: name>xt? ( nt -- xt td-xt | nt 0 )
dup 0= if dup exit then
dup >r name>compile ['] execute <> if
r@ name>interpret over = if rdrop td-xt exit then
then drop r> 0
;
Don't sure it is does what I want in any system.
Correction a typo:
"That's why default execution semantics (that are based on interpretation semantics or on compilation semantics) cannot be specified in the standard"
proposal - Wording: declare undefined interpretation semantics for locals
Factoring out the description of the local is the right step, but it requires more labor. This case will be the first one when semantics for a word are described not in some glossary entry, but in some "Additional usage requirements" section (in this case, a subsection of 13.3).
Defining compilation semantics via run-time semantics is also a good step, although it isn't crucial (it just fixes some confusing). And it's more worthwhile to apply these changes for all such cases at once (i.e., also for EXIT, >R, etc).
So I would suggest the following roadmap:
Add "Interpretation" section in
{:and(LOCAL)glossaries (as easy and quick solution).Factor out description of locals, without changing the wording.
Change wording for all such words at once.
Regarding the repository with the source text — it's important to have each step as a separate commit.
proposal - Wording: declare undefined interpretation semantics for locals
You as proposer decide what and how you propose changes. However, my feeling is that it is better to propose this as one proposal rather than three. And make the changes to EXIT and friends another proposal that covers them all. The editor decides how he deals with version control.
requestClarification - The parts of execution semantics and the calling definition
Just an idea
calling definition: the definition whose performing has been started most recently among those whose performing hasn't been ended.
to perform a definition: to perform, step by step, all parts of the execution semantics for this definition.
requestClarification - The parts of execution semantics and the calling definition
Question I Re 1: The intent (and common practice) is certainly that the execution semantics includes pushing nest-sys (i.e., the return address) on the return stack. Otherwise EXECUTE could not work on a colon definition.
The wording suggests otherwise. Looks like a bug in the wording to me that should be fixed.
Question I Re 2 does not appear to be a question to me. Yes, one could refine the wording as suggested by you, but then, it does not appear to be unclear now.
Question II does not appear to be a question to me, either. The wording could certainly be improved, but I don't think your suggestions would make things clearer. I would look for inspiration in related work (in this case, probably other programming language specifications).