home bbs files messages ]

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