6.1.0450 : colon CORE

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


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



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.


T{ : NOP : POSTPONE ; ; -> }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


ruvavatar of ruv [128] 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.
Reply New Version

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


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

lmravatar of lmr [329] are colon-defs supposed to be compiled in data space?Request for clarification2024-01-05 17:07:09

This may be very basic, but: are colon-definitions supposed to be compiled in data space (addressable by @, ! etc)? Can the thread of compiled XTs (or whatever the implementation uses) for a definition reside in some other address space, visible only to the inner interpreter or the equivalent? I suppose the answer is obvious, since presumably an implementation could compile everything to a primitive.

AntonErtlavatar of AntonErtl

I don't find it written clearly enough in the document (Chapter 3 is what I looked at), that's why I leave this request open; in particular, the document says very little about code space and does not say that compile, allocates in code space or that the compilation semantics of various words allocate in code space.

Anyway, the intention is that the current definition and the stuff that is appended to it lives in code space, except the header which lives in name space (which, as has been noted, is in conflict with he usual meaning of "name space" in programming languages). Both name space and code space may be interleaved with each other and with data space, but they can also be separate. Traditionally, they are interleaved, but for a native-code system I recommend separating out at least the code space, because writing to data close to code causes serious performance penalties (I measured 400 cycles per ! at one point).

ruvavatar of ruv

are colon-definitions supposed to be compiled in data space (addressable by @, ! etc)?

It is not supposed, but allowed. Under the hood, an implementation may allocate data space during compilation. Contiguous regions says: «an implementation is free to allocate data space for use by code»

On the other hand, a program is only allowed to access the address units that are either explicitly allocated by the program, or provided by the system as variables, text-literal regions, input buffers, and other transient regions — see 3.3.3 Data space.

Also, the section 4.1.2 Ambiguous conditions says that an ambiguous condition exists if a program addresses a region not listed in 3.3.3 Data space.

Reply New Version