[369] 2024-12-01 00:16:09 sxjh9935 wrote:

proposal - Octal prefix

Author:

sxjh9935

Change Log:

2024-12-01 - First draft of proposal.

Problem:

It appears there is no octal prefix whereas prefixes for decimal, hexadecimal and binary exist (as per 3.4.1.3).

Solution:

Add octal prefix to 3.4.1.3.

Perhaps use a leading 0 so that it is consistent with other languages like C.

Implementation will be dependent on the interpreter.

Typical use: (Optional)

Valid examples

0377 0111 0777 00

Invalid examples

0888 0008 0989

Proposal:

This should enumerate the changes to the document at 3.4.1.3.

Reference implementation:

Implementation should be left to the interpreter's author.

[r1373] 2024-11-26 01:12:30 AndrewRead replies:

proposal - Known undefined word XLERB

Is xlerb now trademarked by the owner of that internet domain? Do we now need UHO’s permission to use it in the standard?

<< joke! >>

[r1374] 2024-11-27 16:30:56 ruv replies:

proposal - Known undefined word XLERB

For documentation purposes, running tests, and provoking exceptions there is a need for a word that is never in the dictionary.

When the search order is empty, no definition can be found. This can be used to provoke exceptions in test cases.

Overall, I like the idea of "XLERB", but I don't like the new formal requirements for systems and programs, and the ambiguous condition. I think, this can be specified using "should" instead of "shall".

As a counterexample, there is a more critical case: the standard does not specify that the system shall not define a word named "10". Then, why should it specify this for the name "XLERB"?

[r1375] 2024-11-27 20:40:55 ruv replies:

proposal - Known undefined word XLERB

Another option for programs is to check if xlerb defined before run test cases:

[defined] xlerb [if] cr .( [warning, some tests cannot be run because `xlerb` is defined] ) cr [else]
\ run test cases
t{ ' ' catch xlerb -> -13 }t
t{ s" xlerb" find-name -> 0 }t
t{ 3 s" to xlerb" ' evaluate catch nip nip -> -13 }t
[then]

[r1376] 2024-11-27 20:51:54 ruv replies:

proposal - Known undefined word XLERB

An argument against an ambiguous condition about the name "xlerb" is that word lists are sometimes used to store name-value pairs. It would be very unexpected and annoying if some specific name could never be placed to a wordlist.

[r1377] 2024-11-28 04:07:51 bfox9900 replies:

referenceImplementation - Possible Reference Implementation

I was never good at following directions. Here is a version that actually provides the specified output for both cases; string found and string not found. Mea culpa

: SEARCH  ( caddr1 u1 caddr2 u2 -- caddr3 u3 flag)
   2OVER                \ retain a copy of 1st string 
   BEGIN 
     DUP
   WHILE 
     2OVER 4TH OVER COMPARE 
   WHILE 
     1 /STRING  
   REPEAT
   2NIP 2NIP TRUE EXIT      \ string found 
   THEN
   2DROP 2DROP FALSE ;   \ string not found 

[r1378] 2024-11-29 18:18:40 AntonErtl replies:

proposal - minimalistic core API for recognizers

Concerning the supposed lack of use cases: I have mentioned use cases where the state-based interface is at the very least cumbersome in r1038.

state is a bad idea, as demonstrated by the problems mentioned above. We are stuck with it for the existing system, but we must not put state in new interfaces, much less in new defining words.

As for opaque vs. transparent: Opaque would only be an option if the only use of translators was really in the text interpreter and in postpone. But if we want to support other use cases (and there are other use cases, as discussed above), we should do a transparent user interface. And it must not be state-dependent.