From: arne@vajhoej.dk
On 12/6/2025 12:14 PM, Brian Schenkenberger wrote:
> On Dec 6, 2025, at 10:57, Arne Vajhøj via Info-vax
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 there’s something not available in DCL today that one believes would
benefit by being called
> as if a lexical, it’s 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, it’s 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.
I’d
> 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 aren’t “integers” 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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
