Digest #211 2023-02-18

Contributions

[286] 2023-02-17 09:06:20 UlrichHoffmann wrote:

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

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

[r961] 2023-02-16 05:32:46 ruv replies:

comment - Bad Stack Notation?

And n ≥ 1, correspondingly.

[r962] 2023-02-16 05:53:16 ruv replies:

comment - Bad Stack Notation?

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.

[r963] 2023-02-16 13:18:37 JimPeterson replies:

comment - Bad Stack Notation?

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.

[r964] 2023-02-16 15:54:23 ruv replies:

comment - Bad Stack Notation?

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 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 -- )
[r966] 2023-02-17 12:44:50 UlrichHoffmann replies:

referenceImplementation - Example implementation for PICK

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.

[r967] 2023-02-17 14:16:28 UlrichHoffmann replies:

requestClarification - Is data stack required?

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.

[r968] 2023-02-17 15:26:53 ruv replies:

proposal - Formatting: spaces in data type symbols

It's an editorial issue.

In the source 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.