William Clodius actually wrote earlier a long reply to my
wishlist which he asked me to repost to the group as that
didn't happen with his original mail.
Unfortunately, on most issues his comment is "not planned".
Maybe our discussion can help to get a few of these topics
into the next standard. Maybe some of you are willing to sit
down and write a proposal which I cannot do at the moment.
I just wanted to kick the ball into arena since I have not
seen much discussion about the next standard esp in
comp.lang.fortran which is a shame since at least an informal
exchange of ideas and wishes should be happening.
WWS
-----------------------------------------------------------------------
| Werner W Schulz |
| Dept of Chemistry email: [log in to unmask] |
| University of Cambridge Phone: (+44) (0)1223 336 502 |
| Lensfield Road Secretary: 1223 336 338 |
| Cambridge CB2 1EW Fax: 1223 336 536 |
| United Kingdom WWW: |
-----------------------------------------------------------------------
---------- Forwarded message ----------
Date: Sat, 8 Nov 1997 16:06:49 -0600
From: "William B. Clodius" <[log in to unmask]>
To: "Dr W.W. Schulz" <[log in to unmask]>
Subject: Re: wish list of fortran features
>General Remarks:
>
> These are some wishes that I see as useful from my own programming
> experience. Of course, not everybody will agree with this rather
> personal list of wishes. I am ignorant about other proposals
> for F2000. Maybe I am duplicating here. Maybe some things
> are too difficult to implement and there are reasons why it
> might be dangerous.
First: there are two primary organizations involved in the definition of
Fortran 200x, ISO/IES JTC1/SC22/WG5, which is in final charge of the
international standardization effort, and ANSI/NCITS/J3 a US
standardization group to which WG5 delegates detailed work. As J3 both does
the detail work, and effectively acts as the US delegation to WG5, it not
only keeps track of WG5 plans but also records it opinions as to how those
plans should be changed. The current plans for F2000 for these two
organizations are available in different forms at
http://www.etrc.ox.ac.uk/wg5.html
and
http://www.ionet.net/~jwagener/j3/index.html
as someone with a UK email address you may also want to check on the
Fortran Specialist Group.
http://www.etrc.ox.ac.uk/BCS-FSG.html
Second: because of the way standardization works it is too late to
officially propose anything new for F200x that is not at one and the same
time simple to add to the language, an aspect of a currently existing
proposal, and well thought out. (It should also have a fervent backer on
the committee.) As J3 is an ANSI committeee it must make a draft of its
document available for public comments. After the public comments have been
recieved, responses have to be drafted and changes incorporated in the
document before submitting it to the ISO for comments and approval. If a
draft is to be submitted to ISO in 2000 then the ANSI public comment draft
should be available by late 1998, which means that most of 98 is going to
be involved with detailed editorial work and not the discussion of
substantive new ideas.
Third: there remain three potential times for proposing ideas, as a
response to the ANSI discussion period, as a comment to your national
standardization organization (BSI?) during the ISO review, or, as a
proposal for F200x+5 sometime shortly after ISO standardization is
official. I would discourage using the ISO review period as a means of
introducing significant changes.
><snip>
>Features on my wishlist:
>
>(o) Status of pointers/allocatable arrays:
> Pointers should be either associated or disassociated.
> Dangling pointers should be caught by the system.
>
I don't believe this has ever been a problem with allocatable arrays as
their current semantics ensures that they can be implemented on a stack.
Largely fixed in F95 for pointers with NULL(). Note several UK vendors
offer automatic garbage collection.
>(o) Pointers:
> allow pointers to have user-set indices:
> A(0:20) => A_Target(20:40)
> or A( :20) => A_Target(20:40)
> or A(0: ) => A_Target(20:40)
> Pointers (at least the aliasing pointers) are for the
> convenience of the user, this should be enhanced as much
> as possible
I believe this is planned for F200x
>
>(o) Pointers to real/imaginary part of complex numbers
> There is definitely a need to be able to address the
> real and imaginary parts of complex numbers with pointers.
> In practice the F77 way of using code is like this
><snip>
Not currently planned.
>
>(o) The usefulness of RESHAPE and PACK is that it moves the
> burden of indexing from the user to the compiler. This would
> further enhanced by allowing a pointer to point to such a
> structure:
> Real, TARGET :: T(:)
> Real, POINTER :: P(:,:)
> P => RESHAPE( T, (/N,M/) )
>
> In practice this is done very often in F77 by passing an array
> into a subroutine where the array is declared with different
> rank.
> The pointer arrangement would be more transparent and safer.
Not currently planned, lot of difficulty in ensuring a proper detailed
seamantics.
>
>(o) enumerated Type:
> Ada, C/C++, etc have it. It is a very useful and concise way
> to set up a list of options etc.
> It is always better to refer to options/constants by name
> rather than by number as frequently done in old F77 codes
> In F90 one cannot easily collect these options/constants into
> one structure.
> Example:
> TYPE(Enum) :: Weekdays(0:6) = (/Sun,Mon,Tue,Wed,Thu,Fri,Sat/)
> Now one use either Weekdays or directly Sun, etc.
Not currently planned. Sometimes proposed, but never with a significant
number of backers.
>
>
>(o) OO Features:
> The introduction of user-defined types (ADTs)
> has been a great step forward for Fortran but currently any
> addition to a type involves the cumbersome introduction of
> subtypes, just try to translate the 'standard' examples
> of person --> student --> graduate student into Fortran90.
>
> A good OO implementation should be implemented asap.
> There are some good and not so good OO languages out there
> (Eiffel, Beta, Python, etc) and one should learn from them
> what to do and what to avoid.
> There is also some danger that Fortran becomes slowly obsolete
> as fewer and fewer people learn it since it has the notion of
> an old-fashioned language.
> Of course, there will be traditionalists that will 'object' to
> this, but there are so many cases where it is useful, so why
> wait any longer?
Object oriented extensions are planned for F200x. Myself, I would prefer
more functional language ideas as to polymorphism, e.g., Haskell.
>
>(o) Shortening of Fortran
> I think there are many instances where the style of programming
> could be enhanced by allowing more concise statements,
> e.g. ALLOCATE( X(1:N)=Zero ) allocates an array X(1:N) and sets
> all elements to Zero.
> The parameter list of Subroutines and Functions could have
> the declarations of their arguments directly there:
> SUBROUTINE SUB( Integer, INTENT(IN) :: A &
> ,Real, INTENT(IN OUT) :: B &
> )
> instead of repeating it again. It is also less error prone
> (though most compilers will pick it up).
Not currently planned.
>
>
>(o) ASCII characters:
> It is about time to allow for a truly international use of characters.
> The latin-1 (better the unicode ISO 10646) should be mandated asap.
> The old ICHAR,CHAR intrinsics should become obsolete. There is no need
> to support two different character sequences for only historical reasons.
>
> I hear that something along these lines is being proposed already.
There is discussion of increasing the size of the Fortran character set,
but not of mandating a particular character set.
>
>(o) Extension of CASE:
> The current version of the CASE statement is a somewhat inconsistent
> with the rest of the language. It is a much needed improvement of
> the IF-block but has been defined, im my opinion, in the wrong way.
>
> A more useful form is:
> SELECT CASE( A )
> CASE( r1<=A<r2, r3<A<=r4, r5,r6,r7 ) ! r stands for range
> ...
> CASE( r2<=A<r3, r8,r9 )
> ...
> CASE DEFAULT
> END SELECT
> where A can be integer or real or character(ASCII).
>
> The CASE construct is closer to IF-blocks than array indexing
> and this should be reflected.
> In addition, the range expressions should be allowed in IF
> statements as well. (FORTRAN=FORmula TRANslation, remember?)
> I.e. IF( Zero<=X<Two ) THEN
> instead of
> IF( Zero<=X .AND. X<Two ) THEN
>
Not currently planned. In many ways I like the idea.
>(o) EXITs:
> allow exits from any block structure not just DO loops
> this would make goto even rarer.
> But do not ban GOTO's and CONTINUE completely, they are useful
> in -admittedly- rare cases.
Oft discussed, but not planned. The specific use of EXIT for this purpose
would either be incompatible with existing code or would require very
complex rules.
>
>(o) Modules:
> Though the Fortran Standard Committees do not like to get involved
> in matters of operating systems etc. there is a need to solve the
> MODULE problem: different compilers use different ways of providing
> the interfaces of modules during compilation (files .mod, .kmo, .o)
> This can make the porting of code utilities (makefiles) across
> platforms difficult.
Not currently planned. It is difficult to avoid the 90% solution here, and
90% is not good enough.
> Secondly, there is the compilation cascade when the implementation
> of a module is changed but not its (public) interface.
A quality of implementation issue.
> These matters leave room for improvements that have to be addressed
> soon.
><snip>
>
>
>(o) Libraries:
> The step to include a string type (ISO_VARYING_STRING) is a good
> step and should used more often. Common data structures (such as
> linked lists, trees, heaps, etc) could be provided to reduce
> duplication of code, enhance safety, etc. or, at least provide
> us with model implementations that can be copied.
But where do you stop. This really requires a lot of thought and preferably
generic capabilities in the language.
>
>
>(o) Obsolete Features:
> - specific intrinsics and all the restrictions that come with them
> Do we really need ABS,IABS,DABS,CABS, ...
> (use generics)
> - Proposal: change AIMAG to IMAG to be consistent
> - DOUBLE PRECISION (use Real(kind=...))
>
> - PRINT (use WRITE)
> - NULLIFY (With the NULL in F95 NULLIFY becomes redundant.)
Deleting features is rarely a significant simplification and raises the
hackles of large numbers of users.
>
> - Restrictions on internal files (free format,namelist)
> This is really an annoying restriction. Anyone who has tried
> a tiny bit of text processing in Fortran will agree. Often, to be
> conforming with the language, one has to use SCRATCH files
> instead.
>
>(o) Continuation Lines
> Why is it necessary to have an extra ampersand (&) in front of
> formatting statements in READ/WRITE calls?
> E.g. my DEC compilers complains about
> Write(I_OUT, '( " some Variable",I4 &
> /" another one ",I4 &
> )') I,J
> and wants
> Write(I_OUT, '( " some Variable",I4 &
> & /" another one ",I4 &
> & )') I,J
> I don't like to have two rules for continuation lines. Just disallow
> to break strings into two lines without quotes around them.
Deleting features is rarely a significant simplification and raises the
hackles of large numbers of users. Try
Write(I_OUT, '( " some Variable",I4 ' // &
'/" another one ",I4 ' // &
')') I,J
> Secondly why not allow an & either at the end or the beginning of line
> to indicate that is a continuation.
It becomes more difficult to parse, and code maintainers are a form of parsing.
>
>(o) IMPLICIT NONE
> It would have been a good idea to make this the default
> setting for F90 code in recommended format (i.e. free format)
> True it makes F77 and F90/95 a little bit imcompatible
> but safety should take priority.
One persons idea of a lifejacket is another person's idea of a lead weight.
>
>(o) SAVE
> For the sake of transparency, variables should be saved between
> function calls only if they are declared with the attribute SAVE
> not just when initialized.
> This is, however, in conflict with the earlier standards.
Too error prone in practice.
>
>(o) PARAMETER Variant:
> I have wished many times to have a variable that can only be
> declared once at the beginning of a programme and remains constant
> throughout.
> (setting options is a typical example)
No official proposal
>
>(o) Overloaded Operators
> allow commutative operators to reduce duplication of coding
> Also, allow to declare some operators invalid for ADTs. There
> are times when I don't want an assignment of the intrinsic kind.
No official proposal.
>
>(o) Access to OS
> there should be some simple and STANDARD form of accessing the
> operating system and results from those operations
> CALL OP_SYS( ... )
Maybe, but a lot of postential incompatibility problem.
>
>(o) bindings to other languages
> I hear they are woorking on C <--> Fortran
Yes
>
>(o) private/public Types
> <snip>
William B. Clodius Phone: (505) 665-9370
Los Alamos Natl. Lab., NIS-2 FAX: (505) 667-3815
PO Box 1663, MS-C323 Group Off.: 505/667-3422 or 667-5127
Los Alamos, NM 87545 email: [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
