Proposal: Update rationale for SLITERAL

Informal

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv [292] Update rationale for SLITERALProposal2023-03-06 00:03:30

Author

Ruv

Change Log

  • 2023-03-06 Initial version

Problem

In the draft 2020-01, the section A.17.6.1.2212 SLITERAL conflicts with the section 6.1.2165 S".

In 2017 it was decided to merge the words FILE S" and S\" into the corresponding words in CORE/CORE-EXT (see the minutes 2017 and preceding discussion "Core-ext S\" should reference File-ext S\""). It was implemented in the draft 2020-01.

However, the section A.17.6.1.2212 has not been updated, and it shows an implementation for CORE S" before 2017, which leads to confusions (it was noticed by Anthony Howe in "Confusion over S" and SLITERAL").

Solution

Update the section A.17.6.1.2212 according to the new 6.1.2165. Take into account A.6.1.0190 .".

Proposal

Replace the content of the section A.17.6.1.2212 SLITERAL by the following:

The current functionality of 6.1.2165 S" may be provided by the following definition:

: S" ( "ccc\<quote\>" -- c-addr u | )
    [CHAR] " PARSE STATE @ IF POSTPONE SLITERAL THEN
; IMMEDIATE

Note: Depending on the Forth system implementation, this definition may leads to the following environmental restrictions:

  • the lifetime of the string returned by the interpretation semantics for S" is only valid until the input buffer is refilled or the input source is changed;
  • the compilation semantics for S" that are appended by applying POSTPONE to S" cannot be performed if the system in interpretation state.

In the section 6.1.2165 S", add into the last paragraph, which starts with "See:", at the end before the dot:

, A.17.6.1.2212 SLITERAL

ruvavatar of ruvNew Version: Update rationale for SLITERAL

Show differences

Author

Ruv

Change Log

  • 2023-03-07 Better wordings in several places, correction some typos
  • 2023-03-06 Initial version

Problem

In the draft 2020-01, the section A.17.6.1.2212 SLITERAL conflicts with the section 6.1.2165 S".

In 2017 it was decided to merge the words FILE S" and S\" into the corresponding words in CORE/CORE-EXT (see the minutes 2017 and preceding discussion "Core-ext S\" should reference File-ext S\""). It was implemented in the draft 2020-01.

However, the section A.17.6.1.2212 has not been updated, and it shows an implementation for the version of CORE S" before 2017, which leads to confusions (it was noticed by Anthony Howe in "Confusion over S" and SLITERAL").

Solution

Update the section A.17.6.1.2212 according to the new 6.1.2165. Take into account A.6.1.0190 .".

Proposal

Replace the content of the section A.17.6.1.2212 SLITERAL by the following:

The current functionality of 6.1.2165 S" may be provided by the following definition:

: S" ( "ccc\<quote\>" -- c-addr u | )
    [CHAR] " PARSE STATE @ IF POSTPONE SLITERAL THEN
; IMMEDIATE

Depending on the Forth system implementation, this definition can lead to the following environmental restrictions:

  • the lifetime of the string returned by the interpretation semantics for S" is only valid until the input buffer has been refilled or the input source is not the same;
  • the compilation semantics for S" that are appended by applying POSTPONE to S" cannot be performed if the system in interpretation state (due to a possible restriction of POSTPONE).

In the section 6.1.2165 S", add into the last paragraph, which starts with "See:", at the end before the dot:

, A.17.6.1.2212 SLITERAL

ruvavatar of ruv

The phrase "the input source is changed" is slightly ambiguous, since it can mean:

  • "the state of the input source is changed";
  • "the identity of the input source is changed" (i.e., another source is used as the input source, with its own state).

The phrase "the input source is not the same" (which is used in A.6.2.2182 SAVE-INPUT) means that identity of the input source is changed.

Therefore, in the version 2023-03-07 the form "is not the same" is used, instead of "is changed".

AntonErtlavatar of AntonErtl

As you note, this state-smart approximation to the implementation of S" does not quite provide implement what the standard requires, so instead better do something like:

Typical use:

: quine [ source ] sliteral type ;

Note that you can use 2literal instead of sliteral if the string has permanent lifetime.

Reply New Version