[292] 2023-03-06 00:03:30 ruv wrote:

proposal - Update rationale for SLITERAL

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

[r999] 2023-03-03 07:04:18 JohanKotlinski replies:

proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT

SAVE-INPUT/RESTORE-INPUT are used in some user-space code, for example in Gforth assemblers + cross-compilers. Example:

: .times{  ( n -- input n )
  dup >r 1 > IF  save-input  THEN  r> ;
: .}times  ( input n -- input n-1 / 1 / )
  1- dup 0>
  IF  >r restore-input throw r@ 1 >
      IF  save-input  THEN  r>
  THEN ;
:D

I can only imagine one workaround, which is to copy input to a buffer, and EXECUTE it from there. Obviously, such a workaround increases CPU+RAM usage.

[r1000] 2023-03-04 20:37:49 ruv replies:

proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT

SAVE-INPUT/RESTORE-INPUT are used in some user-space code, for example in Gforth assemblers + cross-compilers.

It's a good finding. The words .times{ and .}times are formally defined in the standard Forth. Although, as I can see, they are not used anywhere.

One problem with this construct is that it can work or fail without any explanation, — since the standard does not guarantee any conditions in which restore-input shall work. So the construct .times{ ... .}times is actually a system-specific means (or it has an environmental dependency concerning behavior of restore-input).

Another problem with this construct is that the body is performed at least once regardless of n. To correctly implement the case of n=0, we need to parse the input stream till the corresponding closing .}times (with possible nesting). But if we parse the input stream in this way, we can save the extracted text into a buffer and just translate (evaluate) it the given number of times, without employing save-input/restore-input.

I believe, we should have an API that helps in such tasks. Under the hood it can save a content or position (depending on the input source kind), and provides a uniform interface. Actually, such an API can be even implemented in a portable way if we standardize two things:

1. When the input stream is a string, the line comment shall skip up to the nearest line terminator or to the end of the input buffer (what is encountered first) (see a comment).
2. A program should not depend on the input source kind from which it's translated. It means, it should not rely that the input buffer contains a single line, and that refill reads a single line (see Portable line-oriented parsing). Probably, some helper words should be standardized for that.

Obviously, such a workaround increases CPU+RAM usage.

It depends on how save-input is implemented. A reliable implementation can also save a fragment of the input stream into the memory. OTOH, repeating reading from the file can take more CPU than reading from memory.