On 2/3/2022 4:51 PM, VAXman-@SendSpamHere.ORG wrote:
> I Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> On 2/3/22 10:37, Arne Vajhøj wrote:
>>>>
>>>> A key thing in such tools are string handling.
>>>
>>> Any shortcomings in string handling in Fortran didn't seem to
>>> stop it from proving the 41 primitives and 50 utilities in
>>> STVOS.
>>>
>>
>> You can write a full-blown parser in Macro-32 if you really want to.
>
> I call LIB$T(ABLE_)PARSE. I have a state table in my DCL debugger with over
> 800 lines to parse escape sequences. That's not counting the action routines.
> I couldn't imagine doing it with that strtok() thang.
>
>
>
>> It doesn't mean that any sane person would want to do that when there
>> are better languages available. :-)
>
> SCAN? :P

SCAN sources are on a Freeware CD . . .

--

-- Rob

On 2/3/2022 5:53 PM, Robert A. Brooks wrote:
> On 2/3/2022 4:51 PM, VAXman-@SendSpamHere.ORG wrote:
>> I  Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> It doesn't mean that any sane person would want to do that when there
>>> are better languages available. :-)
>>
>> SCAN? :P
>
> SCAN sources are on a Freeware CD . . .

It says VAX and Alpha.

A quick glance says Bliss source.

Does it build on I64 and x86-64?

Arne

On 2/3/2022 6:05 PM, Arne Vajhøj wrote:
> On 2/3/2022 5:53 PM, Robert A. Brooks wrote:
>> On 2/3/2022 4:51 PM, VAXman-@SendSpamHere.ORG wrote:
>>> I  Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> It doesn't mean that any sane person would want to do that when there
>>>> are better languages available. :-)
>>>
>>> SCAN? :P
>>
>> SCAN sources are on a Freeware CD . . .
>
> It says VAX and Alpha.
>
> A quick glance says Bliss source.
>
> Does it build on I64 and x86-64?

I haven't tried, and I suspect that Reagan has been a bit
busy with other things.

--
-- Rob

On 2/3/2022 2:53 PM, Arne Vajhøj wrote:
> On 2/3/2022 12:04 PM, Bill Gunshannon wrote:
>> On 2/3/22 10:43, Arne Vajhøj wrote:
>>> On 2/3/2022 10:17 AM, Bill Gunshannon wrote:
>>>>> Pascal and the Modula variants offer far more than C. Fortran does not
>>>>> when it comes to implementing userland tools.
>>>>
>>>> Same question. In what way? I have already shown how Fortran was
>>>> used to write an entire userland for the first "POSIX" interface.
>>>> 41 primitives and 50 utilities.
>>> They tend to protect the developers feet a bit.
>>
>> How does one shoot themselves in the foot with Fortran? :-)
>
> Call a subroutine/function with the wrong type of argument.
>
> Use invalid character index.
>
> Use invalid array index.
>
> Have different declaration of same common block.

For those types of mistakes, the foot is the wrong target. Perhaps the head
would be more appropriate?

--
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 2/3/2022 1:43 PM, Simon Clubley wrote:

> BTW, sort-of related to this, does anyone else wish C was a module
> based language ?

I wish C just wasn't ...

--
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 2/3/22 18:15, Dave Froble wrote:
> On 2/3/2022 1:43 PM, Simon Clubley wrote:
>
>> BTW, sort-of related to this, does anyone else wish C was a module
>> based language ?
>
> I wish C just wasn't ...
>
>

Dave, you don't have to use it. Nobody holding a gun to your head.

bill

On Thursday, February 3, 2022 at 6:05:57 PM UTC-5, Arne Vajhøj wrote:
> On 2/3/2022 5:53 PM, Robert A. Brooks wrote:
> > On 2/3/2022 4:51 PM, VAX...@SendSpamHere.ORG wrote:
> >> I Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> >>> It doesn't mean that any sane person would want to do that when there
> >>> are better languages available. :-)
> >>
> >> SCAN? :P
> >
> > SCAN sources are on a Freeware CD . . .
> It says VAX and Alpha.
>
> A quick glance says Bliss source.
>
> Does it build on I64 and x86-64?
>
> Arne
Alpha, really? VAX SCAN used the VCG. I was unaware of a SCAN frontend hooking to GEM.

On Thursday, February 3, 2022 at 2:15:48 PM UTC-5, Simon Clubley wrote:
> On 2022-02-03, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> > On 2/3/22 10:37, Arne Vajhøj wrote:
> >>
> >> A key thing in such tools are string handling.
> >
> > Any shortcomings in string handling in Fortran didn't seem to
> > stop it from proving the 41 primitives and 50 utilities in
> > STVOS.
> >
> You can write a full-blown parser in Macro-32 if you really want to.
>
> It doesn't mean that any sane person would want to do that when there
> are better languages available. :-)
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Well, the Macro-32 parser is written in Macro-32.

On 2/3/2022 8:22 PM, John Reagan wrote:
> On Thursday, February 3, 2022 at 6:05:57 PM UTC-5, Arne Vajhøj wrote:
>> On 2/3/2022 5:53 PM, Robert A. Brooks wrote:
>>> On 2/3/2022 4:51 PM, VAX...@SendSpamHere.ORG wrote:
>>>> I Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>> It doesn't mean that any sane person would want to do that when there
>>>>> are better languages available. :-)
>>>>
>>>> SCAN? :P
>>>
>>> SCAN sources are on a Freeware CD . . .

>> It says VAX and Alpha.
>>
>> A quick glance says Bliss source.
>>
>> Does it build on I64 and x86-64?

> Alpha, really? VAX SCAN used the VCG. I was unaware of a SCAN frontend hooking to GEM.

https://vmssoftware.com/community/freeware/

says:

<quote>
VAXSCAN

VAX SCAN is a native mode high level language designed for text
processing that operates under the VMS Operating System. VAX SCAN
programs can invoke and be invoked by routines written in other VMS
languages as well as many Run-Time Library routines. This is the
complete VAX SCAN system, sources and all.

Architecture: VAX, Alpha
Authors: Glenn Everhart
</quote>

You say that it is VAX only?

Arne

On Thursday, February 3, 2022 at 8:31:57 PM UTC-5, Arne Vajhøj wrote:
> On 2/3/2022 8:22 PM, John Reagan wrote:
> > On Thursday, February 3, 2022 at 6:05:57 PM UTC-5, Arne Vajhøj wrote:
> >> On 2/3/2022 5:53 PM, Robert A. Brooks wrote:
> >>> On 2/3/2022 4:51 PM, VAX...@SendSpamHere.ORG wrote:
> >>>> I Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> >>>>> It doesn't mean that any sane person would want to do that when there
> >>>>> are better languages available. :-)
> >>>>
> >>>> SCAN? :P
> >>>
> >>> SCAN sources are on a Freeware CD . . .
>
> >> It says VAX and Alpha.
> >>
> >> A quick glance says Bliss source.
> >>
> >> Does it build on I64 and x86-64?
> > Alpha, really? VAX SCAN used the VCG. I was unaware of a SCAN frontend hooking to GEM.
> https://vmssoftware.com/community/freeware/
>
> says:
>
> <quote>
> VAXSCAN
>
> VAX SCAN is a native mode high level language designed for text
> processing that operates under the VMS Operating System. VAX SCAN
> programs can invoke and be invoked by routines written in other VMS
> languages as well as many Run-Time Library routines. This is the
> complete VAX SCAN system, sources and all.
>
> Architecture: VAX, Alpha
> Authors: Glenn Everhart
> </quote>
>
> You say that it is VAX only?
>
> Arne
That's my understanding.

On 2/3/2022 9:20 PM, John Reagan wrote:
> On Thursday, February 3, 2022 at 8:31:57 PM UTC-5, Arne Vajhøj wrote:
>> On 2/3/2022 8:22 PM, John Reagan wrote:
>>> On Thursday, February 3, 2022 at 6:05:57 PM UTC-5, Arne Vajhøj wrote:
>>>> On 2/3/2022 5:53 PM, Robert A. Brooks wrote:
>>>>> On 2/3/2022 4:51 PM, VAX...@SendSpamHere.ORG wrote:
>>>>>> I Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>>>> It doesn't mean that any sane person would want to do that when there
>>>>>>> are better languages available. :-)
>>>>>>
>>>>>> SCAN? :P
>>>>>
>>>>> SCAN sources are on a Freeware CD . . .
>>
>>>> It says VAX and Alpha.
>>>>
>>>> A quick glance says Bliss source.
>>>>
>>>> Does it build on I64 and x86-64?
>>> Alpha, really? VAX SCAN used the VCG. I was unaware of a SCAN frontend hooking to GEM.
>> https://vmssoftware.com/community/freeware/
>>
>> says:
>>
>> <quote>
>> VAXSCAN
>>
>> VAX SCAN is a native mode high level language designed for text
>> processing that operates under the VMS Operating System. VAX SCAN
>> programs can invoke and be invoked by routines written in other VMS
>> languages as well as many Run-Time Library routines. This is the
>> complete VAX SCAN system, sources and all.
>>
>> Architecture: VAX, Alpha
>> Authors: Glenn Everhart
>> </quote>
>>
>> You say that it is VAX only?
>>
> That's my understanding.

You should know.

It is probably just an error that is lists Alpha.

Arne

On 2/3/2022 9:27 PM, Arne Vajhøj wrote:
> On 2/3/2022 9:20 PM, John Reagan wrote:
>> On Thursday, February 3, 2022 at 8:31:57 PM UTC-5, Arne Vajhøj wrote:
>>> On 2/3/2022 8:22 PM, John Reagan wrote:
>>>> On Thursday, February 3, 2022 at 6:05:57 PM UTC-5, Arne Vajhøj wrote:
>>>>> It says VAX and Alpha.
>>>>>
>>>>> A quick glance says Bliss source.
>>>>>
>>>>> Does it build on I64 and x86-64?
>>>> Alpha, really? VAX SCAN used the VCG. I was unaware of a SCAN
>>>> frontend hooking to GEM.
>>> https://vmssoftware.com/community/freeware/
>>>
>>> says:
>>>
>>> <quote>
>>> VAXSCAN
....
>>> Architecture: VAX, Alpha
>>> Authors: Glenn Everhart
>>> </quote>
>>>
>>> You say that it is VAX only?
>>>
>> That's my understanding.
>
> You should know.
>
> It is probably just an error that is lists Alpha.

I looked at the kit again.

The readme's says:

"Also present are VESTED images for Alpha, built from the VAX images."

"Complete VAX SCAN sys + vested images for AXP
This is the complete VAX SCAN system, sources and all. Also present
are VESTED images for Alpha, built from the VAX images."

I guess VEST'ed VAX images would run on Alpha but emit VAX code??

Arne

On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
> On 2/3/2022 1:43 PM, Simon Clubley wrote:
>
>> BTW, sort-of related to this, does anyone else wish C was a module
>> based language ?
>
> I wish C just wasn't ...
>

What would be your suggested alternative for a system programming
language suitable for use within a kernel ?

Simon.

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

On 2/4/22 08:56, Simon Clubley wrote:
> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/3/2022 1:43 PM, Simon Clubley wrote:
>>
>>> BTW, sort-of related to this, does anyone else wish C was a module
>>> based language ?
>>
>> I wish C just wasn't ...
>>
>
> What would be your suggested alternative for a system programming
> language suitable for use within a kernel ?
>

PL/M. PL/I. Ada. And there are others as well. :-)

bill

On 2/4/2022 8:56 AM, Simon Clubley wrote:
> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/3/2022 1:43 PM, Simon Clubley wrote:
>>
>>> BTW, sort-of related to this, does anyone else wish C was a module
>>> based language ?
>>
>> I wish C just wasn't ...
>
> What would be your suggested alternative for a system programming
> language suitable for use within a kernel ?

There were plenty back in the days. IBM PL/S, DEC Bliss, HP SPL etc..
Disclaimer: I don't really know these languages.

For the future Rust seems like the only viable candidate. There is
strong OS interest for it. The interest for Go seems to focus
more on the layer just above the kernel (like container stuff).

Many would say C++ I guess, but I just got a gut feeling that C++
would either be "programming in C in C++" or the developers
would loose control of what is going on because one C++
statement end up executing a ton of code under the hood.

Arne

On 2/4/2022 8:56 AM, Simon Clubley wrote:
> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/3/2022 1:43 PM, Simon Clubley wrote:
>>
>>> BTW, sort-of related to this, does anyone else wish C was a module
>>> based language ?
>>
>> I wish C just wasn't ...
>>
>
> What would be your suggested alternative for a system programming
> language suitable for use within a kernel ?
>
> Simon.
>

Since you asked ...

An implementation of Basic that produced kernel and thread safe results.

--
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

In article <61fc2d6d$0$700$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> There is no argument type check between caller and called
> in Fortran.

There has been since Fortran90.

On 2/4/2022 12:36 PM, Phillip Helbig (undress to reply) wrote:
> In article <61fc2d6d$0$700$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> There is no argument type check between caller and called
>> in Fortran.
>
> There has been since Fortran90.

I do not see that.

$ type ts1_90.f90
! this should not compile with Fortran 77
program ts
real (kind=4) x
x = 123.456
call f(x)
end
$ type ts2_90.f90
! this should not compile with Fortran 77
subroutine f(x)
integer (kind=4) x
print *, x
end
$ for /warn=all ts1_90
$ for /warn=all ts2_90
$ link ts1_90 + ts2_90
$ run ts1_90
-377928714

Arne

On 2022-02-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/4/2022 8:56 AM, Simon Clubley wrote:
>> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> I wish C just wasn't ...
>>
>> What would be your suggested alternative for a system programming
>> language suitable for use within a kernel ?
>
> There were plenty back in the days. IBM PL/S, DEC Bliss, HP SPL etc..
> Disclaimer: I don't really know these languages.
>
> For the future Rust seems like the only viable candidate. There is
> strong OS interest for it. The interest for Go seems to focus
> more on the layer just above the kernel (like container stuff).
>

For now, Rust is highly fashionable, but so was Ruby at one time.

It really is a pity there isn't a viable Wirth style language in the mix
these days (_without_ mandatory uppercase keywords :-) ) that could
be used in kernel code. Readability and strong type safety (and improved
robustness in general) all in one language would sit very nicely with me.

> Many would say C++ I guess, but I just got a gut feeling that C++
> would either be "programming in C in C++" or the developers
> would loose control of what is going on because one C++
> statement end up executing a ton of code under the hood.
>

C++ is utterly unsuitable for use in a kernel IMHO. It simply has
way too much going on behind the scenes.

Simon.

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

On 2022-02-04, Dave Froble <davef@tsoft-inc.com> wrote:
> On 2/4/2022 8:56 AM, Simon Clubley wrote:
>> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> I wish C just wasn't ...
>>>
>>
>> What would be your suggested alternative for a system programming
>> language suitable for use within a kernel ?
>>
>
> Since you asked ...
>
> An implementation of Basic that produced kernel and thread safe results.
>

The problem there is that it would not be Basic in any meaningful sense.

Basic appears to have even more going on behind the scenes in some ways
than even C++ does. All that would have to disappear before you could
even consider using it in kernel code.

Simon.

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

On 2/4/2022 1:31 PM, Simon Clubley wrote:
> On 2022-02-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/4/2022 8:56 AM, Simon Clubley wrote:
>>> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> I wish C just wasn't ...
>>>
>>> What would be your suggested alternative for a system programming
>>> language suitable for use within a kernel ?
>>
>> There were plenty back in the days. IBM PL/S, DEC Bliss, HP SPL etc..
>> Disclaimer: I don't really know these languages.
>>
>> For the future Rust seems like the only viable candidate. There is
>> strong OS interest for it. The interest for Go seems to focus
>> more on the layer just above the kernel (like container stuff).
>>
>
> For now, Rust is highly fashionable, but so was Ruby at one time.

Ruby was pretty hot like 10 years ago. Ruby did not end up
taking over the world. But the language is still widely used
(I would call it a tier 2 language).

Rust's success is not guaranteed either. It got some good backing.
And it is a very narrow field. So I would say that it has a fair
chance.

But anything can happen. Maybe it will take over the world. Maybe
it will continue as a small but relevant language. Maybe it will die
within the next decade or two.

What are probabilities? 20%, 60% and 20% maybe.

> It really is a pity there isn't a viable Wirth style language in the mix
> these days (_without_ mandatory uppercase keywords :-) ) that could
> be used in kernel code. Readability and strong type safety (and improved
> robustness in general) all in one language would sit very nicely with me.

I agree.

But the industry went in another direction.

Pascal and Ada are niche languages (what I call tier 3 languages) and
Modula-2 is practically extinct.

Arne

On 2/4/2022 1:36 PM, Simon Clubley wrote:
> On 2022-02-04, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/4/2022 8:56 AM, Simon Clubley wrote:
>>> On 2022-02-03, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> I wish C just wasn't ...
>>>>
>>>
>>> What would be your suggested alternative for a system programming
>>> language suitable for use within a kernel ?
>>>
>>
>> Since you asked ...
>>
>> An implementation of Basic that produced kernel and thread safe results.
>>
>
> The problem there is that it would not be Basic in any meaningful sense.
>
> Basic appears to have even more going on behind the scenes in some ways
> than even C++ does. All that would have to disappear before you could
> even consider using it in kernel code.
>
> Simon.
>

As I mentioned, an implementation that addresses such concerns.

There could be option switches for desired targets.

I find the Basic syntax very easy to read, understand, and use. Isn't that the
most important thing?

--
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

jgd@cix.co.uk (John Dallman) writes:

> In article <29ad12ab-b1a7-4a44-b1fa-3d12812cf603n@googlegroups.com>,
> xyzzy1959@gmail.com (John Reagan) wrote:
> > On Thursday, February 3, 2022 at 2:15:48 PM UTC-5, Simon Clubley
> > > You can write a full-blown parser in Macro-32 if you really want
> > > to. It doesn't mean that any sane person would want to do that when
> > > there are better languages available. :-)
> > Well, the Macro-32 parser is written in Macro-32.
>
> That sounds as if someone got carried away by the power of the VAX
> instruction set, as compared with previous instruction sets they'd used.
>
> John

The PDP-10 macro assembler (Macro-10, Macro-20) is written in itself, and is
still in use as an intermediate step by the PDP-10 C compiler. Given that the
base code is 55 years old, and performs its job entirely adequately for modern
software development *in C*, why rewrite it (which by definition will introduce
new bugs)?

I suspect that the writer(s) of Macro-32 were familiar with the internals of
Macro-10...

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

In article <61fd68e5$0$699$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> On 2/4/2022 12:36 PM, Phillip Helbig (undress to reply) wrote:
> > In article <61fc2d6d$0$700$14726298@news.sunsite.dk>,
> > =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
> >> There is no argument type check between caller and called
> >> in Fortran.
> >
> > There has been since Fortran90.
>
> I do not see that.

You need to have an explicit interface.

On 2/4/2022 4:13 PM, Phillip Helbig (undress to reply) wrote:
> In article <61fd68e5$0$699$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> On 2/4/2022 12:36 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <61fc2d6d$0$700$14726298@news.sunsite.dk>,
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>>> There is no argument type check between caller and called
>>>> in Fortran.
>>>
>>> There has been since Fortran90.
>>
>> I do not see that.
>
> You need to have an explicit interface.

OK.

program ts
interface
subroutine f(x)
integer (kind=4) x
end subroutine
end interface
real (kind=4) x
x = 123.456
call f(x)
end

does give an error.

So Fortran 90 is up at the C level.

But that is still pretty bad compared to most other
languages.

Arne