ISO/IEC JTC1/SC22/WG5 N1595

                         The future of Part 2              

                                 John Reid

Lawrie Schonfelder, editor of Part 2, is unfortunately unable to attend 
the May meeting. I have therefore been corresponding with him to seek his
opinion on how we should proceed re Part 2. This is what he says:

JKR asked:
Part 2 is due for renewal next year. Is it your wish that I ask SC22
to renew it? Or should we revise it to conform with F2003? 

JLS replied:
I think we should renew it. If we are to withdraw it as redundant as 
Van claims, it is incumbent on us to at least renew it this time 
round with a large notice that we intend to withdraw it next review. 
This gives the one cycle notice that we have for a long time said 
we would give before withdrawing a feature; in effect we would be 
declaring part 2 "obsolescent" at this review and "obsolete" next time.

I am also unconvinced as to the redundancy. The allocatable length 
character feature of F2003 provides a type with essentially similar 
representational capabilities as the existing derived type but it is 
spelled differently. Every program that uses the part 2 standard will 
have to be modified to change the declarations. 

Although I think most of the overloads for intrinsics will function 
in the same, correct, way for arguments that have been declared as 
allocatable length character as for type(varying_string), I can't be 
sure without careful checking.

At least one intrinsic overload will not be the same. The 
CHAR(varying_string,[length]) does not have an equivalent 
CHAR(alloc_char) variant intrinsically defined. Then there are 
all the procedures defined by part 2 that have no intrinsic 
equivalents, e.g. REPLACE, EXTRACT, SPLIT, etc. and the i/o routines 
in part 2.

F2003 actually gives two possible alternative representational forms 
for the type. Both should be better than the pointer component form 
currently used. These are

TYPE VARYING_STRING
PRIVATE
CHARACTER,DIMENSION(:),ALLOCATABLE :: chars
ENDTYPE VARYING_STRING
or
TYPE VARYING_STRING
PRIVATE
CHARACTER(:),ALLOCATABLE :: chars
ENDTYPE VARYING_STRING

Either could be used for an improved implementation of the module 
(as you know the first already exists and I will try a version of 
the second as soon as I get my hands on a F2003 compiler). It is 
not yet clear which would provide the most effective implementation. 
I would hope the latter but without testing we can't be sure.
In neither case is there any needed change to the standard only 
to the illustrative module.

My preference is for the standard to be formally renewed and that 
the alternative module versions be placed on the web site once they 
have been produced and tested.

And in a later message JLS said:

I have been thinking a bit more about part 2.

I believe we should renew part 2 for the reasons I gave before but 
I am thinking that a genuine update, and not just a revised module,  
could usefully be made in the light of F2003. This is to add DTIO 
routines to provide an alternative to the get, put etc. i/o procedures.

I have begun looking at producing a version of the module 
based on an allocatable length character representation. By and large it 
looks reasonably straight forward but to obtain precisely the semantics 
of the pointer or allocatable array of character is significantly 
complicated due to the fact that LEN is not defined for an unallocated 
argument, nor are ==,>,<, etc. This results in a lot of extra tests in 
procedures that otherwise would be simple use of the intrinsic operation 
on the components. This is another subtle difference between the 
VARYING_STRING of part 2 and CHARACTER(:),ALLOCATABLE.