To my surprise the first message in this thread (?) has also been
the last until today. I'll try to comment on some of the ideas of
the original poster. I will remove the parts on which I have nothing
to say or just nothing to add.
Dr W.W. Schulz wrote:
>
> 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.
> <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.
Good to know that someone is concerned about the mess in which
the pointers and allocatables in F90 are.
1) One can't tell whether a pointer has been allocated or pointer
assigned to an allocatable. Thus in general it is impossible to
deallocate pointers safely.
2) The behaviour of local allocatable arrays has changed from F90
to F95. I'd say the change was from very obviously bad to less
obviously bad.
In F90 an allocatable without the save attribute that was not
deallocated before exit would be in some undefined state everafter
(I don't remember the exact name of the state, but it's not
important here, I guess). It was so obvious a mistake that
the behaviour was changed in F95.
In F95 such allocatable would be automatically deallocated. It's
an improvement because the irregularity of an allocatable's state
has been removed. It's subtly wrong because:
a) it may hide a possible bug in an incorrect F90 program which
went unnoticed because of some specific compiler implementation,
b) it may temporarily hide a mistake when the allocatable was
intended
by the programmer to be declared with a SAVE attribute,
c) when this "feature" is deliberately used to save typing effort,
this promotes a messy programming style in which a program
depends on implicit mechanisms.
In my view the runtime system should detect when an allocated
allocatable is left allocated at the exit point of the function
and stop the program with an error message.
> (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.
I agree enumerated types are very useful. I'd add that (as it was
discussed in another thread) it would be nice to have constants (not
just parameters). A possibly useful "definition" of a constant could
be: an object that is assigned value exactly once during program
execution, possibly before any other executable statments are executed.
> (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.
In general I disagree. Each such addition would need some extra syntax /
semantics. The ability to shorten a program by a line or two often
leads novice C/C++ programmers to write cryptic constructs using large
numbers of operators. The gain in conciseness is almost immediately
paid for with program's readability.
In some cases such shortcuts might be useful, but in my opinion
the example provided by the original poster do not fall into
this category.
> 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).
I have mixed feelings about the above. It works fine with ANSI C, but
the longish declarations containig many attributes may not be very
readable.
> (o) Extension of CASE:
> The current version of the CASE statement is 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).
I agree that this form of CASE would be appropriate in many cases.
I disagree with arguments that exact comparisons with real numbers
should be avoided because they depend on floating point hardware
(an often cited reason to disallow REALs as loop iterators).
> (o) Modules:
> <snip>
> Secondly, there is the compilation cascade when the implementation
> of a module is changed but not its (public) interface.
> These matters leave room for improvements that have to be addressed
> soon.
Modules as they are designed do not support the separation of
the interface and implementation. They are simply poorly designed.
Or perhaps designed for a different purpose.
> In addition, does the current standard say anything about this:
> Modules A, B, C
> B: use A
> C: use B ! is A also visible in C through B?
Yes, it's visible. Surprising effects may occur if access protection
is used in A and B (which also appears later in the original posting).
> (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.
Right. The problem is, libraries in form of modules may only be
distributed easily in source form (no way to separate interface
from implementation).
> (o) Obsolete Features:
> <snip>
> - DOUBLE PRECISION (use Real(kind=...))
There should be a KIND value defined in the standard that would always
make REAL(k) the same as DOUBLE PRECISION. After all we have plenty of
good old F77 code to interface to. And, yes, it used DOUBLE PRECISION
quite often. In general, there should be predefined KINDS directly
corresponding to the most often used F77 types.
> - NULLIFY (With the NULL in F95 NULLIFY becomes redundant.)
Too late. Any F90 code using pointers uses NULLIFY now. Besides, I
don't see any problem with this redundancy.
> (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.
I'd opt for requiring the compilers to have an appropriate command
line option.
> (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.
Agreed, on both accounts. Since already F95 is not 100% compatible
with F77, it's probably the right time to do it.
> (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.
Yes. I wrote about it earlier in this message. There was a (short)
thread lately in which the differences between PARAMETER's and
constants were discussed.
> (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.
Agreed. I want to have:
a) operators like C's +=, -= etc. (for ease of notation as well
as efficient code),
b) ability to define my own assignment-like binary operators with
the left hand side argument INTENT(INOUT) and right hand side
argument INTENT(IN). They should have flexible naming conventions
allowing to define more than one such operator for any pair of
argument types.
<End of my comments>
I do hope that after all some people will be interested enough to
comment.
Regards,
----------------------------------------------------------------------
Artur Swietanowski mailto:[log in to unmask]
Institut fuer Statistik, Operations Research und Computerverfahren,
Universitaet Wien, Universitaetsstr. 5, A-1010 Wien, Austria
tel. +43 (1) 407 63 55 - 120 fax +43 (1) 406 41 59
----------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
