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


,------------------------------------------
| 2023-02-17 09:06:20  UlrichHoffmann  wrote:
| proposal - Agenda Forth-200x interim Meeting 2023-02-17T15:00Z
| see: https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2023-02-17t15-00z#contribution-286
`------------------------------------------
Not sure my Mattermost message with the agenda for today's meeting came through to everyone. So I post it here again. 


> Hi @all 
>
> my calendar shows a meeting this Friday, 2023-02-17 we agreed on during the last meeting in September. I propose we start at 15:00 UTC (16:00 MET, 07:00 PST).
> 
> Please find attached the unsurprising agenda. If you have any remarks please do not hesitate to comment.
> 
> @gerald, I would appreciate if you could set up the conference system for the meeting but I could also provide a Zoom room if necessary.
> 
> Any comments welcome.
> 
> Best Regards, Ulli

---

## Agenda Forth-200x interim Meeting 2023-02-17T15:00Z

16:00 MET  
07:00 PST

Estimated duration 120 minutes + workshop

- Welcome / Participants (10 min)

- Agreement on the agenda  (5 min)  
  Do we have any additional points to discuss?

- Review of Procedures (5 min)

- Review of new Proposals and Contributions (since the September'22 meeting, 2022-09-14/15) (60 min)
  see https://forth-standard.org/proposals and https://forth-standard.org/contributions  
   - [250] Formatting: spaces in data type symbols
     in formatting-spaces-in-data-type-symbols  
     2022-09-17 11:27:57 - ruv
   - block, LOAD -
     Possible Test Case, Suggested Testcase  
     2023-02-11 16:39:10 - JimPeterson
   - block, bs  -
     "... the remainder of the current,
     line."? Request for clarification  
     2023-02-11 16:04:29 - JimPeterson
   - block, THRU  -
     Possible Reference Implementation, Suggested reference implementation  
     2023-02-11 15:56:14 - JimPeterson
   - core, PICK  -
     Example implementation for PICK,
     Suggested reference implementation  
     2023-02-10 21:51:27 - ruv
   - core, ROLL  -
     Example implementation for ROLL,
     Suggested reference implementation  
     2023-02-10 21:32:22 - ruv
   - core, RESTORE-INPUT  -
     About behavior or RESTORE-INPUT, 
     Comment  
     2023-02-07 16:09:01 - ruv
   - core, RESTORE-INPUT  -
     Address of the input buffer after RESTORE-INPUT,
     Request for clarification  
     2023-02-07 10:03:28  - ruv
   - core, d  -
     Suggested reference implementation  
     2023-01-12 08:26:50 - JohanKotlinski
   - relax-documentation-requirements-of-ambiguous-conditions  
   [272] Relax documentation requirements of Ambiguous Conditions - Proposal  
   2022-12-29 19:25:35 - JohanKotlinski
   - doc - Comment  
   2022-12-21 11:40:45  - JohanKotlinski
   - core, CHAR   - 
     Describe Compile time and Run time behavior, 
     Comment  
     2022-11-19 09:25:07 - PopovMP

- Bio Break (10 min)

- Any other business (20 min)
   - A Forth 2022/2023 snapshot?
   - ...

- Date of next meeting (5 min)
   - EuroForth-2023?

- Workshop (Forth Modification Lab) (open end)
   - What are current Forth community topics
     - Memory operators 8, 16, 32, 64 bits - signed/unsigned
     - other topics?
   - discussion






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


,------------------------------------------
| 2023-02-16 05:32:46  ruv  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-961
`------------------------------------------
And *n* ≥ 1, correspondingly.


,------------------------------------------
| 2023-02-16 05:53:16  ruv  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-962
`------------------------------------------
Including a diagram for the return stack, and using `u` instead of `n`, we get:

- `N>R ( x_n ... x_1 u | 0 -- ) ( R: -- j*x u | 0 )`
- `NR> ( -- x_n ... x_1 u | 0 ) ( R: j*x u | 0 -- )`

I still think that a variant based on `i*x` is correct too, and far better readable:
- `N>R ( i*x u -- ) ( R: -- j*x u )`
- `NR> ( -- i*x u ) ( R: j*x u -- )`

And from the specification should be clear that *i=u*, but *j* is unknown.



,------------------------------------------
| 2023-02-16 13:18:37  JimPeterson  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-963
`------------------------------------------
I think what I mean to say is if, as a stack-constrained system, I choose to use a buffer to store the items and place a reference to the buffer on the return stack, *my* stack notation would be:

```
N>R ( i*n +n -- ) ( R: -- pBuf )
```

Given that the rationale says that I can do that, I don't think the documentation should imply anything about the format of the data on the return stack after the call except that some opaque data exists there, much like what the stack notation for `DO` and `LOOP` say.


,------------------------------------------
| 2023-02-16 15:54:23  ruv  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-964
`------------------------------------------
Even when a buffer is used, the spec requires to put the number of items on the top of the return stack. I.e., only the part `j*x` may vary.
So a possible variant for _actual_ implementation is: `N>R ( i*x +n -- ) ( R: -- addr.buf +n )` 
NB: _add.buf_ is a subtype of _j*x_, given that `j` is undetermined.

---

Of course, a new **implementation-dependent** data type _nr-sys_ can be introduced into the specification, so the stack diagrams will be:
- `N>R ( u*x u -- ) ( R: -- nr-sys u )`
- `NR> ( -- u*x u ) ( R: nr-sys u -- )`

But you have to provide another **rationale** for that — since the data type _j*r_ [already meets](#reply-952) the goals you mentioned before.

With enough reason, the spec can be even changed in a backward-incompatible way as:
- `N>R ( u*x u -- ) ( R: -- nr-sys )`
- `NR> ( -- u*x u ) ( R: nr-sys -- )`



,------------------------------------------
| 2023-02-17 12:44:50  UlrichHoffmann  replies:
| referenceImplementation - Example implementation for PICK
| see: https://forth-standard.org/standard/core/PICK#reply-966
`------------------------------------------
Yes PLACE has a common meaning in systems influenced by F83. It's used to copy a string to a memory location ( c-addr1 u c-addr2 -- ) and place a length byte at addr2. So addr2 will then be a counted string  (addr2 COUNT TYPE)... See the [PLACE +PLACE proposal](https://forth-standard.org/proposals/place-place#reply-745).


,------------------------------------------
| 2023-02-17 14:16:28  UlrichHoffmann  replies:
| requestClarification - Is data stack required?
| see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-967
`------------------------------------------
In my opinion, the ctual SAVE-INPUT values could be in a different memory area at some addrese ADDR and the stack effect of SAVE-INPUT might just be  ( -- ADDR 1 ). This would be acceptable as a standard behaviour and would relieve the data stack on stack space limited systems.


,------------------------------------------
| 2023-02-17 15:26:53  ruv  replies:
| proposal - Formatting: spaces in data type symbols
| see: https://forth-standard.org/proposals/formatting-spaces-in-data-type-symbols#reply-968
`------------------------------------------
It's an editorial issue.

In the [source](https://github.com/Forth-Standard/forth-standard/blob/master/core.tex#L185) it looks as:
```
\item \stack{n_1|u_1 n_2|u_2}{n_3|u_3}
```

I.e., no additional spaces around a bar in the data type symbols like `n_1|u_1`.