Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.forth    |    Forth programmers eat a lot of Bratwurst    |    117,927 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 116,580 of 117,927    |
|    Gerry Jackson to Krishna Myneni    |
|    Re: 0 SET-ORDER why?    |
|    27 Jun 24 23:08:19    |
      From: do-not-use@swldwa.uk              On 27/06/2024 20:22, Krishna Myneni wrote:       > On 6/27/24 14:09, Krishna Myneni wrote:       >> On 6/26/24 23:14, Gerry Jackson wrote:       >>> On 26/06/2024 14:36, Ruvim wrote:       >>>> One possible use case:       >>>>       >>>> : turnkey ( -- ) 0 set-order       >>>> also Target definitions       >>>> also Minimal also       >>>> ;       >>>       >>> ALSO duplicates the wordlist at the head of the search order. If the       >>> search order is empty there is nothing to duplicate. Therefore ALSO       >>> applied to an empty search order ought to be an ambiguous condition.       >>>       >>> Presumably the above definition works because a target wordlist       >>> replaces whatever garbage ALSO leaves in the search order. So the       >>> definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.       >>> Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above       >>> justification for 0 SET-ORDER.       >>>       >>       >> Good analysis showing that       >>       >> 1) The definition of TURNKEY is flawed.       >>       >> 2) 0 SET-ORDER is not necessary.       >>       >>       >>> But having said that it is better for 0 SET-ORDER to do what is       >>> natural instead of yet another ambiguous condition.       >>>       >>> > Another possible use case:       >>> >       >>> > : s-to-n ( addr u -- n )       >>> > depth >r       >>> > get-order n>r 0 set-order       >>> > ['] evaluate ['] execute-interpreting catch       >>> > nr> set-order       >>> > depth 1- r> <> if -12 throw then       >>> > ;       >>>       >>> This is a better use case e.g. if BASE is greater than decimal 10       >>> converting an alphanumeric string to a number could clash with a word       >>> in the dictionary. Having an empty search order eliminates that       >>> possibility.       >>>       >>       >> This use case is convoluted and there may be a better of dealing with       >> the anticipated problem.       >>              It has been a real problem, years ago I compiled some preset data in Hex       (before the $ prefix was standardised). Something like A5 c, 13 c, D0 c, ...       and the application worked on a number of systems and then crashed on       another standard system. On investigation I found that D0 was a defined       word in that system - hence a crash. OK the $ prefix solves that but not       the general problem e.g. BASE = #24 say              >> If not, we should consider what's missing in       >> Forth allowing us to solve the problem more directly.       >>       >>       >> No one has pointed to a need for 0 SET-ORDER in interpretation state,       >> and there is no to undo its use in interpretation state in a standard.       >> Furthermore an empty search order contradicts the concept of a minimum       >> search order.       >>       >> The solutions are:       >>       >> 1) leave everything as is, and live with the contradiction and the       >> hazard of performing 0 SET-ORDER in interpretation state.              I favour this, there are other ways of achieving the effect of       0 SET-ORDER in interpretation mode, for example              1) WORDLIST 1 SET-ORDER              2) Using PREVIOUS on a search order of FORTH-WORDLIST only (assuming       FORTH-WORDLIST contains PREVIOUS)              3) ...              I suspect trying to ban every possibility isn't worth it              >>       >> 2) make SET-ORDER state-smart, and live with the contradiction. This       >> will potentially break code.       >>       >> 3) disallow zero as an argument to SET-ORDER e.g. throw an error for       >> zero.       >>       >> Am I missing any other options?       >>       >> Personally, I favor 3) -- throwing an error when zero is an argument       >> to SET-ORDER.       >>       >       > Edits:       >       > No one has pointed to a need for 0 SET-ORDER in interpretation state,       > and there is no standard way to undo its use in interpretation state.       >       > 3) disallow zero as an argument to SET-ORDER e.g. throw an error for       > zero. This will break existing code where zero is an argument to SET-ORDER.       >       > Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have       > ever used it in a definition.       >       > --       > KM       >              --       Gerry              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca