| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 107:36:10 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,678 |
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
On 01/01/2025 16:12, Arne Vajhøj wrote:
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Interesting - many thanks
I was surprised to see that Pascal was created in 2970!
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
I was surprised to see that Pascal was created in 2970!
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
Arne
Arne Vajhøj has brought this to us :
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
In the first section, you might also mention that VMS Pascal has
excellent support in LSE/SCA - for those who still use DECset...
Didn't see anything about the VARYING type and its so useful
<varying>.BODY and <varying>.LENGTH functions, as well as READV and
WRITEV. Probably the most important things to know if you have to
manipulate character strings.
May be also mention that the VMS Pascal compiler comes with declaration modules for all VMS system services and RTLs. Combined with LSE/SCA
support, this makes system programming extremely easy.
Ah, and also, good support of VMS Pascal by SDL...
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That’s how files like STARLET.PAS get automatically generated.
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
On 1/2/2025 7:34 PM, Lawrence D'Oliveiro wrote:
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That’s
how files like STARLET.PAS get automatically generated.
I know what it is is.
On Thu, 2 Jan 2025 20:49:43 -0500, Arne Vajhøj wrote:
On 1/2/2025 7:34 PM, Lawrence D'Oliveiro wrote:
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That’s
how files like STARLET.PAS get automatically generated.
I know what it is is.
It’s also not that hard to understand, if you take the “Rosetta Stone” approach of looking at the original SDL source and comparing with its
output for a particular language that you know.
There was also one called MDL, if I recall rightly, which looked like it
was more on the MACRO level.
On 1/2/2025 5:19 PM, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
On 1/2/2025 8:52 PM, Arne Vajhøj wrote:
On 1/2/2025 5:19 PM, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
It's written in C++ so we were waiting for a native C++ compiler.
As it turns out, SDL uncovered some dark areas of the compiler that needed addressing.
We have a working SDL on X86 now.
On 1/2/2025 10:29 PM, Robert A. Brooks wrote:
On 1/2/2025 8:52 PM, Arne Vajhøj wrote:
On 1/2/2025 5:19 PM, Arne Vajhøj wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
:-)
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
It's written in C++ so we were waiting for a native C++ compiler.
As it turns out, SDL uncovered some dark areas of the compiler that needed >> addressing.
We have a working SDL on X86 now.
I thought it was PL/I. Which is why I asked.
On 1/2/2025 7:34 PM, Lawrence D'Oliveiro wrote:
On Thu, 2 Jan 2025 17:19:14 -0500, Arne Vajh°j wrote:
On 1/2/2025 5:01 AM, Marc Van Dyck wrote:
Ah, and also, good support of VMS Pascal by SDL...
Too advanced for me.
SDL is just the common language used for defining interfaces. That?s how
files like STARLET.PAS get automatically generated.
I know what it is is. Otherwise I could not have commented on
the level.
On 1/2/2025 10:32 PM, Arne Vajhøj wrote:
On 1/2/2025 10:29 PM, Robert A. Brooks wrote:
On 1/2/2025 8:52 PM, Arne Vajhøj wrote:
But speaking of SDL.
Does anybody know what VSI's plan is for SDL on VMS x86-64?
Rewrite?
It's written in C++ so we were waiting for a native C++ compiler.
As it turns out, SDL uncovered some dark areas of the compiler that
needed
addressing.
We have a working SDL on X86 now.
I thought it was PL/I. Which is why I asked.
Rewritten in the early 2000's.
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
On 1/2/2025 10:48 PM, Robert A. Brooks wrote:
On 1/2/2025 10:32 PM, Arne Vajhøj wrote:
I thought it was PL/I. Which is why I asked.
Rewritten in the early 2000's.
Ah. So it was rewritten for Itanium instead of being AEST'ed.
I wonder whether it was because someone at HP decided
to do the right thing or because AEST couldn't handle
it.
In article <vl3pi8$2r2sr$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
C supports 'long double' which _may_ be the same as
`quadruple`, depending on the implementation, though
that's usually 80-bit floats.
I would not say that 'chr' and 'ord' are like casts in C.
Pascal is strongly, statically typed; C is weakly typed with
implicit conversions. Conversion between characters and integer
types in Pascal is an explicit operation, but `int c = 'a' + 1;`
is perfectly legal in C.
You give two C equivalents of, `round`: `lround` and
`ceil(v + 0.5)`. Surely the latter should be `trunc(v + 0.5)`:
But, consider negative numbers,
and note that one would still
have to do a conversion to an integer type.
Your C equivalent of `substr` is not correct; exercise left to
the reader (consider what happens when `ix` is beyond the end of
the string). For that matter, this is true of the VSI Pascal
example as well: you should specify the preconditions that must
be true.
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
You may want to mention that Pascal, the semicolon is a
statement separator, not a terminator, and hence why the last
"END" in the protocol is followed by "." and not ";".
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
On 1/3/2025 10:11 AM, Dan Cross wrote:
In article <vl3pi8$2r2sr$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
VMS Pascal for C/Java/C# programmers:
https://www.vajhoej.dk/arne/articles/vmspascal.html
It is a "pre-release" - I am not sure I got it right.
So I would love some feedback.
C supports 'long double' which _may_ be the same as
`quadruple`, depending on the implementation, though
that's usually 80-bit floats.
Very good point. It is 128 bit on VMS unless using /L_DOUBLE=64.
Added.
I would not say that 'chr' and 'ord' are like casts in C.
Pascal is strongly, statically typed; C is weakly typed with
implicit conversions. Conversion between characters and integer
types in Pascal is an explicit operation, but `int c = 'a' + 1;`
is perfectly legal in C.
It was the best explanation I could come up with.
You give two C equivalents of, `round`: `lround` and
`ceil(v + 0.5)`. Surely the latter should be `trunc(v + 0.5)`:
Ooops. All ceil should be floor.
Fixed.
But, consider negative numbers,
Very good point.
I have added notes.
and note that one would still
have to do a conversion to an integer type.
Yes.
Fixed.
Your C equivalent of `substr` is not correct; exercise left to
the reader (consider what happens when `ix` is beyond the end of
the string). For that matter, this is true of the VSI Pascal
example as well: you should specify the preconditions that must
be true.
Invalid index or length causes an exception in VMS Pascal.
But I don't want to get into that level of detail.
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
Close enough for the purpose of this article.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
Fixed.
You may want to mention that Pascal, the semicolon is a
statement separator, not a terminator, and hence why the last
"END" in the protocol is followed by "." and not ";".
The article is more what to do than why to do that.
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
In article <67781447$0$711$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 10:11 AM, Dan Cross wrote:
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
Close enough for the purpose of this article.
Perhaps. I may be worth an asterisk, as often C programmers
will want to write:
while ((s = fgets(s, len, fp)) != NULL) {
char *nl = strchr(s, '\n');
if (nl != NULL)
*nl = '\0';
}
Which is a bit more cumbersome than the Pascal equivalent. When
carriage returns get mixed in, it gets even nastier, so much so
that one may just write a helper function to deal with it.
I think you are right. I have added a note.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
Fixed.
Fixed, but the comparison to C is slightly wrong:
`while not(eof(f)) do` is not exactly the same as
`while(!feof(f))`. In particular, while in VSI Pascal `EOF(f)`
will be true on the first iteration of the loop if `f` is empty,
the same is not true for `feof` from stdio: in order for `feof`
to be true, stdio must observe the end-of-file condition of `f`
via some input operation. This leads to awkward code sequences
like this:
ch = fgetc(fp);
while (!feof(fp)) {
/*
* Do something with `ch`
* ...
*/
ch = fgetc(fp);
}
C feof is a crap function.
I think I will drop feof completely and add fgetc
not returning EOF. I already have fgets not returning NULL.
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Also, it's a bit of a bummer that you didn't mention nested
functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
There is already an example. fac is inside testfac.
I will add a note about it.
In article <67781447$0$711$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 10:11 AM, Dan Cross wrote:
`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.
Close enough for the purpose of this article.
Perhaps. I may be worth an asterisk, as often C programmers
will want to write:
while ((s = fgets(s, len, fp)) != NULL) {
char *nl = strchr(s, '\n');
if (nl != NULL)
*nl = '\0';
}
Which is a bit more cumbersome than the Pascal equivalent. When
carriage returns get mixed in, it gets even nastier, so much so
that one may just write a helper function to deal with it.
`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.
Fixed.
Fixed, but the comparison to C is slightly wrong:
`while not(eof(f)) do` is not exactly the same as
`while(!feof(f))`. In particular, while in VSI Pascal `EOF(f)`
will be true on the first iteration of the loop if `f` is empty,
the same is not true for `feof` from stdio: in order for `feof`
to be true, stdio must observe the end-of-file condition of `f`
via some input operation. This leads to awkward code sequences
like this:
ch = fgetc(fp);
while (!feof(fp)) {
/*
* Do something with `ch`
* ...
*/
ch = fgetc(fp);
}
The structure you present at the end as "equivalent" of a
varying character array is not correct. `integer16` is a signed
type, with a maximum value of 32,767. The length field for a
`varying [n] of char` is an integer subrange type with word
representation. That is, `length` is unsigned 0..max, where max
is <= 65,535.
Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
Also, it's a bit of a bummer that you didn't mention nested functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
Regardless, it may be worthwhile to
at least mention it, since you state explicitly that there are
three types for representing textual, string-like data, but
VSI's documentation makes it clear that there are actually four.
Also, it's a bit of a bummer that you didn't mention nested
functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
There is already an example. fac is inside testfac.
I will add a note about it.
Ah, I see it now; the lack of indentation makes it hard to spot.
On 1/3/2025 1:51 PM, Dan Cross wrote:
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
I never use string (on VMS).
$ search sys$common:[syshlp.examples.pascal]*.pas varying
$ search sys$common:[syshlp.examples.pascal]*.pas "string("
indicate that whoever write VMS Pascal examples also prefer
varying of char over string.
If I were to guess about why, then I believe it is historic
reasons. varying of char has been there since like forever.
string was added with ISO Pascal support later.
Regardless, it may be worthwhile to
at least mention it, since you state explicitly that there are
three types for representing textual, string-like data, but
VSI's documentation makes it clear that there are actually four.
Good point.
I have updated.
Also, it's a bit of a bummer that you didn't mention nested
functions/procedures, which are among the cooler aspects of the
language:
$ type foo.pas
(* foo *)
program foo(output);
procedure hello;
procedure world(var who: String);
function punct: char;
begin
punct := '!'
end;
begin
who := 'World' + punct
end;
var
who: String (10);
begin
world(who);
writeln('Hello, ', who)
end;
begin
hello
end.
There is already an example. fac is inside testfac.
I will add a note about it.
Ah, I see it now; the lack of indentation makes it hard to spot.
I don't indent them.
With the blank lines I put in then I feel that indenting
nested procedures/functions would make it too much space.
In article <6778415e$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:51 PM, Dan Cross wrote:
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
I never use string (on VMS).
$ search sys$common:[syshlp.examples.pascal]*.pas varying
$ search sys$common:[syshlp.examples.pascal]*.pas "string("
indicate that whoever write VMS Pascal examples also prefer
varying of char over string.
If I were to guess about why, then I believe it is historic
reasons. varying of char has been there since like forever.
string was added with ISO Pascal support later.
I suspect that's close, but ISO Pascal doesn't have a 'VARYING'
array type, either.
I suspect you're referring to what ISO calls "Extended Pascal"
(ISO 10206); ISO Pascal (ISO 7185) doesn't support a `String`
type of either the VSI Pascal form or the Turbo
Pascal/Delphi/FreePascal form, only manifest string literals and
`packed array [1..n] of char`. Of course, one can define a type
alias, and ISO 7185 says this:
|Any type designated packed and denoted by an array-type having
|as its index-type a denotation of a subrange-type specifying a
|smallest value of 1 and a largest value of greater than 1, and
|having as its component-type a denotation of the char-type,
|shall be designated a string-type.
An annoyance with ISO Pascal is that an array's size is part of
its type, and there is no separate slice type that could act
as a window into an array independent of size and be passed
around, so it is difficult to write procedures and functions
that operate on e.g. strings, generically. See also, >https://www.lysator.liu.se/c/bwk-on-pascal.html
However, these deficiencies are largely addressed in ISO 10206
Extended Pascal, which provides a variable-length string type
and permits conformant array parameters, which for VSI Pascal
appear to monomorphize over the argument type.
... I feel that indenting nested
procedures/functions would make it too much space.
On Fri, 3 Jan 2025 14:58:22 -0500, Arne Vajhøj wrote:
... I feel that indenting nested
procedures/functions would make it too much space.
At an indentation step of 4 columns and a window width of typically 100 columns, I find that leaves room for plenty of indentation steps.
In article <6778415e$0$708$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:51 PM, Dan Cross wrote:
In article <vl9aln$o72$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2025 1:17 PM, Dan Cross wrote:
In article <67781447$0$711$14726298@news.sunsite.dk>,
And also fixed in the description of VARYING further up.
You should seriously mention the STRING type, though.
I think VARYING OF CHAR is what is used most in VMS Pascal.
Weird; I can't imagine why.
I never use string (on VMS).
$ search sys$common:[syshlp.examples.pascal]*.pas varying
$ search sys$common:[syshlp.examples.pascal]*.pas "string("
indicate that whoever write VMS Pascal examples also prefer
varying of char over string.
If I were to guess about why, then I believe it is historic
reasons. varying of char has been there since like forever.
string was added with ISO Pascal support later.
I suspect that's close, but ISO Pascal doesn't have a 'VARYING'
array type, either.
I suspect you're referring to what ISO calls "Extended Pascal"
(ISO 10206); ISO Pascal (ISO 7185) doesn't support a `String`
type of either the VSI Pascal form or the Turbo
Pascal/Delphi/FreePascal form, only manifest string literals and
`packed array [1..n] of char`.
In article <vl9khp$cdg$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
However, these deficiencies are largely addressed in ISO 10206
Extended Pascal, which provides a variable-length string type
and permits conformant array parameters, which for VSI Pascal
appear to monomorphize over the argument type.
Actually, I guess that conformant array parameterss were in ISO
7185, which had two "levels" of compliance; level 0 omitted them
and level 1 includes them. That language is retained in ISO
10206. Original, Wirth Pascal does not have them.
Extended Pascal's variable string type appears more or less
identical to the string type in VSI Pascal.