Print

Print


Hello,

The % is there to stay folks. Time cannot be reversed as far as I
know...If someone wants to contribute to Fortran, think about what can
be done to improve the language, not your cosmetic personal preferences.
Van and Lawrie both had good points, but I am not convinced that adding
a second syntax now to correct some of the problematic original
decisions is a good thing due to duplicity...

Alvaro Fernandez wrote:
> It's not insurmountable, but if the code was written e.g. assuming that
> random access to entries was essentially free, such an assumption would have
> to be revisited - and you end up coding differently anyway. So what did the
> accessor gain you, then? Of course, if properly written, you wouldn't be
> hopping around too much anyway... I don't know. It seems that it's not that
> easy to isolate the repercussions of such changes in underlying assumptions.
Well, nothing is easy if you want both abstractions and efficiency.
But there are many cases where indeed you can preserve both speed and
abstraction.

For example, assume that you have a data structure where you have
objects numbered from 1 to N, but you don't really know what N is, i.e.,
N may grow (think of sparse matrix factorization, for example). One
approach will make a big array of these things and use direct indexing
into it. This will be better when you have a good upper bound on N (if N
crosses your bound, reallocate and copy the array). But if you don't
have a good bound on N or want to conserve memory, you can allocate
things in blocks, and change your array component into an
accessor/updater function. This will still be efficient, modulo the
extra procedure call, which can be avoided by inlining, since converting
an index into the memory address is easy: Divide with the block size to
find which block to look in, and then where in the block to look.

There are ways to do something like this in future Fortran without
accessor/updater functions. What needs to be allowed is to use a
pointer-result function reference as if it is a variable:

type :: t
    real :: x
end type

function p(i)
    integer :: i
    type(t), pointer :: p
    ...
end function

p(3)%x=3.0 ! Updater
write(*,*) p(3)%x ! Accessor

The exact same would work if I make p an array:

type(t), dimension(100) :: p
p(3)%x=3.0 ! Updater
write(*,*) p(3)%x ! Accessor

By using type-bound procedures (Fortran 2003 OOP) and this kind of
feature one can almost emulate updater/accessor methods. I can give the
example, but since most readers likely do not know F2003 yet, it is
unlikely to be useful.

Best,
Aleks