See https://fortran-lang.discourse.group/t/poll-fortran-202x-conditional-expressions-syntax/1425/80?u=beliavsky referencing https://j3-fortran.org/doc/year/21/21-157r2.txt with code example.
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
equivalent to
if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end if
I think it will be a nice addition to the language, inspired by the ternary operator of C.
I grant the first is powerful and makes it worth it for that reason.
As for the second, I suppose one eventually gets familiar-enough with
the idiom it isn't so obfuscating, but personally I still find it more confusing than helpful in C albeit I'll be first to admit have written
only as much C as was forced into over the last 40 years.
If one likes terse, that's one's privilege and I'm first to agree the language shouldn't go out of its way to prevent the user from coding as
suits their style/taste.
But, does the ternary form do anything to aid the compiler in producing
any better/faster/more optimized code than the equivalent if...end
construct?
Either/both just turn into conditional branch/jump don't they? Same as
a computed GOTO vs a CASE structure; the point is more for the human
than the computer/compiler so there's advantages to clarity as well.
On Wednesday, July 7, 2021 at 5:36:13 AM UTC-4, pehache wrote:
..
Apart from being more cryptic, I can't see any advantage over the
if/then/else construct
..
Re: ".. I can't see any advantage over the if/then/else construct ..," that is an incorrect assessment of this new feature in Fortran 202X.
As noted upthread, there can be considerable advantage with this feature when it comes to reference to procedures with optional arguments and the advantage scales rapidly with the number of optional arguments.
And to reiterate, the additional advantage is with those who seek compact code.
Actually the advantage is that the result can be used directly within an expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif
would have do
pehache <pehache.7@gmail.com> schrieb:
Actually the advantage is that the result can be used directly within an
expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif
would have do
There was one certainty: Whatever syntax was chosen, some people
would object :-)
The current one is rather similar to C, which means that people who
know the feature from other programming languages will recognize it.
As noted upthread, there can be considerable advantage with this feature when it
comes to reference to procedures with optional arguments and the advantage scales rapidly with the number of optional arguments.
I don't really get that... An exemple maybe ?
On Thursday, July 8, 2021 at 4:42:02 AM UTC-7, pehache wrote:
(snip, someone wrote)
As noted upthread, there can be considerable advantage with this feature when it
comes to reference to procedures with optional arguments and the advantage >>> scales rapidly with the number of optional arguments.
I don't really get that... An exemple maybe ?
I wrote this above, calling a subroutine with three optional arguments, in all combinations.
j=0
if(a) j=ior(j,1)
if(b) j=ior(j,2)
if(c) j=ior(j,4)
select case(j)
case (0)
call sub(,,)
case (1)
call sub(a,,)
case (2)
call sub(,b,)
case (3)
call sub(a,b,)
case (4)
call sub(,,c)
case (5)
call sub(a,,c)
case (6)
call sub(,b,c)
case (7)
call sub(a,b,c)
end select
I would say this is confusing at best. The "a", "b", and "c" variables
are logical, and used to set j, which is only used to select the call.
But sub() is always called with .true. present arguments and .false' nonpresent arguments (assuming that syntax even works), so why not just have
call sub(a,b,c)
An example of the conditional expression is
call sub( (<expression> ? a : b) )
which is equivalent to
if ( expression ) then
call sub(a)
else
call sub(b)
endif
Now consider a subroutine with more than one such argument. Each
argument would double the number of possible if-then-else branches
(O(2^N) coding effort) required to select the correct calling sequence,
but it can be done with a single call using the multiple conditional expressions (O(N) coding effort). Further, this cannot be done with
MERGE, because the result of MERGE is an modifiable expression. That
means it can be associated with intent(out) and intent(inout) dummy arguments, and the updated values are passed back to the calling program correctly through the argument association.
This could also be achieved with pointers, conditionally assigning each pointer actual argument. That approach also requires O(N) rather than
O(2^N) coding effort. However that would require that the possible
arguments all be targets, which suppresses optimization in the same way
that C, C++, etc. languages have suppressed optimization due to wild pointers.
In my opinion, the fact that the result is modifiable is the real useful feature of the conditional expression semantics. When used to replace
MERGE or IF-THEN-ENDIF, it is mostly, apart from the short-circuit
feature, just redundant eye candy.
I don't really get that... An exemple maybe ?
...
Fortran is not for compact code.
<conditional-argument> ::=
<expr> ? <expr> -: { : }
Now consider a subroutine with more than one such argument. EachI believe that MERGE cannot be used with intent(out) or intent(inout) arguments, but I haven't thought about this recently.
argument would double the number of possible if-then-else branches
(O(2^N) coding effort) required to select the correct calling sequence,
but it can be done with a single call using the multiple conditional
expressions (O(N) coding effort). Further, this cannot be done with
MERGE, because the result of MERGE is an modifiable expression. That
means it can be associated with intent(out) and intent(inout) dummy
arguments, and the updated values are passed back to the calling program
correctly through the argument association.
I believe that MERGE cannot be used with intent(out) or intent(inout) arguments, but I haven't thought about this recently.
Yes, that was a typo in that sentence. I meant "unmodifiable" for MERGE,
in contrast to "modifiable" for the conditional expression.
On 7/6/2021 2:41 AM, Ron Shepard wrote:
And since it is modifiable, I'm wondering if it can be used on the left hand side of an equals sign?No.The syntax added is for a conditional expression, which can be a
"primary" in an expression (see https://stevelionel.com/drfortran/2021/04/03/doctor-fortran-in-order-order/), or as a conditional actual argument in a procedure reference.
There is nothing I can think of that would block adding this third usage
in the future, but it was not included in the design.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org
pehache <peha...@gmail.com> schrieb:Would the limited "if then else" structure of the conditional expression provide opportunity for improved optimisation ?
Actually the advantage is that the result can be used directly within an expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif
would have doThere was one certainty: Whatever syntax was chosen, some people
would object :-)
The current one is rather similar to C, which means that people who
know the feature from other programming languages will recognize it.
Certainly good enough for me.
Would the limited "if then else" structure of the conditional expression provide opportunity for improved optimisation ?
On Saturday, July 10, 2021 at 9:19:53 PM UTC-7, JCampbell wrote:
(snip)
Would the limited "if then else" structure of the conditional expression provide opportunity for improved optimisation ?
As well as I know, MERGE is allowed to optimize, only evaluating one argument,
but isn't required to do that. The new operator requires it.
On Friday, July 2, 2021 at 1:58:24 AM UTC+10, Beliavsky wrote:
See https://fortran-lang.discourse.group/t/poll-fortran-202x-conditional-expressions-syntax/1425/80?u=beliavsky referencing https://j3-fortran.org/doc/year/21/21-157r2.txt with code example.
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
bizarre syntax, cryptic, and archaic.
It seems to be an attempt to revive something from Algol 60, viz,
y = if a>b then x else z;
which is less bizarre.
.
equivalent to
if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end if
I think it will be a nice addition to the language, inspired by the ternary operator of C.
As well as I know, MERGE is allowed to optimize, only evaluating one argument,
but isn't required to do that. The new operator requires it.
That hypothetical situation works the other way too. MERGE is allowed to optimize by evaluating its arguments early (reusing register values, minimizing memory references, reusing allocated temporary arrays, etc.),
and the new operator forbids that optimization, requiring the short
circuit semantics instead.
I think it will be a nice addition to the language, inspired by the ternary operator of C.
We agree on something. I have never used this syntax in C as I dislike it.
There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:
#define BEGIN {
#define END {
gah4 <gah4@u.washington.edu> schrieb:
There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:
#define BEGIN {
#define END {
I assume you mean
#define END }
:-)
And it fact that the original Bourne shell was written in a style
like that. Stephen Bourne was rather unique in that he was a
fan of Algol 68, which is why the Unix shell has some syntax
details inspired by that language.
In article <scj76j$b87$1@newsreader4.netcologne.de>, Thomas Koenig <tkoenig@netcologne.de> writes:
gah4 <gah4@u.washington.edu> schrieb:
There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:
#define BEGIN {
#define END {
I assume you mean
#define END }
:-)
And it fact that the original Bourne shell was written in a style
like that. Stephen Bourne was rather unique in that he was a
fan of Algol 68, which is why the Unix shell has some syntax
details inspired by that language.
A Fortran programmer can write Fortran in any language.
See https://fortran-lang.discourse.group/t/poll-fortran-202x-conditional-expressions-syntax/1425/80?u=beliavsky referencing https://j3-fortran.org/doc/year/21/21-157r2.txt with code example
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
equivalent to
if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end if
I think it will be a nice addition to the language, inspired by the ternary operator of C.
Was there any motivation of such a choice over more modern syntax, such as this?
y = a(i) if i>=1 .and. i<=Size(a) else -Huge(y)
..
I feel it is interesting (and a bit surprising) that the committee chose the C-like ternary
form, but as for the above Python form, isn't it "problematic" to use for fixed-form
source form with the (notorious) implicit rule? (because spaces are neglected), e.g., ..
On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:
Can the Fortran standard at least mark fixed-form source as RETIRED? Please.
Was there any motivation of such a choice over more modern syntax, such as this?
y = a(i) if i>=1 .and. i<=Size(a) else -Huge(y)
Am 03.09.21 um 16:53 schrieb FortranFan:
On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:the need to have backward compatibility with fixed-form source where
blanks are insignificant?
Can the Fortran standard at least mark fixed-form source as RETIRED? Please.
I greatly support that idea. There will always be compiler options that
allow compilation of such legacy codes, but all new features in my
opinion only really need to properly work with free-form.
..
If all compilers will continue to support the old feature, this
creates ambiguity for the compiler writers and the users, which
is a Bad Thing (TM).
Am 03.09.21 um 16:53 schrieb FortranFan:
On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:the need to have backward compatibility with fixed-form source where blanks are insignificant?
Can the Fortran standard at least mark fixed-form source as RETIRED?
Please.
I greatly support that idea. There will always be compiler options that
allow compilation of such legacy codes, but all new features in my
opinion only really need to properly work with free-form.
...
thus avoiding the
compatibility problem altogether?
On 07/09/2021 00:31, Ron Shepard wrote:
...
thus avoiding the compatibility problem altogether?
Introducing a new feature that can't be used in the older fixed-form
doesn't break backward compatibility.
On 9/8/21 7:22 AM, Ev. Drikos wrote:
On 07/09/2021 00:31, Ron Shepard wrote:
...
thus avoiding the compatibility problem altogether?
Introducing a new feature that can't be used in the older fixed-form
doesn't break backward compatibility.
This is a correct answer to a different question. My question was about compiler options to allow new features to be used in fixed-form, not backwards compatibility with existing code.
On 9/4/21 2:53 PM, JRR wrote:
Am 03.09.21 um 16:53 schrieb FortranFan:
On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:the need to have backward compatibility with fixed-form source where
blanks are insignificant?
Can the Fortran standard at least mark fixed-form source as RETIRED?
Please.
I greatly support that idea. There will always be compiler options
that allow compilation of such legacy codes, but all new features in
my opinion only really need to properly work with free-form.
Are there any current fortran statements or features that can only be
used in free-source form? If not, then adopting such a feature would be
a new direction for the language.
If such a feature were introduced, and if it were possible to introduce
a compiler option that would override the standard and allow the new
feature to be used in fixed-source form, then why couldn't the standard
have been written that way to begin with, thus avoiding the
compatibility problem altogether?
OK, I repeat my response including the relevant earlier response by FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."
Ev. Drikos <drik...@gmail.com> schrieb:
OK, I repeat my response including the relevant earlier response by FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."It just introduces arbitrary incompatibility into the language, for
which there is no need.
Not a good idea.
The "no need" part is the other way around. Formula translation need NOT remain tied
to fixed-form source format any more than someone who asks for every new
statement feature to integrate well with ASSIGN from FORTRAN I, all support
for character intrinsic types and internationalization to work with Hollerith
from FORTRAN I, all IO facilities to also work with PUNCH statement
from FORTRAN I and also differentiate between IO toward TAPE and DRUM,
all compiler optimizations to be driven by FREQUENCY statement from FORTRAN I,
all numerical (and floating-point) exceptions to also work with ACCUMULATOR OVERFLOW from FORTRAN I, all processors to also recognize SENSOR LIGHT
on/off toggle from FORTRAN I, etc. will be ignored.
No reserved words complicates both forms, but is, I believe, a
worthwhile feature to Fortran.
Ev. Drikos <drik...@gmail.com> schrieb:
OK, I repeat my response including the relevant earlier response by FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."It just introduces arbitrary incompatibility into the language, for
which there is no need.
Not a good idea.
piątek, 10 września 2021 o 17:03:37 UTC+2 Thomas Koenig napisał(a):in different files, away from Modern Fortran. It is possible and *very easy* to call old routines from Modern Fortran. Mixing old and new Fortran in one file is against good practices anyway.
..
FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."It just introduces arbitrary incompatibility into the language, for
which there is no need.
Not a good idea.In my opinion there is need, because it is another situation when "this will break fixed format" is used as an argument. And this argument is invalid. Because there is "no need" to use the fixed form for anything. It is only for old codes, which live
It is not arbitrary, since it clearly slows down the development of the language. It is a burden, and detaching this burden would enable many new solutions to be introduced into Fortran and make it more relevant for new projects.clear separation) would be beneficial.
To call something "needed" or "not needed", there must be a working scenario in which the change would help. There is no real scenario where using modern features in fixed form would yield a good outcome. But there are many fields where the opposite (
Dominik
On Friday, September 10, 2021 at 11:04:30 AM UTC-7, FortranFan wrote:.
(snip)
The "no need" part is the other way around. Formula translation need NOT remain tiedThere are two different things, sometimes called syntax and semantics.
to fixed-form source format any more than someone who asks for every new statement feature to integrate well with ASSIGN from FORTRAN I, all support for character intrinsic types and internationalization to work with Hollerith
from FORTRAN I, all IO facilities to also work with PUNCH statement
from FORTRAN I and also differentiate between IO toward TAPE and DRUM,
all compiler optimizations to be driven by FREQUENCY statement from FORTRAN I,
all numerical (and floating-point) exceptions to also work with ACCUMULATOR OVERFLOW from FORTRAN I, all processors to also recognize SENSOR LIGHT on/off toggle from FORTRAN I, etc. will be ignored.
When adding new features, one must be sure that the syntax doesn't create ambiguities in parsing. That is complicated in fixed form because blanks are ignored. No reserved words complicates both forms, but is, I believe, a worthwhile feature to Fortran. Keeping the old statements is mostly not
a problem for parsing.
Reminds me, though, the SLITE and SLITET, sense light and sense light test, routines are in OS/360 Fortran, though there are no actual lights. One can turn on and off the virtual lights, and test them. (That is, four logical values.)
I did always find it interesting that the Fortran II style I/O statements, that went
away in Fortran IV (and 66), came back later. (Though not the tape and drum versions.) OS/360 Fortran supports READ (for unit 5), PRINT (for unit 6)
and PUNCH (for unit 7). (There is no requirement that unit 7 actually
be a card punch or, more usually, SYSOUT=B.)
I do like using PRINT for debugging, as it is easy to recognize as different from the actual I/O statements.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 98:43:14 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,783 |