forums.silverfrost.com

tk · Joined: 20 Jan 2007 Posts: 7 Location: Dublin, Ireland

I see nothing in a search under "Fortran 2003" -- hence this thread.

Is it the intention of Silverfrost to remain within the ambit of Fortran 95 syntaxt ?
Or is an upgrade to a more Fortran 2003-like syntaxt possible in the near future ?

I ask as there appears to be a growing need to enhance the language with features from other languages as well as enable more inter-operability between languages.

Naturally, since Fortran's main users are either legacy or specialist high performance applications, it may well be that there is limited marketing attraction towards the more recent syntaxt changes.

But I'd be very interested in Silverfrost's position on this general question.

My good wishes for the New Year to all staff and users of Silverfrost.

PaulLaidler · Posted: Wed Jan 25, 2012 6:57 pm Post subject:

FTN95 already contains a few Fortran 2003 features.
ENUM has just been added but there are no immediate plans to add anything more.

dpannhorst · Joined: 29 Aug 2005 Posts: 165 Location: Berlin, Germany

Hi Paul,

does your answer mean that there will be no future development to Fortran 2003 and/or Fortran 2008?

In other parts of the forum the support of 64-bit processors is also discussed and it seems to that there will be also no development in this direction.

I think many of the users of Silverfrost's compiler are very, very interested in these (new) features.

What is the reason, to not go on with the development of Silverfrost Fortran?

Isn't there enough personal for development? Are you the last and only developer?

It would be very pity, to see the Silverfrost compiler leaving the market by this way!

Best regards (and still hoping for the future),

Detlef Pannhorst

Wilfried Linder · Posted: Thu Jan 26, 2012 4:43 pm Post subject:

I fully agree with Detlef. Don't let Silverfrost Fortran die.

Regards - Wilfried

PaulLaidler · Posted: Thu Jan 26, 2012 6:40 pm Post subject:

I can only confirm what I have already written. There are no immediate plans to extend the Fortran but further development is not ruled out. There seems to be a greater interest in developing a 64bit compiler so this would have a greater priority but we would need to find a cost effective way to proceed.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

As a long time Fortran user, mainly in the fields of numericsl methods and operational simulation, I consider the directions of Fortran 2008 to be the wrong directions for my interests. My view is that if you need these features, use C...
I accept that this may not be a commonly held view, but I see the effort that is being placed in the development of the Fortran language as misplaced.
Back in the 80's there was more emphasis on a more portable Fortran and provision of programming structures that were more robust. My view is that some recent trends fail on both these points.
My impression of the development of .net is a good example that the development costs killed Lahey and certainly impacted on Salford. I think a lot of the features in 2008 would have a similar effect and have a very limited user base.
My view of Salford is that it is the best compiler for doing code development, but falls short on run-time performance and extension to 64-bit.
I want Salford to remain viable, so I would have a vote against 2008 features on this basis. I'm sure there are others out there who would disagree with this view, especially C programmers.
I hope there remains a need for numerical calculations using Fortran.

John

(My vote for No 1 improvement task for FTN95 would be to improve performance, by including some new processor instructions that are commonly available since /p6 was implemented, especially vector instructions)

Emanuele · Joined: 21 Oct 2009 Posts: 77 Location: Bologna (Italy)

Dear John,
I am not aware of the fate of Lahey and I'm not able to evaluate the costs vs benefits of the .net development, but I'd like to remark that the good interoperability between ftn95 and .net is the main reason (not the only one, of course) why I chose this compiler. And this is also the reason why I trust in a future 64 bit development.
But I agree with you about the need of performance improvement, also in reading/writing files.

tk · Joined: 20 Jan 2007 Posts: 7 Location: Dublin, Ireland

It's not appropriate for ordinary users like me to make bold suggestions on what ought be in or out -- I don't have to pay the Silverfrost bills.

It would be interesting however to see results of a good survey of active users of FTN95 through the world, what they'd add or subtract to the compiler and what gains or eases they'd expect from such changes.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

As someone who writes "Modern" Fortran, I think there is much to commend some of the newer features in Fortran 2003 and Fortran 2008. For the most part a good job has been done to provide the Fortran programmer with a rich set of features for implementing programs which don't lend themselves to procedural style, e.g. data centric or object oriented styles.

At the same time, the language is backwards compatible with most of Fortran 77 so legacy and "dusty deck" codes can be compiled.

I would like to see the Silverfrost compiler add some more features of Fortran 2003, but it is not just the compiler that would have to change; the debugger (SDBG) would also need to be updated. To expect a full implementation may require a complete re-write of the compiler and debugger which is a big ask.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

David,
I see that you are embracing new programming styles. Unfortunately I am one of the older fortran programmers whose skills do not include "procedural style, e.g. data centric or object oriented styles."

John

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

John,

There is nothing wrong with well-written Fortran 77 style code. Unfortunately I see a lot of such code that is poorly structured and difficult to read (as well as code that is poorly structured, difficult to read, and wrong). I do find that using some of the new ideas in Fortran 90/95 allow code to be structured in a way that makes it easier for the programmer to convey meaning. However, I am very selective in what I use and a lot of my coding still looks like Fortran 77.

Unfortunately (or fortunately, depending on your point of view), the new object-orientated features in 2003 are not supported very well in compilers yet, so I only use these things in code I write to educate myself. The only 2003 features I use regularly are command line arguments, which Silverfrost already supports Wink

. And I don't even think about Fortran 2008 yet (its far too early) and co-arrays (!!!) for parallel programming just confuse me even though I understand MPI and OpenMP.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

David,

I have obtained a copy of the Fortran 2008 draft, dated 2010-11-24. The introduction starts:

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

There's a lot of things in Fortran 2003/2008 that are there to support object-oriented programming, and, if you are not familiar with that way of doing things or the terminology involved, it can all seem a bit alien and unecessary.

The new features are discussed in these documents fron NAG's website.

New features of Fortran 2003

New features of Fortran 2008

Almost all the good things from Fortran 77 are still in the language (a few things are obsolete) and there is no need to use the new things if you dont want to.

Amongst the good things in 2008 are some of the new intrinsic functions, especially the scientific/engineering functions bessel_j0, bessel_j1, erf, erfc, gamma, hypot, norm2 etc.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

simon · Joined: 05 Jul 2006 Posts: 268

I avoided Fortran 90 for years, but when I eventually decided to experiment with some of the new features my programming style slowly began to change, and has now transformed quite considerably. I find that my scientist colleagues, who are traditional traditional Fortran 77 users, now do not really know what to do with my programmes, but my programmer colleagues, who generally have other language backgrounds, find them much easier to work with. However, this convergence of form is not the main advantage - the new features have made it possible to construct programmes that I would have considerable difficulty to programme in Fortran 77. So I am a big advocate for keeping the compiler up-to-date with the new standards. I am not so excited by some of the new intrinsic functions - there are libraries available for some of those - but features such as object-oriented programming support, and C-interoperability, for example, are very helpful.

If ENUM has been added, as Paul indicates, then the F2003 extensions help page in Plato is out-of-date. Are there other features that have been implemented that are not listed there?

I suspect that there are not many new people learning Fortran nowadays, and that of those of us who do know the language, only a few are bothering to learn how to use the new features.

weaverwb · Joined: 04 Aug 2005 Posts: 37 Location: Monterey

As someone who has code that takes a week to run on a very fast Xeon, do concurrent and coarrays look very attractive. I know very little about compilers but both of these seem like they would be difficult to implement. If I'm wrong and they are relatively easy, I would lobby hard for them as multi-core computers are very much the norm these days and my code is essentially incompatible with the structure of GPUs.