From: clubley@remove_me.eisner.decus.org-Earth.UFP   
      
   On 2025-12-09, Arne Vajhøj  wrote:   
   > On 12/9/2025 8:55 AM, Simon Clubley wrote:   
   >>   
   >> 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.   
   >   
      
   Yes, _DCL_. No, _NOT_ your DCL script. (In the exact same way as existing   
   lexicals work.)   
      
      
   > Existing lexicals does not need this because they are implemented   
   > inside DCL.   
   >   
      
   And so is this new internal interface that you import. (And you do it via   
   some form of an import statement, not '@').   
      
   Once again, as explained previously, when a new version of DCL is built,   
   the output from the VMS language interface generator (which would now have   
   a DCL backend), is used to generate a module which is linked directly with   
   DCL during building. This means DCL is able to allow DCL scripts direct   
   access to all the system services/library functions/etc without the _script_   
   having to use the hack of some user-defined lexical.   
      
   > 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.   
   >   
      
   Your above example is wrong. That system_services call would have to   
   be inside an object you define in your script (assuming you really are   
   aiming for 100% backwards compatibility). When DCL sees an object reference   
   it calls the object handler (which is nice new code written in C, not   
   Macro-32).   
      
   Oh, and since it's within an object, you can use a string/integer in a   
   specific position in a list or indexed within a dictionary/associative   
   array as a parameter to that call. Some nice possibilities if you think   
   about it.   
      
   > 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.   
   >   
      
   Huh ? Why ? These are parameters available from anywhere within the script,   
   including old DCL and new DCL OO code. And once again, that new call has to   
   be inside a OO module that you write.   
      
   > 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.   
   >   
      
   No. All the new modern stuff is only supported from within objects you   
   define within your DCL scripts. All the traditional scripts are therefore   
   unaffected and 100% backwards compatible. If you think about it, keeping   
   all the new stuff isolated within objects you write is actually a very   
   clean approach to maintaining backwards compatibility.   
      
   Pretty much the same way you can write C using a C++ compiler, but can   
   also write full-blown C++ code with lots of advanced functionality when   
   compared to C. And also how you can mix C and C++ in the same program.   
      
   _Now_ do you see ? :-)   
      
   Simon.   
      
   --   
   Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP   
   Walking destinations on a map are further away than they appear.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)