I'm curious: Did you try TRANSFER(), or was it too slow?

It does seem that both these cases can be summarized as the need for having
untyped ("typeless") variables of some kind in this very heavily typed
language.

The typeless idea sounds great... it's sort of like treating the data as a
box in a shipping facility. We don't care what it is, just that we can move
it around, so only allow motion and comparison operations. (Following the
example, if shipping boxes were like typed variables you could only have
doctors move medical equipment, bricklayers move bricks, etc. so you could
never have a general shipping facility.)


Alvaro


-----Original Message-----
From: Fortran 90 List [mailto:[log in to unmask]] On Behalf Of
Russell, Richard
Sent: Tuesday, March 09, 2004 3:56 PM
To: [log in to unmask]
Subject: Data type "UNDEFINED"

If I read the other thread correctly, the present standard calls for default
real and integer types to occupy the same amount of storage space. It was
noted in one thread that some programs do make use of this and depend on it,
for various reasons. I do this myself, and doing it is a bit troublesome,
because it falls in the category of "tricky code." In my application, I have
a data management routine that moves strings of data around on behalf of the
routines calling it. The types of those data strings include integers,
reals, and characters. The data manager doesn't care about the type of a
string, only that it occupies a certain number of units of storage, or
"words." A caller provides a vector containing a string of words (stored or
retrieved), plus a word count. Implementation makes use of EQUIVALENCE in
the calling routines to force integer or character strings to occupy the
same space as a real vector passed to the data manager. Equivalence applied
to character and non-character is not strictly allowed by the standard, but
the various Lahey compilers I have used allow it. The implementation works,
as long as the data manager does no arithmetic or other manipulations of the
data strings that would depend on interpretion of a word as one data type or
another.

Now, then, to matter of an "UNDEFINED" type. If the standard is to continue
to require that default real and integer data occupy the same amount of
space, or at least that such types can be defined that do so, then it would
appear useful to be able to define a data type as not having any particular
interpretable bit pattern, but occupying the same amount of space as the
others. The compiler would be required to prevent any operation on such an
entity that would require interpretation as one type or another. Only
movement or perhaps equal- compare would be allowed. EQUIVALENCE would allow
having character and UNDEFINED to occupy the same (starting) location. In
essence, providing this would basically legitimize the
character-noncharacter equivalence issue, while providing some measure of
error checking and conceivably avoiding use of a particular instruction on a
computer that requires a word to have a particular interpretable bit pattern
without generating a fault (I am not aware of any such existing problems).

I imagine that this proposal:

a)Is easily shot down.
b)Was proposed before (and shot down).
c)Has some merit and will generate a lengthy thread also.

We'll see. If someone can point me at a compliant way of handling my data
movement problem, for which I have used EQUIVALENCE, above, I'd like to see
it.

Dick Russell

-----------------------------------------
*****************Internet Email Confidentiality Footer******************

Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible
for delivery of the message to such person), you may not copy or deliver
this message to anyone. In such case, you should destroy this message
and notify the sender by reply email. Please advise immediately if you
or your employer do not consent to Internet email for messages of this
kind. Opinions, conclusions and other information in this message that
do not relate to the official business of The Shaw Group Inc. or its
subsidiaries shall be understood as neither given nor endorsed by it.
________________________________________________________________________
The Shaw Group Inc.
http://www.shawgrp.com