From: arne@vajhoej.dk   
      
   On 12/9/2025 8:55 AM, Simon Clubley wrote:   
   > On 2025-12-08, Arne Vajhøj  wrote:   
   >> On 12/8/2025 9:12 AM, Simon Clubley wrote:   
   >>> Lists/dictionaries/tuples/etc should be a core facility.   
   >>>   
   >>> General OO functionality with structured imports of the objects.   
   >>>   
   >>> Generation of the VMS header files for all the languages will also   
   >>> include generation of DCL OO headers and modules that can be directly   
   >>> imported by a DCL script.   
   >>>   
   >>> As such, there is no need for user defined lexicals (which, with the   
   >>> current DCL design, would have to run in user mode instead of supervisor   
   >>> mode anyway for security reasons). You just import the OO module containing   
   >>> the system service that you want to call.   
   >>   
   >> ????   
   >>   
   >> Having a script language call native code requires some builtin   
   >> capability in the script language.   
   >>   
   >> Examples: Python ctypes, VBScript COM etc..   
   >   
   > You have completely and totally missed what I am saying above. Read it again.   
   >   
   > There is absolutely no need for the hack of user defined lexicals because   
   > missing system calls are added to a newDCL as a plugin module when a new   
   > version of newDCL is built. All the existing procedural code gets to use   
   > the existing lexicals in a 100% backwards compatible manner.   
   >   
   > All the new code, where backwards compatibility is not a concern, gets to   
   > use the new extended OO Python-style interface to the system services.   
   >   
   > The native code you call is a part of newDCL, in the exact same way that   
   > the native code which is run when you call a lexical is a part of DCL.   
   >   
   >>>> This mean VSI cannot break backwards compatibility for DCL - whatever   
   >>>> ran in 1985 has to run the exact same way today.   
   >>>   
   >>> No problem. You keep the existing interfaces and add OO functionality   
   >>> on top of it for use by new scripts, or any existing scripts you might   
   >>> want to spend the time modifying. There's no reason why all the new OO   
   >>> stuff can't simply be written in C that runs alongside the existing   
   >>> Macro-32 code. Likewise for all the new control structures stuff.   
   >>   
   >> ????   
   >>   
   >> You need one parser not two parsers.   
   >>   
   >> You need some interoperability between new stuff and old stuff.   
   >   
   > Read it again.   
   >   
   > Any variables referenced within an object you create gets all the new   
   > fancy data structures and extended modern limits.   
   >   
   > Any variables referenced that are not within an object, get the   
   > traditional crappy DCL limits and functionality, making them 100%   
   > backwards compatible with existing DCL code.   
   >   
   > Oh, and you only have one parser, not two. It's just that all the new   
   > stuff is handed off to code written in a HLL such as C instead of Macro-32.   
      
   You add DCL support to DCL and get starlet.com with some   
   syntax.   
      
   $ declare class system_services   
   $    ...   
   $    native static function sys$forcex(byref pid: long, bydesc prcnam:   
   string, byval code: long)   
   $    ...   
   $ enddeclare   
      
   (I tried to make it DCL'ish - it could be Python'ish or Java'ish or   
   whatever'ish instead)   
      
   The DCL script does:   
      
   $ @sys$library:starlet   
   $ ...   
   $ system_services.sys$forcex(id, , 44)   
   $ ...   
      
   This needs a way for DCL to call native code, using VMS calling   
   convention.   
      
   Existing lexicals does not need this because they are implemented   
   inside DCL.   
      
   And parsing is not that simple either.   
      
   DCL has an existing parser that get activated.   
      
   And it will process the @ but not the class declaration   
   or the class.method call.   
      
   It will not "handoff" it will give an error.   
      
   And there is also an issue the other way around.   
      
   $ ...   
   $ librtl.lib$put_output("''p1' ''p2' ''p3'")   
   $ ...   
      
   Old DCL cannot do librtl.lib$put_output, so that needs   
   to go to the new DCL, but the new DCL should not   
   reimplement "''p1' ''p2' ''p3'", so that needs to go back to the   
   old DCL.   
      
   Impossible to do without significant changes to old DCL.   
      
   And an extremely complex solution.   
      
   > PS: BTW Arne, have you written any shells/parsers/compiler frontends/etc ?   
      
   It has been more than 25 years.   
      
   >       You are looking at creating an additional hack on top of an existing   
   > set of hacks.   
      
   True.   
      
   But also a low cost way to provide some benefits.   
      
   >              I am using my knowledge to propose a more general and cleaner   
   > solution   
      
   What you propose would be the ugliest most hackish parser and   
   interpreter known to mankind.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)