Requirements for the next standard after Fortran 2015 (tentatively called F2020)

[jean....@gmail.com]

Good evening,

At the next Fortran standards committee meeting that will be held in June 2017, there will be a discussion about planning the next revision:

http://j3-fortran.org/doc/year/17/agenda213.txt

Is there a way for the public to submit a list of features that we would like to be included in the next standard?

For example, generic programming and block based exception handling have been requested a lot of times

Regards,

Jean

[michael siehl]

> Is there a way for the public to submit a list of features that we would like > to > be included in the next standard?

That would be interesting to me too. I have no experiences with submitting something to the standards committee and thus no idea about the requirements for submitting.

In a recent post, here:
https://groups.google.com/forum/#!topic/comp.lang.fortran/5ftwToZ7zdo
or here:
https://github.com/flang-compiler/flang/issues/64
I did mention a a very small coarray-related extension to the F2008 standard: A kind of execution segment or SYNC MEMORY-counter. See the following excerpt from that post:
----------
3. I plan to develop a simple example of coarray-based library code: In principle it should be no problem to use our coarray programming approach to develop (nearly) independent parallel library codes.
4. derived from point 3: I would like to suggest a very simple coarray-related extension to the Fortran 2008 language: A build-in counter for the number of times the SYNC MEMORY statement gets executed (just counting locally on each coarray image): Something like a THIS_SEGMENT intrinsic, where SEGMENT means 'execution segment', i.e. the number of times SYNC MEMORY got executed on that image. (This counter would not be limited to the SYNC MEMORY statement itself, but also count for any other build-in synchronization method that does implicitly execute SYNC MEMORY). Such a simple feature could then already allow for development of completely independent parallel library codes based on coarrays.
(My current approach does require that all parts of an application, and thus all library codes, do use the same segment / SYNC MEMORY counter, which does prevent completely independent coarray-based library development).
----------
I did develop such a counter myself using F2008 syntax already. It works, but the disadvantage is, that the whole application can only make use of a single SYNC MEMORY statement (not realy a disadvantage) and no other build-in synchronization method can be used (that is a real disadvantage). It does also prevent independent coarray-based library development which is my main reason for demanding such a feature.

cheers

[Jacob Williams]

My hope is that they can move toward some kind of modern and open collaboration model that engages the Fortran user community. Fortran could learn a thing or two from some of these newfangled languages like Python. It looks like even the C++ committee is using GitHub now.

[kergonath]

It is a bit fragmented, but there are a lot of very useful Fortran codes on
GitHub. Do you mean a kind of package manager like pip or CPAN? If so, I
would think that it is up to the community to do something, the members of
the committee will never agree on something like that.

That said, agreeing on one format across compilers for the .mod files would
be a good step to make the developers' lives easier. I have found that this
is a significant obstacle to using libraries from GitHub (or elsewhere).

[Gary Scott]

.mod files need to be very efficient...that probably means what's
efficient for one compiler might not be efficient or suitable for
another. Definitely don't want some sort of parable text. That would
be a killer.

[Beliavsky]

Why? When you download the Fortran source files from GitHub and compile them, the .mod files will be generated for you.

[Jacob Williams]

On Saturday, May 27, 2017 at 6:17:46 PM UTC-5, kergonath wrote:
> It is a bit fragmented, but there are a lot of very useful Fortran codes on
> GitHub. Do you mean a kind of package manager like pip or CPAN? If so, I
> would think that it is up to the community to do something, the members of
> the committee will never agree on something like that.

No, I was referring to collaboration on the standard itself (e.g. designing new language features).

[spectrum]

On Sunday, May 28, 2017 at 3:09:37 AM UTC+9, Jacob Williams wrote:
> My hope is that they can move toward some kind of modern and open collaboration model that engages the Fortran user community. Fortran could learn a thing or two from some of these newfangled languages like Python. It looks like even the C++ committee is using GitHub now.

I think Jacob is referring to this kind of committee and community discussions/interactions
like feature/future proposals, new standard library design, issue tracking (about
base syntax and libraries), or any other things about a language itself:

https://isocpp.org/
https://isocpp.org/forums
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals

https://isocpp.org/std/submit-issue
https://isocpp.org/std/submit-a-proposal

The life of an ISO proposal: From “cool idea” to “international standard”
https://isocpp.org/std/the-life-of-an-iso-proposal

And info about what the "committee" and "meetings" are...
https://isocpp.org/std/the-committee
https://isocpp.org/std/meetings-and-participation
# But I guess the need for this kind of "physical" meetings (that need cost) will decrease
gradually because online discussions are now very convenient (including
forums, Github, mail list, etc.)

Though I don't know C++ very well nor the Python community,
various languages seem to be utilizing such developer and community interactions
(if I look at their Github or forum pages). So I also wish such kind of mechanism also exists
in Fortran... (maybe not existing, or even if it exits, not very visible to usual users like us..?)

[spectrum]

Sorry typo...XD
(x) it exits,
=>
(o) it exists

[Thomas Koenig]

kergonath <no_e...@invalid.invalid> schrieb:

> That said, agreeing on one format across compilers for the .mod files would
> be a good step to make the developers' lives easier. I have found that this
> is a significant obstacle to using libraries from GitHub (or elsewhere).

Even if the .mod files were compatible, the object files are not. Each
compiler its own run-time library, and they are all different.

[Dan Nagle]

Hi,

On 2017-05-28 01:31:12 +0000, Jacob Williams said:
> I was referring to collaboration on the standard itself (e.g. designing
> new language features).

I think one issue is to limit the overall magnitude of the worklist
so that compiler suppliers can produce fully-compliant compilers
in a few years. I won't pick "few", but << 10 would be helpful.

That is, writing the standard is all the committee does.
The speed with which actual compilers are made is a limiting factor.

How would you know what feature you want next if you haven't yet used
a compiler supporting all of the latest revision?

--
Cheers!

Dan Nagle

[Gary Scott]

How about a standarized way to interface with MS Visual Studio...that
would save compiler vendors thousands of manhours of wasted effort :)

[Gary Scott]

Not to mention user frustration...

[Richard Maine]

Dan Nagle <danl...@mac.com> wrote:

> How would you know what feature you want next if you haven't yet used
> a compiler supporting all of the latest revision?

That sounds an awful lot like an argument I made some years ago about
approving f2008 before f2003 compilers were widely available. My
argument lost. :-(

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Gary Scott]

On 5/28/2017 10:27 AM, Richard Maine wrote:
> Dan Nagle <danl...@mac.com> wrote:
>
>> How would you know what feature you want next if you haven't yet used
>> a compiler supporting all of the latest revision?
>
> That sounds an awful lot like an argument I made some years ago about
> approving f2008 before f2003 compilers were widely available. My
> argument lost. :-(
>

All I can say is if airplanes and space craft were designed this way,
we'd still be riding in Fred Flintstones' buggy

[Anton Shterenlikht]

Jacob Williams <ja...@degenerateconic.com> writes:

>My hope is that they can move toward some kind of modern and open collabora=
>tion model that engages the Fortran user community. Fortran could learn a t=
>hing or two from some of these newfangled languages like Python. It looks l=

>ike even the C++ committee is using GitHub now.

Github is not going to happen any time soon.
Probably never.
The collaboration is already open.
It happens via the mailing lists.

Anton

[Anton Shterenlikht]

Right... that must be very high on the agenda list for Cray... or IBM...

Anton

[Anton Shterenlikht]

jean....@gmail.com writes:

>Is there a way for the public
> to submit a list of features
> that we would like to be included
> in the next standard?

Ask in
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90

Anton

[Gary Scott]

Well, those have really tiny user bases, not to mention the irrelevance.

[FortranFan]

On Monday, May 29, 2017 at 2:29:18 AM UTC-4, Anton Shterenlikht wrote:

> ..

>
> Github is not going to happen any time soon.
> Probably never.
> The collaboration is already open.
> It happens via the mailing lists.

> ...

@Anton Shterenlikht, @Dan Nagle, and anyone else from the current standard committee who is reading this:

There are many reasons why so many collaboration teams globally have long moved away from mailing lists toward "share" sites such as GitHub which greatly improve productivity, speedup communication, provide good project management and workflow, help reduce errors and rework, enhance documentation particularly with markdown, allow inclusion of 'metadata' via wikis and gists i.e., additional knowledge and background information and data about any new ideas or concepts or data that might be introduced into an effort or a project, facilitate information archival particularly on use cases, and so forth.

A constant refrain has been how resource-constrained is the Fortran standard committee.

Under the circumstances any tools and approaches that can help the committee achieve more with the same is something that should be earnestly investigated, not brushed off so abruptly.

[FortranFan]

On Sunday, May 28, 2017 at 11:22:37 AM UTC-4, Gary Scott wrote:

> ..

> How about a standarized way to interface with MS Visual Studio ..

@Gary Scott,

You know, I know, and the American people know your suggestion about Visual Studio will be and, more importantly, needs to be DOA**.

Separately, you are one who frequently brings up bitstrings in the context of almost any enhancement to the Fortran standard:
https://groups.google.com/d/msg/comp.lang.fortran/iWUgXY0UJ4s/NGHSmmZREAAJ
https://groups.google.com/d/msg/comp.lang.fortran/1TbfQlAmKx8/sT055Qv4BQAJ

This year and the next couple of years provide a crucial window for you to put together a proposal along with your use cases on bitstings.

And if you think you are 'ill-equipped' (https://groups.google.com/d/msg/comp.lang.fortran/1TbfQlAmKx8/XvjRC0ZEBgAJ), use this forum or GitHub or any other mechanism - online or offline - to collaborate with others who can help you put a proposal together. Someone with your experience can achieve this.

But if you are not willing to put the effort toward this, then please stop bringing it up anytime anyone suggests any Fortran feature, it is greatly distracting to say the least.

Thanks,


** http://www.webopedia.com/TERM/D/DOA.html

[Jos Bergervoet]

Speaking about blocks, is there already an action going for the
BLOCK / END BLOCK construct, to add the "use only ..." option?

Shadowing host variables is of course a nuisance, so if you can
select *which ones* that might be easier to read. (Especially if
you read with a compulsive scope checking habit, that is..)

--
Jos

[FortranFan]

On Sunday, May 28, 2017 at 11:12:50 AM UTC-4, Dan Nagle wrote:

> ..

>
> How would you know what feature you want next if you haven't yet used
> a compiler supporting all of the latest revision?

> ..


@Dan Nagle,

I have an extremely hard time comprehending your statement and any attempt on my part to understand it makes me tremendously upset and angry and concerned as to what it implies and that how anyone on the committee can be implying such a thing. So instead of anyone trying to delve into it, it will be useful if you can elaborate what you meant.

For otherwise, the implication will remain you and perhaps others on the committee consider contributors here - i.e., those of us who have feature that we want - are absolutely stupid, that we cannot read and think for ourselves, that we are mindless minions in the absence of standard-conforming processors, that we cannot bring to bear our own mental compilers to process code when the physical ones fail us, that the broader scientific/technical computing domain is either empty or static so there is nothing new to learn from it, that any features already introduced in the standard - even if half-baked due to a non-technical reason such a time-resource constraint or sheer failure of imagination - should be adequate for all until someone in an ivory tower and on the committee has a new revelation, that coders can and will wait forever, even for features that languages such as Ada adopted all the way back in the early 1990s, the possibilities seem endless.

Your statement, without further explanation, appears to betray some of the fundamental questions about Fortran, the so-called WH ones:

WHy Fortran? For WHom? and most importantly, WHen?

And in the meantime, please review and have all other committee members review threads here such as:
https://groups.google.com/d/msg/comp.lang.fortran/R_zBfQKmcHE/5a_KthCMBgAJ
https://groups.google.com/d/msg/comp.lang.fortran/1TbfQlAmKx8/n84hTWpgAwAJ
https://groups.google.com/d/msg/comp.lang.fortran/iWUgXY0UJ4s/LoPqAJggEAAJ
https://groups.google.com/d/msg/comp.lang.fortran/Wo-MxUp-gIY/h8cOUNESAAAJ
https://groups.google.com/d/msg/comp.lang.fortran/AFtpnBh6eLg/2jMw1e_5AgAJ

and that should inform you that no, one does NOT need a compiler supporting ALL of the latest revision to figure out what one wants next.

And please note the issue here is not that of any lack of appreciation and understanding of the tremendous effort and contributions of those on the committee and the time-resource constraints they face - in fact it's clear each and every reader here is most appreciative of the vast and volunteer effort. But the problems being noticed are in terms of a) insufficient engagement on the technical aspects and b) the needless pushbacks along non-technical lines such as the one here or that seen previously about presenting use cases. But when the committee itself is queried of use cases of features added as recently as Fortran 2008 or even 2015, very little useful/actionable information is forthcoming.

Thanks,

[FortranFan]

On Monday, May 29, 2017 at 1:18:34 PM UTC-4, Jos Bergervoet wrote:

> ..

>
> Speaking about blocks, is there already an action going for the
> BLOCK / END BLOCK construct, to add the "use only ..." option?
>
> Shadowing host variables is of course a nuisance, so if you can
> select *which ones* that might be easier to read. (Especially if
> you read with a compulsive scope checking habit, that is..)

> ..


@Jos Bergervoet,

Fortran 2015 has addressed this, thankfully, with the greatly enhanced IMPORT facility, "The IMPORT statement can appear in a contained subprogram or BLOCK construct, and can restrict access via host association; diagnosis of violation of the IMPORT restrictions is required."

So one would be able to do:

-- begin example --
<program or subprogram> foo
..
integer :: i
..
blk1: block
import none ! or import, only : to access specific entities from host
integer :: i ! does not conflict with the host
..
-- end example --

[Richard Maine]

FortranFan <pare...@gmail.com> wrote:
[stuff]

I think i've reached my limit on this sort of posting style, which has
become way too common on the newsgroup recently. I don't need the
aggravation. A killfile entry doesn't help much, and the option to kill
whole infected threads would lose much of the newsgroup anyway.

No need for me to elaborate details. I'm confident that those who would
understand already do, and my prior attempts to address some who don't
get it have been utter failures. I think I'll take Mom's advice on what
to say when I have nothing good to say.

Maybe I'll check back again in a few months. Bye for now. No point in
replying here. A few who know me on facebook can let me know if the tone
here becomes more civilized.

[Gary Scott]

Yes, it was just being silly...after being blasted with a continuous
stream of Intel forum messages related to VS integration for a few
months, it has made me afraid to install the latest upgrade. I had
significant difficulty myself with update 2.

I have near zero time. I have rental properties, I'm remodeling parts
of my own hose, I have important applications that I maintain and
continuously add new features to by request, doing this largely over the
weekend because I have a regular engineering job during the week. I
just can't focus on standard committee stuff. I do have a desire, I
truly DO NOT think I'm qualified, and I truly think that there is little
to no interest in the very tiny number of items I'd like to see improved.

[spectrum]

Hmm, I'm sorry if my posting about the C++ sites or my way of writing
about "committee/user" interactions is not very good... (My intention is
that, if the visibility becomes greater, then more contributors may come.)

# This might be the "red zone" that should not be touched or mentioned
(warned by Stefano before...)

# One thing I completely failed to understand is that, the size of the community
is probably too different between C++ and Fortran (so naturally affecting the
ease of gathering contributors etc). This is probably because C++ is systems
programming language (not limited to HPC), and also games industry uses it
for developing video games (e.g., World of Warcraft <-- good-old MMORPG :-).

And today I have got to know (while looking at the Fortran standards site),
that Richard was the main editor of Fortran95-2003 :-O
http://www.nag.co.uk/sc22wg5/officers.html

And another finding is that various names ("John Reid", "Bill Long") are in the
JISCmail site
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90

But IMHO, it is pretty difficult for any visitor to quickly recognize that this site
is most suited for posting such things (like requests of features etc), because
the site name is like "Fortran 90" and the web site itself is written as
"for UK education and research"...

[Anton Shterenlikht]

Gary Scott <garyl...@sbcglobal.net> writes:

>>>> How about a standarized way to interface with MS Visual Studio...that
>>>> would save compiler vendors thousands of manhours of wasted effort :)
>>> Not to mention user frustration...
>>
>> Right... that must be very high on the agenda list for Cray... or IBM...
>>
>> Anton
>>
>Well, those have really tiny user bases, not to mention the irrelevance.

Both Cray and IBM have representatives on the committee, MS do not.

Anton

[Anton Shterenlikht]

FortranFan <pare...@gmail.com> writes:

>On Monday, May 29, 2017 at 2:29:18 AM UTC-4, Anton Shterenlikht wrote:

>> ..

>>=20

>> Github is not going to happen any time soon.
>> Probably never.
>> The collaboration is already open.
>> It happens via the mailing lists.
>> ...

>@Anton Shterenlikht, @Dan Nagle, and anyone else from the current standard =

>committee who is reading this:

>There are many reasons why so many collaboration teams globally have long m=
>oved away from mailing lists toward "share" sites such as GitHub which grea=
>tly improve productivity, speedup communication, provide good project manag=
>ement and workflow, help reduce errors and rework, enhance documentation pa=
>rticularly with markdown, allow inclusion of 'metadata' via wikis and gists=
> i.e., additional knowledge and background information and data about any n=
>ew ideas or concepts or data that might be introduced into an effort or a p=
>roject, facilitate information archival particularly on use cases, and so f=
>orth.

>A constant refrain has been how resource-constrained is the Fortran standar=
>d committee.

>Under the circumstances any tools and approaches that can help the committe=
>e achieve more with the same is something that should be earnestly investig=

>ated, not brushed off so abruptly.

The J3 committee has it's way of working,
and they have their reasons.
I'm a member of WG5, not of J3.
A version control software is used by J3,
although not to its full potential,
in my opinion.

When I asked for something similar to what you mention,
in JUN-2016, the majority (?) opinion was - no.
The reason given, as far as I understood, that the
the benefits you mention above are not applicable
to standard development work, and the standard is
not best developed using open source software development
practice.

When I say that github is probably not going to be used ever,
this is simply my assessment of the mood of J3.

Anton

[Anton Shterenlikht]

spectrum <septc...@gmail.com> writes:

>But IMHO, it is pretty difficult for any visitor to quickly recognize that this site
>is most suited for posting such things (like requests of features etc), because
>the site name is like "Fortran 90" and the web site itself is written as
>"for UK education and research"...

It's just a personal observation that
some J3 members do not read this group,
but do read the fortran-90 list.
That's all.

I heard from one J3 member an opinion
that CLV is perceived to be dominated by
MS related discussions, and since
he represents a company which has zero
interest in MS users, it's worth his time
to read this group.
I tried to persuade him otherwise.

Anton

[JB]

On the odd chance that you ever read this, thank you for all your
Fortran work over the years.

When I started following c.l.f slightly more than a decade ago, RM's
posts quickly rose, IMHO, to the top in terms of posts worth reading
for their sage advice and in-depth knowledge of the language.

On a related note, while my contributions to this newsgroup are
obviously dwarfed by those of RM, I think I'll also take this
opportunity to say my farewells. I have been mulling over this for a
while, and I guess RM's decision is the final drop, so to speak. My
reasons are largely the same I suspect RM has, although he refrained
from elaborating so I can only speculate. Dropping c.l.f does feel a
bit nostalgic though, as c.l.f is the last usenet newsgroup I have
bothered following, the others having become the usual usenet
cesspools long ago.

So Long, and Thanks for All the Fish!

--
JB

[Gary Scott]

I'm well aware Anton. My post was in jest.

[jean....@gmail.com]

Le dimanche 28 mai 2017 11:22:37 UTC-4, Gary Scott a écrit :

> How about a standarized way to interface with MS Visual Studio...that
> would save compiler vendors thousands of manhours of wasted effort :)

I think this is more an implementation issue than a problem with the Fortran language itself.
One could also ask for a better Xcode integration for OS-X, but again this is implementation issue.

Regards,

Jean

[jean....@gmail.com]

There are features that are already missing:

1- Generic programming to allow reuse of code.
2- Block based exception handling (ex: try/ catch blocks or equivalent).

3- For image and signal processing, unsigned integers. It is frustrating to use the character data type
to represent 8 bit pixels properly.

A few other items would be also desirable.

Regards,

Jean

[Gary Scott]

:) yes, it was in part a complaint of how much effort various vendors
spend trying to make the VS integration work (or not work, often). That
is effort they could be spending on the compiler itself.

[kergonath]

Beliavsky <beli...@aol.com> wrote:
> On Saturday, May 27, 2017 at 7:17:46 PM UTC-4, kergonath wrote:

>> Jacob Williams <ja...@degenerateconic.com> wrote:
>>> My hope is that they can move toward some kind of modern and open

>>> collaboration model that engages the Fortran user community. Fortran
>>> could learn a thing or two from some of these newfangled languages like
>>> Python. It looks like even the C++ committee is using GitHub now.
>>>
>>
>> It is a bit fragmented, but there are a lot of very useful Fortran codes on
>> GitHub. Do you mean a kind of package manager like pip or CPAN? If so, I
>> would think that it is up to the community to do something, the members of
>> the committee will never agree on something like that.
>>
>> That said, agreeing on one format across compilers for the .mod files would
>> be a good step to make the developers' lives easier. I have found that this
>> is a significant obstacle to using libraries from GitHub (or elsewhere).
>
> Why? When you download the Fortran source files from GitHub and compile
> them, the .mod files will be generated for you.
>

Yes, but it means that I have to download and recompile every library. And
then do it again next time I install another code because the build systems
would be different and would expect things to be done in a different way. I
understand very well that there are good and bad reasons for each compiler
having its own format, it still is a pain to deal with if you distribute a
reasonably-complex code. It means that there can be no unified way of
distributing applications and everyone has to come up with a
glue-and-duct-tape solution. Granted, that is only tangentially relevant as
I misunderstood the point being made :)

[kergonath]

Jacob Williams <ja...@degenerateconic.com> wrote:

> On Saturday, May 27, 2017 at 6:17:46 PM UTC-5, kergonath wrote:
>> It is a bit fragmented, but there are a lot of very useful Fortran codes on
>> GitHub. Do you mean a kind of package manager like pip or CPAN? If so, I
>> would think that it is up to the community to do something, the members of
>> the committee will never agree on something like that.
>

> No, I was referring to collaboration on the standard itself (e.g.
> designing new language features).
>

Right, I see. Sorry, the following sentence about GitHub confused me. On
the other hand, is there anything to prevent us ("the community") from
doing that and then propose something for consideration?

[spectrum]

Hi Anton,

While searching the net more (starting from the JISCmail), I've found this page

Report from the JUN-2016 Fortran standardisation committee meeting
http://coarrays.sourceforge.net/wg5-201606-report.text

In particular, the following paragrah gives me the impression how hard
it is to write such a precise draft.

> The HPC editing work was very demanding, required my full concentration,
especially consideration of various corner cases which could
potentially lead to deadlocks or race conditions. Careful crafting
of rules to prohibit such use of collectives, atomics, locks, events
and critical constructs was the main focus of the HPC sub-group.

Another thing I noticed is that, Fortran is different from Rust, C#, D, Nim, Julia,
[insert whatever you like here] in that Fortran compilers are *not* from a single
source (e.g., Rust from Mozilla, C# from Microsoft, etc), but Fortran standards
are for many compiler vendors (without even a "reference compiler"?!).
So, every corner cases need to be "imagined" before an actual
compiler is created... This is extremely different from other compilers above,
because there is only one compiler (essentially), whose behavior "defines"
its syntax (in a sense).

[spectrum]

Also found are the following page with a lot of photos of
the meeting :-)

http://j3-fortran.org/doc/meeting/210/Mesa_Snaps/

I guess if this kind of photos are put on the Fortran standards page,
users (like me) can get the atomosphere of what's the "meeting" looks like...
(I had imagined something like a "conference", but it seems pretty different.)

Another page I found today is this Coarray tutorial page:
http://coarrays.sourceforge.net/
http://coarrays.sourceforge.net/doc.html

Indeed, F2015 seems to have substantial extensions of Coarray features
like collectives, events, teams of images and facilities for dealing
failed images (according to the above reports). Among these, I'm most
interested in how failed images are treated, because this should become
a serious problem with an even increasing number of cores.

---

And I anticipate that the "true" bottleneck will be:

> The speed with which actual compilers are made is a limiting factor.

(from the post of Dan above), according to the experience before...
This is particularly so because there are a bunch of new parallel features
added to Coarray supports in Fortran2015.

---

But my (small) concern is that this is heavily oriented to parallel computing,
and non-parallel computing features are essentially not much different
from Fortran2003 (so already 14 years have passed). Although, very very
personally, I don't expect that the introduction of generics would change
something very much (as far as HPC is concerned), the Fortran 2023 (or
whatever next next standards) might look non-parallel features again.

# Personally, I feel "convenience solutions" are lacking in the current Fortran,
i.e., "batteries are *not* included". This has been becoming serious shortcoming
recently (particularly for young people, IMO).

[mecej4]

On 5/28/2017 10:22 AM, Gary Scott wrote:

> How about a standarized way to interface with MS Visual Studio...that
> would save compiler vendors thousands of manhours of wasted effort :)

[Jest]
Certainly, but only after they give us a standard interface to (i) Excel
and (ii) Windmills.

The first feature (Excel) is one of the most frequently requested
features, and its absence is declared to be driving many to C, if not to
drink.

The second (Windmills) would make the world a better place for the
Second Coming of Don Quixote.
[/Jest]

Surely, you jest.

-- mecej4

mecej...@nospam.invalid
(Replace four by 4, nospam by operamail, invalid by com,
and remove all underscores)

[Dan Nagle]

Hi,

See IMPORT, ONLY

--
Cheers!

Dan Nagle

[FortranFan]

On Monday, May 29, 2017 at 2:14:05 PM UTC-4, Gary Scott wrote:

> .. I have rental properties, I'm remodeling parts

> of my own hose, I have important applications that I maintain and
> continuously add new features to by request, doing this largely over the

> weekend because I have a regular engineering job during the week. ..

@Gary Scott,

That's some serious workload indeed - I only have one property that I'm unable to manage and that is the one I live in!

Ok, if you do find some free time, please elaborate further or post some generic examples online of what you have done with bitwise representation, or comment on what you have in mind relative to other languages such as bitsets in Java or bitarray package in Python, etc.

As I have mentioned previously, it need not be a zero-sum game in terms of features in Fortran, either with scoped enumerations and your bitstring idea or any other feature for that matter. It's possible for a couple of related features to serve many of the same use cases, but at other times they will serve different needs. So I don't quite see the need to discard any idea entirely in favor of another at the level of discussions here by coders; it's a different matter when proposals make it to standard committee who may then pick and choose or defer one for later, etc.

[FortranFan]

On Monday, May 29, 2017 at 4:17:37 PM UTC-4, jean....@gmail.com wrote:

> ..

> There are features that are already missing:
>
> 1- Generic programming to allow reuse of code.
> 2- Block based exception handling (ex: try/ catch blocks or equivalent).
> > 3- For image and signal processing, unsigned integers. It is frustrating to use the character data type to represent 8 bit pixels properly.

> ..

@Jean,

Hope you are able to exert good influence and find great success with the features you seek in the next revision.

Re: generic programming, will it be possible to post any thoughts or comments you have with generic types at this thread?
https://groups.google.com/d/msg/comp.lang.fortran/R_zBfQKmcHE/5a_KthCMBgAJ

Plus elaborate on what else you have in mind, perhaps in a separate thread?

In terms of Block based exception handling, have you seen this subthread?
https://groups.google.com/d/msg/comp.lang.fortran/OsOpiumYCqY/8hmHCAwMDAAJ

and read the paper by Van Snyder?
http://dl.acm.org/citation.cfm?doid=2980025.2980028

By the way, unsigned integers is something that supposedly has been discussed before by the committee and been disapproved, if I am not mistaken.

Thanks,

[FortranFan]

On Saturday, May 27, 2017 at 7:17:46 PM UTC-4, kergonath wrote:

> ..

>
> That said, agreeing on one format across compilers for the .mod files would

> be a good step to make the developers' lives easier. ..

@kergonath,

You are not the one who started this thread at this forum about a year ago, are you!?
https://groups.google.com/d/msg/comp.lang.fortran/jIVnmL9b2ZY/HOW5TVxWCQAJ

I think you are making a good point with your suggestion; as I mentioned in the thread I just linked, ".. a standardized format for MOD file, perhaps based on XML markup (say text-based, possibly compressed even).. " can prove to be very valuable.

[Gary Scott]

On 5/29/2017 4:38 PM, mecej4 wrote:
> On 5/28/2017 10:22 AM, Gary Scott wrote:
>
>> How about a standarized way to interface with MS Visual Studio...that
>> would save compiler vendors thousands of manhours of wasted effort :)
>
> [Jest]
> Certainly, but only after they give us a standard interface to (i) Excel
> and (ii) Windmills.
>
> The first feature (Excel) is one of the most frequently requested
> features, and its absence is declared to be driving many to C, if not to
> drink.
>
> The second (Windmills) would make the world a better place for the
> Second Coming of Don Quixote.
> [/Jest]
>
> Surely, you jest.

yes, I jest...the amount of effort vendors put into integrating with VS
would be better spent on the compiler itself. I long for that VS
integration to be easy, as it should be. MS doesn't have to make it
that difficult.

[FortranFan]

On Monday, May 29, 2017 at 5:25:25 PM UTC-4, spectrum wrote:

> ..

>
> Indeed, F2015 seems to have substantial extensions of Coarray features

> ..

> But my (small) concern is that this is heavily oriented to parallel computing,
> and non-parallel computing features are essentially not much different

> from Fortran2003 (so already 14 years have passed). ..
> ..

> # Personally, I feel "convenience solutions" are lacking in the current
> Fortran, i.e., "batteries are *not* included". This has been becoming
> serious shortcoming recently (particularly for young people, IMO).

@spectrum,

In terms of 'non-parallel computing' features since Fortran 2003, further interoperability with C via TS 29113 is a significant enhancement in Fortran 2015 plus several other goodies with GENERIC statement and IMPORT facility, etc. Also, I think SUBMODULEs turned out to be a major feature of Fortran 2008 along with many other miscellaneous improvements.

Nonetheless, your points are all very valid in my opinion; as to what you say about "convenience solutions" is something I agree too and have long been trying to convey the same here with threads such as:
https://groups.google.com/d/msg/comp.lang.fortran/iWUgXY0UJ4s/LoPqAJggEAAJ
https://groups.google.com/d/msg/comp.lang.fortran/yZa_b_Zqf94/GZ-CXfjym0oJ

Your parallels with C++ too are applicable to Fortran in my view and it's precisely because of extreme resource constraints with Fortran, unlike perhaps with C++, that I feel productivity platforms such as GitHub might be even more relevant for the Fortran committee.

[FortranFan]

On Monday, May 29, 2017 at 3:13:28 PM UTC-4, Anton Shterenlikht wrote:

> ..
>

> When I asked for something similar to what you mention,
> in JUN-2016, the majority (?) opinion was - no.
> The reason given, as far as I understood, that the
> the benefits you mention above are not applicable
> to standard development work, and the standard is
> not best developed using open source software development
> practice.
>
> When I say that github is probably not going to be used ever,
> this is simply my assessment of the mood of J3.

> ..

Thanks much for your feedback, Anton - greatly appreciate your efforts with the J3 committee and your contributions to WG5.

Fortran benefits from your continued attention and attempts at positive influence.

Thanks again,

[Beliavsky]

On Monday, May 29, 2017 at 5:38:22 PM UTC-4, mecej4 wrote:
> On 5/28/2017 10:22 AM, Gary Scott wrote:
>
> > How about a standarized way to interface with MS Visual Studio...that
> > would save compiler vendors thousands of manhours of wasted effort :)
>
> [Jest]
> Certainly, but only after they give us a standard interface to (i) Excel

There was this proposal http://j3-fortran.org/doc/year/05/05-108r1.txt:


J3/05-108r1

To: J3
From: Dan Nagle
Subject: Write CSV files
Date: 2005 Feb 07


Fortran programs can read CSV files via list-directed I/O,
but there's no easy way to write one since the separator
between values is optionally blank or comma (with slash
as a Really Special Case). Also, there's no guarantee
there will be exactly one separator between each pair of values.
If Fortran programs could easily write CSV files,
the value of using Fortran programs along side spreadsheets etc
would be higher than at present.

[Anton Shterenlikht]

yes, it's tough, no way round it.
Regular J3 folk have amazing skills.

Anton

[Anton Shterenlikht]

spectrum <septc...@gmail.com> writes:

>Also found are the following page with a lot of photos of
>the meeting :-)

>http://j3-fortran.org/doc/meeting/210/Mesa_Snaps/

>I guess if this kind of photos are put on the Fortran standards page,
>users (like me) can get the atomosphere of what's the "meeting" looks like...
>(I had imagined something like a "conference", but it seems pretty different.)

I'm not sure what you expected.
In the days when there were ~40 people on the committee,
it still looked more or less like this. There are some
photos from 1990 on J3 site.
Remember that J3 always strives to reach decisions by
consensus, so a round table discussion seems like the right
way of organising the work.

>Another page I found today is this Coarray tutorial page:
>http://coarrays.sourceforge.net/
>http://coarrays.sourceforge.net/doc.html

Yes, this is my course.

>Indeed, F2015 seems to have substantial extensions of Coarray features
>like collectives, events, teams of images and facilities for dealing
>failed images (according to the above reports). Among these, I'm most
>interested in how failed images are treated, because this should become
>a serious problem with an even increasing number of cores.

We just submitted a proposal to ARCHER, the UK
national HPC system to work on filed images in GCC and OpenCoarrays,
and implement a failure tolerance layer
in cgpack.sf.net CA library.

Anton

[Stefano Zaghi]

Il giorno sabato 27 maggio 2017 20:09:37 UTC+2, Jacob Williams ha scritto:
> My hope is that they can move toward some kind of modern and open collaboration model that engages the Fortran user community. Fortran could learn a thing or two from some of these newfangled languages like Python. It looks like even the C++ committee is using GitHub now.

Dear Jacob,

thank you for sharing your idea.

Reading other comments, in particular the ones of the "insider" Anton, I think that a more "open" collaboration in the standard definition is an utopia.

Maybe I am wrong and new members like Damian Rouson will bring fresh air, but this is probably one of my dream.

My best regards.

[Stefano Zaghi]

Il giorno domenica 28 maggio 2017 01:17:46 UTC+2, kergonath ha scritto:

> Jacob Williams <ja...@degenerateconic.com> wrote:
> > My hope is that they can move toward some kind of modern and open
> > collaboration model that engages the Fortran user community. Fortran
> > could learn a thing or two from some of these newfangled languages like
> > Python. It looks like even the C++ committee is using GitHub now.
> >
>

> It is a bit fragmented, but there are a lot of very useful Fortran codes on
> GitHub. Do you mean a kind of package manager like pip or CPAN? If so, I
> would think that it is up to the community to do something, the members of
> the committee will never agree on something like that.
>

> That said, agreeing on one format across compilers for the .mod files would

> be a good step to make the developers' lives easier. I have found that this
> is a significant obstacle to using libraries from GitHub (or elsewhere).

Dear kergonath,

the Fortran "ecosystem" is surely not competitive with respect the one of Python, but my feeling is that such a "practical" aspect is out of the scope of the standard committee work. The "packaging" aspect will affect low-level things that are more close to the OS, rather than the language definition.

Concerning the mod file format, I am not sure, but as Gary said, it could influence performances, thus I am afraid that a "standardized" mod format could impose to the compiler vendors "unnecessary" limits. I use the word "unnecessary" just thinking to what happen in other languages: the only real portable format are the source files, whereas each compiled object has some sort of non portability issue. A compiled library linked against clib will not work well if the clib is substituted by say Intel clib (if exist that, this is just an ideal, non real example). I am not an expert of compiled object portability (i.e. a system administrator), but my guess is that even with a standardized mod format the compiled objects will be not so much portable as they are now. In this regard my knowledge is very limited, maybe I am wrong.

My best regards.

[Stefano Zaghi]

Il giorno domenica 28 maggio 2017 11:06:23 UTC+2, Thomas Koenig ha scritto:
> kergonath <no_e...@invalid.invalid> schrieb:

>
> > That said, agreeing on one format across compilers for the .mod files would
> > be a good step to make the developers' lives easier. I have found that this
> > is a significant obstacle to using libraries from GitHub (or elsewhere).
>

> Even if the .mod files were compatible, the object files are not. Each
> compiler its own run-time library, and they are all different.

Dear Thomas,

thank you for clarifying it, this was my understanding. Compiled Fortran objects will not ever happen to be as portable as Python: the best way to achieve Fortran full portability is distributing the sources, but this cannot be done every-time/everywhere.

My best regards.

[Stefano Zaghi]

Dear Dan,

thank you very much for sharing your idea, it is very appreciated.

Il giorno domenica 28 maggio 2017 17:12:50 UTC+2, Dan Nagle ha scritto:
> I think one issue is to limit the overall magnitude of the worklist
> so that compiler suppliers can produce fully-compliant compilers
> in a few years. I won't pick "few", but << 10 would be helpful.

I disagree, this should not be the reasons driving the definition of a language. If I'll apply the aim "limit the worklist" at a literal-pedant level will never had a features-rich language like Fortran, probably I'll obtain a very "dehydrated" language much more succinct of C (where all seems to live in external library), a language very close to assembler.

I think that standard committee members like you are superhero, but surely their power is limited. As a consequence, it is reasonable that the committee will able to focus on only few items per time: the worklist must be compiled and I agree that the committee has the "ultimate voice" on compiling and applying that list. What I think is not good is to trim out new proposals without discussing about them, that is what your comment conveyed to me: my understanding is that "because committee has few time, the focus will be on only 10 items per time (time in Fortran world is about 10 years...), no matter if the 11 item is a very interesting idea". Such an approach could drive new Fortraners to go away from Fortran.

> That is, writing the standard is all the committee does.

> The speed with which actual compilers are made is a limiting factor.

Yes, but it is a limit for the end-programmer and the compiler vendors, it should not be a limit for the committee. Committee has done great work giving us a wonderful, modern language. I think that committee should continue to think on how improve the language and leave the compiler vendors to struggle with the implementation. However, the reality is surely more complex and (probably the big issue) the compiler vendors are the most important lobby in the committee.

> How would you know what feature you want next if you haven't yet used
> a compiler supporting all of the latest revision?

I totally disagree. I am using some features of Fortran 2008 without having a fully compliant compiler, but I know for sure that:

+ these features are great, thank you to the great work of the committee;
+ I like to have new features, e.g. abstract containers, more support for generic programming.

As Gary said, if this approach was taken in other field we were still traveling by feet rather than flying to the moon.

The delay on having fully compliant compilers cannot be a reason to limit language improvements.

My best regards.

[Stefano Zaghi]

Il giorno domenica 28 maggio 2017 17:22:37 UTC+2, Gary Scott ha scritto:

> On 5/28/2017 10:12 AM, Dan Nagle wrote:
> > Hi,
> >
> > On 2017-05-28 01:31:12 +0000, Jacob Williams said:

> >> I was referring to collaboration on the standard itself (e.g.
> >> designing new language features).
> >

> > I think one issue is to limit the overall magnitude of the worklist
> > so that compiler suppliers can produce fully-compliant compilers
> > in a few years. I won't pick "few", but << 10 would be helpful.
> >

> > That is, writing the standard is all the committee does.
> > The speed with which actual compilers are made is a limiting factor.
> >

> > How would you know what feature you want next if you haven't yet used
> > a compiler supporting all of the latest revision?
> >

> How about a standarized way to interface with MS Visual Studio...that
> would save compiler vendors thousands of manhours of wasted effort :)

Dear Gary,

I think this is out of the scope of the standard committee.

Elsethread you seemed to think that MS Visual Studio is important due to its large users base: I disagree, I think that today Fortran is "vital" mainly for its HPC users. In the HPC users it is common to program with two things: a compiler and a text editor... MS Visual Studio is not so crucial for Fortran future.

My best regards.

[Stefano Zaghi]

Il giorno domenica 28 maggio 2017 17:27:21 UTC+2, Richard Maine ha scritto:

> Dan Nagle <danl...@mac.com> wrote:
>
> > How would you know what feature you want next if you haven't yet used
> > a compiler supporting all of the latest revision?
>

> That sounds an awful lot like an argument I made some years ago about
> approving f2008 before f2003 compilers were widely available. My
> argument lost. :-(
>
> --
> Richard Maine
> email: last name at domain . net
> dimnain: summer-triangle

Dear Richard,

thank you for sharing this anecdote: I can say I am happy that your argument was lost, there are some features of F2008 that are great. I think that your anecdote is a prove that committee is great and often it takes very wise decisions.

My best regards.

[Stefano Zaghi]

Il giorno lunedì 29 maggio 2017 08:37:06 UTC+2, Anton Shterenlikht ha scritto:

> jean....@gmail.com writes:
>
> >Is there a way for the public
> > to submit a list of features
> > that we would like to be included
> > in the next standard?
>

> Ask in
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90
>
> Anton

Dear Anton,

thank you very much for sharing your idea, it is very appreciated.

As spectrum said, I am also surprised that the committee use a mailing list of the "UK education and research" and named "fortran 90".

My best regards.

[Stefano Zaghi]

Dear spectrum,

Il giorno lunedì 29 maggio 2017 21:02:03 UTC+2, spectrum ha scritto:
> Hmm, I'm sorry if my posting about the C++ sites or my way of writing
> about "committee/user" interactions is not very good... (My intention is
> that, if the visibility becomes greater, then more contributors may come.)

I think that you are not the one who "gives fire" to the discussion. The tone of FortranFan is probably the main reason.

> # This might be the "red zone" that should not be touched or mentioned
> (warned by Stefano before...)

Yes, FortranFan tone could be sounded harsh (I think she/he was too much "crude" with Dan, but not harsh). Someone is allowed to do "sarcastic fun", but FortranFan is not allowed to speak frankly.

> # One thing I completely failed to understand is that, the size of the community
> is probably too different between C++ and Fortran (so naturally affecting the
> ease of gathering contributors etc). This is probably because C++ is systems
> programming language (not limited to HPC), and also games industry uses it
> for developing video games (e.g., World of Warcraft <-- good-old MMORPG :-).

Yes, I know little about the C/C++ community, but it sure that the business interest is order of magnitude different. C/C++ is driven by a lot of industries investing a lot of money, Fortran has not such a rich background.

> And today I have got to know (while looking at the Fortran standards site),
> that Richard was the main editor of Fortran95-2003 :-O
> http://www.nag.co.uk/sc22wg5/officers.html
>
> And another finding is that various names ("John Reid", "Bill Long") are in the
> JISCmail site
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90

Here there are many great committee members that with priceless effort spend their free time for helping newbies like us. This is probably an advantage with respect the C/C++ world.

> But IMHO, it is pretty difficult for any visitor to quickly recognize that this site
> is most suited for posting such things (like requests of features etc), because
> the site name is like "Fortran 90" and the web site itself is written as
> "for UK education and research"...

I am surprised too to read that the "almost official" mailing list is the one for "UK education and research" and named "fortran-90", it is somehow anachronistic.

My best regards.

[Anton Shterenlikht]

Stefano Zaghi <stefan...@gmail.com> writes:

>As spectrum said, I am also surprised that the committee use a mailing list=

> of the "UK education and research" and named "fortran 90".

Please do not mis-quote me.
comp-fortran-90 is open to all.
It is not the offical J3 list.
It has no link to J3 or WG5.
What does it matter where it's hosted?

I just noted that some J3 members do
not read CLV, but do read comp-fortran-90.
That's all.

Anton

[Anton Shterenlikht]

Stefano Zaghi <stefan...@gmail.com> writes:

>I am surprised too to read that the "almost official" mailing list is the o=
>ne for "UK education and research" and named "fortran-90", it is somehow an=
>achronistic.=20

As I said, comp-fortran-90 has no connection to J3 or WG5.

Anton

[Stefano Zaghi]

Dear spectrum,

Il giorno lunedì 29 maggio 2017 23:25:25 UTC+2, spectrum ha scritto:
> But my (small) concern is that this is heavily oriented to parallel computing,
> and non-parallel computing features are essentially not much different
> from Fortran2003 (so already 14 years have passed). Although, very very
> personally, I don't expect that the introduction of generics would change
> something very much (as far as HPC is concerned), the Fortran 2023 (or
> whatever next next standards) might look non-parallel features again.

We are in the era where our smartphones have 8 (or more) cores whereas the speed of cores is almost freeze by the last 10 years... parallel computation will be more important day by day, it was a very wise decision of the standard committee to define the great parallel features of the last Fortran standard. In this regard (indeed, also in many other aspects), I think that Fortran is the best.

That said, I am also convinced that we will not have good support for generic programming in the next 20 years...

>
> # Personally, I feel "convenience solutions" are lacking in the current Fortran,
> i.e., "batteries are *not* included". This has been becoming serious shortcoming
> recently (particularly for young people, IMO).

The success of Python, Matlab, Octave is mainly due to the fact that the "batteries are included". I hope that standard committee will take this into account.

My best regards.

[Stefano Zaghi]

Dear Anton,

I am sorry if you think I missquoted you, this was not my intention. I was driven to the wrong conclusion that it was "almost official" (as I said later) just because it is the one read by "some" members (I confused some with most part..., my bad).

Can we conclude that there is not an "official" mailing list?

My best regards.

[Anton Shterenlikht]

Stefano Zaghi <stefan...@gmail.com> writes:

>Can we conclude that there is not an "official" mailing list?

These are the 2 pages you want.
All relevant details are listed there.

http://j3-fortran.org
http://www.nag.co.uk/sc22wg5

Anton

[Stefano Zaghi]

Dear Anton,

thank you very much.

My best regards.

[mecej4]

On 5/29/2017 2:02 PM, spectrum wrote:
> Hmm, I'm sorry if my posting about the C++ sites or my way of writing
> about "committee/user" interactions is not very good... (My intention is
> that, if the visibility becomes greater, then more contributors may come.)
>

> # This might be the "red zone" that should not be touched or mentioned
> (warned by Stefano before...)
>

<--CUT-->
>

Spectrum, I don't think that you need to apologize at all. If you view
this thread with a news-reader that shows the tree structure of threads,
that should be clear.

As far as I can see, Maine was responding to FortranFan's fiery
denunciation of Dan Nagle's post (and to other FF's posts in similar
tones).

Over the past few months I have seen FF become more and more tribal
(forbidding posters from "polluting" his threads) and intolerant, making
me wonder at times if I was watching the birth of a Fortran Mullah or
Muttawa. Criticism/complaints about Fortran and programming matters in
general are fine in C.L.F.; personal attacks on participants or
WG5/J3/... members are unpleasant to read, especially if the targets are
well-regarded people who write politely. Such lapses in self-control are
unfortunate, because I do believe that FF has considerable experience
and expertise that we can benefit from, if he could only refrain from
venting his spleen in C.L.F. so often.

[kergonath]

Hi FortranFan,

No, that's not me, though the thread is interesting. I am not very hopeful,
though. I guess the second best thing would be a decent Fortran-aware build
system, but that's out of topic for this thread.

[Stefano Zaghi]

Dear kergonath,

Il giorno martedì 30 maggio 2017 13:30:00 UTC+2, kergonath ha scritto:
> I guess the second best thing would be a decent Fortran-aware build
> system, but that's out of topic for this thread.

A Fortran building system exists for free

https://github.com/szaghi/FoBiS

It can (automatically) build even complex (module based) Fortran projects. I cannot say if it is "decent" or not, I am not impartial :-)

My best regards.

[kergonath]

Hi Stefano,

Yes, I remember having tried it at some point. I'll have a closer look
again, thanks!

Cheers

[Gary Scott]

For me, a solid development environment that frees me of the idiotic
makefile process (and hand made CM) is critical to my efficiency. I
have to cram a lot of productivity into my day because programming for
me is a background task (engineering tools designed to improve my
efficiency in my real job). VS is the best there is. However, I
understand there are alternatives and I might be ok if some of the
vendors decide to substitute, if it would improve and stabilize the
"integration" difficulties that plague them. However, it must have its
own linker, library manager, resource compiler, and icon editor built in
or available, and have some sort of project/solution manager scheme.

>
> My best regards.
>

[jean....@gmail.com]

Le lundi 29 mai 2017 18:59:05 UTC-4, FortranFan a écrit :
> On Monday, May 29, 2017 at 4:17:37 PM UTC-4, jean....@gmail.com wrote:
>
> > ..
> > There are features that are already missing:
> >
> > 1- Generic programming to allow reuse of code.
> > 2- Block based exception handling (ex: try/ catch blocks or equivalent).
> > > 3- For image and signal processing, unsigned integers. It is frustrating to use the character data type to represent 8 bit pixels properly.
> > ..
>
> @Jean,
>
> Hope you are able to exert good influence and find great success with the features you seek in the next revision.
>
> Re: generic programming, will it be possible to post any thoughts or comments you have with generic types at this thread?
> https://groups.google.com/d/msg/comp.lang.fortran/R_zBfQKmcHE/5a_KthCMBgAJ
>
> Plus elaborate on what else you have in mind, perhaps in a separate thread?
>
> In terms of Block based exception handling, have you seen this subthread?
> https://groups.google.com/d/msg/comp.lang.fortran/OsOpiumYCqY/8hmHCAwMDAAJ
>
> and read the paper by Van Snyder?
> http://dl.acm.org/citation.cfm?doid=2980025.2980028
>
> By the way, unsigned integers is something that supposedly has been discussed before by the committee and been disapproved, if I am not mistaken.
>
> Thanks,



Le lundi 29 mai 2017 18:59:05 UTC-4, FortranFan a écrit :
> On Monday, May 29, 2017 at 4:17:37 PM UTC-4, jean....@gmail.com wrote:
>
> > ..
> > There are features that are already missing:
> >
> > 1- Generic programming to allow reuse of code.
> > 2- Block based exception handling (ex: try/ catch blocks or equivalent).
> > > 3- For image and signal processing, unsigned integers. It is frustrating to use the character data type to represent 8 bit pixels properly.
> > ..
>
> @Jean,
>
> Hope you are able to exert good influence and find great success with the features you seek in the next revision.
>
> Re: generic programming, will it be possible to post any thoughts or comments you have with generic types at this thread?
> https://groups.google.com/d/msg/comp.lang.fortran/R_zBfQKmcHE/5a_KthCMBgAJ
>
> Plus elaborate on what else you have in mind, perhaps in a separate thread?
>
> In terms of Block based exception handling, have you seen this subthread?
> https://groups.google.com/d/msg/comp.lang.fortran/OsOpiumYCqY/8hmHCAwMDAAJ
>
> and read the paper by Van Snyder?
> http://dl.acm.org/citation.cfm?doid=2980025.2980028
>
> By the way, unsigned integers is something that supposedly has been discussed before by the committee and been disapproved, if I am not mistaken.
>
> Thanks,

Good morning,

Actually, I posted a message on comp-fortran-90 mailing list and I had answers from the committee members as it was the case before. That's truly great!

Since the document for the Fortran 2015 standard is not yet 100% finalized, there will be only a general discussion at the June 2017 meeting about planning the development of the next revision. The process of collecting features for Fortran 202X has not started yet.

For me, the parameterized module facility proposed by Van Snyder will be fine to provide the generic programming facilities that are currently missing. For exception handling, the proposal described in Fortran Forum by Van Snyder would also fit the bill.

Unsigned integers are useful for programs that need to read and write image and telemetry files where data items are stored in that format. 8 and 16-bit pixels come to mind. Right now, hacks are required to process them. Also, this will improve C interoperability.

Regards,

Jean

[FortranFan]

On Tuesday, May 30, 2017 at 6:20:39 AM UTC-4, mecej4 wrote:

> .. Maine was responding to FortranFan's fiery

> denunciation of Dan Nagle's post (and to other FF's posts in similar
> tones).
>
> Over the past few months I have seen FF become more and more tribal
> (forbidding posters from "polluting" his threads) and intolerant, making
> me wonder at times if I was watching the birth of a Fortran Mullah or

> Muttawa. .. if he could only refrain from

> venting his spleen in C.L.F. so often.

> ..


This is an unmoderated group in a relatively "free" cyberspace and it goes without saying anyone who feels similarly affected by anything I have written are free to take as time and space and direct as much as opprobrium toward me as they see fit!

In the course of doing so, hopefully they will read and appreciate where I am coming from too and ponder over my views e.g., in the context of this thread, I personally find it very

"unpleasant to read"

that a suggestion by a top-notch developer such as Jacob Williams, a highly knowledgeable 'modern' Fortran educator and prolific FOSS contributor (http://degenerateconic.com/) - whose work I admire greatly - received what appears an *unrelated* response to his good suggestion about GitHub.

It will help me greatly if someone can please explain:

a) what does the question of "How would you know what feature you want next if you haven't yet used a compiler supporting all of the latest revision?" have anything to do with Jacob Williams' suggestion in the first place and

b) what does that counter-question mean anyway in any context? Consider OP's interested in generic programming for example: how does one having used a full-feature Fortran 2015 compiler even help with OP's needs?

Each and every one of mecej4's aspersions - "denunciation", "forbidding", "intolerant", "Fortran M** or M**", "venting his spleen" - are entirely inaccurate and remind me of the approach taught by saul alinsky (https://en.wikipedia.org/wiki/Saul_Alinsky) to the regressive left whose effects were just yesterday being discussed on TV when I was reading this very thread:
http://www.cnn.com/2017/05/28/us/fareed-zakaria-liberals-cnntv/

In the context of this thread, I was only "speaking my mind" and asking Dan Nagle frankly and directly what he meant with his counter question because I did not understand it. Since he is not a frequent contributor who, in the past, has left considerable time gaps between his postings, it was hinted to him a question such as the one he posted, if left hanging, can come across badly, in the manner I summarized - there was no personal attack there - I was being completely open.

Readers should move away from the "safe space" kind of thinking being advocated by some here:
http://thefederalist.com/2016/11/16/safe-spaces-make-world-more-dangerous/

and be accepting of frank and clear dialogue that advances Fortran. I am only striving to be frank and direct, particularly with those who otherwise wield considerable influence given their vast Fortran experience, frequent postings, and/or membership in some influential body, which then brings them ardent and unsuspecting readership, because I think that will help Fortran. It is nothing personal, I only hold everyone here in the highest regard and view all with utmost respect.

Thanks,

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
** @mecej4, in your post, you used two terms from a particular faith orthodoxy which is most insensitive of you particularly given the transformation of the old continent - while trying to impugn me, please pick words that only have to do with me, not pick on an entire other belief system unrelated to me! :-)

[Beliavsky]

On Tuesday, May 30, 2017 at 12:53:17 PM UTC-4, FortranFan wrote:

> Each and every one of mecej4's aspersions - "denunciation", "forbidding", "intolerant", "Fortran M** or M**", "venting his spleen" - are entirely inaccurate and remind me of the approach taught by saul alinsky (https://en.wikipedia.org/wiki/Saul_Alinsky) to the regressive left whose effects were just yesterday being discussed on TV when I was reading this very thread:
> http://www.cnn.com/2017/05/28/us/fareed-zakaria-liberals-cnntv/
>

People rarely think they are being unjustifiably obnoxious -- if they did they would change their behavior. Therefore when one is criticized by several respected members on an Internet forum, who rarely make comments about other posters, it would be wise to consider their objections very seriously.

[FJ]

Another one written in Fortran for C,C++,Fortran codes

http://parfum-echecs.chez-alice.fr/builder/

This version is rather old but I can build a newer one. Notice that it is
used by actual softwares like ASTEC

http://www.irsn.fr/EN/Research/Scientific-tools/Computer-codes/Pages/The-ASTEC-Software-Package-2949.aspx

[Thomas Koenig]

Stefano Zaghi <stefan...@gmail.com> schrieb:

> Yes, but it is a limit for the end-programmer and the compiler
> vendors, it should not be a limit for the committee. Committee
> has done great work giving us a wonderful, modern language. I
> think that committee should continue to think on how improve
> the language and leave the compiler vendors to struggle with the
> implementation.

Not only vendors, in the sense of actually getting paid for what
they do; other people who contribute to compilers too :-|

[...]

> As Gary said, if this approach was taken in other field we were
> still traveling by feet rather than flying to the moon.

Before flying to the moon, you have to learn the laws of gravity :-)

> The delay on having fully compliant compilers cannot be a reason
> to limit language improvements.

Beg to differ (somewhat).

Adding new features before the previous ones have been tested
by users in the field has its dangers; when errors in previous
specifications have not been corrected, heaping on new ones can
compound this.

[herrman...@gmail.com]

On Tuesday, May 30, 2017 at 1:13:58 PM UTC-7, Thomas Koenig wrote:

(snip)

> Adding new features before the previous ones have been tested
> by users in the field has its dangers; when errors in previous
> specifications have not been corrected, heaping on new ones can
> compound this.

New features might have no overlap with not-yet tested features
from previous versions, and so would not likely cause such problems.

Also, new features could be well tested and understood from other
languages, just being new to Fortran. That doesn't guarantee no
problems, but it makes them less likely.

[Stefano Zaghi]

Dear Thomas, thank you for your insight.

Il giorno martedì 30 maggio 2017 22:13:58 UTC+2, Thomas Koenig ha scritto:
> Not only vendors, in the sense of actually getting paid for what
> they do; other people who contribute to compilers too :-|

Yes, I agree, there are many others contributing to compilers. What I meant is that hopefully committee members that have already an heavy weight on their shoulder will not invested also for compilers implementations delay. I hope that committee members can focus their energy on the language definition rather than on the actual implementation issues that should be a different work (in theory).

> Before flying to the moon, you have to learn the laws of gravity :-)

I agree, but do not tell this to "hornets" or they will stop to fly :-)

Probably we could fly without knowing all details of Einstein's relativity this was my point: I can take (great) advantage of Fortran 2008 features even without having access to a fully compliant code. I can add that both the free compilers I have access have bugs for some F2003/2008 features that are claimed to be supported, but this does not limit me to use many other "modern" features.

> Adding new features before the previous ones have been tested
> by users in the field has its dangers; when errors in previous
> specifications have not been corrected, heaping on new ones can
> compound this.

I agree, adding new features to the language without testing them could increase the entropy too fast, but often new features can be added independently to others not yet implemented. What I meant is that if we use the fact that there is not a fully compliant compiler of 2008 at today as an "excuse" to avoid discussion about new features, Fortran is dead. The access to fully (and really, without serious bugs) compliant F2003 compilers is not possible for many of us FOSS developers, that is 14 year later the standard definition. In the computer field this is an era.

In real world we accept compromises, but waiting 10 or 20 years for discussing (forgetting the time necessary for the implementation) about the addition of some generic programming features (just for making an example) because "there is not yet a fully compliant F2008 compiler necessary to test 2008 features" looks like a very huge compromise. This could be a reason why Fortran is loosing ground with respect other languages.

My best regards.

[Dan Nagle]

Hi,

On 2017-05-30 00:42:44 +0000, Beliavsky said:

> On Monday, May 29, 2017 at 5:38:22 PM UTC-4, mecej4 wrote:

>> On 5/28/2017 10:22 AM, Gary Scott wrote:
>>
>>> How about a standarized way to interface with MS Visual Studio...that
>>> would save compiler vendors thousands of manhours of wasted effort :)
>>

>> [Jest]
>> Certainly, but only after they give us a standard interface to (i) Excel
>
> There was this proposal http://j3-fortran.org/doc/year/05/05-108r1.txt:
>
>
> J3/05-108r1
>
> To: J3
> From: Dan Nagle
> Subject: Write CSV files
> Date: 2005 Feb 07
>
>
> Fortran programs can read CSV files via list-directed I/O,
> but there's no easy way to write one since the separator
> between values is optionally blank or comma (with slash
> as a Really Special Case). Also, there's no guarantee
> there will be exactly one separator between each pair of values.
> If Fortran programs could easily write CSV files,
> the value of using Fortran programs along side spreadsheets etc
> would be higher than at present.

Try using g format together with an unlimited format item.

character( len= *), parameter :: sep = <you-pick-it>

UNTESTED: '( g0, *( :, "set", g0))'

You may wish to set the number of digits after the decimal place
via the ".d" part of the g0 descriptor (not shown for clarity).

--
Cheers!

Dan Nagle

[mecej4]

On 5/30/2017 3:13 PM, Thomas Koenig wrote:

> Adding new features before the previous ones have been tested
> by users in the field has its dangers; when errors in previous
> specifications have not been corrected, heaping on new ones can
> compound this.
>

This seems to be an arguable question.

I do not recall the features in detail, but the

ISO Varying Length Character Strings module
ISO/IEC 1539-2 : 1994(E)

available at

ftp://ftp.liv.ac.uk/pub/fortran_std/is1539-2.html

may serve as a concrete example of the conflicting issues at play.

My foggy recollection is that there were at least two widely available
implementations, but the whole thing was abandoned after a few years.

[FortranFan]

On Tuesday, May 30, 2017 at 4:13:58 PM UTC-4, Thomas Koenig wrote:

> ..

> Beg to differ (somewhat).
>
> Adding new features before the previous ones have been tested
> by users in the field has its dangers; when errors in previous
> specifications have not been corrected, heaping on new ones can
> compound this.

On Tuesday, May 30, 2017 at 12:08:23 PM UTC-4, jean....@gmail.com wrote:

> ..

> For me, the parameterized module facility proposed by Van Snyder will be fine to provide the generic programming facilities that are currently missing. ..


So, I wonder where all this goes!?

OP extends support to "parameterized module facility" which does potentially pose some conflicts with parameterized derived type (PDT) feature from Fortran 2003, especially the kind type parameter.

Now according to those working on compilers, PDT has proved rather difficult to implement, especially with type-bound procedures. Moreover there is no target date for implementation of the PDT feature in several compilers, particularly gfortran.

Hence if one goes with the criteria indicated upthread of being able to use a standard feature first (which then extends to a 'widely available' bug-free implementation), folks like OP have no path forward: they have no date as to when they can employ "a compiler supporting all of the latest revision", of course until then "How would" they "know what feature" they "want next", and until then the standard committee cannot consider any requests from actual users.

What's next then for coders like OP hoping for newer features!? Be like Rip Van Winkle - drink their Hollands and go to sleep!? When they wake up, they can find there is no need for coding anymore thanks to AI and that Fortran is just a song:
https://www.youtube.com/watch?v=yd6FLETYZ_c

[jean....@gmail.com]

Good evening,

The advantage of the parameterized module proposal is that it already exists and provide the benefits of code reuse brought by generic programming If a conflict exists between the proposal and parameterized derived types, then the committee will certainly fix it before incorporating it in the language. This is certainly a simpler approach then designing a complete new generic programming facility from scratch. There is no need in Fortran to have a template facility as complex as the one in C++.

When generic programming , structured exception handling and a few minor goodies will be added (such as unsigned integers and automatic string allocation in READ statements), Fortran will be a "complete" programming language. It is clear that resources of the standards committee and compiler writers are limited and we must limit the proposals to features that provide tangible benefits.

The status of the ISO Varying String standard module should also be clarified because, as it stands right now, it is in some state of limbo. It is not included in any compiler package(please correct me if I am wrong), and one has to search on the internet the source code. Either make it an intrinsic module or simply drop it completely and add the REPLACE and SPLIT procedures to the main Fortran language.

Best regards,

Jean

[Wolfgang Kilian]

On 01.06.2017 17:50, jean....@gmail.com wrote:
>
> Good evening,
>
> The advantage of the parameterized module proposal is that it already exists and provide the benefits of code reuse brought by generic programming If a conflict exists between the proposal and parameterized derived types, then the committee will certainly fix it before incorporating it in the language. This is certainly a simpler approach then designing a complete new generic programming facility from scratch. There is no need in Fortran to have a template facility as complex as the one in C++.
>
> When generic programming , structured exception handling and a few minor goodies will be added (such as unsigned integers and automatic string allocation in READ statements), Fortran will be a "complete" programming language. It is clear that resources of the standards committee and compiler writers are limited and we must limit the proposals to features that provide tangible benefits.
>
> The status of the ISO Varying String standard module should also be clarified because, as it stands right now, it is in some state of limbo. It is not included in any compiler package(please correct me if I am wrong), and one has to search on the internet the source code. Either make it an intrinsic module or simply drop it completely and add the REPLACE and SPLIT procedures to the main Fortran language.

I might step in because I'm doing essentially all string handling via
ISO varying string ...

The ISO Varying String module (or, to be exact, an implementation of it)
has the important advantage that it enables arrays of strings of varying
length. Dropping the module is of course possible. But this means that
the programmer has to introduce his own wrapper type for strings in
arrays. Such a wrapper type, done properly, eventually leads to a
recreation of a varying-string module. So rather support the ISO standard?

The missing piece in the language is arrays of objects of varying
property. Not just character strings but also polymorphic entities.

In fact, Fortran arrays are already a generic-programming facility which
is extremely useful, but has inherent limitations. The limitation is
that the type and properties of the array elements have to be uniform.
ISO varying strings remove one of the limitations, at the price of
giving up on some convenient syntax.

Now, parameterized derived types are a second existing generic
programming facility with strong limitations - the parameters have to be
KIND values. The limitations are so strong that I have difficulties to
imagine a meaningful use case.

Parameterized modules would introduce a third version, with different
limitations. Modules, in Fortran, are rather coarse-grained and bulky
entities which leave traces in the file system, for instance.

My ideal version of generic programming would allow parameterization (of
entities by type parameters) to work seamlessly and uniformly on all
scales, be it procedures, types, or modules. For an example where this
works, look at the OCaml language, or some more recent popular languages
which borrowed from it. But I know that this may be a bit too much to
expect in the context of Fortran.

In any case, Fortran is an ideal context for generic programming - for
the simple reason that it is a compiled language. It is almost
guaranteed that generic-programming constructs do not degrade
performance, because they are always resolved at compile time.
(Dynamic polymorphism, which has been implemented already, can degrade
performance, although this is often negligible.) So I very much hope
that new developments follow that direction, and the result should be
more versatile that the PDT facility that we got.

-- Wolfgang

>
> Best regards,
>
> Jean
>
>
>> OP extends support to "parameterized module facility" which does potentially pose some conflicts with parameterized derived type (PDT) feature from Fortran 2003, especially the kind type parameter.
>>
>> Now according to those working on compilers, PDT has proved rather difficult to implement, especially with type-bound procedures. Moreover there is no target date for implementation of the PDT feature in several compilers, particularly gfortran.
>>
>> Hence if one goes with the criteria indicated upthread of being able to use a standard feature first (which then extends to a 'widely available' bug-free implementation), folks like OP have no path forward: they have no date as to when they can employ "a compiler supporting all of the latest revision", of course until then "How would" they "know what feature" they "want next", and until then the standard committee cannot consider any requests from actual users.
>>
>> What's next then for coders like OP hoping for newer features!? Be like Rip Van Winkle - drink their Hollands and go to sleep!? When they wake up, they can find there is no need for coding anymore thanks to AI and that Fortran is just a song:
>> https://www.youtube.com/watch?v=yd6FLETYZ_c

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[FortranFan]

On Thursday, June 1, 2017 at 1:14:46 PM UTC-4, Wolfgang Kilian wrote:

> ..

> My ideal version of generic programming would allow parameterization (of
> entities by type parameters) to work seamlessly and uniformly on all

> scales, be it procedures, types, or modules ..

That was precisely my idea nearly a couple of years ago with "GENERIC, .. :: TYPE(..) => .." facility as explained in this thread:
https://groups.google.com/d/msg/comp.lang.fortran/R_zBfQKmcHE/5a_KthCMBgAJ

which can apply to procedures, types, and modules.

A lot has happened since Van Snyder's proposal from over 15 years ago on parameterized modules. To remain consistent with how the standard has advanced since then, particularly with Fortran 2015 enhancement of the GENERIC statement, I hope this topic makes it to the next revision but in a comprehensive and consistent manner with the syntax and semantics of modern Fortran.

[Dan Nagle]

Hi,

On 2017-06-01 17:14:44 +0000, Wolfgang Kilian said:

> The ISO Varying String module (or, to be exact, an implementation of
> it) has the important advantage that it enables arrays of strings of
> varying length. Dropping the module is of course possible. But this
> means that the programmer has to introduce his own wrapper type for
> strings in arrays. Such a wrapper type, done properly, eventually
> leads to a recreation of a varying-string module. So rather support
> the ISO standard?

Why not continue to use your implementation of iso_varying_strings?

I think vs may be withdrawn this time around.

--
Cheers!

Dan Nagle

[robin....@gmail.com]

The CMPLX builtin needs to be made generic,
so that it accepts arguments of default precision, double precision, and
whatever extra precisions are available, and to return a result of the
same precision, namely, default, double, or extra precisions, respectively.

Compatabilty with the old non-generic form can be provided by a compiler option.

[Wolfgang Kilian]

[accidentally first sent to PM, sorry Dan]

On 02.06.2017 04:01, Dan Nagle wrote:
> Hi,
>
> On 2017-06-01 17:14:44 +0000, Wolfgang Kilian said:
>
>> The ISO Varying String module (or, to be exact, an implementation of
>> it) has the important advantage that it enables arrays of strings of
>> varying length. Dropping the module is of course possible. But this
>> means that the programmer has to introduce his own wrapper type for
>> strings in arrays. Such a wrapper type, done properly, eventually
>> leads to a recreation of a varying-string module. So rather support
>> the ISO standard?
>
> Why not continue to use your implementation of iso_varying_strings?

Of course. It's not ours but the implementation by Rich Townsend (based
on allocatables) that we are using.

>
> I think vs may be withdrawn this time around.
>

I admit that this is an academic issue since no vendor did actually
adopted this part of the standard, in the sense of providing a genuine
(optimized) implementation.

Nevertheless, my concern is that dropping Ivs would make a useful part
of the Standard obsolescent for which no adequate replacement exists in
the new revision. At least, I'm not aware of any. That's somewhat unusual.

-- Wolfgang

[robin....@gmail.com]

On Friday, June 2, 2017 at 3:14:46 AM UTC+10, Wolfgang Kilian wrote:

> I might step in because I'm doing essentially all string handling via
> ISO varying string ...
>
> The ISO Varying String module (or, to be exact, an implementation of it)
> has the important advantage that it enables arrays of strings of varying
> length.

You could always use PL/I, which has had this facilty since 1966.

[Adam Hirst]

On 30/05/17 10:42, Stefano Zaghi wrote:
>> # Personally, I feel "convenience solutions" are lacking in the current Fortran,
>> i.e., "batteries are *not* included". This has been becoming serious shortcoming
>> recently (particularly for young people, IMO).
> The success of Python, Matlab, Octave is mainly due to the fact that the "batteries are included". I hope that standard committee will take this into account.

I've only been involved with Fortran since 2011, having come from Python
and Matlab, and can definitely agree with this. I found myself arduously
and mostly unsuccessfully reinventing the wheel on several occasions
during my first few years due to the relative lack of "built-in"
functionality for e.g. Linear Algebra, Nonlinear Equations,
Optimisation/Minimisation, sorting routines, function interpolation
etc., and what to me at the time seemed like a lack of documentation,
not of the routines themselves, but rather of what routines exist in the
first place, making it all seem almost like "folklore".

It seems a shame that, despite us having a wealth of existing Fortran
codes in various repositories (Netlib and TOMS to name but a few), all
of these must be explicitly sought after by the programmer, and none are
in any way integrated into the Fortran "user experience". Even setting
up BLAS/LAPACK can be a chore for some users when not developing in a
GNU/Linux environment with a package manager.

I certainly wouldn't suggest simply stipulating that compilers must
provide all of these packages and routines as part of a "standard
library", however it would seem to me that a curated selection of these
being available as part of "intrinsic modules" would be a huge step
forward and would greatly assist users of the language both new and old.

Best regards,
Adam

--
If you're an IRC user, why not drop by ##fortran on Freenode?

[Wolfgang Kilian]

I come from the opposite direction, a field of basics science where
existing solutions are rare and even more rarely applicable without
modification. But there exist packages to interface to, those are
easily available from within the community itself. The standard library
for particle physics users used to be a Fortran 77 library but has been
replaced by C++ stuff in the last decades. With C interop, interfaces
are straightforward to write, however.

For recurring trivial and non-numerical problems, Fortran is missing a
facility analogous to the STL of the C++ world. While C++ continues to
being praised for its power and versatility, I got the impression that
the STL functionality is at least a major factor in the popularity of
this language for scientific coding. This has been discussed at length
in this newsgroup. The main obstacle regarding Fortran is missing
language support for generic containers and algorithms. It appears as
if such issues might be addressed soon by the standards committee.
Agreeing on anything will take time, obviously.

For nontrivial stuff - numerical algorithms are always nontrivial! -
there are quite a few commercial packages, and some (probably dated)
freely available ones. Where known solutions are useful, I'd guess that
spending some money and using a commercial library might be the best choice.

For numerical algorithms, standardization is rather unlikely because the
sheer number of possibilities, requirements, and widely different fields
of application. Instead of forcing compiler vendors to implement a huge
amount of APIs as intrinsic modules, I'd vote for concentrating effort
on the core language and on a truly basic and generic STL-like facility
-- without the pitfalls and quirks of C++, of course.

-- Wolfgang

[robin....@gmail.com]

On Friday, June 2, 2017 at 9:30:26 PM UTC+10, Adam Hirst wrote:
> On 30/05/17 10:42, Stefano Zaghi wrote:
> >> # Personally, I feel "convenience solutions" are lacking in the current Fortran,
> >> i.e., "batteries are *not* included". This has been becoming serious shortcoming
> >> recently (particularly for young people, IMO).
> > The success of Python, Matlab, Octave is mainly due to the fact that the "batteries are included". I hope that standard committee will take this into account.
>
> I've only been involved with Fortran since 2011, having come from Python
> and Matlab, and can definitely agree with this. I found myself arduously
> and mostly unsuccessfully reinventing the wheel on several occasions
> during my first few years due to the relative lack of "built-in"
> functionality for e.g. Linear Algebra, Nonlinear Equations,
> Optimisation/Minimisation, sorting routines, function interpolation
> etc., and what to me at the time seemed like a lack of documentation,
> not of the routines themselves, but rather of what routines exist in the
> first place, making it all seem almost like "folklore".
>
> It seems a shame that, despite us having a wealth of existing Fortran
> codes in various repositories (Netlib and TOMS to name but a few), all
> of these must be explicitly sought after by the programmer, and none are
> in any way integrated into the Fortran "user experience". Even setting
> up BLAS/LAPACK can be a chore for some users when not developing in a
> GNU/Linux environment with a package manager.

There are also Numerical Recipes in Fortran.
and various other collections including Alan Miller's.
Google will help find them.

[Adam Hirst]

On 02/06/17 14:52, robin....@gmail.com wrote:
> There are also Numerical Recipes in Fortran.
> and various other collections including Alan Miller's.
> Google will help find them.

Indeed, and also from John Burkardt. My inclusion of the phrase "to name
but a few" was intended to exclude me from needing to enumerate *all*
the ones I know. :)

I've heard enough bad things about (at least the older revisions of)
Numerical Recipies to be inclined to avoid that, though.

[robin....@gmail.com]

On Friday, June 2, 2017 at 11:06:16 PM UTC+10, Adam Hirst wrote:

> On 02/06/17 14:52, r.no...@gmail.com wrote:
> > There are also Numerical Recipes in Fortran.
> > and various other collections including Alan Miller's.
> > Google will help find them.
>
> Indeed, and also from John Burkardt. My inclusion of the phrase "to name
> but a few" was intended to exclude me from needing to enumerate *all*
> the ones I know. :)

As for the ones that you mentioned, you suggested that it was a chore
to obtain them and that they were unsuited for use.

Those that I mentioned are easy to obtain, either from text book
such as NR and from other online collections that are freely and readily
available, and because they are well-documented, are easily
interfaced into a program.

>
> I've heard enough bad things about (at least the older revisions of)
> Numerical Recipies to be inclined to avoid that, though.

The rumors aare unfounded.

[Adam Hirst]

On 02/06/17 16:55, robin....@gmail.com wrote:
> As for the ones that you mentioned, you suggested that it was a chore
> to obtain them

For some, sure. And it definitely is MORE of a chore than obtaining
packages in Julia/Python/etc., wherever your own comfort level is.

> and that they were unsuited for use.

Not at all.

>> I've heard enough bad things about (at least the older revisions of)
>> Numerical Recipies to be inclined to avoid that, though.
>

> The rumors are unfounded.
>
I recall coming across this page a few years ago, and some anecdotal
evidence from other people I know settled it for me. Others can of
course feel free to use whatever they want, and I definitely have also
seen a page where the authors address some of the issues, usually
referencing newer editions.

http://www.uwyo.edu/buerkle/misc/wnotnr.html

Further discussion of this probably warrants its own thread, but I
expect it's already been discussed to death across the history of usenet.

[spectrum]

> Those that I mentioned are easy to obtain, either from text book
> such as NR and from other online collections that are freely and readily
> available, and because they are well-documented, are easily
> interfaced into a program.

If you have much time and interest, you can spend sufficient time for looking for
(seemingly most reliable) codes on the net (without being not sure whether it is
really reliable), validate the codes by yourself, debug when some problem occurs
(if it is possible for the user), ask the developers for any issues by sending
e-mails (hoping that the e-mail address is still valid, or if the developer is
still interested in that code), while your interest might be something very different
from such a "low-level" part (in terms of the user's interest and goal).

For example, I have seen a question about PCA in a different thread in this forum,

https://groups.google.com/forum/#!topic/comp.lang.fortran/LoYiHsbcP1o

and Stefano kindly searched the net for possible solutions.
For all these pages (for Fortran), the above concern applies.

On the other hand, searching the net with keywords "python pca"
immediately shows the scikit-learn page:

http://scikit-learn.org/stable/modules/generated/sklearn.decomposition.PCA.html

In this page, we can find various examples, usage, references, etc.
Though we may need to consult good textbooks or materials
to understand the background theory etc, there is probably no concern
that the code is obsolete (e.g., cannot be compiled due to some conflicts with
modern syntax or semantic changes). Another good point is that
we can ask questions, e.g.,
https://stackoverflow.com/questions/tagged/scikit-learn
(though it is arguable whether this site is good or bad...)
or send issues/PR via Github for more improvement (if the project is
hosted there).

Because of the community efforts, there is also little concern that
the code or tool becomes obsolete very soon (i.e., kept supported).
http://scikit-learn.org/stable/about.html#people
http://scikit-learn.org/stable/developers/contributing.html

---

Although I used PCA as one example, everything is something like that
recently... so it is very natural that people are attracted by Python or other
languages (even if there is weak points about computational speed).

---

In sum, I think that although it is "easy" (when one is used to Fortran!)
to gather info from various sources and make it work successfully,
the above kind of community efforts are also extremely helpful
to save much time for the user side. Also, we want to avoid re-inventing
the wheel, but rather spend more time to create or find more "new" or
"interesting" things (which may lead to new value, e.g., writing a paper).

---

But maybe this kind of problem should be tackled by the user community,
not by the Standards (or committee)...

[spectrum]

# Hmm, "in sum" may be too old English?? (I just mimicked someone
used this in a lecture...)

As for community efforts, I guess "Boost" might be a better model rather
than directly considering a "std::" thing. If some routines or methods included
in Boost are found to be really useful, they may be considered for inclusion
into the std library.

Is it possible to consider such "semi" or "quasi" standard collection of
utilities (incl. file and string handling) or interfaces to existing
numerical libraries, e.g., LAPACK and netlib for special functions?
For ODE, there seem to be some almost de-fact standard Fortran libraries.

Though it is almost impossible to make such a thing very rich (to the same
degree as Python/Matlab/Julia/R), even if the most common/core things
are available "out-of-the-box" (without hassle for difficult compilation
and interfacing etc), I guess user experience will become probably much better
than now.

# Indeed, I myself also hope such a thing, because I have written tons of lib_foo.F90
and lib_bar.F90, which quite overlaps (!) with those already in Github (I didn't know
that for years...). This is quite a waste of time, IMO.

[spectrum]

> For numerical algorithms, standardization is rather unlikely because the
> sheer number of possibilities, requirements, and widely different fields
> of application. Instead of forcing compiler vendors to implement a huge
> amount of APIs as intrinsic modules, I'd vote for concentrating effort
> on the core language and on a truly basic and generic STL-like facility
> -- without the pitfalls and quirks of C++, of course.

As for templates, I'm still wondering if it is really so extremely hard for compiler
vendors to introduce templates in the minimal fashion
into Fortran? (given that many other languages already have them).
This is because I have seen some people are using "poor man's
templates" (e.g., using C or F preprocessors or Python etc) to emulate
such things. Although emulation is very limited, if the specification is made
similarly restrictive (in the initial stage), the burden for compiler
implementation might be not too large...?

subroutine mysub<S, T>( a, b )
type(S) :: a
type(T) :: b
! do something
end subroutine
...
call mysub<integer, real>( 100, 1.23 )

# but the the mechanism of "instantiation" of mysub<S,T> is
# not trivial to be consistent with the .mod mechanism...?
# (can learn much from other languages for this aspect...?)

# Maybe I am writing a very redundant thing as other threads, so
# will try to read the "Generics, anyone!" thread first (but this is long...)

---

Also a related page found: "parameterized module" (2005):
http://j3-fortran.org/doc/meeting/172/05-181r1.txt

and an article about poor man's template (1997):
http://dl.acm.org/citation.cfm?id=274108&dl=ACM&coll=DL&CFID=769764663&CFTOKEN=99346931

[David Duffy]

spectrum <septc...@gmail.com> wrote:
>
> Although I used PCA as one example, everything is something like that
>

I agree in one sense, but statistical languages like R are just using
the older standard Fortran libraries: 30% of the core codebase is
Fortran. When I wanted to implement PCA, I only had to write 60 lines
of driver code for EISPACK. Generally, if you sniff around interpreted
languages that carry out a task you are interested in, you can find the
appropriate libraries.

By contrast, to call the curses library, it requires more like 3000
lines of interfaces.

[Stefano Zaghi]

Dear spectrum, Adam and all interested,

I think that the "ecosystem" supporting Fortran is somehow off topic with respect this thread. Thus it could be more convenient to open a dedicated thread in order to not dilute too much this one. That said, I am following you off topic, my apologize to all.

In our group on GitHub we have tried a lot to find a way to improve our (meaning for all Fortraners) ecosystem experience. Our first attempt (driven by Chris) was this https://github.com/Fortran-FOSS-Programmers/FLATPack-defunct : its aim was to make the installation of GitHub Fortran project as easy as possible.

After some thoughts we understand that others have already created a very handy tool: Spack, https://spack.readthedocs.io/en/latest/ , that is "a package management tool designed to support multiple versions and configurations of software on a wide variety of platforms and environments. It was designed for large supercomputing centers, where many users and application teams share common installations of software on clusters with exotic architectures, using libraries that do not have a standard ABI."

Spack being simple and effective is a very good Fortran mimic-alternative to Python PyPi. For the happiness of our group Chris have created a sort of PyPi-like register where you can register your Fortran program as mush as like you do on PyPi. Our register is here https://github.com/Fortran-FOSS-Programmers/FLATPack We will happy to accept your programs to be registered in out PyPi-like database. The registration is very easy, essentially you have to provide a sort of "config" file, e.g. https://github.com/Fortran-FOSS-Programmers/FLATPack/blob/master/packages/face/package.py

Notably Spack is language agnostic, thus you can exploit it to install everything into a sane multi-compiler/multi-version ecosystem. Exploiting it within "desk" I had found my nirvana.

Going back on topic, it is very interesting the work the committee are doing on parametrized module feature. Can anyone point out resources about it (papers, proposals, examples, etc...)? Are there compiler vendors already working on it, maybe as an extension to the standard?

My best regards.

[FortranFan]

On Friday, June 2, 2017 at 8:24:39 AM UTC-4, Wolfgang Kilian wrote:

> .. Instead of forcing compiler vendors to implement a huge

> amount of APIs as intrinsic modules, I'd vote for concentrating effort
> on the core language and on a truly basic and generic STL-like facility
> -- without the pitfalls and quirks of C++, of course.

> ..


Re: ".. forcing compiler vendors to implement a huge amount of APIs ..", most readers are discerning enough to know certain things (being able to work with strings) do make sense to be part of the language whereas other more complicated aspects (say ODE/PDE solvers) are in the realm of external libraries. Most do think in terms of effort on part of implementers and the value proposition for the users, the classic cost-benefit analysis and they already show a focus on how any enhancement will serve the real customer here i.e., the one who actually has to "code in anger" using Fortran.

Consider intrinsic modules of ISO_C_BINDING and ISO_FORTRAN_ENV (and now the header ISO_Fortran_binding.h for a companion C processor) and intrinsic derived types such as C_PTR, etc.: the "amount" of entities covered by such intrinsic stuff may appear 'huge' according to some (not to me though) but I will argue the effort for an implementer to support such intrinsic stuff is *not* enormous by any means; if any vendor is complaining of this, then they have absolutely the wrong idea of serving Fortran.

And another point, an *important* one to consider is this: what Fortranners are calling out for, almost poor souls making desperate pleas, is mostly a *subset* of capabilities that the scientific/technical world have found useful, based on well over a couple of decades of experience with other languages (C++, Java, etc.) and it is utterly shameful, despicable almost, when the language cannot include such 'goodies' for the coder. Come on, who in this day and age would not like a built-in 'string' class in Fortran! And what science is there to put one together!? Why is it such a big deal for Fortran 202X when other languages managed to achieve it over 40 to 60 years ago!? Similar to 'string' facilities are a few other things - container classes such as lists, stacks, etc. (and convenient iterators with them) and some algorithms e.g., sorting - that many Fortranners can do with 'standard' ways of working.

As I have indicated many times before on this forum and elsewhere, the importance of 'standardized' APIs cannot be stressed enough in this day and age, at least for many of the well-established, almost mundane, tasks that coders require regularly in their work. Nothing will distract and distress a coder more to find some operation being different in one place vs another for something as trivial and rudimentary as 'string' e.g., chars() operation in StringiFor (https://github.com/szaghi/StringiFor) versus aniso_varying_string (http://www.megms.com.au/aniso_varying_string.htm), no offense to the brilliant authors of these libraries :-)

Fortranners are already considerate and compromising enough to seek a rather limited range of 'intrinsic' capabilities. It is high time the language served them well.

[Richard Weed]

On Saturday, June 3, 2017 at 9:05:03 AM UTC-5, FortranFan wrote:

> And another point, an *important* one to consider is this: what Fortranners are calling out for, almost poor souls making desperate pleas, is mostly a *subset* of capabilities that the scientific/technical world have found useful, based on well over a couple of decades of experience with other languages (C++, Java, etc.) and it is utterly shameful, despicable almost, when the language cannot include such 'goodies' for the coder. Come on, who in this day and age would not like a built-in 'string' class in Fortran! And what science is there to put one together!? Why is it such a big deal for Fortran 202X when other languages managed to achieve it over 40 to 60 years ago!? Similar to 'string' facilities are a few other things - container classes such as lists, stacks, etc. (and convenient iterators with them) and some algorithms e.g., sorting - that many Fortranners can do with 'standard' ways of working.
>
> As I have indicated many times before on this forum and elsewhere, the importance of 'standardized' APIs cannot be stressed enough in this day and age, at least for many of the well-established, almost mundane, tasks that coders require regularly in their work. Nothing will distract and distress a coder more to find some operation being different in one place vs another for something as trivial and rudimentary as 'string' e.g., chars() operation in StringiFor (https://github.com/szaghi/StringiFor) versus aniso_varying_string (http://www.megms.com.au/aniso_varying_string.htm), no offense to the brilliant authors of these libraries :-)
>
> Fortranners are already considerate and compromising enough to seek a rather limited range of 'intrinsic' capabilities. It is high time the language served them well.

Fortran Fan and others.

Many of the issues discussed in this thread are the same ones covered in a
thread I started last year. Unfortunately Life as it has a nasty habit
of doing got it the way and I couldn't pursue it until now. I would like to
add the following points etc. to the discussion.

1. I totally agree with the opinions expressed about the lack of intrinsic support for things like lists, stacks etc. and sorting algorithms. Modern solution methods in areas such as Computational Fluid Dynamics and Computational Structural Mechanics use unstructured grid systems that do not map easily to arrays. Therefore things like lists, trees and hash tables etc are required for a variety of tasks like sorting/renumbering and finding nearest-neighbors. Yes there are plenty of third party packages that can do these tasks but many of them are encumbered by a license or copyright that makes it either impracticle or impossible to use in your code. It also means that you must distribute these packages with your code and require the reciever of the code to build those packages along with your code. As someone who was tasked to maintain some large simulation codes (usually written in C++) that used a large number of 3rd party packages, I can tell you that the biggest issue I had was with packages that required a particular version of a system library that was either older or newer than the one available on the system I was building on. This issue does not occur if more of the functionality needed for things like standard ADTs (lists etc) that anyone who has written anything more complex than "hello world" knows should be an intrinsic capability in the language.

2. A standard response from the compiler developers appears to be "it's too hard". To me this is just a "dog ate my homework" excuse for not reaching out to the the user community and finding what their ultimate customers really want and implementing those capabilities before implementing what they and their fellow developers think is "cool" or fits into THEIR vision of what Fortran should be.
Your doomed to fail from the start if you refuse to take on the difficult as well as the easy. In the words of a popular song from the WW II generation, "the difficult we'll do right now. The impossible will take a little while". I think that this "it's too hard" attitude is why 12 plus years after the F2003 standard was released we still only have a handfull of compilers that are compliant (and those still have bugs that make using some of the more useful new features from the standard unreliable). The situation with F2008 is even worse. There is no excuse for the IBMs, Intels, and Nvidia/Portland Groups of the world who all have net worths that exceed the sovereign wealth funds of many nation states on this planet to take more than a couple of years to generate a fully compilant (and mostly bug free) compiler.

3. Several people call for enhance Generic Programming support although I think what they really want is support for static polymorphisim (ie. an STL like library). My stance on this is that if more things (again like ADT's) were
made an intrinsic part of the language the need for an STL like capability goes away or is greatly diminished. I personally would like to see more emphasis placed on making Fortran MATLABs older but still smarter and faster brother. By this I mean intrinsic interfaces (and note I say interfaces and NOT implementation) to standard linear algebra routines. Give me a standard interface that would work for whatever package I chose to use (LAPACK, MKL, IMSL etc) so I wouldn't have to use preprocessors directives etc. to handle the various different interfaces for the same procedure

4. I'll close with a suggestion regarding an intrinsic list implementation and invite both the compiler developers and fellow users to comment and add their own ideas. My requirements for an intrisic list capability are as follows.

a. It should relieve the programmer from ever defining, manipulating or even being aware of the recursive pointers commonly used in the standard list implementations you see in your algorithms and data structures texts. In my experience, pointers are inherently evil and should be avoided at all cost. In my experience implementing lists in Fortran, its the recursive pointers that always bite you in the rear end.

b. The syntax should be just an extension of something that already exists in Fortran. Along this line, I think a combination of the existing TYPE statement with elements of the current string handling capability would provide the basis for a workable intrinsic list capablity that would be immediately recognizable and usable to users. Here is what I have in mind.

The TYPE statement (or alternatively a dedicated LIST statement) would be used to create either a simple list of intrinsic types (Integer, Real etc).

Examples

TYPE(Real64), LIST :: mylist

or just

LIST(Real64) :: mylist

Similarly, a list of derived types would be

Type mymapenode

Character(LEN=3) :: key
Integer :: keyindex

End Type

LIST(mymapnode) :: mylist

While I would be willing to just have a circular list since I find it the most useful, an alternative ACCESS or LINK parameter could be used to select between single link or circular (double) link

ie Type(Real64), LIST, LINK=Single :: mylist = NULL_LIST


c. prepending and appending to the list would follow the current string concatenation procedure

mylist = 1.0 ! would set initial node
mylist = mylist//3.0 would add 3.0 to the end
mylist = 4.0//mylist would prepend 4.0 at the front

d. Iterating through the list would be the same as interating through a string
(ie using the start:end syntax).

example extracting the first 3 items in a list just be

newlist = mylist(1:3)

c. A set of functions that are analogs to the string functions (INDEX, VERIFY,
SCAN etc) could be used to search lists for specific values. For the case of
a derived type node you would probably need something like a COMPONENT
to specify which component you want to search on. Also functions analogous
to TRIM, ADJUSTL, ADJUSTR etc would be needed to shrink the lists to recover
unused memory etc.

I think that this approach has advantages over an implementation that defines an intrinsic container and dedicated iterators because it builds on existing capabilities and concepts instead of just mimicing implementations in other languages. I would also hope (but realize its probably impracticle) that some
of the existing compiler code dedicated to strings could be refactored to handle strings because what is a string really but a list of characters.

Just my 2 cents.

RW

[Richard Weed]

Ment to say compiler code dedicated to strings could be refactored to handle LISTS (not strings)