,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2023-06-07 01:09:02  sxjh9935  wrote:
| proposal - 2C! and 2C@
| see: https://forth-standard.org/proposals/2c-and-2c-#contribution-299
`------------------------------------------
Author:

    sxjh9935
    
Change Log:

    2023-06-07 - First draft of proposal.

Problem:

    When using Forth for system programming, it is not usual for 16-bit values to be written or read. There are Forth words that handle 64-bit values, 32-bit values, 8-bit values but not 16-bit values.

Solution:

    Introduce two new words - 2C! and 2C@.
    
    The signatures for the two words are as follows-
    
    2C! ( x1 x2 c-addr -- )
    
    2C@ ( c-addr -- x1 x2 )
    
    In both instances, x1 is the value at the higher address (c-addr+1) and x2 is the value at the lower address (c-addr).

Proposal:

    These words should form part of the CORE dictionary.
    
    The words 2C! and 2C@ should be, respectively, inserted at 6.1.0360 and 6.0365.

    The following word definitions should be inserted.
    
    2C!
    ( x1 x2 c-addr -- )
    Store char pair at c-addr with x2 at c-addr and x1 at the next c-addr.
    
    2C@
    ( c-addr -- x1 x2 )
    Fetch char pair at c-addr. x2 is stored at c-addr and x1 at the next c-addr.
   

Reference implementation:

    2C@:
    DUP CHAR+ C@ SWAP C@

    2C!:
    SWAP OVER C! CHAR+ C!
    
    These implementations were written without reference to other publicly available implementations.
    
    After these implementations were written, the author checked whether such words are described in publicly available code. By sheer coincidence, the author found implementations nearly identical to 2C@. The difference being that 1+ was used rather than CHAR+. The author also found implementations of 2C! but such implementations made use of the return stack and such use of the return stack is unnecessary.


,---------.
| Replies |
`---------´


,------------------------------------------
| 2023-05-05 18:47:22  JohanKotlinski  replies:
| example - New Line characters in a string passed to EVALUATE
| see: https://forth-standard.org/standard/core/EVALUATE#reply-1018
`------------------------------------------
It was pointed out to me in another thread, that it is probably not right to change `REFILL`. But I am still hopeful that something good may come out of this discussion.


,------------------------------------------
| 2023-05-06 00:17:14  JohanKotlinski  replies:
| requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found?
| see: https://forth-standard.org/standard/core/PARSE#reply-1019
`------------------------------------------
This thread is incredibly illuminating! I wish I saw it sooner, as I have struggled with the same problems.

I think I understand and agree now, that the ideal way to load a text file from RAM buffer is to add a custom REFILL behaviour, which is able to get lines from a RAM buffer.
The real shortcoming of the Forth standard then, is that regular users are not able do this. The system-provided REFILL is set in stone by the forthwright, and cannot easily be altered.

This could be fixed by adding a standard way for users to add custom REFILL behaviors.
The simplest idea I can think of (just to get an idea):

`SET-REFILL ( source-id xt -- ) \\ Set a custom REFILL for the given source id`


,------------------------------------------
| 2023-05-06 00:18:05  NickMessenger  replies:
| example - 
| see: https://forth-standard.org/standard/file/INCLUDED#reply-1020
`------------------------------------------
I see now this issue was discussed at length on [PARSE](https://forth-standard.org/standard/core/PARSE#contribution-144). Please pardon the noise I have some reading to do.


,------------------------------------------
| 2023-05-06 06:29:50  JohanKotlinski  replies:
| requestClarification - What happens when parse reaches the end of the parse area and the parse delimiter was not found?
| see: https://forth-standard.org/standard/core/PARSE#reply-1021
`------------------------------------------
OK, maybe SET-REFILL above is a bit too simplistic. It might be better solved by a word like:

    INCLUDE-XT ( source-id xt -- ) \ Include a text file using a custom SOURCE-ID and REFILL execution token.

It is fair to point out, such a word is probably already compatible with the standard, and the standard does not need to explicitly provide it. I will continue to experiment in this direction, and report if the results seem generally useful.