6 Glossary

6.2.2530 [COMPILE] bracket-compile CORE EXT

Interpretation:

Interpretation semantics for this word are undefined.

Compilation:

( "<spaces>name" -- )

Skip leading space delimiters. Parse name delimited by a space. Find name. If name has other than default compilation semantics, append them to the current definition; otherwise append the execution semantics of name. An ambiguous condition exists if name is not found.

Note:

This word is obsolescent and is included as a concession to existing implementations.

See:

Rationale:

Typical use: : name2 ... [COMPILE] name1 ... ; IMMEDIATE

Testing:

With default compilation semantics
T{ : [c1] [COMPILE] DUP ; IMMEDIATE -> }T
T{ 123 [c1] -> 123 123 }T

With an immediate word
T{ : [c2] [COMPILE] [c1] ; -> }T
T{ 234 [c2] -> 234 234 }T

With special compilation semantics
T{ : [cif] [COMPILE] IF ; IMMEDIATE -> }T
T{ : [c3]  [cif] 111 ELSE 222 THEN ; -> }T
T{ -1 [c3] -> 111 }T
T{  0 [c3] -> 222 }T

ContributeContributions

MitraArdronavatar of MitraArdron [173] Obsoleted - by what? Request for clarification2021-01-05 08:24:25

If a word is flagged as obsolescent, shouldn't there be at least a pointer to the prefered alternative(s)?

AntonErtlavatar of AntonErtl

If you want to append the compilation semantics of X, write POSTPONE X. If you want to append the execution semantics of a word with default compilation semantics, write X.

Closed
Reply New Version

ruvavatar of ruv [192] How to avoid default compilation semantics in the specification for [COMPILE]Comment2021-04-21 09:46:05

The specification for [COMPILE] is based on the notion of default compilation semantics (this notion implicitly follows from 3.4.3.3 Compilation semantics).

For example:

  • [COMPILE] IF is equivalent to POSTPONE IF, since IF has non default compilation semantics.
  • [COMPILE] EXIT is equivalent to EXIT, since EXIT has default compilation semantics.

A side note. It looks like a user should still know an implementation detail of a word to correctly apply (or not apply) [COMPILE] to it. Before Forth-94 a user should know whether a word is immediate or not, and since Forth-94 a user should know whether a word has default compilation semantics or not default.

We have a number of words that have default compilation semantics and undefined interpretation semantics in their glossary entries (i.e. specifications). At least for some of them we would want to reword the specification in this regard (see also a comment).

For example, if we rename "Execution" section into "Run-Time" section and introduce "Compilation" section into the glossary entry for EXIT, then this word formally becomes a word with non default compilation semantics. And then the semantics of [COMPILE] EXIT phrase is changed.

How we can solve this problem with [COMPILE]?

Allow to apply [COMPILE] to the only words that have default compilation semantics?

Or perhaps it's a time to destandardize [COMPILE] at all?

NB: if EXIT is implemented as an immediate word in a Forth system, then actually it has non default compilation semantics in this Forth system, and then [COMPILE] EXIT will produce incorrect code, if [COMPILE] isn't specially tweaked for such cases.

ruvavatar of ruv

Typo: "Allow to apply [COMPILE] to the only words that have non default compilation semantics".

Yet another problem with [COMPILE].

Usually, a user can redefine almost any word in a Forth system.

For example, to implement a profiler, EXIT can be redefined as an immediate word. But after that [COMPILE] EXIT works in a non standard way.

So it needs to also redefine [COMPILE], and either tweak handling of some words ad hoc, or just raise an error for any word in the argument (to avoid silently generating incorrect code by original [COMPILE]).

AntonErtlavatar of AntonErtl

The implementation of [COMPILE] needs to know how EXIT is implemented, the user does not need to know. As you point out elsewhere, a number of systems get [COMPILE] EXIT wrong; and apparently users don't care enough to report this bug to the maintainer of the affected systems. One reason is probably that, if they want the standard behaviour of [COMPILE] EXIT, they just write EXIT. In any case, [COMPILE] is obsolescent, so the behaviour of [COMPILE] will probably be outside of the scope of the next standard; therefore the appetite in the committee for discussing it is very small.

Closed
Reply New Version

ruvavatar of ruv [195] A final test case for [COMPILE] Suggested Testcase2021-04-28 23:36:43

The test that many systems fail:

T{ :NONAME 1 [COMPILE] EXIT 2 ; EXECUTE -> 1 }T

Definitely, [COMPILE] should be excluded, but not due to this test fails in some systems. There are other critical points.

See also a discussion/raw message in comp.lang.forth.

Reply New Version