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