From: arne@vajhoej.dk   
      
   On 12/13/2025 1:27 PM, Mark Berryman wrote:   
   > On 12/5/25 7:41 PM, Arne Vajhøj wrote:   
   >> A reimplementation of DCL in C (or another language, but C is   
   >> probably the current preference) is not a solution:   
   >> * risk only achieving 99.9% compatiblity instead of 100% compatibility   
   >> * expensive   
      
   > Why not make a 2nd DCL, one that can live on the system in parallel with   
   > the current DCL.  Call it DCL64 since it would use 64-bit variables   
   > instead of 32-bit.  Which DCL a given process used would be specified in   
   > sysuaf or creprc (and, possibly, spawn).  I'd would also like to see the   
   > following:   
   >   
   > 1. Variables can be integer, string, or floating-point.   
   > 2. Longer string lengths.   
   > 3. Enhance SYS$FAO to support floating-point.   
   > 4. New constructs (e.g. loops, arrays, etc.)   
   > 5. Lexicals match system functions.   
   >     (i.e., easy for the vendor to update lexicals to match new functions   
   >      or enhanced functionality and being able to specify multiple items   
   >      to return in a single lexical call)   
   > 6. An option to make pipe syntax the default without having to specify   
   > the pipe command.   
   > 7. An option to make Set process/parse=extend and Set process/   
   > token=extend as default.   
   > 8. Commands and switches match on 8 chars instead of 4.   
   >     (e.g., I'd like to see both open and openssl exist as separate   
   > commands).   
   > 9. No automatic upcasing the command line.  (Internal parsing is case-   
   > insensitive).  The idea is to reduce the need for lib$initialize in   
   > utilities written in C.   
   > 10. Otherwise, still DCL.   
   > 11. Perhaps even make the character set UTF-8 instead of ASCII.  (Of   
   > course, then I'd be asking for a DECterm that used UTF-8).   
      
   That would be a better DCL.   
      
   :-)   
      
   > Benefits:   
   >   
   > No need to be 100% backwards compatible.  Make it as backwards   
   > compatible as possible but the edge cases that make it difficult to   
   > rewrite DCL in a HLL wouldn't apply since the original DCL is still   
   > there to handle them.   
      
   So if someone needed old DCL for an edge case they could just   
   login with /CLI=DCL (users having DCL64 as default in SYSUAF)?   
      
   That still leaves the investment though.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)