Hi,

Disclaimer: Title of posting is provocative on purpose :-).
In EPLI we have the OPTIONAL keyword for proc-parameters. Using OPTIONAL one can hand over a parameter to a proc or not.

Example:
// procedure:
do_something: proc(a, b, c);
dcl a dec fixed(5);
dcl b dec fixed(5);
dcl c dec fixed(5) optional;
if present(c) then .....
// user
call do_something(2,3,4);
// or
call do_something(2,3,*);

I repeatedly stumbled accross code where one wrote
if c_contains_info
then call do_something(a, b, c);
else call do_something(a, b, *);

Imho the better approach would be to write (in some way)
call do_something(a, b, c, c_contains_info);

My example is as simple as possible, imagine a proc with 2 or 3 OPTIONALs.

And for those situations where there is a real optional parameter a generic is imho the better approach as i can completely omit the parameter and not "hide" it behind a "*".
x = format_currency(value);
x = format_currency(value, format_string);

I'm aware that it's not the fault of the language but of the user, but more and more i get the impression that OPTIONAL has more cons than pros.

Am i missing something?
br Johann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/14/21 7:07 AM, johann woeckinger wrote:

Hi,

Disclaimer: Title of posting is provocative on purpose :-).
In EPLI we have the OPTIONAL keyword for proc-parameters. Using OPTIONAL one can hand over a parameter to a proc or not.

Example:
// procedure:
do_something: proc(a, b, c);
dcl a dec fixed(5);
dcl b dec fixed(5);
dcl c dec fixed(5) optional;
if present(c) then .....
// user
call do_something(2,3,4);
// or
call do_something(2,3,*);

I repeatedly stumbled accross code where one wrote
if c_contains_info
then call do_something(a, b, c);
else call do_something(a, b, *);

Imho the better approach would be to write (in some way)
call do_something(a, b, c, c_contains_info);

My example is as simple as possible, imagine a proc with 2 or 3 OPTIONALs.

And for those situations where there is a real optional parameter a generic is imho the better approach as i can completely omit the parameter and not "hide" it behind a "*".
x = format_currency(value);
x = format_currency(value, format_string);

I'm aware that it's not the fault of the language but of the user, but more and more i get the impression that OPTIONAL has more cons than pros.

Am i missing something?
br Johann

This is a late addition to a language that started out with no such
facility at all, apart from the awkward GENERIC keyword. Most new
languages have a feature along these lines, but not the same. There are
keyword parameters with default values, for example. There is
overloading, and there is the feature that Ada calls “generic” and C++ calls “templates”. Or you can simply use pointers/locators that may have the value null/nil. Swift has all of these, but also allows ordinary parameters, not merely locators, to have the value nil. For example:

func doSomething(a: Int, b: Int, c: Int = 4) {
...
}

or:

func doSomething(a: Int, b: Int) {
/* 2-argument version */
}
func doSomething(a: Int, b: Int, c: Int) {
/* 3-argument version */
}

or:

func doSomething(a: Int, b: Int, c: Int?) {
if let c_verified = c {
realDoSomething(a, b, c_verified)
} else {
realDoSomething(a, b, 4)
}
}

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 14, 2021 at 1:07:42 PM UTC+2, johann woeckinger wrote:

Hi,

Disclaimer: Title of posting is provocative on purpose :-).
In EPLI we have the OPTIONAL keyword for proc-parameters. Using OPTIONAL one can hand over a parameter to a proc or not.

Example:
// procedure:
do_something: proc(a, b, c);
dcl a dec fixed(5);
dcl b dec fixed(5);
dcl c dec fixed(5) optional;
if present(c) then .....
// user
call do_something(2,3,4);
// or
call do_something(2,3,*);

I repeatedly stumbled accross code where one wrote
if c_contains_info
then call do_something(a, b, c);
else call do_something(a, b, *);

Imho the better approach would be to write (in some way)
call do_something(a, b, c, c_contains_info);

My example is as simple as possible, imagine a proc with 2 or 3 OPTIONALs.

And for those situations where there is a real optional parameter a generic is imho the better approach as i can completely omit the parameter and not "hide" it behind a "*".
x = format_currency(value);
x = format_currency(value, format_string);

I'm aware that it's not the fault of the language but of the user, but more and more i get the impression that OPTIONAL has more cons than pros.

Am i missing something?
br Johann

One correction and one additional question:

1) Correction:
EPLI allows to omit the "*" if the trailing parameter is not provided, so there's no need for generic in that case, one can write "...call do_something(a, b);" without providing a generic

2) additional question:
Is there a "more elegant" solution than implementing a separate "indicator variable" (in my sample "c_contains_info")?
Setting "c" to "null" seems a bit dirty. Implementing a defined struct that couples "c" and "c_contains_info" seems pretty excessive. Any solutions/ideas out there?

br johann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 15, 2021 at 9:08:05 AM UTC+10, John W. Kennedy wrote:

On 7/14/21 7:07 AM, johann woeckinger wrote:

Hi,

Disclaimer: Title of posting is provocative on purpose :-).
In EPLI we have the OPTIONAL keyword for proc-parameters. Using OPTIONAL one can hand over a parameter to a proc or not.

Example:
// procedure:
do_something: proc(a, b, c);
dcl a dec fixed(5);
dcl b dec fixed(5);
dcl c dec fixed(5) optional;
if present(c) then .....
// user
call do_something(2,3,4);
// or
call do_something(2,3,*);

I repeatedly stumbled accross code where one wrote
if c_contains_info
then call do_something(a, b, c);
else call do_something(a, b, *);

Imho the better approach would be to write (in some way)
call do_something(a, b, c, c_contains_info);

My example is as simple as possible, imagine a proc with 2 or 3 OPTIONALs.

And for those situations where there is a real optional parameter a generic is imho the better approach as i can completely omit the parameter and not "hide" it behind a "*".
x = format_currency(value);
x = format_currency(value, format_string);

I'm aware that it's not the fault of the language but of the user, but more and more i get the impression that OPTIONAL has more cons than pros.

Am i missing something?

.

This is a late addition to a language that started out with no such
facility at all, apart from the awkward GENERIC keyword.

.
Apart from the handy GENERIC facility, there has always been
the ENTRY facility, with which parameter lists of differing lengths
could be included in the same procedure. This neatly dealt
with cases where one or more arguments were not required.
.
Optional arguments is an extension of this idea, and enables
one or more arguments to be omitted.
.
I think that it is neat.
.

Most new
languages have a feature along these lines, but not the same. There are keyword parameters with default values, for example. There is
overloading, and there is the feature that Ada calls “generic” and C++ calls “templates”. Or you can simply use pointers/locators that may have the value null/nil. Swift has all of these, but also allows ordinary parameters, not merely locators, to have the value nil. For example:

func doSomething(a: Int, b: Int, c: Int = 4) {
...
}

or:

func doSomething(a: Int, b: Int) {
/* 2-argument version */
}
func doSomething(a: Int, b: Int, c: Int) {
/* 3-argument version */
}

or:

func doSomething(a: Int, b: Int, c: Int?) {
if let c_verified = c {
realDoSomething(a, b, c_verified)
} else {
realDoSomething(a, b, 4)
}
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

johann woeckinger <woecki@gmail.com> wrote:

On Wednesday, July 14, 2021 at 1:07:42 PM UTC+2, johann woeckinger wrote:

Hi,

Disclaimer: Title of posting is provocative on purpose :-).
In EPLI we have the OPTIONAL keyword for proc-parameters. Using OPTIONAL
one can hand over a parameter to a proc or not.

Example:
// procedure:
do_something: proc(a, b, c);
dcl a dec fixed(5);
dcl b dec fixed(5);
dcl c dec fixed(5) optional;
if present(c) then .....
// user
call do_something(2,3,4);
// or
call do_something(2,3,*);

I repeatedly stumbled accross code where one wrote
if c_contains_info
then call do_something(a, b, c);
else call do_something(a, b, *);

Imho the better approach would be to write (in some way)
call do_something(a, b, c, c_contains_info);

My example is as simple as possible, imagine a proc with 2 or 3 OPTIONALs. >>
And for those situations where there is a real optional parameter a
generic is imho the better approach as i can completely omit the
parameter and not "hide" it behind a "*".
x = format_currency(value);
x = format_currency(value, format_string);

I'm aware that it's not the fault of the language but of the user, but
more and more i get the impression that OPTIONAL has more cons than pros.

Am i missing something?
br Johann

One correction and one additional question:

1) Correction:
EPLI allows to omit the "*" if the trailing parameter is not provided, so there's no need for generic in that case, one can write "...call do_something(a, b);" without providing a generic

2) additional question:
Is there a "more elegant" solution than implementing a separate
"indicator variable" (in my sample "c_contains_info")?
Setting "c" to "null" seems a bit dirty. Implementing a defined struct
that couples "c" and "c_contains_info" seems pretty excessive. Any solutions/ideas out there?

br johann

Why would the indicator variable be better? The current syntax provides a “hidden” variable automatically generated by the compiler that the PRESENT BIF tests.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 30, 2021 at 4:57:13 PM UTC+2, bearlyabus...@gmail.com wrote:

johann woeckinger <woe...@gmail.com> wrote:

On Wednesday, July 14, 2021 at 1:07:42 PM UTC+2, johann woeckinger wrote:

Hi,

Disclaimer: Title of posting is provocative on purpose :-).
In EPLI we have the OPTIONAL keyword for proc-parameters. Using OPTIONAL >> one can hand over a parameter to a proc or not.

Example:
// procedure:
do_something: proc(a, b, c);
dcl a dec fixed(5);
dcl b dec fixed(5);
dcl c dec fixed(5) optional;
if present(c) then .....
// user
call do_something(2,3,4);
// or
call do_something(2,3,*);

I repeatedly stumbled accross code where one wrote
if c_contains_info
then call do_something(a, b, c);
else call do_something(a, b, *);

Imho the better approach would be to write (in some way)
call do_something(a, b, c, c_contains_info);

My example is as simple as possible, imagine a proc with 2 or 3 OPTIONALs.

And for those situations where there is a real optional parameter a
generic is imho the better approach as i can completely omit the
parameter and not "hide" it behind a "*".
x = format_currency(value);
x = format_currency(value, format_string);

I'm aware that it's not the fault of the language but of the user, but
more and more i get the impression that OPTIONAL has more cons than pros. >>
Am i missing something?
br Johann

One correction and one additional question:

1) Correction:
EPLI allows to omit the "*" if the trailing parameter is not provided, so there's no need for generic in that case, one can write "...call do_something(a, b);" without providing a generic

2) additional question:
Is there a "more elegant" solution than implementing a separate
"indicator variable" (in my sample "c_contains_info")?
Setting "c" to "null" seems a bit dirty. Implementing a defined struct that couples "c" and "c_contains_info" seems pretty excessive. Any solutions/ideas out there?

br johann

Why would the indicator variable be better? The current syntax provides a “hidden” variable automatically generated by the compiler that the PRESENT
BIF tests.

--
Pete

very valid question as i didn't describe it well in my original posting! because of some "business logic" that determines that c either contains some valuable info or not.
just came into my mind: similar to the not-null-indicator of null-able db2 columns (but that somehow leads us away from the original topic :-)).

my conclusion so far: when there are "different operations", optional parameters are fine, if it's just "different amount of data" an indicator variable might be better.

br johann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Just a word about GENERIC:

Be aware that this is a language element already being present in PL/I(F)
of the late 60's . And it took some decades to discover , that you can
define a procedure, or function identity by the combination of it's name,
the number of parameters, and the data types of the parameters.

PL/I was far ahead of the time it was invented. The only changes since
then was adding functionality. But it's concept is still the same. A small syntactical add on lies in adding empty parentheses expected behind
procedure and function (incl. BUILTIN ) names not having any parameters,
in order to make it visible in the source code, that it is not the name of a simple variable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, August 12, 2021 at 7:34:23 PM UTC+10, archives.in...@gmail.com wrote:

Just a word about GENERIC:

Be aware that this is a language element already being present in PL/I(F)
of the late 60's . And it took some decades to discover , that you can
define a procedure, or function identity by the combination of it's name,
the number of parameters, and the data types of the parameters.

.
IIRC, user-written generic procedures in PL/I were available in 1966.
.

PL/I was far ahead of the time it was invented. The only changes since
then was adding functionality. But it's concept is still the same. A small syntactical add on lies in adding empty parentheses expected behind
procedure and function (incl. BUILTIN ) names not having any parameters,
in order to make it visible in the source code, that it is not the name of a simple variable.

.
Yes, a considerable advance compared to FORTRAN, a language in
which is was necessary to spell out the individual function names,
such as SQRT and DSQRT, according to the type of the argument.
PL/I-F was introduced by 1966.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I think that most contemporary programming languages handle it today
similarly, as Pascal does. The example below I use, when I am teaching
Pascal.
-------------------------------------------------------------------
program pardemo(input,output) ;

procedure show_me ;
begin writeln('It''s me !') end ;

procedure show_me(name : string) ;
begin writeln('It''s me and ',name,' !') end ;

procedure show_me(name1,name2 : string) ;
begin writeln('It''s ',name1,', ',name2,', and me !') end ;

procedure show_me(name : string ; number : integer) ;
begin writeln('It''s ',name,', me, and ',number,' others !') end ;

begin
show_me ;
show_me('Albert') ;
show_me('Martha','Juliette') ;
show_me('Robin',5)
end .
-------------------------------------------------------------------
Resulting Output:

It's me !
It's me and Albert !
It's Martha, Juliette, and me !
It's Robin, me, and 5 others !

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sorry ! groups.google.com has destroyed the formatting of my programme code :-( I do not know, how you see my message in your mail box.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robin Vowels <robin.vowels@gmail.com> wrote:

On Thursday, August 12, 2021 at 7:34:23 PM UTC+10, archives.in...@gmail.com wrote:

Just a word about GENERIC:

Be aware that this is a language element already being present in PL/I(F)
of the late 60's . And it took some decades to discover , that you can
define a procedure, or function identity by the combination of it's name,
the number of parameters, and the data types of the parameters.

.
IIRC, user-written generic procedures in PL/I were available in 1966.
.

PL/I was far ahead of the time it was invented. The only changes since
then was adding functionality. But it's concept is still the same. A small >> syntactical add on lies in adding empty parentheses expected behind
procedure and function (incl. BUILTIN ) names not having any parameters,
in order to make it visible in the source code, that it is not the name of a >> simple variable.

.
Yes, a considerable advance compared to FORTRAN, a language in
which is was necessary to spell out the individual function names,
such as SQRT and DSQRT, according to the type of the argument.
PL/I-F was introduced by 1966.

I’d forgotten that, as well as lack of mixed-mode arithmetic. I came to
PL/I from FORTRAN, and it was like night and day.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Markus Loew <memos.suisse@gmail.com> wrote:

Sorry ! groups.google.com has destroyed the formatting of my programme code :-(
I do not know, how you see my message in your mail box.

GG is broken. shows up fine to me. Maybe if you cut from GG and pasted into some simple notepad-thingy it would show up OK?

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you Pete, for the information! I have created a groups.io PL/I(F) an MVS 3.8j group,
Maybe it is interesting for you. As I do not have your mail address, I cannot send an invitation to you.
You are very welcome to apply for membership at groups.io/g/pl1f-and-mvs38j/. As I moderate the group, I can immediately take measures, if an inappropriate messaging, as to
be seen here, appears.

Best regards Markus Loew,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, August 14, 2021 at 11:53:57 PM UTC-4, memos....@gmail.com wrote:

Thank you Pete, for the information! I have created a groups.io PL/I(F) an MVS 3.8j group,
Maybe it is interesting for you. As I do not have your mail address, I cannot send an invitation to you.
You are very welcome to apply for membership at groups.io/g/pl1f-and-mvs38j/. As I moderate the group, I can immediately take measures, if an inappropriate messaging, as to
be seen here, appears.

Best regards Markus Loew,

Markus,

Is that a google groups group? I've not been able to find it. May I ask why a PL/I(F) specific group, when there's already a Pl/I group? Are there enough folks/problems for a PL/I(F) MVS specific group?

Thank you
Cornell

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Cornell
Just have a look at the link mentioned in my post: groups.io/g/pl1f-and-mvs38j/ , this is not a Google group. I created it as a Yahoo group, and I moved it to groups.io when Yahoo downgraded their group services.
b rgds
Markus Loew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)