On 1/10/2024 9:28 PM, bill wrote:
> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:

>> The world has evolved.
>
> Exactly. BASIC also evolved, but better languages have passed it by.
>
> bill

I confess to curiosity. In what ways has other languages passed by Basic?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/11/2024 8:56 AM, Simon Clubley wrote:
>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>>>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>
>>>>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>>>>> problem. The fact that there is also that 32 bit capability hanging around
>>>>> should not be a detriment, right?
>>>>>
>>>>
>>>> Try using RMS in totally 64-bit mode. Unless there's been further
>>>> development since, not everything in RMS had a 64-bit address option.
>>>>
>>>
>>> My understanding, which could be totally wrong, is that the major concept of "64
>>> bit" is about addresses.
>>>
>>
>> And that is exactly what I am talking about. Not everything in RMS had
>> a 64-bit addressing API the last time I checked.
>>
>> Simon.
>>
>
> Then I have to ask, "so what?"=
>

You claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.

> If RMS doesn't fit your requirements, then don't use it.

Everyone uses RMS, even if it hidden from you by the language. The RMS
references are still in the executable you create however.

>
> What does it matter how RMS works internally?
>
> Perhaps I'm just the old dog that cannot learn new tricks?
>

As above, you claimed that "totally 64 bit apps can be implemented on VMS".
I am showing you why that is not the case.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <unpa1b$3316l$2@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/10/2024 9:28 PM, bill wrote:
>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>> The world has evolved.
>>
>> Exactly. BASIC also evolved, but better languages have passed it by.
>
>I confess to curiosity. In what ways has other languages passed by Basic?

Usually the answer to this is going to be some combination of
better abstraction facilities, better safety properties, more
capable and ergonomic libraries, etc.

VSI BASIC appears to have a few useful things like static type
definitions, functions, etc, and it frees the programmer from
_having_ to specify e.g. line numbers. But it doesn't seem to
have a lot of support for other abstraction facilities like
modules, classes, or anything of that nature. String handling
seems anemic. There doesn't seem to be support for generalized
memory pointers, let along non-nullable references, so your
ability to create rich linked data structures seems limited. I
don't see any support for higher-order functions, lambdas, or
closures; no currying of functions. Statement modifiers seem
kind of neat, but I bet they can be easily misused.

All in all, it doesn't look like a terrible language (it's not
COBOL); it looks like an early-1980s-era language. But nothing
about it jumps out at me as being spectacularly amazing, either.

I suppose I would turn the question around and ask what's about
BASIC makes it more suitable than other languages for particular
types of programs?

- Dan C.

On 1/11/2024 1:17 PM, Simon Clubley wrote:
> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/11/2024 8:56 AM, Simon Clubley wrote:
>>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>>>>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>>>>>> problem. The fact that there is also that 32 bit capability hanging around
>>>>>> should not be a detriment, right?
>>>>>
>>>>> Try using RMS in totally 64-bit mode. Unless there's been further
>>>>> development since, not everything in RMS had a 64-bit address option.
>>>>
>>>> My understanding, which could be totally wrong, is that the major concept of "64
>>>> bit" is about addresses.
>>>
>>> And that is exactly what I am talking about. Not everything in RMS had
>>> a 64-bit addressing API the last time I checked.

That is correct. Practically only data related fields in RAB64
supports 64 bit addresses.

>> Then I have to ask, "so what?"=
>
> You claimed that "totally 64 bit apps can be implemented on VMS".
> I am showing you why that is not the case.

I guess that depends on what is meant by "totally 64 bit".

If it means that all addresses stored in process space whether
user code or VMS code are stored as 64 bit then it indeed seems
unlikely.

It it means that in user code all addresses are 64 bit, then that
should be doable.

>> If RMS doesn't fit your requirements, then don't use it.
>
> Everyone uses RMS, even if it hidden from you by the language. The RMS
> references are still in the executable you create however.

In practice yes.

In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
it is very cumbersome (especially if one cannot use RMS for stuff
like finding IFI).

Arne

On 2024-01-09 22:09:30 +0000, Lawrence D'Oliveiro said:

> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>
>> And again, what you are interested here in has been available for many
>> years via Sector 7.
>
> I’m not sure they did a comprehensive enough job. For instance, I
> remember the previous time this came up, reading between the lines in
> one of their case studies, the original customer scenario mentioned
> using DECnet, but that was missiong from the description of the
> solution.

In the traditional OpenVMS realm, porting apps to newer OpenVMS
architectures has never been transparent, whether with DECmigrate or
otherwise. Source code compatibility has been the goal, but full source
compatibility wasn't ever achieved. (q.v. OpenVMS porting manuals)

Nothing on the order of the transparency provided by Rosetta or Rosetta
2 has ever been available for OpenVMS.

As for DECnet networking, that's a sizable chunk of inner-mode code to
make that work, whether in OpenVMS or in Linux using the now-deprecated
DECnet code. OpenVMS uses an ACP and drivers, and provides an API known
as VCI. It might be workable to re-create a non-IP network stack in
user mode with some API at roughly the level of Linux (or OpenVMS) tap,
though how well that might perform at links running at tens of gigabits
per second and potentially faster? But for a user app being migrated
off of OpenVMS, might as well migrate the networking to IP APIs while
porting the code to the target Sector 7 environment.

Ain't nobody going to do a complete Sector 7 platform in one shot,
either. APIs and itemcodes will get dribbled out as needed and
available and tested, and the really obscure or arcane API usage stuff
will get re-written or replaced within the apps.

More generally, I'd also wonder why anybody would target the Linux
kernel for their kernel transplantation. Serious question. No insult
intended toward Linux here, but any kernel transplant best considers
all of the available open-source kernels, if the existing OpenVMS
kernel is not going to be preserved. Why would anybody pick the Linux
kernel for a transplant, over the other candidates? Picking Linux also
means GPL compliance is involved, and that makes things interesting as
VSI doesn't own full rights to the HPE-provided OpenVMS code.

--
Pure Personal Opinion | HoffmanLabs LLC

On 1/11/24 11:17 AM, Simon Clubley wrote:
> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/11/2024 8:56 AM, Simon Clubley wrote:
>>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>>>>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>
>>>>>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>>>>>> problem. The fact that there is also that 32 bit capability hanging around
>>>>>> should not be a detriment, right?
>>>>>>
>>>>>
>>>>> Try using RMS in totally 64-bit mode. Unless there's been further
>>>>> development since, not everything in RMS had a 64-bit address option.
>>>>>
>>>>
>>>> My understanding, which could be totally wrong, is that the major concept of "64
>>>> bit" is about addresses.
>>>>
>>>
>>> And that is exactly what I am talking about. Not everything in RMS had
>>> a 64-bit addressing API the last time I checked.
>>>
>>> Simon.
>>>
>>
>> Then I have to ask, "so what?"=
>>
>
> You claimed that "totally 64 bit apps can be implemented on VMS".
> I am showing you why that is not the case.
>
>> If RMS doesn't fit your requirements, then don't use it.
>
> Everyone uses RMS, even if it hidden from you by the language. The RMS
> references are still in the executable you create however.
>
>>
>> What does it matter how RMS works internally?
>>
>> Perhaps I'm just the old dog that cannot learn new tricks?
>>
>
> As above, you claimed that "totally 64 bit apps can be implemented on VMS".
> I am showing you why that is not the case.

Um, if I have a 64-bit app, that would mean I have complete access to
P0, P1, P2 space. Now, I choose to put some data structures in P0
space, does that mean that the app is suddenly no longer "totally 64-bit"?

I've written 64-bit apps. I've certainly never had to copy data from P2
space to P0 space because of some limitation. I've used both 32-bit and
64-bit item lists and descriptors, including dynamic descriptors. None
of the system services or RTL routines I used had any problem accepting
my parameters. Where in all of this, in your definition, has my app
stopped becoming a 64-bit app?

For me, it is ok for the documentation to say that a certain item needs
to be in P0 space. I have no problem putting there and I still have a
64-bit app with full access to 64-bit address space. Nothing the system
requires to be in P0 space is dynamic. It is set it up and forget it
(at least as far as anything I can remember using).

Mark Berryman

On 2024-01-09 21:35:00 +0000, John Dallman said:

> In article <unkd47$25cg2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
>
>> I suspect that all direct calls to LIB$ and SYS$ no matter if it is
>> Macro-32 or Fortran or C would have to be manually edited to use new 64
>> bit capable version, but that the various language RTL could switch to
>> 64 bit capable versions transparently.
>
> With a sufficiently regular naming scheme, a compiler could make
> substitutions, but I don't know if the current scheme will cope.

Cope nope. Best reasonably achievable is probably a lint-like tool
that'll scan for and point to problem areas.

Areas of "fun" will be itemlists, quota lists, and specific itemcodes
and APIs and app-level code that will probably need to be extended or
replaced such as UAI$_PWD.

Itemlists are great, right up until you hit the limit. And two passes
through an itemlist (first for sizing, second for buffers) is less than
optimal. (I've worked with message-passing APIs that are far cleaner;
that have less code cruft, and that hide the remapping involved.

OpenVMS is reminiscent of PDP-11 RSX-11M these days, in terms of all
the "fun" involved in keeping the 32-bit source code and 32-bit
binaries working.

And if the results of the 64-bit rework are centrally focused on source
code compatibility with the existing 32-/64-bit APIs and not with
having a flat 64-bit address space with 64-bit calls throughout, well,
why bother? Keep that stuff in the current 32-/64-bit world.

--
Pure Personal Opinion | HoffmanLabs LLC

On 1/10/2024 9:28 PM, bill wrote:
> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>> On 1/10/2024 6:54 PM, Lawrence D'Oliveiro wrote:
>>> On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:
>>>> I maintained and developed an ERP system consisting of well over a
>>>> million lines of code, which worked well to support our business
>>>
>>> So you got it to work, back in the day. Nowadays, there are easier
>>> ways of
>>> achieving the same thing. For one thing, you would have many existing
>>> libraries to draw on, instead of having to write all that code yourself.
>>
>> The world has evolved.
>
> Exactly.  BASIC also evolved, but better languages have passed it by.

You need to distinguish between VMS Basic and the broad family
of Basic.

VMS Basic a very nice language for writing business apps
back in the 1980's: all the control structures needed by
a procedural language, the needed types including decimal,
builtin support for index-sequential files, efficient code
etc..

That ERP system of over a million lines of code would
have been much larger if written in Cobol/Fortran/C.

In todays world VMS Basic are missing a lot: support
for object oriented programming, support for generic programming,
support for functional programming, libraries (database, ORM,
XML, JSON, HTTP etc.).

But that lack is not inherent for Basic. VB.NET got all that stuff.

In some cases the syntax is a little "obvious that this is a bolt-on
not something the language was born with", but it has it.

Arne

On 2024-01-10 20:17:03 +0000, Lawrence D'Oliveiro said:

> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>
>> ... I think BASIC did have a pretty good run in the 90's and early
>> 2000's, particularly on the Windows desktop platform.
>
> It had a role on 1980s micros, I’ll grant you that. The ability to
> switch on and start typing code made for quite a productive
> environment: type a statement with a line number to add it to your
> in-memory program, or without to execute the line immediately.
>
> Nowadays, Jupyter notebooks offer a more modern environment for such
> incremental, even scratchpad-style programming. And Python is a more
> modern language without the limitations of BASIC.

There's sufficient BASIC code that's still in active use to keep VSI
interested in providing at least some tooling for those OpenVMS
customers.

A whole lot of that BASIC code came through from the PDP-11 era
platforms and tools. It is entrenched.

Would I pick BASIC for wholly new app work? Probably not.

But there's a lot of BASIC code around that would otherwise need to be
reworked or rewritten. Or ported to BASIC on some other platform.

--
Pure Personal Opinion | HoffmanLabs LLC

On Thu, 11 Jan 2024 15:51:26 -0500, Stephen Hoffman wrote:

> Why would anybody pick the Linux kernel for a
> transplant, over the other candidates?

Because it already has the widest support for available hardware, and
filesystems, and network protocol stacks, and security layers, and
virtualization/containerization technologies, and other legacy emulators,
and other apps.

In short, it’s the place that will maximize your choices for other, future
migrations.

On 1/11/2024 2:42 PM, Dan Cross wrote:
> In article <unpa1b$3316l$2@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/10/2024 9:28 PM, bill wrote:
>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>> The world has evolved.
>>>
>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>
>> I confess to curiosity. In what ways has other languages passed by Basic?
>
> Usually the answer to this is going to be some combination of
> better abstraction facilities, better safety properties, more
> capable and ergonomic libraries, etc.
>
> VSI BASIC appears to have a few useful things like static type
> definitions, functions, etc, and it frees the programmer from
> _having_ to specify e.g. line numbers. But it doesn't seem to
> have a lot of support for other abstraction facilities like
> modules, classes, or anything of that nature. String handling
> seems anemic. There doesn't seem to be support for generalized
> memory pointers, let along non-nullable references, so your
> ability to create rich linked data structures seems limited. I
> don't see any support for higher-order functions, lambdas, or
> closures; no currying of functions. Statement modifiers seem
> kind of neat, but I bet they can be easily misused.
>
> All in all, it doesn't look like a terrible language (it's not
> COBOL);

Dave has his fixation on BASIC. One of mine is COBOL.
When using it to do the kind of work is was designed and intended for
just what do you think is wrong with COBOL?

bill

On 11/01/2024 21:13, Stephen Hoffman wrote:
> On 2024-01-10 20:17:03 +0000, Lawrence D'Oliveiro said:
>
>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>
>>> ... I think BASIC did have a pretty good run in the 90's and early
>>> 2000's, particularly on the Windows desktop platform.
>>
>> It had a role on 1980s micros, I’ll grant you that. The ability to
>> switch on and start typing code made for quite a productive
>> environment: type a statement with a line number to add it to your
>> in-memory program, or without to execute the line immediately.
>>
>> Nowadays, Jupyter notebooks offer a more modern environment for such
>> incremental, even scratchpad-style programming. And Python is a more
>> modern language without the limitations of BASIC.
>
> There's sufficient BASIC code that's still in active use to keep VSI
> interested in providing at least some tooling for those OpenVMS customers.
>
> A whole lot of that BASIC code came through from the PDP-11 era
> platforms and tools. It is entrenched.
>
> Would I pick BASIC for wholly new app work? Probably not.
>
> But there's a lot of BASIC code around that would otherwise need to be
> reworked or rewritten. Or ported to BASIC on some other platform.
>
Our million plus lines suite indeed did start on PDP, but was expanded
very significantly under VMS.

I found loads of ghastly code used to do what was later in a single
built in function...

--
Chris

On 1/11/2024 1:17 PM, Simon Clubley wrote:
> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/11/2024 8:56 AM, Simon Clubley wrote:
>>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>>>>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>
>>>>>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>>>>>> problem. The fact that there is also that 32 bit capability hanging around
>>>>>> should not be a detriment, right?
>>>>>>
>>>>>
>>>>> Try using RMS in totally 64-bit mode. Unless there's been further
>>>>> development since, not everything in RMS had a 64-bit address option.
>>>>>
>>>>
>>>> My understanding, which could be totally wrong, is that the major concept of "64
>>>> bit" is about addresses.
>>>>
>>>
>>> And that is exactly what I am talking about. Not everything in RMS had
>>> a 64-bit addressing API the last time I checked.
>>>
>>> Simon.
>>>
>>
>> Then I have to ask, "so what?"=
>>
>
> You claimed that "totally 64 bit apps can be implemented on VMS".
> I am showing you why that is not the case.
>
>> If RMS doesn't fit your requirements, then don't use it.
>
> Everyone uses RMS, even if it hidden from you by the language. The RMS
> references are still in the executable you create however.

For text files, that is correct. One does not need to use RMS indexed and
relative files.

>>
>> What does it matter how RMS works internally?
>>
>> Perhaps I'm just the old dog that cannot learn new tricks?
>>
>
> As above, you claimed that "totally 64 bit apps can be implemented on VMS".
> I am showing you why that is not the case.
>
> Simon.
>

There is a slight difference between "can be" and "always will be".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
> On 1/11/2024 1:17 PM, Simon Clubley wrote:
>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 1/11/2024 8:56 AM, Simon Clubley wrote:
>>>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>>>>>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>> As far as I know, totally 64 bit apps can be implemented on VMS. So,
>>>>>>> what's the
>>>>>>> problem. The fact that there is also that 32 bit capability hanging around
>>>>>>> should not be a detriment, right?
>>>>>>
>>>>>> Try using RMS in totally 64-bit mode. Unless there's been further
>>>>>> development since, not everything in RMS had a 64-bit address option.
>>>>>
>>>>> My understanding, which could be totally wrong, is that the major concept
>>>>> of "64
>>>>> bit" is about addresses.
>>>>
>>>> And that is exactly what I am talking about. Not everything in RMS had
>>>> a 64-bit addressing API the last time I checked.
>
> That is correct. Practically only data related fields in RAB64
> supports 64 bit addresses.
>
>>> Then I have to ask, "so what?"=
>>
>> You claimed that "totally 64 bit apps can be implemented on VMS".
>> I am showing you why that is not the case.
>
> I guess that depends on what is meant by "totally 64 bit".
>
> If it means that all addresses stored in process space whether
> user code or VMS code are stored as 64 bit then it indeed seems
> unlikely.
>
> It it means that in user code all addresses are 64 bit, then that
> should be doable.
>
>>> If RMS doesn't fit your requirements, then don't use it.
>>
>> Everyone uses RMS, even if it hidden from you by the language. The RMS
>> references are still in the executable you create however.
>
> In practice yes.
>
> In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
> it is very cumbersome (especially if one cannot use RMS for stuff
> like finding IFI).
>
> Arne
>

And if one is using a database product that has nothing to do with RMS ???

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/11/2024 2:42 PM, Dan Cross wrote:
> In article <unpa1b$3316l$2@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/10/2024 9:28 PM, bill wrote:
>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>> The world has evolved.
>>>
>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>
>> I confess to curiosity. In what ways has other languages passed by Basic?
>
> Usually the answer to this is going to be some combination of
> better abstraction facilities, better safety properties, more
> capable and ergonomic libraries, etc.

Which then asks the question, are such really better? Perhaps some of that is
more opinion than fact.

Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.

> VSI BASIC appears to have a few useful things like static type
> definitions, functions, etc, and it frees the programmer from
> _having_ to specify e.g. line numbers. But it doesn't seem to
> have a lot of support for other abstraction facilities like
> modules, classes, or anything of that nature.

What amuses me about that is that when people talk about "classes", I don't have
a clue what they are talking about. Perhaps I do, if the case is new names for
old concepts. That is something I didn't like about Microsoft, they seemed to
like re-naming concepts.

> String handling
> seems anemic.

Can't let that one go. Basic in my opinion does strings very well.

> There doesn't seem to be support for generalized
> memory pointers,

Correct, Basic does not have any pointer data types. It does have a function to
retrieve the value of a pointer.

> let along non-nullable references, so your
> ability to create rich linked data structures seems limited.

Not sure what that means ...

> I
> don't see any support for higher-order functions,

Not sure what that means ...

> lambdas,

Not sure what that means ...

> or
> closures;

Not sure what that means ...

> no currying of functions.

Not sure what that means ...

> Statement modifiers seem
> kind of neat, but I bet they can be easily misused.

Statement modifiers are very useful, and in some ways make code easier to
understand.

> All in all, it doesn't look like a terrible language (it's not
> COBOL); it looks like an early-1980s-era language. But nothing
> about it jumps out at me as being spectacularly amazing, either.

It''s not amazing, it just works.

> I suppose I would turn the question around and ask what's about
> BASIC makes it more suitable than other languages for particular
> types of programs?

For me personally, I really like the syntax of the language. When I have to
attempt to read C code I'm easily confused. Many other languages seem to copy
the syntax of C.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Fri, 12 Jan 2024 00:40:47 -0500, Dave Froble wrote:

> Basic in my opinion does strings very well.

Only if you measure it by the pre-Perl era.

On 12/01/2024 06:15, Lawrence D'Oliveiro wrote:
> On Fri, 12 Jan 2024 00:40:47 -0500, Dave Froble wrote:
>
>> Basic in my opinion does strings very well.
>
> Only if you measure it by the pre-Perl era.

Perl is the work of the devil!

--
Chris

On 1/12/2024 12:08 AM, Dave Froble wrote:
> On 1/11/2024 3:48 PM, Arne Vajhøj wrote:
>> On 1/11/2024 1:17 PM, Simon Clubley wrote:
>>> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> If RMS doesn't fit your requirements, then don't use it.
>>>
>>> Everyone uses RMS, even if it hidden from you by the language. The RMS
>>> references are still in the executable you create however.
>>
>> In practice yes.
>>
>> In theory one can use SYS$QIO(W) for all IO and bypass RMS. But
>> it is very cumbersome (especially if one cannot use RMS for stuff
>> like finding IFI).
>
> And if one is using a database product that has nothing to do with RMS ???

I would still expect that database product to use RMS to open
the database file even if the actual IO is done by
SYS$QIO(W) / SYS$IO_PERFORM(W) or via memory mapped file.

Arne

On 2024-01-11, Mark Berryman <mark@theberrymans.com> wrote:
>
> Um, if I have a 64-bit app, that would mean I have complete access to
> P0, P1, P2 space. Now, I choose to put some data structures in P0
> space, does that mean that the app is suddenly no longer "totally 64-bit"?
>

No, not if it is your choice instead of some API restriction.

> I've written 64-bit apps. I've certainly never had to copy data from P2
> space to P0 space because of some limitation. I've used both 32-bit and
> 64-bit item lists and descriptors, including dynamic descriptors. None
> of the system services or RTL routines I used had any problem accepting
> my parameters. Where in all of this, in your definition, has my app
> stopped becoming a 64-bit app?
>

The moment you are forced to keep something at a location that can be
reached by a 32-bit address because of an API restriction that does not
have a 64-bit alternative, such as those seen in the RMS APIs.

That includes if the language RTL is doing the 32-bit API access for you
without it ever being explicit in your code.

> For me, it is ok for the documentation to say that a certain item needs
> to be in P0 space. I have no problem putting there and I still have a
> 64-bit app with full access to 64-bit address space. Nothing the system
> requires to be in P0 space is dynamic. It is set it up and forget it
> (at least as far as anything I can remember using).
>

Yes, but that's doesn't meet David's claim of being able to create a pure
64-bit application. I was replying to that and nothing else.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-12, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/11/2024 2:42 PM, Dan Cross wrote:
>> In article <unpa1b$3316l$2@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 1/10/2024 9:28 PM, bill wrote:
>>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>>> The world has evolved.
>>>>
>>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>>
>>> I confess to curiosity. In what ways has other languages passed by Basic?
>>
>> Usually the answer to this is going to be some combination of
>> better abstraction facilities, better safety properties, more
>> capable and ergonomic libraries, etc.
>
> Which then asks the question, are such really better? Perhaps some of that is
> more opinion than fact.
>
> Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
>
>> VSI BASIC appears to have a few useful things like static type
>> definitions, functions, etc, and it frees the programmer from
>> _having_ to specify e.g. line numbers. But it doesn't seem to
>> have a lot of support for other abstraction facilities like
>> modules, classes, or anything of that nature.
>
> What amuses me about that is that when people talk about "classes", I don't have
> a clue what they are talking about. Perhaps I do, if the case is new names for
> old concepts. That is something I didn't like about Microsoft, they seemed to
> like re-naming concepts.
>

This is absolutely nothing to do with Microsoft. It is a general language
concept/construct.

Sorry David, but you don't understand this and the other items Dan lists,
then you are not qualified to judge the relative merits of other languages
to BASIC.

[Snip other examples]

>
>> I suppose I would turn the question around and ask what's about
>> BASIC makes it more suitable than other languages for particular
>> types of programs?
>
> For me personally, I really like the syntax of the language. When I have to
> attempt to read C code I'm easily confused. Many other languages seem to copy
> the syntax of C.
>

I suggest you look at the Wirth-style languages then. They are nothing
like C.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <l0bi9hFgf55U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 1/11/2024 2:42 PM, Dan Cross wrote:
>> In article <unpa1b$3316l$2@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 1/10/2024 9:28 PM, bill wrote:
>>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>>> The world has evolved.
>>>>
>>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>>
>>> I confess to curiosity. In what ways has other languages passed by Basic?
>>
>> Usually the answer to this is going to be some combination of
>> better abstraction facilities, better safety properties, more
>> capable and ergonomic libraries, etc.
>>
>> VSI BASIC appears to have a few useful things like static type
>> definitions, functions, etc, and it frees the programmer from
>> _having_ to specify e.g. line numbers. But it doesn't seem to
>> have a lot of support for other abstraction facilities like
>> modules, classes, or anything of that nature. String handling
>> seems anemic. There doesn't seem to be support for generalized
>> memory pointers, let along non-nullable references, so your
>> ability to create rich linked data structures seems limited. I
>> don't see any support for higher-order functions, lambdas, or
>> closures; no currying of functions. Statement modifiers seem
>> kind of neat, but I bet they can be easily misused.
>>
>> All in all, it doesn't look like a terrible language (it's not
>> COBOL);
>
>Dave has his fixation on BASIC. One of mine is COBOL.
>When using it to do the kind of work is was designed and intended for
>just what do you think is wrong with COBOL?

Nothing per se, I just wanted to give you a rise. :-)
(Sorry; couldn't resist.)

- Dan C.

In article <unqjcn$3c1o2$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/11/2024 2:42 PM, Dan Cross wrote:
>> In article <unpa1b$3316l$2@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 1/10/2024 9:28 PM, bill wrote:
>>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>>> The world has evolved.
>>>>
>>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>>
>>> I confess to curiosity. In what ways has other languages passed by Basic?
>>
>> Usually the answer to this is going to be some combination of
>> better abstraction facilities, better safety properties, more
>> capable and ergonomic libraries, etc.
>
>Which then asks the question, are such really better? Perhaps some of that is
>more opinion than fact.

Some of it is opinion. Some of it is limitations in the
language. Some of it is suitability for purpose.

>Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.

Understood.

>> VSI BASIC appears to have a few useful things like static type
>> definitions, functions, etc, and it frees the programmer from
>> _having_ to specify e.g. line numbers. But it doesn't seem to
>> have a lot of support for other abstraction facilities like
>> modules, classes, or anything of that nature.
>
>What amuses me about that is that when people talk about "classes", I don't have
>a clue what they are talking about. Perhaps I do, if the case is new names for
>old concepts. That is something I didn't like about Microsoft, they seemed to
>like re-naming concepts.

I'm not sure what Microsoft has to do with it. The concept of a
"class" has existed in one form or the others since Simula in
1967.

>> String handling
>> seems anemic.
>
>Can't let that one go. Basic in my opinion does strings very well.

What do you like about it?

Consider writing a lexical analyzer for a simple expression
language; what would such a thing look like, in BASIC? Here I
want to take a string as input, and emit a list of tokens that
correspond to the elements of the langauge that are represented
in that string.

>> There doesn't seem to be support for generalized
>> memory pointers,
>
>Correct, Basic does not have any pointer data types. It does have a function to
>retrieve the value of a pointer.

That makes it challenging to implement dynamically sized data
structures like trees or graphs where the size is not already
known, or hash tables that use chaining for collision resolution
etc.

How would I do these things in VSI BASIC?

>> let along non-nullable references, so your
>> ability to create rich linked data structures seems limited.
>
>Not sure what that means ...

Basically, pointers that are always valid in pointing to an
object of a known type and and that can never be nil.

>> I
>> don't see any support for higher-order functions,
>
>Not sure what that means ...

Basically, functions that can be passed as arguments to other
functions or functions that can be returned from functions.
These let me do things like write a generic hash table
implementation, where I can then parameterize calls into the
resulting data type with functions that implement the actual
hash for particular types of data. "Hash table of FOO."

>> lambdas,
>
>Not sure what that means ...

Anonymous functions; ie, functions that are unnamed. They're
very handy in languages that support higher-order functions.
For example, I can trivially write a projection function that
will extract a particular member from a data structure to use
as a sort key.

>> or
>> closures;
>
>Not sure what that means ...

Functions that are created dynamically and "close over" part of
their surrounding environment, e.g., to capture a value that is
used in the closure itself.

>> no currying of functions.
>
>Not sure what that means ...

Partial application of a function, which allows me to create a
new function that calls some underlying function with some
arguments already "filled in". An example, from SML:

fun fib' a b 0 = a
| fib' a b n = fib' (a + b) a (n - 1)

val fib = fib' 0 1

Here `fib` is a function to return the nth Fibonacci
number.

This example demonstrates several of these concepts:

; sml
Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
- val fib =
= let fun fib' a b 0 = a
= | fib' a b n = fib' (a + b) a (n - 1)
= in fn n => fib' 0 1 n
= end;
val fib = fn : int -> int
- fib;
val it = fn : int -> int
- fib';
stdIn:3.1-3.5 Error: unbound variable or constructor: fib'
- map;
val it = fn : ('a -> 'b) -> 'a list -> 'b list
- map (fn n => fib n) [1,2,3,4,5,6,7,8,9];
val it = [1,1,2,3,5,8,13,21,34] : int list
- ^D
;

Here, we see an example of a closure, in which the anonymous
function (aka, lambda) returned from the `let` clause that is
bound to `fib` closes over the `fib'` function, which is not
visible outside of the `let`. Furthermore, `fib` is an example
of currying as above. We see the use of higher-order functions
in the call to `map`, which applies `fib` to each element of the
given list. We can see it again with a slightly different
example:

- List.tabulate(10, fn n => fib n);
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
val it = [0,1,1,2,3,5,8,13,21,34] : int list

Again, these are all examples from Standard ML, a langauge that
dates from the 80s, and takes its roots in the 70s.

>> Statement modifiers seem
>> kind of neat, but I bet they can be easily misused.
>
>Statement modifiers are very useful, and in some ways make code easier to
>understand.

I'm sure they are useful, but I can also imagine that they can
turn into spaghetti if not used judiciously.

X = X * 0.1 unless FOO != 2;
X = X * 0.2 unless FOO = 2;

seems strictly less readable than

IF FOO != 2
X = X * 0.1
ELSE
X = X * 0.2

(Apologies for syntax errors.)

>> All in all, it doesn't look like a terrible language (it's not
>> COBOL); it looks like an early-1980s-era language. But nothing
>> about it jumps out at me as being spectacularly amazing, either.
>
>It's not amazing, it just works.

Sure. That doesn't mean that it's good by modern standards.

>> I suppose I would turn the question around and ask what's about
>> BASIC makes it more suitable than other languages for particular
>> types of programs?
>
>For me personally, I really like the syntax of the language. When I have to
>attempt to read C code I'm easily confused. Many other languages seem to copy
>the syntax of C.

As has been mentioned, not all "modern" languages have C-like
syntax. Examples that pop out at me off the top of my head
include Oberon (Wirth's final language, descendent of Modula-2),
Ruby, Python, Clojure (a Lisp that targets the JVM), F# (a
dialect of the OCaml language --- another entry in the ML
family --- that targets the CLR), OCaml itself (with a native
compiler). Most of these are 20 years old or more; the youngest
language on the list is probably Clojure, which is only 17, but
has its root in Lisp, which dates from the 50s.

Simply preferring the syntax, however, doesn't feel like
sufficient reason to claim that other languages haven't passed
BASIC, even VSI BASIC, by. I'm sure it was a decent business
data processing langauge in the 80s; not so much now days.

- Dan C.

In article <unra5q$3eha8$1@dont-email.me>,
Chris Townley <news@cct-net.co.uk> wrote:
>On 12/01/2024 06:15, Lawrence D'Oliveiro wrote:
>> On Fri, 12 Jan 2024 00:40:47 -0500, Dave Froble wrote:
>>
>>> Basic in my opinion does strings very well.
>>
>> Only if you measure it by the pre-Perl era.
>
>Perl is the work of the devil!

Please don't feed the troll.

- Dan C.

On 1/12/2024 8:41 AM, Simon Clubley wrote:
> On 2024-01-12, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/11/2024 2:42 PM, Dan Cross wrote:
>>> In article <unpa1b$3316l$2@dont-email.me>,
>>> Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 1/10/2024 9:28 PM, bill wrote:
>>>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>>>> The world has evolved.
>>>>>
>>>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>>>
>>>> I confess to curiosity. In what ways has other languages passed by Basic?
>>>
>>> Usually the answer to this is going to be some combination of
>>> better abstraction facilities, better safety properties, more
>>> capable and ergonomic libraries, etc.
>>
>> Which then asks the question, are such really better? Perhaps some of that is
>> more opinion than fact.
>>
>> Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
>>
>>> VSI BASIC appears to have a few useful things like static type
>>> definitions, functions, etc, and it frees the programmer from
>>> _having_ to specify e.g. line numbers. But it doesn't seem to
>>> have a lot of support for other abstraction facilities like
>>> modules, classes, or anything of that nature.
>>
>> What amuses me about that is that when people talk about "classes", I don't have
>> a clue what they are talking about. Perhaps I do, if the case is new names for
>> old concepts. That is something I didn't like about Microsoft, they seemed to
>> like re-naming concepts.
>>
>
> This is absolutely nothing to do with Microsoft. It is a general language
> concept/construct.
>
> Sorry David, but you don't understand this and the other items Dan lists,
> then you are not qualified to judge the relative merits of other languages
> to BASIC.

I won't argue that, because it's quite likely true. I don't use or pay
attention to other languages. Perhaps I've settled into my own level of
incompetence.

What I do know is that I've never had any problems that I could not solve using
Basic. Then again, we all know I don't get out much.

> [Snip other examples]
>
>>
>>> I suppose I would turn the question around and ask what's about
>>> BASIC makes it more suitable than other languages for particular
>>> types of programs?
>>
>> For me personally, I really like the syntax of the language. When I have to
>> attempt to read C code I'm easily confused. Many other languages seem to copy
>> the syntax of C.
>>
>
> I suggest you look at the Wirth-style languages then. They are nothing
> like C.

Did that long ago. Was disgusting ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

The first thing I'll admit is that computers are used for far more things than
I've been exposed to.

I have no clue on the design and implementation of GUI stuff.

I have no clue on the design and implementation of real time stuff, self driving
cars, navigation, and such.

I've got friends and relatives that use computers for music, though, they are
users, not developers.

And much more ...

My background has been business applications, database design and
implementation, and sometimes system type stuff, sometimes called system
programming. I've implemented a few interesting tools. Async messaging systems
are interesting, and helpful.

Overall, your post is interesting.

On 1/12/2024 12:26 PM, Dan Cross wrote:
> In article <unqjcn$3c1o2$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/11/2024 2:42 PM, Dan Cross wrote:
>>> In article <unpa1b$3316l$2@dont-email.me>,
>>> Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 1/10/2024 9:28 PM, bill wrote:
>>>>> On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
>>>>>> The world has evolved.
>>>>>
>>>>> Exactly. BASIC also evolved, but better languages have passed it by.
>>>>
>>>> I confess to curiosity. In what ways has other languages passed by Basic?
>>>
>>> Usually the answer to this is going to be some combination of
>>> better abstraction facilities, better safety properties, more
>>> capable and ergonomic libraries, etc.
>>
>> Which then asks the question, are such really better? Perhaps some of that is
>> more opinion than fact.
>
> Some of it is opinion. Some of it is limitations in the
> language. Some of it is suitability for purpose.

Suitability for purpose is always rather important.

>> Below, when I write Basic, I'm referring to DEC/Compaq/HP/VSI Basic.
>
> Understood.
>
>>> VSI BASIC appears to have a few useful things like static type
>>> definitions, functions, etc, and it frees the programmer from
>>> _having_ to specify e.g. line numbers. But it doesn't seem to
>>> have a lot of support for other abstraction facilities like
>>> modules, classes, or anything of that nature.
>>
>> What amuses me about that is that when people talk about "classes", I don't have
>> a clue what they are talking about. Perhaps I do, if the case is new names for
>> old concepts. That is something I didn't like about Microsoft, they seemed to
>> like re-naming concepts.
>
> I'm not sure what Microsoft has to do with it. The concept of a
> "class" has existed in one form or the others since Simula in
> 1967.
>
>>> String handling
>>> seems anemic.
>>
>> Can't let that one go. Basic in my opinion does strings very well.
>
> What do you like about it?
>
> Consider writing a lexical analyzer for a simple expression
> language; what would such a thing look like, in BASIC? Here I
> want to take a string as input, and emit a list of tokens that
> correspond to the elements of the langauge that are represented
> in that string.

Don't totally understand, perhaps parsing for commands, switches, and such would
be similar.

>>> There doesn't seem to be support for generalized
>>> memory pointers,

A pointer data type can be very useful. A compiler could use such to generate
proper sizing for different systems. But, in the end, it is just a numeric
piece of data. If one can process the numbers, that works. Not as generic,
but, it works. For VAX, it is an unsigned longword. For 64 bit addressing, it
is an unsigned 64 bit integer.

For example, what is the difference between memory pointers and indices in an in
memory resident data structure, such as linked lists? Not much, in concept, right?

>> Correct, Basic does not have any pointer data types. It does have a function to
>> retrieve the value of a pointer.
>
> That makes it challenging to implement dynamically sized data
> structures like trees or graphs where the size is not already
> known, or hash tables that use chaining for collision resolution
> etc.

Not really. There is always LIB$GET_VM.

> How would I do these things in VSI BASIC?

Once you can get the memory, what's the difference between say, linked lists
there, vs using pre-allocated array(s)?

>>> let along non-nullable references, so your
>>> ability to create rich linked data structures seems limited.
>>
>> Not sure what that means ...
>
> Basically, pointers that are always valid in pointing to an
> object of a known type and and that can never be nil.

Seems to me, pointers/indices in use always have a valid value?

>>> I
>>> don't see any support for higher-order functions,
>>
>> Not sure what that means ...
>
> Basically, functions that can be passed as arguments to other
> functions or functions that can be returned from functions.
> These let me do things like write a generic hash table
> implementation, where I can then parameterize calls into the
> resulting data type with functions that implement the actual
> hash for particular types of data. "Hash table of FOO."

Hash tables takes me back to the mid 1970s. :-)

Is what you mean something like:

Z = FIX( SQR( SomeValue ) )

Yeah, rather simple, but is that what you refer to?

>>> lambdas,
>>
>> Not sure what that means ...
>
> Anonymous functions; ie, functions that are unnamed. They're
> very handy in languages that support higher-order functions.
> For example, I can trivially write a projection function that
> will extract a particular member from a data structure to use
> as a sort key.

Not sure if you're making my brain hurt, or discussing something so simple it
doesn't deserve a name. I've built sort keys for longer than I can remember.

>>> or
>>> closures;
>>
>> Not sure what that means ...
>
> Functions that are created dynamically and "close over" part of
> their surrounding environment, e.g., to capture a value that is
> used in the closure itself.

More brain pain ...

>>> no currying of functions.
>>
>> Not sure what that means ...
>
> Partial application of a function, which allows me to create a
> new function that calls some underlying function with some
> arguments already "filled in". An example, from SML:
>
> fun fib' a b 0 = a
> | fib' a b n = fib' (a + b) a (n - 1)
>
> val fib = fib' 0 1
>
> Here `fib` is a function to return the nth Fibonacci
> number.

Why does that require a special name?

> This example demonstrates several of these concepts:
>
> ; sml
> Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
> - val fib =
> = let fun fib' a b 0 = a
> = | fib' a b n = fib' (a + b) a (n - 1)
> = in fn n => fib' 0 1 n
> = end;
> val fib = fn : int -> int
> - fib;
> val it = fn : int -> int
> - fib';
> stdIn:3.1-3.5 Error: unbound variable or constructor: fib'
> - map;
> val it = fn : ('a -> 'b) -> 'a list -> 'b list
> - map (fn n => fib n) [1,2,3,4,5,6,7,8,9];
> val it = [1,1,2,3,5,8,13,21,34] : int list
> - ^D
> ;
>
> Here, we see an example of a closure, in which the anonymous
> function (aka, lambda) returned from the `let` clause that is
> bound to `fib` closes over the `fib'` function, which is not
> visible outside of the `let`. Furthermore, `fib` is an example
> of currying as above. We see the use of higher-order functions
> in the call to `map`, which applies `fib` to each element of the
> given list. We can see it again with a slightly different
> example:
>
> - List.tabulate(10, fn n => fib n);
> [autoloading]
> [library $SMLNJ-BASIS/basis.cm is stable]
> [library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
> [autoloading done]
> val it = [0,1,1,2,3,5,8,13,21,34] : int list
>
> Again, these are all examples from Standard ML, a langauge that
> dates from the 80s, and takes its roots in the 70s.

I'm going to guess that your experience includes labels for certain things,
which might be helpful at times, and exist in subsets of programming practices.
Nothing wrong with that, but might be confusing to some others.

>>> Statement modifiers seem
>>> kind of neat, but I bet they can be easily misused.
>>
>> Statement modifiers are very useful, and in some ways make code easier to
>> understand.
>
> I'm sure they are useful, but I can also imagine that they can
> turn into spaghetti if not used judiciously.
>
> X = X * 0.1 unless FOO != 2;
> X = X * 0.2 unless FOO = 2;
>
> seems strictly less readable than
>
> IF FOO != 2
> X = X * 0.1
> ELSE
> X = X * 0.2
>
> (Apologies for syntax errors.)