From: mark@theberrymans.com   
      
   On 12/5/25 7:41 PM, Arne Vajhøj wrote:   
   > Context   
   > -------   
   >   
   > 1)   
   >   
   > My opinion is that DCL:   
   > * is fine for interactive use   
   > * is fine for small scripts (5-25 lines with at most a few lexical   
   >    functions, a few if statements and 'Pn' usage   
   > * is not up to expectations for writing large scripts aka   
   >    programming in DCL   
   >   
   > One can argue that DCL should not be used for programming, but fact   
   > is that it is used that way.   
   >   
   > So what is missing for programming? I would say biggest   
   > items are:   
   > * loops   
   > * switch/case   
   > * arrays   
   > * user defined lexicals   
   >   
   .   
   .   
   .   
   > What to do?   
   > -----------   
   >   
   > A totally new shell with a new syntax is not a solution:   
   > * the oldtimers want DCL   
   > * the newcomers want standard (bash, Python etc.)   
   > * expensive   
   >   
   > 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 the need to reimplement?   
      
   Here is my opinion on the subject.  I have no idea how many others will   
   share it.   
      
   I have used a few scripting languages over the years, however...   
      
   I like DCL.  I prefer it over any other shell I've ever used.  But it is   
   also over 40 years old with only limited enhancements over the years.   
      
   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).   
      
   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.   
      
   There is then all the time needed to make sure any existing scripts will   
   work (or be updated as needed) in the new DCL.   
      
   Much easier for the vendor to enhance in the future.   
      
   These are some of the thoughts I've had over the years.  Feel free to   
   throw darts at them.   
      
   Mark Berryman   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)