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


,------------------------------------------
| 2024-12-01 00:16:09  sxjh9935  wrote:
| proposal - Octal prefix
| see: https://forth-standard.org/proposals/octal-prefix#contribution-369
`------------------------------------------
## 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.



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


,------------------------------------------
| 2024-11-26 01:12:30  AndrewRead  replies:
| proposal - Known undefined word XLERB
| see: https://forth-standard.org/proposals/known-undefined-word-xlerb#reply-1373
`------------------------------------------
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! >>


,------------------------------------------
| 2024-11-27 16:30:56  ruv  replies:
| proposal - Known undefined word XLERB
| see: https://forth-standard.org/proposals/known-undefined-word-xlerb#reply-1374
`------------------------------------------
> 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"?



,------------------------------------------
| 2024-11-27 20:40:55  ruv  replies:
| proposal - Known undefined word XLERB
| see: https://forth-standard.org/proposals/known-undefined-word-xlerb#reply-1375
`------------------------------------------
Another option for programs is to check if `xlerb` defined before run test cases:
```forth
[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]
```



,------------------------------------------
| 2024-11-27 20:51:54  ruv  replies:
| proposal - Known undefined word XLERB
| see: https://forth-standard.org/proposals/known-undefined-word-xlerb#reply-1376
`------------------------------------------
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.



,------------------------------------------
| 2024-11-28 04:07:51  bfox9900  replies:
| referenceImplementation - Possible Reference Implementation
| see: https://forth-standard.org/standard/string/SEARCH#reply-1377
`------------------------------------------
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 
```


,------------------------------------------
| 2024-11-29 18:18:40  AntonErtl  replies:
| proposal - minimalistic core API for recognizers
| see: https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers#reply-1378
`------------------------------------------
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](https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers#reply-1038).

`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.