From Newsgroup: comp.os.vms

On 12/6/2025 12:14 PM, Brian Schenkenberger wrote:

On Dec 6, 2025, at 10:57, Arne Vajh|+j via Info-vax <info-vax@rbnsn.com> wrote:

On 12/6/2025 10:33 AM, Arne Vajh|+j wrote:

On 12/6/2025 5:42 AM, Marc Van Dyck wrote:

User written lexical functions, on the other hand, would be a real
bonus. There are, for one, still many parts of the operating system
for which you need to get information, and the only possible way to do >>>> it is to parse some output (think of everything TCP/IP, for example),
while there is a callable interface available to get the info properly. >>> Yes.

And even though it is possible to run an exe that set a symbol
with lib$set_symbol, then getting it as a lexical would make it
more readable.

Note that VSI could add it to existing DCL:

f$udl(shrimg, arg1, ...)

with a convention of entry point:

int udl$function(int narg, enum dcl_type *argtyp, void *argval, enum dcl_typ *rettyp, void *retval)

If they wanted to.

New lexical functions have been added over time.

I'll try but likely a waste of time as my posts do not seem to make it through via the mailing list.

I got to the mail list, but none of the two news servers
I checked.

Many years ago, I extended DCL with a lexical extension. I called it F$X. There was much talk
at the time about being able to add site lexicals to DCL, so I did the grunt work to see if I could
add such a mechanism. This fell out of my work on the DCL Debugger I was working on at the
time.

IMNSHO, this is not a great idea. DCL programs will be written and shared, and people will not
have the particular extended lexical code. What language will the extended code be written in
if it is shared? C? What if a site doesn't possess a C compiler license?

It would be a generic VMS shareable image, VMS calling standard to
provide the capability.

People could make them in C or Pascal or Macro-32 or ...

If someone want to share some DCL and the source of the extension,
then recipient would need the relevant compiler.

But I think that is a fair restriction.

If thererCOs something not available in DCL today that one believes would benefit by being called
as if a lexical, itrCOs be better to simply write a program that can accept command line arguments
via LIB$GET_FOREIGN, CLI$ and CLD definition, or a combination thereof with LIB$TPARSE
and, if necessary, store results in a symbol.

That is and always have been a possibility.

Just not quite as elegant as a lexical function.

Extensive programs written in DCL are slow! Sure, itrCOs easy to make quick edits and fixes, but
DCL is not nor should it be considered a programming language like compiled languages.

That is definitely good advice.

But at least historically then programming in DCL has happened.

There is a book to prove it.

IrCOd
prefer to see, if something new were to be added, support for larger integer math (ie. 64 bit) is
my request. Of course, it *is* possible now but takes some special effort to perform such math
using F$fao() and the results really arenrCOt rCLintegersrCY as far as DCL is concerned.

That could also be useful.

64 bit or go all the way aka unlimited (there are of course
practical limits)?

But that may require changes to real DCL.

I don't see a DCL pre-processor adding that. It could
add type declaration and store values as string.
Like PHP BC. But every operation would be something
externally. Performance would suck.

Arne





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/6/2025 3:47 PM, Brian Schenkenberger wrote:

On Dec 6, 2025, at 15:23, Arne Vajh|+j via Info-vax <info-vax@rbnsn.com> wrote:

I have always wanted something like:

dcl.init() # open pseudo terminal
res1 = dcl.do(command1) # send command to pseudo terminal and return
output
...
resn = dcl.do(commandn) # send command to pseudo terminal and return
output
dcl.close() # close pseudo terminal

PTD$ routines exist today.

I know.

However, yourCOd need a process with DCL mapped
connected
with the pseudo-terminal to execute the command you pass to it.

I know.

YourCOd be no better off
than if you used a PIPE because that process is NOT the process for
which you may be
seeking the information (ie. SHOW PROCESS).

That model would mean a Python process and a DCL process. A
process duo.

And yes that could be a problem in some cases.

But in most cases I would expect both to either not be
interested in processes or be interested in other processes
than themselves.

I really had to bend over backward to have my DCL debugger work in/with
the current
process because I wanted to be able to debug DCL in the process
environment where a
problem may persent itself. (eg. quotas, rights, privileges, defaults,
etc.) Debugging DCL
in a BATCH or NETWORK process was another goal. Debugging DCL in environments
that are NOT interactive are quite different and there are often
problems that the author
doesnrCOt see until his|her procedure is executing in those environments.

DCL debugger is probably a bit different. It is by definition interested
in its own process. More difficult problem I think.

More advanced requirements means more advanced solution needed.

BTW, what is status of your DCL debugger? Commercial available?
Free available? Sitting on the shelf?

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2