Prev: allocate() initialization
Next: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
From: Richard Maine on 20 Apr 2010 02:21
Jim Xia <jimxia(a)hotmail.com> wrote:

> ...PDT is a tough feature too. It is a truly
> untried feature in any other languages, and its implementation has
> posed so many challenges to our compiler. I assume it'll be true to
> all implementors. The trouble is, though, that I can't see how
> programmers really benefit from this feature. Maybe someone from this
> forum can shed some light on this.

It isn't hard to see a benefit. There was once a time when I was a
pusher of the PDT feature for some of the benefits. I have come to
believe that the benefits don't justify the cost, however.

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").

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.

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.)

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 | 
Pages: 1
Prev: allocate() initialization
Next: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard