6 Glossary

6.1.0190 ." dot-quote CORE

Interpretation:

Interpretation semantics for this word are undefined.

Compilation:

( "ccc<quote>" -- )

Parse ccc delimited by " (double-quote). Append the run-time semantics given below to the current definition.

Run-time:

( -- )

Display ccc.

See:

Rationale:

Typical use: : X ... ." ccc" ... ;

An implementation may define interpretation semantics for ." if desired. In one plausible implementation, interpreting ." would display the delimited message. In another plausible implementation, interpreting ." would compile code to display the message later. In still another plausible implementation, interpreting ." would be treated as an exception. Given this variation a Standard Program may not use ." while interpreting. Similarly, a Standard Program may not compile POSTPONE ." inside a new word, and then use that word while interpreting.

Testing:

T{ : pb1 CR ." You should see 2345: "." 2345"; pb1 -> }T

See F.6.1.1320 EMIT.

ContributeContributions

mcondronavatar of mcondron [101] Right-justified text outputProposal2019-08-01 22:07:03

This contribution has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.

mcondronavatar of mcondron

This reply has been moved to the proposal section.

StephenPelcavatar of StephenPelc

This reply has been moved to the proposal section.

AntonErtlavatar of AntonErtl

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

EricBlakeavatar of EricBlake [405] behavior on newlineRequest for clarification2025-08-20 05:00:22

Is the behavior of this word:

: a ." multiline?
s" [char] " ;

ambiguous, dependent on the context of whether the compilation occurred from user input vs. evaluate, block, or a file? Or asked differently, is there any difference in compliance between an implementation that behaves as if it has automatic refill even from user input (which would output the string represented as s\" multiline\ns" plus push the integer '"' to the stack), vs. an implementation that terminates the search for the closing " at the newline (which would output the string s" multiline?" plus pushing a c-addr and length 7 to the stack representing "[char] ")?

https://github.com/ForthHub/discussion/discussions/126 mentions how to portably deal with \ in multiline input contexts, but doesn't mention other scenarios where multiline vs. single line interpretations can alter how a word would be defined.

ruvavatar of ruv

Yes, this definition for a is ambiguous.

that behaves as if it has automatic refill

In general, the observable effects of standard words are always specified, and they cannot do anything that is observable (by a standard program) but was not specified.

Therefore, the words «s"», «."», «parse-name», «[']», «to», etc, cannot refill the input buffer, because this is not specified (and can be detected by a standard program). Thus, according to their specified behavior, they can extract a multi-line text (or a lexeme on another line) from the input buffer when the input source is a string or a block, but cannot do so when the input source is a file or the user input device (since in these cases the input buffer always contains a single line).

The rationale A.6.2.2295 to the word «to» says "Therefore TO and name must be contiguous and on the same line in the source text". Perhaps we should formally introduce such a rule as the corresponding ambiguous condition for all parsing words that never refills the input buffer.

AntonErtlavatar of AntonErtl

The standard clearly specifies in 3.4.1 that the parsing of ." ends when the parse area (line or block) ends. So if that definition is on the command line or in a file, it is equivalent to

: a ." multiline?" s" char " ;

If that definition is in a single block (with 64-char "lines"), it is equivalent to

: a ." multiline?                                               s" [char] " ;
Reply New Version