From: arne@vajhoej.dk   
      
   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   
      
   2)   
      
   Shell capabilities does not sell systems today. Users are not doing   
   shell at all. Programmers work mostly on PC's. Only system managers are   
   still doing a lot of shell work and their shell experience is not likely   
   to determine platform decisions.   
      
   So VSI cannot justify investing a lot of money in a new shell, because   
   there is no business case.   
      
   3)   
      
   The vast majority of future VMS system managers will have experience   
   with alternative scripting languages that actually are available on VMS.   
   Most notable bash (GNV) and Python, but there are other: I like Groovy,   
   there may still be some that like Perl etc. So future DCL programming   
   will mostly be enhancing existing COM file done by existing VMS system   
   managers.   
      
   This mean VSI cannot break backwards compatibility for DCL - whatever   
   ran in 1985 has to run the exact same way today.   
      
   4)   
      
   According to many years of internet gossip, then the DCL code base   
   is very difficult to enhance, because it is Macro-32 and very tricky   
   Macro-32 that is. The last big language change was probbaly   
   if-then-else-endif in 1988.   
      
   VSI cannot start classic evolution process of adding new features   
   to DCL over time.   
      
   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   
      
   What I see left is the "RATFOR approach" (in this century it should   
   probbaly be called "transpiling approach", but I suspect more people   
   here know about RATFOR than all the transpiling to JavaScript being   
   done today). Pre-processing extended DCL to old DCL.   
      
   Convert loop constructs to goto's and labels. Convert switch/case to   
   if's. Convert arrays from name[ix] to name_'ix'. Add a syntax for   
   declaring user defined lexicals from shareable images and translate   
   usage to call of UDL utility that calls functions in shareable   
   image and return value in symbol that is then used.   
      
   This should by design ensure 100% compatibility. Anything not new   
   will be left unchanged and processed by todays DCL.   
      
   And due to the fixed format and relative simplicity of of DCL then   
   I suspect that the pre-processor would not be that bad to implement.   
   But of course I could be wrong.   
      
   Preprocessing would obviously only work before symbol substitution.   
      
   $ a[1] = 123   
      
   works.   
      
   $ b1 = "["   
   $ b2 = "]"   
   $ a'b1'1'b2' = 123   
      
   does not work.   
      
   It could be implemented different ways.   
      
   A) On the fly   
      
   $ @@foobar   
      
   will preprocess foobar.xcom into memory and let DCL read from that memory.   
      
   B) Separate step   
      
   $ dcl2 foobar   
      
   converting foobar.xcom to foobar.com and:   
      
   $ @foobar   
      
   I am wondering maybe something like this has already been done and   
   are on one of the DECUS tapes.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)