:

( C: "<spaces>name" -- colon-sys )

Skip leading space delimiters. Parse name delimited by a space. Create a definition for name, called a "colon definition". Enter compilation state and start the current definition, producing colon-sys. Append the initiation semantics given below to the current definition.

The execution semantics of name will be determined by the words compiled into the body of the definition. The current definition shall not be findable in the dictionary until it is ended (or until the execution of DOES> in some systems).

Initiation:

( i * x -- i * x ) ( R: -- nest-sys )

Save implementation-dependent information nest-sys about the calling definition. The stack effects i * x represent arguments to name.

name Execution:

( i * x -- j * x )

Execute the definition name. The stack effects i * x and j * x represent arguments to and results from name, respectively.

See:

Rationale:

Typical use: : name ... ;

In Forth 83, this word was specified to alter the search order. This specification is explicitly removed in this standard. We believe that in most cases this has no effect; however, systems that allow many search orders found the Forth-83 behavior of colon very undesirable.

Note that colon does not itself invoke the compiler. Colon sets compilation state so that later words in the parse area are compiled.

Testing:

T{ : NOP : POSTPONE ; ; -> }T
T{ NOP NOP1 NOP NOP2 -> }T
T{ NOP1 -> }T
T{ NOP2 -> }T

The following tests the dictionary search order:

T{ : GDX   123 ;    : GDX   GDX 234 ; -> }T
T{ GDX -> 123 234 }T

ContributeContributions

ruvavatar of ruv Better wording for ColonProposal2020-02-06 02:14:04

This contribution has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.
Accepted
Reply New Version

ruvavatar of ruv The parts of execution semantics and the calling definitionRequest for clarification2020-02-21 15:32:19

Headnote

The specification says: a) Append the initiation semantics given below to the current definition. b) The execution semantics of name will be determined by the words compiled into the body of the definition.

Question I

Is the initiation semantics part of the execution semantics?

It seems yes, but slightly vague.

Since 1) These initiation semantics are not a word compiled into the body. And 2) "the current definition" and "the execution semantics of the current definition" is not the same.

Re 2: COMPILE, appends execution semantics not just "to the current definition", but "to the execution semantics of the current definition". Perhaps it should be said somewhere that "appending semantics to the current definition" means appending these semantics to the execution semantics of the current definition. Or just use the same wording as in the specification for COMPILE,.

Question II

What definition is a calling definition?

The initiation semantics is to save information about the calling definition. But it seems the standard nowhere says how to call a definition, or what definition is the calling definition.

EXECUTE performs execution semantics. COMPILE, appends execution semantics. EXIT (and the code appended by Semicolon ;) returns control to the calling definition. But nobody calls the definition.

It looks like this issue reason is a gap between two different models (abstractions). We should find some bridge between this models, or use only one model.


NB: My interest is purely formal, it relates to the only wording of the specifications. From the implementation point of view, it's clear what definition is a calling definition. But the question is how to formulate it in the language of the Standard.

ruvavatar of ruv

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.

AntonErtlavatar of AntonErtl

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).

Reply New Version