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,937 of 117,927   
   albert@spenarnc.xs4all.nl to ruvim.pinka@gmail.com   
   Re: bye with exit status   
   06 Nov 24 14:58:15   
   
   In article ,   
   Ruvim   wrote:   
   >Many Forth systems running under an operating system provide   
   >system-specific capabilities to terminate with an exit status [1].   
   Note that it is not Forth-system-specific but operating-system specific.   
   Once you leave the Forth, the exit status is non-existent, as far   
   as Forth is concerned.   
      
   >   
   >For example, the following code fragments have stack effect ( n -- ⊥ )   
   >and use n as the process exit status:   
   >   
   >   SwiftForth "exitstatus ! bye"   
   >   VfxForth   "exitcode ! bye"   
   >   Gforth     "(bye)"   
   >   ciforth    "exit-code ! bye"   
   >   mf3        "sysexit"   
   >   Post4      "bye-code"   
   >   SP-Forth   "halt"   
   >   
   >Could you suggest some names for the word with this functionality so   
   >that one of them can be standardized?   
      
   A turnkey process should not detect an error, or if it is, that   
   error should be the users fault.   
   In ciforth I immediately terminate a turnkey process in case of an error.   
   (The user has an alternative: starting a Forth, then 'SOMETHING CATCH.   
   He misses nothing.)   
   The error number is the same as reported in the interpreter and is   
   documented in the application, or the Forth itself.   
      
   >   
   >This word should not output any messages.   
   Which word? Do you propose the functionality of Gforth's (bye)   
   in the standard?   
      
   >   
   >   
   >There are at least three different notions of premature termination of   
   >code execution:   
   >   — return from a Forth definition (to the caller)   
   >   — terminate a thread/task   
   >   — terminate the process   
   >And they should not be confused.   
      
   IMO all error conditions should have a distinct error number.   
   So a distinction between the conditions must be made in the   
   documentation of this error number. No need to theorize about   
   a common convention between the types of error.   
      
   The second set me thinking. This means that EXIT-CODE should be   
   a user variable. I follow Chuck Moore, I build that bridge if   
   I must cross the Rubicon.   
      
   >[1]    
   >--   
   >Ruvim   
   >   
   --   
   Temu exploits Christians: (Disclaimer, only 10 apostles)   
   Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall   
   Art For Home, Office And Garden Decor - Perfect For Windows, Bars,   
   And Gifts For Friends Family And Colleagues.   
      
   --- 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