Re: J3's workings

Richard Maine wrote:
Beliavsky <beliavsky@xxxxxxx> wrote:

Maybe after Fortran 2003, the language should evolve
by having compiler writers, both commercial and volunteer, (gfortran
and g95) add extensions that they think are important based on user
requests. If those features are adopted by several compilers, they
could later be standardized.

I think that approach is completely unacceptable.

But how can we test out new features before standardizing them?

1. As a user, I avoid using vendor extensions even when they are
features that I highly desire. While I make exceptions, they are darned
rare. And features supported by only a single vendor are even more rare
(as in I can't think of a single one that I use). This wasn't always the
case, but it is now. I'm not the only user like this. Thus you get a
biased picture by looking only at things that users have pushed
compilers developers into doing as extensions. You don't get the kind of
features that people like me want; I tend to view that as a negative.
:-)

There are programs where portability is likely to be important
and those where it isn't. I remember using Fortran 77 features in
WATFIV in 1974, before I even knew there was a standard, but that
was in small programs that were not likely to ever be used again.

2. When compiler vendors independently develop a feature independent of
standardization, it is almost inevitable that the different versions of
the feature won't be identical. This causes difficulty in the
standardization.

How about implementing proposed features before they are standardized?
Again, mostly for programs with an short expected life so it won't
be a big problem if the standard is different.

A common approach recently has been to deliberately do
the feature in a way that is different from any of the existing
implementations in a way that allows support of both the vendor-specific
and the newly standardized versions to coexist. That approach works fine
for things like intrinsic procedures, where using a different name is
enoug hto avoid conflict. That approach wouldn't work so well for more
basic things in the language.

Well, hopefully by now the really basic things will have been added.
That wasn't as true in the Fortran 66 and 77 days.

Also, there are likely some things were the only thing against them
is a rule that prohibits them. For one, my recently suggested nested
internal procedures. Yes, there are complications to doing it, and
they need to be considered, but I hope there wouldn't be a conflict.

-- glen

.

Relevant Pages

  • Re: Fortran Features
    ... without a specific list of extensions. ... In order to make the features optional like this, ... will need to be included in the standard. ... means that you get into a substantial debate on each ...
    (comp.lang.fortran)
  • Re: idea: on the issue of C and language extensions
    ... features; this route would be based mostly on something like a mailing ... implementations, yet far lighter weight and informal than forcing ... extensions they have done already... ... When parts of the Standard released by such a major organisation like ...
    (comp.std.c)
  • Re: GCC
    ... Code written for advanced compilers will be incompatible ... > it looks like it's finally getting better now that the standard is ... features and requiring us to change existing code to adapt ... many portability issues to deal with. ...
    (Debian-User)
  • Re: Program Fails When Parameter Fixed Constants are Changed (F77) ??
    ... feature first into the standard and then into compilers. ... It was omitted from f95 because, in spite of people working quite a bit ... and well before there were many f77 compilers. ... was not comfortable using those features in my fortran codes because ...
    (comp.lang.fortran)
  • Re: Diff Between ANSI C and Embedded C
    ... >>>See the technical report TR18037 for the exact differences.# ... >implementations of extensions for addressing I/O bits and registers, ... Also different compilers for the same parts have different extensions. ... Embedded C defines extensions to Standard C. ...
    (comp.std.c)