New WG5 web site and Fortran 2020 feature survey!

[Steve Lionel]

For many years, the "web home" of ISO/IEC JTC1/SC22/WG5 (the
international Fortran standards committee, or WG5 for short) has been
graciously hosted by NAG. I am pleased to announce that WG5 now has its
own web site: https://wg5-fortran.org/ The site is served over https and
is "mobile friendly".

The WG5 web site is where you'll find news about what's happening with
the Fortran standard, and links to all WG5 documents. Information on
current and past standards is also available there.

On the home page you will see a link to a survey, requesting opinions on
and suggestions for features that you would like to see in the next
Fortran standard, tentatively titled Fortran 2020. If you want to help
shape the future of Fortran, please take a few minutes and fill out the
survey. While the survey will remain open through January 2018, we will
start analyzing responses at the October J3 meeting. Also, the list of
features the survey asks you to rank may be amended based on suggestions
received.

I welcome all comments on the web site, and especially if you discover
any problems. Not yet done are the email list indexes and news older
than 2016.
--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[Stefano Zaghi]

Dear Steve,

thank you very much this initiative, it is really appreciated. I have not yet tested all the website, but the survey seems to work well: I completed it, but I have not proposed nothing on my own (point 4). On GitHub we are trying to collect more detailed proposals, we hope we can submit them later before October in a different way other than this survey.

My best regards.

[FortranFan]

On Wednesday, July 19, 2017 at 8:37:48 PM UTC-4, Steve Lionel wrote:

> .. I am pleased to announce that WG5 now has its

> own web site: https://wg5-fortran.org/ The site is served over https and
> is "mobile friendly".
>

> ..

>
> I welcome all comments on the web site, and especially if you discover
> any problems. Not yet done are the email list indexes and news older
> than 2016.
> --

> ..


Steve,

No words can describe how great it is to find WG5 Fortran group have its own dedicated website and to contemplate all the communication channels this can open up over time - starting with your survey - for all the regular users of Fortran.

Fortran truly enters the modern era!

For the Fortranners out there Steve, "this is the beginning of a beautiful" thing!

Thank you.

[spectrum]

Dear Steve,

Thanks very much for making such a new web site (with a nice color scheme :)
I will definitely participate in the survey and also send comments/requests
about the web site as necessary.

And one (immediate) possible idea for improvement is...

It might be useful for the web site to have some "primer (tour)" or "Getting started"
pages that highlight most useful features of modern Fortran
(including modules, types, arrays, parallel features, and so on...) so that people
familiar only to other languages (or know only the old versions of FORTRAN)
so that they get the current "look-and-feel" of the language pretty quickly.

-- I had several opportunities that I wanted to show such features to other people,
but I could not find a convenient "introduction" page...
Even the Wikipedia page is not that good with almost no code samples, e.g.,
https://en.wikipedia.org/wiki/Fortran#Fortran_2008

-- For more extensive resources, there are external sites like Fortran Wiki,
http://fortranwiki.org/fortran/show/HomePage
but I guess it would be helpful for potential new users to be able to
a rough idea of modern Fortran coding quickly (hopefully in lower-case letters... :-)

-- But this kind of thing clearly needs contributions from various people (to
save/share time), and in that aspect, Github is very convenient because of
"issues" and "pull request" systems (i.e., anyone can join easily and send
their contributions via pull requests, or just propose ideas via "issues" and
discuss with other people). An example of "issue" is something like...

https://github.com/Fortran-FOSS-Programmers/Fortran-202X-Proposals/issues/10

If someone send a prototype of such "Getting started" page via pull request,
then other people can make comments/discussions about good and bad points,
improve it if necessary, and it may be "published" (merged into official pages)
after some condition/agreement is satisfied among people (e.g., review by
committee members...?) That kind of thing seems pretty straight on Github,
so it may be useful for considerations in future (e.g., as an extension of the
official Fortran standards page to include such "plus alpha" pages).

https://swift.org/getting-started/#installing-swift
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2-ID1

https://golang.org/doc/
https://golang.org/doc/install

https://isocpp.org/get-started
https://isocpp.org/tour

Finally, thank you very much again and taking time for this! :-)

[michael siehl]

The survey worked well for me. Here is what I filed to the questions:


3. If you have a suggestion not listed above, please describe it here. Include references to other languages, if any, that have a similar feature. How would you use it in your applications? Have you used this feature in applications written in other languages?

I would like to suggest a very simple coarray-related extension to the Fortran 2008 language: A build-in counter to track the execution segments, just counting locally on each coarray image (i.e. the number of times the SYNC MEMORY statement gets executed - explicitly as well as implicitly - ): Something like a THIS_SEGMENT intrinsic.
I did develop such a counter myself, easily in less than 5 minutes using few lines of F2008 syntax. (The working code can be found here, see STEP 1 and the 161125_src subfolder: https://github.com/MichaelSiehl/Using-Atomic-Subroutines-and-Sync-Memory-to-Restore-Segment-Ordering ).
It works, but the disadvantage is that the whole application can only make use of a single SYNC MEMORY statement (not really a disadvantage) and no other build-in synchronization method can be used (that is a minor disadvantage). The main disadvantage of the user-defined implementation of such a segment counter is that it does prevent independent development of the distinct parts of a parallel application (e.g. independent coarray-based library development) which is my main reason for demanding such a feature: All parts of a parallel application must use the same user-defined segment counter. A build-in segment counter could allow largely independent development of the distinct parts of a coarray-based parallel application.


2. For the feature you ranked highest, how would it help in development of your applications? Have you used this feature in applications written in other languages?

Practical use for a segment counter:
The practical use of such a segment counter is strongly related to the use of SYNC MEMORY and atomic subroutines and thus, also to the implementation of customized synchronization procedures. In practice, tracking the execution segments on the images is required for checking and for restoring the segment order among coarray images. A simple but working example program to restore segment ordering among a number of coarray images, using Fortran 2008 source code, can be found here: https://github.com/MichaelSiehl/Atomic_Subroutines--How_the_Parallel_Codes_may_look_like--Part_1 . Here, the segment order among the images gets restored just by executing the SYNC MEMORY statement the required times, like this:
...
! restore the segment order (among the involved images) for this image:
do intCount = 1, intNumberOfSyncMemoryStatementsToExecute
!
call OOOPimsc_subSyncMemory (Object_CA) ! execute sync memory
!
end do
...


4. Any general comments for the Fortran committee?

The Fortran 95 base language together with (only a small subset of) the Fortran 2008 coarray-related language features might be already the promise for an highly flexible and nearly unlimited parallel programming. Applying some simple programming 'tricks' does already allow to make safe use of the SYNC MEMORY statement together with atomic subroutines to implement customized synchronizations programmed as procedures.
Moreover, due to a simple programming technique, we can easily transmit two (limited-size) integer values within a single call to an atomic subroutine. This allows, at the same time, to transmit and to synchronize the remote transfer of an atomic (limited-size) integer value. We should be able to use this to process (integer) array data atomically, just by synchronizing each array element separately. And with the ability to process array data atomically, even with unordered (customized) segment ordering, there are virtually no limitations for the development of parallel applications using Fortran 2008 already. (The only hardware-related limitation might be that atomicity may not be guaranteed between distinct processor types).
With, otherwise, safe use of SYNC MEMORY and atomic subroutines, the implementation of all the required synchronization primitives can be accomplished by the Fortran 2008 programmer her-/himself.
Further research is required for the design of spin-wait loop synchronizations: nested spin-wait loops do allow for the implementation of NON-BLOCKING customized synchronization primitives.

[michael siehl]

For the survey itself, maybe it is better to first ask for question 3. and after that for question 2.

Best Regards

[edmondo.g...@gmail.com]

Dear all,
I think that some improuvement can be done on the Fortran Object Oriented
part, but tell me if I am wrong.

Once I created a Fortran user defined type around a C++ class,
that means storing inside a user defined type a C pointer, creating some C
wrappers that will call the C++ methods, etc. I'm not presentig the real
example as it was not complete, but I want to discuss some features that
whould help in wrapping a Fortran uerd defined type around a C++ class.

let's say we have:

type t_myCclass
type(C_PTR) :: ptr
end type

Now in order to make everything working you need to define the final subroutine,
that will call the C++ destructor, and make it impure elemental.
That way it will also work for arrays of your objects.

Then you need a defined assignment, that will call a C++ assignment method.

Now we may have the following problems, assume you have:

type(t_myCclass) :: a(10)

a(2:10) = a(1:9)

With an intrinsic assigment the compiler may reorganize the loop and if
necessary call the final routine or even create a temporary.

But with a defined assignment you have to check everything by yourself and
that statement may even be illegal.

My proposal is:

1. add an "elemental_assignment" as:

type t_myCclass
...
contains
generic :: elemental_assignment(=) => myCclass_assign
procedure,private :: myCclass_assign
end type
...
impure elemental myCclass_assign(...

where the procedure pointed by an elemental_assignment should be elemental
(pure or impure) and the order of the assignment will be decided by the
compiler, so one have to change the rule that an impure elemental procedure should
only process array elements in Fortran order.

Second the compiler should be able to create a temporary if needed, so one also
needs a copy constructor (using C++ terminology).

2. Add a copy constructor, that may be called "initial" (as in Fortran we
use "final" for the destructor).

type t_myCclass
...
contains
...
initial :: myCclass_initial
end type

where myCclass_initial will basically be a copy constructor:

function myCclass_initial(obj) result(r)
type(t_myCclass),intent(inout) :: obj ! intent(inout) Some reference counting may be present
type(t_myCclass) :: r
! copy obj in r
end function

3. Some sintactic sugar: many time I'm writing:
type mytype
...
contains
generic :: my_generic_name => name_1, name_2, name_3
procedure, private :: name_1, name_2, name_3
end type

So I'd like to drop the second line and just write:

type mytype
...
contains
generic :: my_generic_name => name_1, name_2, name_3
end type

that is to make a rule that if some specific name
in a generic statement is not present in a corresponding
procedure statement (inside a type definition), it will be equivalent
of being present as a private procedure.


In C++, they have also introduced the move constructor and move semantic
to avoid unnecessary calls of copy constructors and the destructors,
but now I'm lost, so I'm certain that people smarter than me will figure
out how to make everything as fast as possible.

Of course, as usual, my proposals may have a lot of problems I've not
thought about, I'm not a compiler writer, so I hope you apologize me
if I have been too naive.

Do you have comments, do you think they may be useful, or there could be simpler
way to achieve the same?

Of course if you put just allocatables inside a user defined type you don't have
to worry at all, as everything will be automatic, you just use the intrinsic assigment
and the compiler will do all the machinery.

Cheers,

[FortranFan]

On Thursday, July 27, 2017 at 9:21:02 AM UTC-4, edmondo.g...@gmail.com wrote:

> Dear all,
> I think that some improuvement can be done on the Fortran Object Oriented
> part, but tell me if I am wrong.
>

> ..

@edmondo.g...@gmail.com,

You certainly have a lot of good ideas but please keep in mind as things stand, Fortran only has interoperability with a companion C processor and that's how things may remain. And given the legacy, constructs and semantics, and direction of Fortran and C++ languages, getting classes in C++ to interoperate better with derived types in Fortran may always present challenges.

By the way, I assume you have reviewed by the book by Rouson et al. (http://dl.acm.org/citation.cfm?id=2018862) and the work by Rouson and Morris, especially at Sandia with Trilinos (e.g., http://aip.scitation.org/doi/abs/10.1109/MCSE.2012.33) that discuss a lot of aspects of C++ classes working with Fortran code. As far as I know, they are both involved in the Fortran standards committee and you may want to communicate with them on your ideas.

Your point about "In C++, they have also introduced the move constructor and move semantic to avoid unnecessary calls of copy constructors and the destructors, but now I'm lost, so I'm certain that people smarter than me will figure out how to make everything as fast as possible." is a good one. Please see this thread:
https://groups.google.com/d/msg/comp.lang.fortran/Xn-ax-YzEwE/sFnmK-lnBwAJ

I too hope the Fortran standards committee will make a positive movement on "move semantics" in the next standard revision.

I appreciate highly your interest in using Fortran and seeking newer facilities in it. I hope you will succeed greatly in learning what changes in Fortran will be good for you and other users and what aspects, if any, you should avoid in your code design and in influencing newer revisions of the language.

All the best,

[edmondo.g...@gmail.com]

Dear FortranFan,

apologize me for my late answer and for reopening an old discussion.

I had another crazy idea, what about a move assignement that will behave as a standard assignment when no allocatable or pointer variable are concerned, while it behave as a move_alloc when it encounter an allocatable, and it is also explicit, I mean with another symbol.
Of course it should be able to descend recursively into the user defined types.

As an example, assume that the symbol is "<=" (so looks like a move):
Given:

type t_a
integer :: one
end type
type t_b
type(t_a), allocatable :: a
end type
type t_c
type(t_b) :: b
real :: two
end type

type(t_c) :: d, c

Then:

d <= c

Should be equivalent to:

d%two = c%two
call move_alloc(c % b % a, d % b %a)

This move assignment needs that also the RHS is definable.

Well, of course, there could be smarter and more generic way to achieve the same result.

Cheers,
:-)

[FortranFan]

On Monday, September 11, 2017 at 1:24:25 PM UTC-4, edmondo.g...@gmail.com wrote:

> ..

>
> I had another crazy idea, what about a move assignement that will behave as a standard assignment when no allocatable or pointer variable are concerned, while it behave as a move_alloc when it encounter an allocatable, and it is also explicit, I mean with another symbol.
> Of course it should be able to descend recursively into the user defined types.
>

> As an example, assume that the symbol is "<=" (so looks like a move): ..


@edmondo.g...@gmail.com,

Your idea looks good to me.

Please note I am considering the use cases of 'move semantics' that may include working with generic containers and also increasing/decreasing the size of the basic container in Fortran which is an ARRAY of derived types and I wonder if it is possible to build on your concept:

a) first to introduce an intrinsic procedure, say MOVE_COPY and similar to MOLE_ALLOC, that effectively does what you describe but that the more verbose but perhaps an explicit-looking instruction can be available for coders e.g.,

call move_copy( from=foo, to=tmp(1:N) )

b) to provide coders the flexibility to design the MOVE operation in their derived types if they choose to implement it, similar to FINAL operation and one that is philosophically analogous to implicit/explicit move constructors in C++, etc. That is, how about

module t_b_m
..

type t_b
type(t_a), allocatable :: a

contains
move :: move_t_b ! MOVE operation similar to FINAL
! coders need only implement it if they wish to
end type
..
contains
..
subroutine move_t_b( lhs, rhs )
type(t_b), intent(inout) :: lhs
type(t_b), intent(inout) :: rhs
..
end module t_b_m

Then for MOVE procedures, there can be a set of rules (and possibly constraints) that guide a coder toward suitable design of their derived types but which gives the coder adequate flexiblity to deal with type components, whether they have ALLOCATABLE/POINTER attributes, procedure pointers, handles to resources (e.g., files), etc.

So then when a coder does something like:

tmp(1:N) <= foo
! or
! call move_copy( from=foo, to=tmp(1:N) )

all the explicit operations per MOVE procedures (and implicit if not implemented) are invoked recursively.

Please note I don't have the background nor the ability to extend language semantics and flaws are quite likely in my suggestions above and I also don't think I can dig deeper into this; it's just that the above are some of the thoughts I had in mind on what might be useful with such a feature.

But I hope the standards committee will see it fit to include such a concept in the next revision and develop it fully. Perhaps you can join the committee or find other ways to collaborate with them; your contributions will be valuable and your ideas will serve the language greatly.

Regards,

[edmondo.g...@gmail.com]

I was also thinking at a subroutine instead of an assignment like "<=", but I was worrying that TKR will strike.

I mean I would have liked that if "a" and "b" are allocatable variable
a <= b
will be equivalent to a move_alloc, while if they are just standard variables it will means a simple assignment. You cannot use a subroutine in this case as TKR will strike.

Thanks for your praise, I also read all your posts as they are always very interesting.

I hope that this brainstorming is useful for the future development of this language and that the Fortran committee can take some idea from here.

Cheers, Edmondo

[Ev. Drikos]

On 12/09/2017 11:35, edmondo.g...@gmail.com wrote:
> I mean I would have liked that if "a" and "b" are allocatable variable
> a <= b
> will be equivalent to a move_alloc, while if they are just standard variables it will means a simple assignment.

Hello,

Please note that using a relop (.le.) for a special type of assignments
at the beginning of a statement seems syntactically possible, I've not
tested & confirmed it, but IMO it can prevent a more important feature.

Currently Fortran doesn't allow assignment expressions as an expression
primary but I hope we will see them in the near future.


Ev. Drikos

[edmondo.g...@gmail.com]

Il giorno martedì 12 settembre 2017 16:39:41 UTC+2, Ev. Drikos ha scritto:

Well, yes, but while
a += 1
may be interpreted as:
a = a + 1
It's not clear for me how to interpret:
a = a < b
as the "a" should be a logic variable and so it cannot be compared in a ".le." expression.

That said, we may use a "<==" symbol for the move assignment, or whatever collection of symbolic characters you like, I have just taken the first I thought but I'm not stick to it.

Cheers,
Edmondo

[Jos Bergervoet]

On 9/12/2017 5:31 PM, edmondo.g...@gmail.com wrote:
> Il giorno martedì 12 settembre 2017 16:39:41 UTC+2, Ev. Drikos ha scritto:
>> On 12/09/2017 11:35, wrote:
>>> I mean I would have liked that if "a" and "b" are allocatable variable
>>> a <= b
>>> will be equivalent to a move_alloc, while if they are just standard variables it will means a simple assignment.
>>
>> Hello,
>>
>> Please note that using a relop (.le.) for a special type of assignments
>> at the beginning of a statement seems syntactically possible, I've not
>> tested & confirmed it, but IMO it can prevent a more important feature.
>>
>> Currently Fortran doesn't allow assignment expressions as an expression
>> primary but I hope we will see them in the near future.
>>
>>
>> Ev. Drikos
>
> Well, yes, but while
> a += 1
> may be interpreted as:
> a = a + 1
> It's not clear for me how to interpret:
> a = a < b

Also, it seems difficult to get the interpretation of
a /= 2
to be
a = a/2
because it already has the meaning
.not. (a == 2)

So probably one can only introduce +=, -= and *= with
their usual meaning as assignment expressions, but not
the corresponding one for division..

--
Jos

[Ev. Drikos]

On 12/09/2017 18:31, edmondo.g...@gmail.com wrote:
>> Currently Fortran doesn't allow assignment expressions as an expression
>> primary but I hope we will see them in the near future.

>> ...

> Well, yes, but while
> a += 1
> may be interpreted as:
> a = a + 1
> It's not clear for me how to interpret:
> a = a < b
> as the "a" should be a logic variable and so it cannot be compared in a ".le." expression.

I's not referring to C/C++ assignment operators like "+=" or "-="; just
the Fortran assignment & pointer assignment operators, ie:

If ( y = f(x) > 0 ) print *, "f(x)=", y

Ev. Drikos

[Ian Harvey]

Fortran does not have assignment or pointer assignment operators. Adding them to the language would be quite a change.

[Ev. Drikos]

On 13/09/2017 06:53, Ian Harvey wrote:
> Fortran does not have assignment or pointer assignment operators. ...
>

They aren't named so?

[Ian Harvey]

Fortran has assignment and pointer assignment statements. The '=' and '=>' tokens in those statements, that delineate the left hand side thing being assigned to from the right hand side expression (or target), are just bits of syntax. Unlike similar constructs in other languages, those tokens do not designate operators.

Operators in Fortran, currently, must not alter their operands. You would need to remove that restriction for an assignment operator to be useful. Removing that restriction would have implications for things like the ordering of evaluation of operands in an expression, which the language currently does not specify at all, or even the need to evaluate an expression at all. Tread carefully.

Consider that defined assignment in Fortran is specified using a subroutine, while a defined operator is specified using a function.

As an aside, Fortran 2008 as initially published did permit syntax along the lines of `a <= b = c`, where `a <= b` had to resolve to a function with a data pointer result. That resulted in a syntax ambiguity, so the ability to have that sort of syntax was removed/restricted.

[Thomas Jahns]

On 09/12/17 21:51, Jos Bergervoet wrote:
> Also, it seems difficult to get the interpretation of
>   a /= 2
> to be
>   a = a/2
> because it already has the meaning
>   .not. (a == 2)

But since integer and logical are separate types in Fortran, the interpretation
would be unambiguous, even though Fortran (as most other languages)
traditionally does not consider the left-hand-side of assignment for resolving
such issues.

Thomas

[edmondo.g...@gmail.com]

As one of the reason I have preferred an "assignment" for the "move" operation is that one routine cannot have dummy arguments that can be both allocatable, that can be allocated inside the routine, and not allocatable not pointer (let's say "normal") arguments.

So another crazy idea, the assumed allocation.
A dummy can be defined as assumed allocation, that is something like:

subroutine visitrome(a)
real,allocation(:) :: a

if (isallocatable(a)) then
if (.not.allocated(a)) allocate(a)
end if
a = ...
end subroutine

that can be called as:
real, allocatable :: a
real :: b

call visitrome(a)
call visitrome(b)

Some points, first assumed allocation dummy variable are equivalent to allocatable and "normal" dummy arguments, but not to pointers dummy argumetns as the "intent" meaning for pointer dummy arguments is quite different from that of "normal" or allocatable variable.

Allocatable actual argument with intent(out) will be deallocated as usual, while nothing happen to "normal" variable. Attempt to allocate or deallocate a "normal" variable will result in a runtime error.

A possible syntax sugar that may change slightly the behaviour of not conforming program is to allow a "normal" variable as argument to the "allocated" function, the result should be ".true.". That way one may simplify the above function with just an "if(.not.allocated(a)) allocate(a)" without checking first if it is an allocatable.

One possible tricky point is related to the upper and lower index, but I think the best is to stick to the actual behaviour.

If a pointer is passed as an actual arguments should be treated as it were a "normal" dummy argument as it is now.

Cheers,

[Ev. Drikos]

On 13/09/2017 10:37, Ian Harvey wrote:
> ...

> Operators in Fortran, currently, must not alter their operands.

> ...

Perhaps you are right but recently I posted an example to c.l.f that
does exactly that and the compiler didn't even warn me. It's sth like:

stack = stack + disk

In that example, the overloaded binary operator '+' pushes the right
operand onto the stack and returns a stack reference also, so it can be
reused in various ways, ie as shown above.

Is such an instruction illegal?

Ev. Drikos

[Ian Harvey]

The dummy arguments in a function that implements a defined operation
must be INTENT(IN) - see F2008 12.4.3.4.2p1.

You are not permitted to define or redefine a dummy argument that is
INTENT(IN) during the execution of the relevant procedure (F2008 5.3.10p2).

If the function invoked by the expression `stack + disk` redefines
`stack` or `disk` - changes their value, in the sense that Fortran
defines values for objects of derived type - then the code is
non-conforming.

(Fortran's concept of value of an object of derived type (F2008 4.5.8)
does not consider the value of pointer components.)

I can't comment on specifics of the code beyond that, without seeing the
specific code.

[edmondo.g...@gmail.com]

As you said, the actual stack may be changed if it is stored in a pointer component of the dummy argument with intent(in).

Note 5.16 of 5.3.10 paragraph applies.

[Dick Hendrickson]

Remember that types don't have to be intrinsic, operators can be
overloaded even for intrinsic-type operands, and right-hand-sides can be
complicated expressions. I'd be surprised if things like "+=" could be
defined for the general case and not surprise some people.

Dick Hendrickson

[Ev. Drikos]

Likely, the interpretation would be unambiguous because Fortran doesn't
allow expression statements, that is a statement that is an expression.


Ev. Drikos

[Ev. Drikos]

On 13/09/2017 14:18, Ian Harvey wrote:
> On 13/09/2017 8:03 PM, Ev. Drikos wrote:

> ...

> The dummy arguments in a function that implements a defined operation
> must be INTENT(IN) - see F2008 12.4.3.4.2p1.
>
> You are not permitted to define or redefine a dummy argument that is
> INTENT(IN) during the execution of the relevant procedure (F2008 5.3.10p2).
>
> If the function invoked by the expression `stack + disk` redefines
> `stack` or `disk` - changes their value, in the sense that Fortran
> defines values for objects of derived type - then the code is
> non-conforming.
>
> (Fortran's concept of value of an object of derived type (F2008 4.5.8)
> does not consider the value of pointer components.)
>

Thank you, I'll also have a closer look at the draft.

> I can't comment on specifics of the code beyond that, without seeing the
> specific code.

The example is here:
groups.google.com/d/msg/comp.lang.fortran/VI64EaFSSY0/O88D9HV_BAAJ

Ev. Drikos

[Ian Harvey]

The functions in that stack example that implement the defined operations do not not modify their arguments. For example, op_push first copies one of its arguments into the function result variable, and then modifies that copy.

[Ev. Drikos]

On 13/09/2017 22:49, Ian Harvey wrote:
> The functions in that stack example that implement the defined operations do not not modify their arguments. For example, op_push first copies one of its arguments into the function result variable, and then modifies that copy.
>

Indeed, you're right.

It's a surprise to me that a reference assignment actually clones
(copies) the object.

[Ian Harvey]

What do you mean by reference assignment?

A reference in Fortran is typically modelled using a Fortran pointer.

[Ev. Drikos]

On 14/09/2017 03:05, Ian Harvey wrote:
> What do you mean by reference assignment?
>

The arguments are passed by reference and my assumption was that the
function returns a reference, in that case the one I'd assigned to it.

[Ian Harvey]

That confuses implementation with language specification.

For all we know, the arguments are passed on a silver platter with a side serving of greens. Being a little more realistic, for intent(in) arguments, it is quite conceivable that the arguments are passed by value.

But it doesn't really matter, the language specifies how argument association should appear to behave, and it specifies how assignment should appear to behave.

[Ev. Drikos]

On 14/09/2017 07:24, Ian Harvey wrote:


At first, I'd like to say that I appreciate your feedback.

>
> ... Being a little more realistic, for intent(in) arguments, it is quite conceivable that the arguments are passed by value.
>

Since the language however has the keyword "VALUE", it's not obvious to
me; BTW, there is also the concept of a constant reference ("const") in
other languages.

...

> But it doesn't really matter, the language specifies how argument association should appear to behave, and it specifies how assignment should appear to behave.
>

Without any doubt!

Ev. Drikos

[herrman...@gmail.com]

On Tuesday, September 12, 2017 at 12:51:37 PM UTC-7, Jos Bergervoet wrote:

(big snip)

> Also, it seems difficult to get the interpretation of
> a /= 2
> to be
> a = a/2
> because it already has the meaning
> .not. (a == 2)

> So probably one can only introduce +=, -= and *= with
> their usual meaning as assignment expressions, but not
> the corresponding one for division..

The assignment operator, and allowing general expressions
as statements, is a funny feature of C.

It is legal in C to have a statment:

2+2;

which adds 2 and 2, and ignores the result.

Note that Java removed this feature. You can still call
functions (methods) and ignore the result in Java, but not
general expressions.

Note that there are complications with allowing expression
statements to Fortran. If you have a function named READ:

READ(3)

would be a legal function reference.

Without adding general expressions as statements, one could
add new assignment statements, such that:

i += 2

and

i /= 2

where legal assignment statements. As

i.ne.2

is not a legal assignment, there is no ambiguity.

Yes C and Java allow one to put an assignment into
an expression, but this isn't done all that often.
(I don't count the parts of for, or the content of
while, where those do occur as an expression context.)

[Ev. Drikos]

On 15/09/2017 21:07, herrman...@gmail.com wrote:

> ...

> Without adding general expressions as statements, one could
> add new assignment statements, such that:
>
> i += 2

What would offer such a shorthand to Fortran?

> Yes C and Java allow one to put an assignment into
> an expression, but this isn't done all that often.
> (I don't count the parts of for, or the content of
> while, where those do occur as an expression context.)
>

Perhaps, it could facilitate source code conversion from C to Fortran.

Since function calls in Fortran can have name arguments, such a feature
would had to be a bit more complex though.

Ev. Drikos

[herrman...@gmail.com]

On Friday, September 15, 2017 at 11:56:13 AM UTC-7, Ev. Drikos wrote:

(snip, I wrote)

> > Without adding general expressions as statements, one could
> > add new assignment statements, such that:

> > i += 2

> What would offer such a shorthand to Fortran?

Not all that much in that case, but consider

bigarray(i+j, k-l, m-i)%somemember(l-m) += y(x)

For even slightly complicated left sides, it means you
don't have to verify that the two are the same every time
you look at it, debug it, or change it.

It has the additional advantage, more important in C,
that any side effects only happen once:

array(myrand(x)) += 1

is not the same as:

array(myrand(x)) = array(myrand(x)) + 1

if myrand(x) can be different each time it is called,
such as if it is a random number generator.

[spectrum]

On Saturday, September 16, 2017 at 5:20:15 AM UTC+9, herrman...@gmail.com wrote:
> On Friday, September 15, 2017 at 11:56:13 AM UTC-7, Ev. Drikos wrote:
>
> (snip, I wrote)
>
> > > Without adding general expressions as statements, one could
> > > add new assignment statements, such that:
>
> > > i += 2
>
> > What would offer such a shorthand to Fortran?
>
> Not all that much in that case, but consider
>
> bigarray(i+j, k-l, m-i)%somemember(l-m) += y(x)
>
> For even slightly complicated left sides, it means you
> don't have to verify that the two are the same every time
> you look at it, debug it, or change it.
>

Yes, I have been using some macro exactly for this purpose (i.e., to avoid
writing a long-name thing twice).

When I was using F77, I needed to write a lot of 6-dimensional loops for some
calculation, and it was tedious to check the exact match of indices
on the left- and right-hand sides of an assignment, something like

somevecA( i1, i2, i3, i4, i5, i6 ) = somevecA( i1, i2, i3, i4, i5, i6 ) + otherVecB3( i1, i2, i3+m, i4, i5, i6 ) * hmat( i5, i6 )

(please don't worry about details... I just don't remember it :)
To make it even a bit easier to read the expression, I often wrote it like

somevecA( i1, i2, i3, i4, i5, i6 ) =
somevecA( i1, i2, i3, i4, i5, i6 ) + otherVecB3( i1, i2, i3+m, i4, i5, i6 ) * hmat( i5, i6 )

After F90, I have been using

_( somevecA( i1, i2, i3, i4, i5, i6 ) ) + otherVecB3( i1, i2, i3+m, i4, i5, i6 ) * hmat( i5, i6 )

by defining

#define _(x) x = x

(which is included by my "default" header file).
So, I would really appreciate if += etc are included into the standard :-)

# I guess /= will not have ambiguity because the conditional part in IF statements
do not allow assignment. Another possibility of ambiguity is boolean (e.g., a /= b /= c), but if a /= b is regarded as boolean, it is simply illegal because it means assignment to boolean values.

[spectrum]

> After F90, I have been using

Here, "F90" is not important (as standards), I just mean I started using macros
after learning F90 or 95...

[Ian Harvey]

associate(x => somevecA( i1, i2, i3, i4, i5, i6 ))
x = x + otherVecB3( i1, i2, i3+m, i4, i5, i6 ) * hmat( i5, i6 )
end associate

I would only use the C preprocessor for this sort of stuff if I was
deliberately trying to obfuscate my code and confuse future readers.

[spectrum]

Hi Ian,

> I would only use the C preprocessor for this sort of stuff if I was
> deliberately trying to obfuscate my code and confuse future readers.

It is no problem because many of my codes are written solely
for my own calculations (not for passing to others). Besides, I can readily
convert them (when necessary) to standard Fortran sources
by applying C processors (<-- this is the important part :)

Also, although people often suggests me to use associate constructs,
in my very honest opinion, it is not very readable when used for single
assignment because of the verboseness of the words
"associate" and "end associate" (though they are of course useful
for giving short-hand names when such variables appear many times
in a scope).

[spectrum]

> I would only use the C preprocessor for this sort of stuff if I was
> deliberately trying to obfuscate my code and confuse future readers.

PS. I'm not advocating more "active or aggressive" use of C processors.
Rather, I'm trying to show how such "efforts" (via some preprocessing) have been
made by the user to augment facilities that are not present in current Fortran
(including generic containers, maybe...)

[Ev. Drikos]

On 15/09/2017 23:20, herrman...@gmail.com wrote:
> On Friday, September 15, 2017 at 11:56:13 AM UTC-7, Ev. Drikos wrote:
>
> (snip, I wrote)
>
>>> Without adding general expressions as statements, one could
>>> add new assignment statements, such that:
>
>>> i += 2
>
>> What would offer such a shorthand to Fortran?
>
> Not all that much in that case, but consider
>
> bigarray(i+j, k-l, m-i)%somemember(l-m) += y(x)
>

As a Fortran learner, I haven't seen so far neither pointer arithmetic
nor iterators and I'm also curious to figure out how one can access big
arrays efficiently, especially those which have dynamic shape.

When I hear about big arrays this is my first thought.

Ev. Drikos