Re: [Plplot-devel] Command-line parsing improvements for both C and Fortran

[Alan W. I. <ir...@be...>]

On 2018-01-03 13:28-0000 Arjen Markus wrote:

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>>
>> This commit completes my parsing API changes in bindings/fortran/*.f90 and my
>> changes to examples/fortran/x01f.f90 to test all of these parsing API's.  I would
>> appreciate your review of my implementation.
>> Furthermore, I would appreciate you following the parsing testing advice in
>> README.release section 2.7.2 to discover which parts of this API work for gfortran
>> with version > 4.9.2 (e.g., for your Cygwin and MinGW-w64/MSYS2 platforms) as
>> well as the ifort compiler you have access to (and possibly the nagfor compiler you
>> have arranged access to in the past).
>>
>> By the way, I am not sure of the correct terminology for character arrays that have
>> both length and size allocated.  I refer to them above as "dynamic length and size",
>> but I have also seen the term "deferred-length" used for character strings with
>> allocated length.
>>
> Unless I am mistaken the official term is deferred-length.
>
> I have not yet tested this with my compilers, but I have reviewed the implementation. I have very few comments about it:
>
> -        It is a pity that we cannot disambiguate on the deferred/assumed length alone, but that is an issue of the language rules (the type of "assumed-length character string" simply encompasses the type of "deferred-length character string". Elaborate workaround might be possible, using classes/derived types, but that is not worth the trouble I think).
>
> -        If we decide at some point that we need to keep the various implementations, then perhaps we could "layer" the versions:
>
> o   The deferred-length variant can call the assumed-length + allocated size variant
>
> o   This can in turn call the fixed size variant
>
> It would reduce the amount of code, by a small amount of source lines. But again, that may not be worth our while.
>
> I should have time to test the implementation tomorrow. Maybe that will bring out more comments ;).

Thanks for your review of the code and your comments above based on
that review.  With regard to the "layering" idea, I would like to keep
the 3 variants completely independent of each other because the
deferred-length + allocated size variant is preferred and the
assumed-length + allocated size and the assumed-length + assumed size
variants are deprecated. Furthermore, I agree the required
disambiguate parameter on the assumed-length + allocated size variant
is a "wart" for that variant, but I don't think we need to be too
concerned about that wart since it is a deprecated variant.

I did look at
<https://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>
and support for "allocatable character length" (what we now
call deferred-length character) is pretty widespread (e.g.,
gfortran-5.2, ifort 17.0, and nagfor 6.1 and above) so I am pretty
sure your tests tomorrow of the modern gfortran and ifort cases
(and presumably your eventual test of nagfor) as well as
my eventual (once I install Debian Stretch with gfortran-6.3.0) 
test of modern gfortran will all go well.

That said, one notable (because they feature PLplot capability)
holdout is Absoft where the box in the above PDF is blank indicating
support for this important Fortran 2003 feature is unknown.  Absoft do
claim they support "essentially all" of Fortran 2003 so that is a good
sign, but a site:www.absoft.com google search showed no mention of
"character(len=:)" or "deferred length" or "allocatable length" so
that is a bad sign.  Anyhow, I plan to reestablish contact with Absoft
(assuming you can demonstrate good test results of the deferred-length
+ allocated size variant for modern gfortran and ifort) and ask them
to do the same test you are doing and temporarily keep or throw away
the deprecated versions of the above API before the release depending
on those results.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________