Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: FDIS
From: Jim Xia on 20 Apr 2010 10:13

> To me, the fundamental benefit was to make parameterized intrinsic types
> integrate better. The one of most interest to me was REAL. The
> parmeterization of REAL is handy... until you try to have a REAL
> component in a derived type. An awful lot of my data in f90 and later
> ends up in derived types.
>
> As soon as you have a real component in a derived type, you can no
> longer support multiple kinds of REAL for that variable in the same
> program without excessive "gymnastics" or something like PDTs. If you
> want a single and double (and maybe quad) versions of that variable, you
> need to have separate type names for each corresponding derived type,
> which cascades into pretty much needing to have separate copies of
> procedures that use the type, which in turn cascades up to anything that
> uses those procedures, etc.
>
> Imagine, for example, doing something like complex if the language
> didn't support it intrinsically. In many ways, complex is like a derived
> type with 2 real components. (There have even been serious proposals to
> redefine complex to be a standard derived type, but that has multiple
> subtle "issues").


I think it would be much better to have template functions in Fortran
than PDT. Many of these issues can be handily resolved by template
functions -- functions that accept parameterized arguments, including
derived types. Template functions are more general solutions than
PDTs which seriously limit your choices by confining your play in a
derived type definition. To me, writing functions that operate on
these PDTs will likely be the most frustrating exercise for
programmers to apply PDTs. In short I believe PDTs are a poorly
designed language feature.


>
> Probably the contexts where this is most of concern are in writing
> libraries to be used by other programs. A library writer often needs to
> provide for multiple precisions to support multiple applications.


PDTs are unlikely to be interoperable with any other languages. No
other known languages seem to support similar language feature.
Unless you're solely developing libraries for Fortran users, you
wouldn't think of PDTs as a viable choice. I've seen proposals to
support vector data-type declarations using PDTs and interoperable
with C. Once you give it a hard look, you realize it is a hopeless
approach.


>
> But let me repeat that, although I do see benefits from PDTs, that does
> not mean that I think those benefits are big enough to be worth the
> evidently large cost. If I could roll time back 15+ years to when PDTs
> were being added as a proposed language feature, I'd change my vote. (I
> voted yes back then, but I now think I was wrong to do so.)
>


Cost is only one issue. If there are sufficient reasons to add the
feature because it solves large amount of problems, then I'll vote for
it. However, I don't believe this is the case for PDT. Anyhow, it
seems too late to regret on something has happened many years ago.


Cheers,

Jim
From: Craig Powers on 21 Apr 2010 14:18
Jim Xia wrote:
> On Apr 20, 4:47 pm, Craig Powers <craig.pow...(a)invalid.invalid> wrote:
>>> PDTs are unlikely to be interoperable with any other languages. No
>>> other known languages seem to support similar language feature.
>>> Unless you're solely developing libraries for Fortran users, you
>>> wouldn't think of PDTs as a viable choice. I've seen proposals to
>>> support vector data-type declarations using PDTs and interoperable
>>> with C. Once you give it a hard look, you realize it is a hopeless
>>> approach.
>> In the abstract (based purely on a rough understanding of the feature
>> and no knowledge of its details), I suspect it might be feasible to hook
>> into C++ templates in some way or another. Any generic programming
>> feature will have issues with interop, as there are relatively few other
>> languages that support that. C++ is the only one that I know of offhand.
>
>
> No, PDT is quite different from C++ templates. The missing key in
> PDTs are the language capabilities to generate different routines for
> the same type but with different kind type parameters. It's like you
> have to rewrite the same algrithms repeatedly for single precision,
> double precision and quad precisions. A template function is what
> Fortran is missing -- a facility that asks compiler to generate the
> different code for different precisions based on the same algorithm.
> PDTs don't address this issue and use of PDTs will actually add burden
> to the developers to manually resolve this issue.

Oh, I certainly agree that a generic programming facility would be a
very welcome addition to Fortran; the absence is the one thing that
would drive me to work in C++ over Fortran, as a matter of fact.

However, even though PDT is wholly inadequate as a generic programming
facility, I do see it as falling into that general classification, and
thus it has some relation to C++ templates. Even in the absence of
one-to-one feature correspondence, it's possible there might be room for
some sort of interop hook.
 | 
Pages: 1
Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: FDIS