Hi there!

Just interesting is the name for VMS coding style, any references ?
Hungarian ? White ? Any other ?

On 9/28/2021 12:33 PM, El SysMan wrote:
> Just interesting is the name for VMS coding style, any references ?
> Hungarian ? White ? Any other ?

You are asking about VMS specific naming conventions and
code formatting style?

There is a convention for DEC/CPQ/HP(E)/VSI stuff to use $ and
own stuff to use _. Never heard of a name for it.

Regarding location of {} in C family languages then
I have never heard of a VMS style. C programmers
use the style they use elsewhere, whatever that is.
Java developers follow Java convention. Etc..

Arne

On 2021-09-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/28/2021 12:33 PM, El SysMan wrote:
>> Just interesting is the name for VMS coding style, any references ?
>> Hungarian ? White ? Any other ?
>
> You are asking about VMS specific naming conventions and
> code formatting style?
>
> There is a convention for DEC/CPQ/HP(E)/VSI stuff to use $ and
> own stuff to use _. Never heard of a name for it.
>
> Regarding location of {} in C family languages then
> I have never heard of a VMS style. C programmers
> use the style they use elsewhere, whatever that is.
> Java developers follow Java convention. Etc..
>

$ set response/mode=good_natured_troll

And the sensible programmers all use Whitesmiths... :-)

Simon.

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

On 2021-09-28 16:33:47 +0000, El SysMan said:

> Just interesting is the name for VMS coding style, any references ?
> Hungarian ? White ? Any other ?

The old unique-by-convention symbol naming scheme is obviously
analogous to / derivative from Hungarian notation, but AFAIK doesn't
have a specific name.

The manual that this material was included within seems to have
disappeared from the current VSI documentation, but here's an older
copy; see chapter 3 for details:

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04623122

There wasn't a source code formatter around, though astyle and some
other tools have been used in more recent years. These tools do not
apply the variable naming.

OpenVMS itself commonly uses SDL (available on the freeware), and SDL
can and usually does generate symbols using the traditional
symbol-naming format.

--
Pure Personal Opinion | HoffmanLabs LLC

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

> On 9/28/2021 12:33 PM, El SysMan wrote:
> > Just interesting is the name for VMS coding style, any references ?
> > Hungarian ? White ? Any other ?
>
> You are asking about VMS specific naming conventions and
> code formatting style?
>
> There is a convention for DEC/CPQ/HP(E)/VSI stuff to use $ and
> own stuff to use _. Never heard of a name for it.
>
> Regarding location of {} in C family languages then
> I have never heard of a VMS style. C programmers
> use the style they use elsewhere, whatever that is.
> Java developers follow Java convention. Etc..

Fortran programmers can program Fortran in any language. :-)

On Wed, 29 Sep 2021 08:00:21 +0000, Phillip Helbig (undress to reply)
wrote:

> In article <6153494b$0$692$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>> On 9/28/2021 12:33 PM, El SysMan wrote:
>> > Just interesting is the name for VMS coding style, any references ?
>> > Hungarian ? White ? Any other ?
>>
>> You are asking about VMS specific naming conventions and code
>> formatting style?
>>
>> There is a convention for DEC/CPQ/HP(E)/VSI stuff to use $ and own
>> stuff to use _. Never heard of a name for it.
>>
>> Regarding location of {} in C family languages then I have never heard
>> of a VMS style. C programmers use the style they use elsewhere,
>> whatever that is.
>> Java developers follow Java convention. Etc..
>
> Fortran programmers can program Fortran in any language. :-)

I once had to fix someone's ALGOL program. Labels in columns 1-5, code
starting in column 7, minimal use of control constructs in excess of the
most basic...

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On Wednesday, 29 September 2021 at 6:33:11 am UTC+9:30, Stephen Hoffman wrote:
> On 2021-09-28 16:33:47 +0000, El SysMan said:
>
>
> OpenVMS itself commonly uses SDL (available on the freeware), and SDL
> can and usually does generate symbols using the traditional
> symbol-naming format.

> --
> Pure Personal Opinion | HoffmanLabs LLC

Before SDL there was MDL (Maynard Definition Language) which was simpler than SDL
(I emulated it in DCL) but which used the same symbol conventions.

I suspect MDL went back to the RSX days which puts it in the same time frame as
Hungarian Notation (1970ish) so they may be independent.

On 9/29/2021 4:22 AM, Bob Eager wrote:
> On Wed, 29 Sep 2021 08:00:21 +0000, Phillip Helbig (undress to reply)
> wrote:
>
>> In article <6153494b$0$692$14726298@news.sunsite.dk>,
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>
>>> On 9/28/2021 12:33 PM, El SysMan wrote:
>>>> Just interesting is the name for VMS coding style, any references ?
>>>> Hungarian ? White ? Any other ?
>>>
>>> You are asking about VMS specific naming conventions and code
>>> formatting style?
>>>
>>> There is a convention for DEC/CPQ/HP(E)/VSI stuff to use $ and own
>>> stuff to use _. Never heard of a name for it.
>>>
>>> Regarding location of {} in C family languages then I have never heard
>>> of a VMS style. C programmers use the style they use elsewhere,
>>> whatever that is.
>>> Java developers follow Java convention. Etc..
>>
>> Fortran programmers can program Fortran in any language. :-)
>
> I once had to fix someone's ALGOL program. Labels in columns 1-5, code
> starting in column 7, minimal use of control constructs in excess of the
> most basic...

Oh yes.

I posted this here a few months ago when this particular topic came up.

"Pascal" code:

PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.

Arne

On 2021-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I posted this here a few months ago when this particular topic came up.
>
> "Pascal" code:
>
> PROGRAM GOTOFUN(INPUT,OUTPUT);
> LABEL L731,L113,L247,L588,L761,L922,L399,L601;
> VAR LBL:INTEGER;
> VAR I:INTEGER;
> BEGIN
> L731: GOTO L113;
> LBL:=399;
> L113: I:=0;
> WRITELN(I);
> L247: LBL:=601;
> IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
> L588: I:=I+1;
> WRITELN(I);
> GOTO L399;
> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;

Is that a computed goto implemented in Pascal ????????????? :-)

Wow.

I wonder if it's possible to also make assigned goto (which was even
more brain damaged IMHO) work in Pascal ?

IOW, do any Pascal variants allow you to goto a label held within
a variable ? (I hope not, but you never know.)

I have absolutely no idea BTW if you can do this - I've never tried
to do anything like that in Pascal.

> L922: I:=I+1;
> WRITELN(I);
> CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
> L399: GOTO L761;
> L601: END.
>

Simon.

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

On 9/29/2021 9:02 AM, Simon Clubley wrote:
> On 2021-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I posted this here a few months ago when this particular topic came up.
>>
>> "Pascal" code:
>>
>> PROGRAM GOTOFUN(INPUT,OUTPUT);
>> LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>> VAR LBL:INTEGER;
>> VAR I:INTEGER;
>> BEGIN
>> L731: GOTO L113;
>> LBL:=399;
>> L113: I:=0;
>> WRITELN(I);
>> L247: LBL:=601;
>> IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
>> L588: I:=I+1;
>> WRITELN(I);
>> GOTO L399;
>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>
> Is that a computed goto implemented in Pascal ????????????? :-)
>
> Wow.
>
> I wonder if it's possible to also make assigned goto (which was even
> more brain damaged IMHO) work in Pascal ?
>
> IOW, do any Pascal variants allow you to goto a label held within
> a variable ? (I hope not, but you never know.)
>
> I have absolutely no idea BTW if you can do this - I've never tried
> to do anything like that in Pascal.

No - it is emulating assigned goto as I don't think you can save a label
in a variable.

>> L922: I:=I+1;
>> WRITELN(I);
>> CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;

This is the computed goto.

>> L399: GOTO L761;
>> L601: END.

Arne

On 2021-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> No - it is emulating assigned goto as I don't think you can save a label
> in a variable.
>

Thanks Arne.

That code was so horrible I wasn't 100% sure what it was doing.

It looks like it was written by the kind of person who probably
wishes Hollerith constants were still a thing. :-)

Simon.

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

On 9/29/21 1:46 PM, Simon Clubley wrote:
> On 2021-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> No - it is emulating assigned goto as I don't think you can save a label
>> in a variable.
>>
>
> Thanks Arne.
>
> That code was so horrible I wasn't 100% sure what it was doing.

Stylistically, yes, it was horrible. But I had no problem
understanding it. But then, I have been doing production
Pascal for over 40 years.

>
> It looks like it was written by the kind of person who probably
> wishes Hollerith constants were still a thing. :-)

I doubt anyone still wants Hollerith constants. They were
needed once but those days are long gone.

bill

On Thursday, September 30, 2021 at 1:11:35 PM UTC+13, Bill Gunshannon wrote:
> I doubt anyone still wants Hollerith constants.

I remember in my younger days thinking how neat they were. You could have any (printable, at least) characters you liked in the string, no escaping conventions necessary.

Thanks for answers OLD$K_BOYS! :-)

On Thursday, 30 September 2021 at 5:30:33 pm UTC+9:30, El SysMan wrote:
> Thanks for answers OLD$K_BOYS! :-)

I think that should be OLD$L_BOYS as in Long ... in the tooth.

On 2021-09-29, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 9/29/21 1:46 PM, Simon Clubley wrote:
>> On 2021-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> No - it is emulating assigned goto as I don't think you can save a label
>>> in a variable.
>>>
>>
>> Thanks Arne.
>>
>> That code was so horrible I wasn't 100% sure what it was doing.
>
> Stylistically, yes, it was horrible. But I had no problem
> understanding it. But then, I have been doing production
> Pascal for over 40 years.
>

That wasn't Pascal Bill. :-) That was FORTRAN IV code using
Pascal syntax. :-)

Simon.

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

On 2021-09-30, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Thursday, September 30, 2021 at 1:11:35 PM UTC+13, Bill Gunshannon wrote:
>> I doubt anyone still wants Hollerith constants.
>
> I remember in my younger days thinking how neat they were. You could have any (printable, at least) characters you liked in the string, no escaping conventions necessary.

So it turns out you are a fixed-length field type of person after all. :-)

Simon.

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

On Thursday, September 30, 2021 at 1:38:06 AM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, September 30, 2021 at 1:11:35 PM UTC+13, Bill Gunshannon wrote:
> > I doubt anyone still wants Hollerith constants.
> I remember in my younger days thinking how neat they were. You could have any (printable, at least) characters you liked in the string, no escaping conventions necessary.

I still think they are neat, and wish SQL supported it.

On 2021-09-30 12:13:20 +0000, Simon Clubley said:

> On 2021-09-30, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>> On Thursday, September 30, 2021 at 1:11:35 PM UTC+13, Bill Gunshannon wrote:
>>>
>>> I doubt anyone still wants Hollerith constants.
>>
>> I remember in my younger days thinking how neat they were. You could
>> have any (printable, at least) characters you liked in the string, no
>> escaping conventions necessary.
>
> So it turns out you are a fixed-length field type of person after all. :-)

Having UTF-8 string support and raw string support in a platform and in
a programming language makes most of this encoding a non-issue. In
Swift, for instance. ObjC does pretty well here, too.

This change is pervasive within a platform, both for the effort
involved to get everything (shell, compilers, editors, libraries)
working, and then for what can be done within the applications with
rather less of the syntactic obfuscation.

This does get ugly when you have to retrofit support into platforms and
apps, particularly with a platform that supports ASCII or DEC MCS / ISO
Latin 1 and that lacks robust Unicode and UTF-8 support.

There's a reason many old server apps tend to look dated...

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/30/2021 12:40 PM, Stephen Hoffman wrote:
> On 2021-09-30 12:13:20 +0000, Simon Clubley said:
>> On 2021-09-30, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>>> On Thursday, September 30, 2021 at 1:11:35 PM UTC+13, Bill Gunshannon
>>> wrote:
>>>>
>>>> I doubt anyone still wants Hollerith constants.
>>>
>>> I remember in my younger days thinking how neat they were. You could
>>> have any (printable, at least) characters you liked in the string, no
>>> escaping conventions necessary.
>>
>> So it turns out you are a fixed-length field type of person after all.
>> :-)
>
> Having UTF-8 string support and raw string support in a platform and in
> a programming language makes most of this encoding a non-issue.

I don't see why UTF-8 support should solve the problem of having
to escape the character used for string start and end.

And most platforms ten to use UTF-16 internally (memory) and
UTF-8 externally (IO).

> This change is pervasive within a platform, both for the effort involved
> to get everything (shell, compilers, editors, libraries) working, and
> then for what can be done within the applications with rather less of
> the syntactic obfuscation.
>
> This does get ugly when you have to retrofit support into platforms and
> apps,

As PHP 6 showed.

Arne

On Friday, October 1, 2021 at 2:21:45 AM UTC+13, osuv...@gmail.com wrote:
>
> On Thursday, September 30, 2021 at 1:38:06 AM UTC-4, Lawrence D’Oliveiro wrote:
>
>> On Thursday, September 30, 2021 at 1:11:35 PM UTC+13, Bill Gunshannon wrote:
>>
>>> I doubt anyone still wants Hollerith constants.
>>
>> I remember in my younger days thinking how neat they were. You could have any
>> (printable, at least) characters you liked in the string, no escaping conventions
>> necessary.
>
> I still think they are neat, and wish SQL supported it.

Given that you need escaping for non-printable characters, I suppose the loss in requiring them for quote characters as well (and the escape character itself) is small.

I can imagine people getting fed up with the tedium of counting how many characters were in their literals. Though I suppose having coding forms with numbered columns made this easier. And in Emacs, I can select the text and type alt-equals to find out exactly how many characters it contains.

On the flip side, you then have some fun when nesting one language in another. I once wrote some Python code which was outputting a web page with embedded JavaScript that was in turn generating further dynamic page content. I had up to seven backslashes in a row in places.

On Friday, October 1, 2021 at 5:40:57 AM UTC+13, Stephen Hoffman wrote:
>
> Having UTF-8 string support and raw string support in a platform and in
> a programming language makes most of this encoding a non-issue.

And don’t forget identifiers. Unicode offers many creative ways of avoiding collisions with reserved words. For example, it might be quite natural for a routine which copies data from a producer to a consumer (with some processing along the way) to have arguments named “in” and “out”, but if (as in Python) “in” is a reserved word, you can substitute “ın” instead!

And I already mentioned being able to have “∕” in filenames, because *nix systems interpret “/” as the path component separator.

On Friday, October 1, 2021 at 1:12:25 AM UTC+13, Simon Clubley wrote:
> That wasn't Pascal Bill. :-) That was FORTRAN IV code using
> Pascal syntax. :-)

All together now ...

*Real Programmers Can Write FORTRAN In Any Language!*

Really, though, as a sometime Pascal fan, all those redundant parentheses made me twitch. Yes, its simplified* operator precedence rules did require a fair few parentheses in places, but not where that program used them.

*Not to say limited

On Friday, October 1, 2021 at 5:54:43 AM UTC+13, Arne Vajhøj wrote:
>
> And most platforms ten to use UTF-16 internally (memory) ...

UTF-16 was a face-saving compatibility hack which nobody voluntarily uses. It dates from the first versions of Unicode, when the standards committee assured everybody that, to paraphrase, “16 bits ought to be enough for anybody!”, that Unicode was UCS-2, now and for the future. And certain companies -- Sun with Java, Microsoft with Windows NT, Apple with HFS-Plus -- took them at their word.

Then a few years later the Unicode people changed their minds, and decided we weren’t just going to represent writing scripts in current use, but all the historical ones as well, so we needed something more like 20 bits (for now). And so the “surrogates” blocks were allocated, and what was originally UCS-2 was now redefined as UTF-16, to allow those abovementioned systems to be hacked to deal with the new reality.