comp.lang.ada
 help / color / mirror / Atom feed
* Delays for implementations of Fortran features
@ 2014-01-18 12:40 Colin Paul Gloster
  2014-01-18 13:03 ` Simon Clubley
  0 siblings, 1 reply; 16+ messages in thread
From: Colin Paul Gloster @ 2014-01-18 12:40 UTC (permalink / raw)


[-- Attachment #1: Type: TEXT/PLAIN, Size: 7567 bytes --]

Dear Ada programmers:

Compilers for Fortran codes are lagging behind the Fortran standard.

Regards,
Colin Paul Gloster



On January 13th, 2014, Tom Clune sent to COMP-FORTRAN-90@JISCMail.ac.UK:
|----------------------------------------------------------------------------|
|"On Jan 12, 2014, at 4:44 PM, John Harper <harper@MSOR.VUW.AC.NZ> wrote:    |
|                                                                            |
|      On Fri, 10 Jan 2014, Tom Clune wrote:                                 |
|                                                                            |
|            Date: Fri, 10 Jan 2014 12:48:54 -0500                           |
|            From: Tom Clune <Thomas.L.Clune@NASA.GOV>                       |
|            Reply-To: Fortran 90 List                                       |
|            <COMP-FORTRAN-90@JISCMAIL.AC.UK>                                |
|            To: COMP-FORTRAN-90@JISCMAIL.AC.UK                              |
|            Subject: Re: retraction (was Re: Is this legal                  |
|            (F2003 or F2008)?)                                              |
|                                                                            |
|            On Jan 10, 2014, at 11:36 AM, "Lionel, Steve"                   |
|            <steve.lionel@intel.com> wrote:                                 |
|                                                                            |
|                  Tom Clune wrote:                                          |
|                                                                            |
|                  ➢ The strategy I posted yesterday was                     |
|                  flawed in that it attempted to assign a                   |
|                  pointer to an internal procedure.   Most                  |
|                  compiler accepted it, and I had not                       |
|                  realized that such a restriction                          |
|                  existed.                                                  |
|                                                                            |
|                  That is legal F2008, and some compilers                   |
|                  have supported it for a while.                            |
|                                                                            |
|                                                                            |
|            Steve,                                                          |
|                                                                            |
|            Thanks for the clarification.                                   |
|                                                                            |
|            It has become an interesting juggling act for                   |
|            developers that must choose between portability and             |
|            powerful new features.    There are a number of                 |
|            things in F2008 that I would absolutely use if all 3            |
|            of my baseline compilers supported them.  (I don't              |
|            intend to name names here.)                                     |
|                                                                            |
|            Cheers,                                                         |
|                                                                            |
|            - Tom                                                           |
|                                                                            |
|                                                                            |
|      You're lucky if your only problem is unsupported f2008 features.      |
|      I still avoid f2003 features because some of them are                 |
|      unsupported by some of the                                            |
|      4 compilers I use. So I'm stuck with a Fortran dialect that's 11      |
|      years                                                                 |
|      out of date. One non-f95 feature I use occasionally is SYSTEM         |
|      which is non-standard but all 4 compilers support it, albeit in       |
|      different ways: some treat it as an intrinsic subroutine, others      |
|      as an always-available external one, but that's OK if the             |
|      program says neither INTRINSIC SYSTEM nor EXTERNAL SYSTEM. I use      |
|      it because the compilers don't all support                            |
|      the f2008 feature EXECUTE_COMMAND_LINE.                               |
|                                                                            |
|                                                                            |
|Sure, there are some F2003 features that I must avoid because one or more   |
|compiler does not support them.    One fear that I have is that I've        |
|"learned" to avoid some of these features and will never integrate them into|
|my code when they become available.   OTOH, I eagerly await the day that    |
|gfortran supports deferred-length strings as structure components.          |
|                                                                            |
|And, like yourself, I will use nonstandard, but widely portable extensions  |
|such as SYSTEM when appropriate.   Occasionally I'll even use #ifdef to     |
|kludge a solution for a compiler that lacks a feature (e.g.                 |
|EXECUTE_COMMAND_LINE,  ERROR STOP, etc.)     However, conditional           |
|compilation is rather limited for working around many missing/broken OO     |
|features.                                                                   |
|                                                                            |
|Cheers,                                                                     |
|                                                                            |
|- Tom                                                                       |
|                                                                            |
|                                                                            |
|                                                                            |
|                                                                            |
|      -- John Harper, School of Mathematics Statistics and Operations       |
|      Research                                                              |
|      Victoria University, PO Box 600, Wellington 6140, New Zealand         |
|      e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5276 fax               |
|      (+64)(4)463 5045                                                      |
|                                                                            |
|                                                                            |
|Thomas Clune, Ph. D.  <Thomas.L.Clune@nasa.gov>                             |
|Chief, Software Systems Support Office Code 610.3                           |
|NASA GSFC 301-286-4635                                                      |
|MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov>                               |
|Greenbelt, MD 20771"                                                        |
|----------------------------------------------------------------------------|

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-18 12:40 Delays for implementations of Fortran features Colin Paul Gloster
@ 2014-01-18 13:03 ` Simon Clubley
  2014-01-18 14:37   ` Colin Paul Gloster
  0 siblings, 1 reply; 16+ messages in thread
From: Simon Clubley @ 2014-01-18 13:03 UTC (permalink / raw)


On 2014-01-18, Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote:
>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
>
> --8323328-1982622538-1390048774=:23391
> Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> Content-ID: <alpine.LNX.2.00.1401181340201.23391@anapnea.net>
>
> Dear Ada programmers:
>
> Compilers for Fortran codes are lagging behind the Fortran standard.
>

Please do not post MIME messages to a plain text medium.

I have left the full message in so you can see how it appears to others.

Oh, and I have noticed you tend to post quoted messages in some full
width box and use tab/space indentation instead of just adding a extra
quote character at the start of the line like everyone else does.

That makes it difficult to quote messages in replies, especially when
you want to comment on a message two or three levels up the message
thread while also commenting on the latest message.

Now onto my response to your message, which can be accurately summed up
as "so ?".

If people have a large Fortran code base, they are going to work within
the limits of the compilers they have to work with; they are unlikely to
rewrite everything in Ada.

A Ada programmer OTOH may well choose to write that algorithm in Ada in
the first place instead of switching to Fortran, but they need to be a
Ada programmer in the first place.

Simon.

> Regards,
> Colin Paul Gloster
>
>
>
> On January 13th, 2014, Tom Clune sent to COMP-FORTRAN-90@JISCMail.ac.UK:
>|--------------------------------------------------------------------------=
> --|
>|"On Jan 12, 2014, at 4:44 PM, John Harper <harper@MSOR.VUW.AC.NZ> wrote:  =
>  |
>|                                                                          =
>  |
>|      On Fri, 10 Jan 2014, Tom Clune wrote:                               =
>  |
>|                                                                          =
>  |
>|            Date: Fri, 10 Jan 2014 12:48:54 -0500                         =
>  |
>|            From: Tom Clune <Thomas.L.Clune@NASA.GOV>                     =
>  |
>|            Reply-To: Fortran 90 List                                     =
>  |
>|            <COMP-FORTRAN-90@JISCMAIL.AC.UK>                              =
>  |
>|            To: COMP-FORTRAN-90@JISCMAIL.AC.UK                            =
>  |
>|            Subject: Re: retraction (was Re: Is this legal                =
>  |
>|            (F2003 or F2008)?)                                            =
>  |
>|                                                                          =
>  |
>|            On Jan 10, 2014, at 11:36 AM, "Lionel, Steve"                 =
>  |
>|            <steve.lionel@intel.com> wrote:                               =
>  |
>|                                                                          =
>  |
>|                  Tom Clune wrote:                                        =
>  |
>|                                                                          =
>  |
>|                  =E2=9E=A2 The strategy I posted yesterday was           =
>           |
>|                  flawed in that it attempted to assign a                 =
>  |
>|                  pointer to an internal procedure.   Most                =
>  |
>|                  compiler accepted it, and I had not                     =
>  |
>|                  realized that such a restriction                        =
>  |
>|                  existed.                                                =
>  |
>|                                                                          =
>  |
>|                  That is legal F2008, and some compilers                 =
>  |
>|                  have supported it for a while.                          =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|            Steve,                                                        =
>  |
>|                                                                          =
>  |
>|            Thanks for the clarification.                                 =
>  |
>|                                                                          =
>  |
>|            It has become an interesting juggling act for                 =
>  |
>|            developers that must choose between portability and           =
>  |
>|            powerful new features.    There are a number of               =
>  |
>|            things in F2008 that I would absolutely use if all 3          =
>  |
>|            of my baseline compilers supported them.  (I don't            =
>  |
>|            intend to name names here.)                                   =
>  |
>|                                                                          =
>  |
>|            Cheers,                                                       =
>  |
>|                                                                          =
>  |
>|            - Tom                                                         =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|      You're lucky if your only problem is unsupported f2008 features.    =
>  |
>|      I still avoid f2003 features because some of them are               =
>  |
>|      unsupported by some of the                                          =
>  |
>|      4 compilers I use. So I'm stuck with a Fortran dialect that's 11    =
>  |
>|      years                                                               =
>  |
>|      out of date. One non-f95 feature I use occasionally is SYSTEM       =
>  |
>|      which is non-standard but all 4 compilers support it, albeit in     =
>  |
>|      different ways: some treat it as an intrinsic subroutine, others    =
>  |
>|      as an always-available external one, but that's OK if the           =
>  |
>|      program says neither INTRINSIC SYSTEM nor EXTERNAL SYSTEM. I use    =
>  |
>|      it because the compilers don't all support                          =
>  |
>|      the f2008 feature EXECUTE_COMMAND_LINE.                             =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|Sure, there are some F2003 features that I must avoid because one or more =
>  |
>|compiler does not support them.    One fear that I have is that I've      =
>  |
>|"learned" to avoid some of these features and will never integrate them in=
> to|
>|my code when they become available.   OTOH, I eagerly await the day that  =
>  |
>|gfortran supports deferred-length strings as structure components.        =
>  |
>|                                                                          =
>  |
>|And, like yourself, I will use nonstandard, but widely portable extensions=
>  |
>|such as SYSTEM when appropriate.   Occasionally I'll even use #ifdef to   =
>  |
>|kludge a solution for a compiler that lacks a feature (e.g.               =
>  |
>|EXECUTE_COMMAND_LINE,  ERROR STOP, etc.)     However, conditional         =
>  |
>|compilation is rather limited for working around many missing/broken OO   =
>  |
>|features.                                                                 =
>  |
>|                                                                          =
>  |
>|Cheers,                                                                   =
>  |
>|                                                                          =
>  |
>|- Tom                                                                     =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|      -- John Harper, School of Mathematics Statistics and Operations     =
>  |
>|      Research                                                            =
>  |
>|      Victoria University, PO Box 600, Wellington 6140, New Zealand       =
>  |
>|      e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5276 fax             =
>  |
>|      (+64)(4)463 5045                                                    =
>  |
>|                                                                          =
>  |
>|                                                                          =
>  |
>|Thomas Clune, Ph. D.  <Thomas.L.Clune@nasa.gov>                           =
>  |
>|Chief, Software Systems Support Office Code 610.3                         =
>  |
>|NASA GSFC 301-286-4635                                                    =
>  |
>|MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov>                             =
>  |
>|Greenbelt, MD 20771"                                                      =
>  |
>|--------------------------------------------------------------------------=
> --|
> --8323328-1982622538-1390048774=:23391--


-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
[Note: email address not currently working as the system is physically moving]
Microsoft: Bringing you 1980s technology to a 21st century world


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-18 13:03 ` Simon Clubley
@ 2014-01-18 14:37   ` Colin Paul Gloster
  2014-01-18 15:20     ` Simon Clubley
  0 siblings, 1 reply; 16+ messages in thread
From: Colin Paul Gloster @ 2014-01-18 14:37 UTC (permalink / raw)


On 18th January 2014, Simon Clubley sent:
|-----------------------------------------------------------------------|
|"[. . .]                                                               |
|                                                                       |
|Now onto my response to your message, which can be accurately summed up|
|as "so ?".                                                             |
|                                                                       |
|[. . .]                                                                |
|                                                                       |
|Simon."                                                                |
|-----------------------------------------------------------------------|

Perhaps you do not find it remarkable that during 2014 people compile
Fortran codes (which are not in FORTRAN 77) with compilers which fully
support neither F2003 nor F2008.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-18 14:37   ` Colin Paul Gloster
@ 2014-01-18 15:20     ` Simon Clubley
  2014-01-19  4:07       ` Dan'l Miller
  0 siblings, 1 reply; 16+ messages in thread
From: Simon Clubley @ 2014-01-18 15:20 UTC (permalink / raw)


On 2014-01-18, Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote:
> On 18th January 2014, Simon Clubley sent:
>|-----------------------------------------------------------------------|
>|"[. . .]                                                               |
>|                                                                       |
>|Now onto my response to your message, which can be accurately summed up|
>|as "so ?".                                                             |
>|                                                                       |
>|[. . .]                                                                |
>|                                                                       |
>|Simon."                                                                |
>|-----------------------------------------------------------------------|
>
> Perhaps you do not find it remarkable that during 2014 people compile
> Fortran codes (which are not in FORTRAN 77) with compilers which fully
> support neither F2003 nor F2008.

So to translate that into Ada, are you saying that people should only be
using the very latest Ada revisions and hence only the latest compilers ?

If so, that's so out of touch with reality I don't know where to begin.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
[Note: email address not currently working as the system is physically moving]
Microsoft: Bringing you 1980s technology to a 21st century world


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-18 15:20     ` Simon Clubley
@ 2014-01-19  4:07       ` Dan'l Miller
  2014-01-19 11:54         ` Marius Amado-Alves
  0 siblings, 1 reply; 16+ messages in thread
From: Dan'l Miller @ 2014-01-19  4:07 UTC (permalink / raw)


On Saturday, January 18, 2014 9:20:01 AM UTC-6, Simon Clubley wrote:
> So to translate that into Ada, are you saying that people should only be
> using the very latest Ada revisions and hence only the latest compilers ?
> 
> If so, that's so out of touch with reality I don't know where to begin.

I think that the original poster is saying that Ada and Fortran share a common problem:  some non-open-source compilers are not seeing the investment this decade that that they saw in prior decades, due in turn to lower revenues.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19  4:07       ` Dan'l Miller
@ 2014-01-19 11:54         ` Marius Amado-Alves
  2014-01-19 12:59           ` J-P. Rosen
  2014-01-19 13:03           ` Nasser M. Abbasi
  0 siblings, 2 replies; 16+ messages in thread
From: Marius Amado-Alves @ 2014-01-19 11:54 UTC (permalink / raw)


"I think that the original poster is saying that Ada and Fortran share a common problem: some non-open-source compilers are not seeing the investment this decade that that they saw in prior decades, due in turn to lower revenues." (Miller)

Yes, and the conclusion would be: get used to--and use--open source, and make money some other way.

But, there seems to be an important difference between the two open source communities: GNAT is quickly maintained w.r.t. to the language revision, whereas GFORTRAN is not (as reported above).


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 11:54         ` Marius Amado-Alves
@ 2014-01-19 12:59           ` J-P. Rosen
  2014-01-19 13:03           ` Nasser M. Abbasi
  1 sibling, 0 replies; 16+ messages in thread
From: J-P. Rosen @ 2014-01-19 12:59 UTC (permalink / raw)


Le 19/01/2014 12:54, Marius Amado-Alves a écrit :
> Yes, and the conclusion would be: get used to--and use--open source,
> and make money some other way.

Well, you can also make money with open source - see Gnat and AdaControl!
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 11:54         ` Marius Amado-Alves
  2014-01-19 12:59           ` J-P. Rosen
@ 2014-01-19 13:03           ` Nasser M. Abbasi
  2014-01-19 13:26             ` Bill Findlay
                               ` (2 more replies)
  1 sibling, 3 replies; 16+ messages in thread
From: Nasser M. Abbasi @ 2014-01-19 13:03 UTC (permalink / raw)


On 1/19/2014 5:54 AM, Marius Amado-Alves wrote:

> But, there seems to be an important difference between the two
>open source communities: GNAT is quickly maintained w.r.t. to the
>language revision, whereas GFORTRAN is not (as reported above).
>

May be that is because the new Fortran standard now has in it
everything but the kitchen sink? Modern Fortran has become
more complicated than C++, and one has to feel sorry for the
compiler engineers working on gfortran trying to catch up with
all those new "modern" features being added to Fortran every
few years.

In the good old days, a computer language was simple and could be
learned in few days from cover to cover. Now it takes years
and one still can't learn everything in it.

--Nasser



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 13:03           ` Nasser M. Abbasi
@ 2014-01-19 13:26             ` Bill Findlay
  2014-01-19 13:50             ` Simon Clubley
  2014-01-20 10:15             ` Marius Amado-Alves
  2 siblings, 0 replies; 16+ messages in thread
From: Bill Findlay @ 2014-01-19 13:26 UTC (permalink / raw)


On 19/01/2014 13:03, in article lbgiej$kcv$1@speranza.aioe.org, "Nasser M.
Abbasi" <nma@12000.org> wrote:

> In the good old days, a computer language was simple and could be
> learned in few days from cover to cover. Now it takes years
> and one still can't learn everything in it.

There was nothing good about the old days other than the efforts of the
people who worked to give us what we enjoy today.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 13:03           ` Nasser M. Abbasi
  2014-01-19 13:26             ` Bill Findlay
@ 2014-01-19 13:50             ` Simon Clubley
  2014-01-19 14:06               ` J-P. Rosen
  2014-01-20 10:19               ` Marius Amado-Alves
  2014-01-20 10:15             ` Marius Amado-Alves
  2 siblings, 2 replies; 16+ messages in thread
From: Simon Clubley @ 2014-01-19 13:50 UTC (permalink / raw)


On 2014-01-19, Nasser M. Abbasi <nma@12000.org> wrote:
> On 1/19/2014 5:54 AM, Marius Amado-Alves wrote:
>
>> But, there seems to be an important difference between the two
>>open source communities: GNAT is quickly maintained w.r.t. to the
>>language revision, whereas GFORTRAN is not (as reported above).
>>
>
> May be that is because the new Fortran standard now has in it
> everything but the kitchen sink? Modern Fortran has become
> more complicated than C++, and one has to feel sorry for the
> compiler engineers working on gfortran trying to catch up with
> all those new "modern" features being added to Fortran every
> few years.
>

At some point, a language reaches a good set of functionality for it's
intended purposes and going beyond that can make the language more
difficult to use than it should be. Perhaps the Fortran community now
have the language they need in their day to day work.

Ada didn't get it fully right with Ada 83, but Ada 95 is a good sweet
spot for me. If the Ada language maintainers are not careful, then they
are in danger of making the same mistake with Ada and produce something
more complex than needed.

Sometimes I wonder (and this is a general comment on language committees,
not something directed to specific language committees like Fortran and
Ada) if the temptation is to continue adding features into a language,
even if the language doesn't need it, just so the language committee can
continue in it's job, even if adding those features were to make the
language more complex than it needs to be.

[And yes, I know many of the language committees are staffed by people
who are not directly paid for the work, but being able to say you are a
active member of a language committee is a good thing to be able to place
on your CV for your paid work.]

> In the good old days, a computer language was simple and could be
> learned in few days from cover to cover. Now it takes years
> and one still can't learn everything in it.
>

I _really_ like Wirth's approach with his active effort to reduce a
language to it's required core elements (I'm thinking about the Oberon
variants here).

Simon.

PS: I just wish Oberon didn't have upper case keywords which need to be
upper case because they are case sensitive keywords.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
[Note: email address not currently working as the system is physically moving]
Microsoft: Bringing you 1980s technology to a 21st century world

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 13:50             ` Simon Clubley
@ 2014-01-19 14:06               ` J-P. Rosen
  2014-01-19 14:51                 ` Dennis Lee Bieber
  2014-01-20 10:19               ` Marius Amado-Alves
  1 sibling, 1 reply; 16+ messages in thread
From: J-P. Rosen @ 2014-01-19 14:06 UTC (permalink / raw)


Le 19/01/2014 14:50, Simon Clubley a écrit :
> Sometimes I wonder (and this is a general comment on language committees,
> not something directed to specific language committees like Fortran and
> Ada) if the temptation is to continue adding features into a language,
> even if the language doesn't need it, just so the language committee can
> continue in it's job, even if adding those features were to make the
> language more complex than it needs to be.

Not for the sake of the committee, but a language team that would stop
following the trends and simply say "that's enough, we keep it like
this" would kill the language.

Whether you like it or not, you have to keep moving to prove that you're
not dead.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 14:06               ` J-P. Rosen
@ 2014-01-19 14:51                 ` Dennis Lee Bieber
  0 siblings, 0 replies; 16+ messages in thread
From: Dennis Lee Bieber @ 2014-01-19 14:51 UTC (permalink / raw)


On Sun, 19 Jan 2014 15:06:15 +0100, "J-P. Rosen" <rosen@adalog.fr>
declaimed the following:

>Le 19/01/2014 14:50, Simon Clubley a écrit :
>> Sometimes I wonder (and this is a general comment on language committees,
>> not something directed to specific language committees like Fortran and
>> Ada) if the temptation is to continue adding features into a language,
>> even if the language doesn't need it, just so the language committee can
>> continue in it's job, even if adding those features were to make the
>> language more complex than it needs to be.
>
>Not for the sake of the committee, but a language team that would stop
>following the trends and simply say "that's enough, we keep it like
>this" would kill the language.
>
>Whether you like it or not, you have to keep moving to prove that you're
>not dead.

	The trick is to differentiate the motion from rot and decay effects.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 13:03           ` Nasser M. Abbasi
  2014-01-19 13:26             ` Bill Findlay
  2014-01-19 13:50             ` Simon Clubley
@ 2014-01-20 10:15             ` Marius Amado-Alves
  2 siblings, 0 replies; 16+ messages in thread
From: Marius Amado-Alves @ 2014-01-20 10:15 UTC (permalink / raw)


> > ... GNAT is quickly maintained w.r.t. to the
> > language revision, whereas GFORTRAN is not (as reported above). (Marius)
> 
> May be that is because the new Fortran standard now has in it
> everything but the kitchen sink? ... (Nasser)

Probably a major factor, yes.
One good thing of Ada is that she has grown well so far.
But frankly I hope she stops growing now.
It's time for a new language, with all these lessons learnt.
FORTRAN should have stopped growing long time ago.
C++ should never had start growing at all.
Meanwhile good programmers/engineers/managers just switch to Ada and forget the FORTRAN and C++ monstruosities.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-19 13:50             ` Simon Clubley
  2014-01-19 14:06               ` J-P. Rosen
@ 2014-01-20 10:19               ` Marius Amado-Alves
  2014-01-25 15:44                 ` darek
  2014-01-25 21:46                 ` darek
  1 sibling, 2 replies; 16+ messages in thread
From: Marius Amado-Alves @ 2014-01-20 10:19 UTC (permalink / raw)


> I _really_ like Wirth's approach with his active effort to reduce a
> language to it's required core elements (I'm thinking about the Oberon
> variants here). (Simon)

Yes, fine approach and language. I've tried it some years ago and didn't stick with it because the implementation was too limited and non portable and still a little buggy I think. I'll have to check how it is now.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-20 10:19               ` Marius Amado-Alves
@ 2014-01-25 15:44                 ` darek
  2014-01-25 21:46                 ` darek
  1 sibling, 0 replies; 16+ messages in thread
From: darek @ 2014-01-25 15:44 UTC (permalink / raw)


On Monday, 20 January 2014 11:19:10 UTC+1, Marius Amado-Alves  wrote:
> > I _really_ like Wirth's approach with his active effort to reduce a
> 
> > language to it's required core elements (I'm thinking about the Oberon
> 
> > variants here). (Simon)
> 
> 
> 
> Yes, fine approach and language. I've tried it some years ago and didn't stick with it because the implementation was too limited and non portable and still a little buggy I think. I'll have to check how it is now.


Hi there,
 try this link: http://www.ocp.inf.ethz.ch/wiki/

There is a new version of the Oberon system called A2. The A2 is written in Active Oberon language, ans it runs under Windows/Linux/Solaris x86 (as a normal process). It could be also installed in the native mode (http://www.ocp.inf.ethz.ch/wiki/Documentation/Installation). The Active Oberon language is still evolving, and at ETHZ they use it in education and research. 
Personally, I use a windows-based version of the system (it is different than anything else  but it is a real fun to work with when you get used to it). 

There is also the Zonon programming language (http://www.zonnon.ethz.ch/) which has more advanced features added (http://www.zonnon.ethz.ch/archive/znnLanguageReportv04y090606draft.pdf).

If you some time to burn you can watch some of presentations: http://www.multimedia.ethz.ch/conferences/2011/oberon

Regards,
  Darek

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Delays for implementations of Fortran features
  2014-01-20 10:19               ` Marius Amado-Alves
  2014-01-25 15:44                 ` darek
@ 2014-01-25 21:46                 ` darek
  1 sibling, 0 replies; 16+ messages in thread
From: darek @ 2014-01-25 21:46 UTC (permalink / raw)


On Monday, 20 January 2014 11:19:10 UTC+1, Marius Amado-Alves  wrote:
> > I _really_ like Wirth's approach with his active effort to reduce a
> 
> > language to it's required core elements (I'm thinking about the Oberon
> 
> > variants here). (Simon)
> 
> 
> 
> Yes, fine approach and language. I've tried it some years ago and didn't stick with it because the implementation was too limited and non portable and still a little buggy I think. I'll have to check how it is now.


16:44 (5 hours ago)
On Monday, 20 January 2014 11:19:10 UTC+1, Marius Amado-Alves  wrote:
- show quoted text -
Hi there,
 try this link: http://www.ocp.inf.ethz.ch/wiki/

There is a new version of the Oberon system called A2. The A2 is written in Active Oberon language, and it runs under Windows/Linux/Solaris x86 (as a normal process). It could be also installed in the native mode (http://www.ocp.inf.ethz.ch/wiki/Documentation/Installation). The Active Oberon language is still evolving, and at ETHZ they use it in education and research.
Personally, I use a windows-based version of the system (it is different than anything else  but it is a real fun to work with when you get used to it).

There is also the Zonnon programming language (http://www.zonnon.ethz.ch/) which has more advanced features added (http://www.zonnon.ethz.ch/archive/znnLanguageReportv04y090606draft.pdf).

If you have time to burn you can watch some of presentations: http://www.multimedia.ethz.ch/conferences/2011/oberon

Regards,
  Darek 


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2014-01-25 21:46 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-18 12:40 Delays for implementations of Fortran features Colin Paul Gloster
2014-01-18 13:03 ` Simon Clubley
2014-01-18 14:37   ` Colin Paul Gloster
2014-01-18 15:20     ` Simon Clubley
2014-01-19  4:07       ` Dan'l Miller
2014-01-19 11:54         ` Marius Amado-Alves
2014-01-19 12:59           ` J-P. Rosen
2014-01-19 13:03           ` Nasser M. Abbasi
2014-01-19 13:26             ` Bill Findlay
2014-01-19 13:50             ` Simon Clubley
2014-01-19 14:06               ` J-P. Rosen
2014-01-19 14:51                 ` Dennis Lee Bieber
2014-01-20 10:19               ` Marius Amado-Alves
2014-01-25 15:44                 ` darek
2014-01-25 21:46                 ` darek
2014-01-20 10:15             ` Marius Amado-Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox