At 09:25 AM 12/4/00 +0100, Giampaolo Bottoni wrote:
>I look at ftp://ftp.j3-fortran.org/j3/doc/standing/007 but,
>if I have correctly understood, the  ASSOCIATE construct is,
>from some points of view,  LESS powerful than Pascal's and
>(this is for me more important) JavaScript's WITH.
>
>Whith the ASSOCIATE construct I must specify ALL the
>associated components. I would like instead to IMPLICITLY
>specify to the compiler that a lot of variables belongs to
>the same object.
>
>With the WITH construct I can look at any  Fortran 77
>old instruction sequence, create a service derived utility_type whose
>components are all the instruction sequence variables
>and then, using a simple WITH, perform the
>sequence instructions with the data of the created utility_object.
>Without any modification of the old instruction sequence
>and without a long list of all the instruction sequence variables !!!!
>
>If the same calculation must be performed with different
>data, a parallelization procedure (using the Unix pthread_create(...)
>or the Windows CreateThread(...)) can be set up where
>each thread works on a different element of a vector whose elements
>are of the type of the utility_object.
>
>A NEW PROPOSAL for the ASSOCIATE instruction: If I could write:
>
>ASSOCIATE ( *=> myobj%* )
>    a=b+c+d+...+z
>END ASSOCIATE
>
>that is if all the components would match to their own names (*=>myobj%*),
>the ASSOCIATE instruction could work exactly as the WITH !!!
>Now, instead, I must write:
>
>ASSOCIATE (a =>myobj%a, b=>myobj%b ,..., z=myobj%z)
>
>a very hard and tiring work if I have hundred of components!
>
>...
>
>Joking aside, do you think that my proposed enancement ( *=> xxx%* )
>can be accepted ?

I think it improbable.

The committee was unhappy with the Pascal-like version of WITH for a number
of reasons. I probably don't remember them all, but here are a couple:

1. The component names unconditionally override local variables with the
same name.  This may not be a problem for small programs written by a
single author, as that author can arrange for the names not to overlap, but
in larger programs with multiple authors, the probability for name
conflicts seemed high.  It would be possible to work around this if a
renaming facility (like that on the USE statement) were included, but that
seemed at odds with the original intent of having a _simple_ ASSOCIATE
construct.

2. Although the Pascal-like approach can work well when dealing with the
components of a single structure, it worked poorly when programming
interactions between two or more structures.  One could only "abbreviate"
the references to one of the structures, so references to the other(s) had
to be written in full.

For these reasons and others, the committee felt it better that the user,
rather than the compiler, be in control of the abbreviated names being
created by ASSOCIATE.  It was assumed that in the single structure case,
rather than write

ASSOCIATE (a =>myobj%a, b=>myobj%b ,..., z=myobj%z)
    a=b+c+d+...+z
END ASSOCIATE

one would be more likely to write something like

ASSOCIATE (M => myobj)
    M%a=M%b+M%c+M%d+...+M%z
END ASSOCIATE

[In practice, most of the components names are likely to be longer that one
character, but the "abbreviation" for the object really is likely to be one
or two characters long, so the "overhead" for referencing components would
be kept relatively small.]  This approach extends well to multiple
structures; all one has to do is add more "abbreviations" for the
designators of the other objects.

I realize that this approach does not work well for the particular problem
you are describing because of your requirement that the reference syntax
not be changed.  I suppose it _possible_ that the committee would consider
your proposed extension to support that particular class of problems, but I
think it likely that they would find the size of this problem domain too
small to justify this much extra baggage.

[I find it somewhat disingenuous for you to complain about dealing with
hundreds of component names in the ASSOCIATE statement when you were
willing to deal with those same hundreds of names in creating the
type.  Indeed, if I were faced with your application on a one-shot basis, I
would probably use my favorite editor to convert the type definition into
the required ASSOCIATE statement, so I wouldn't have to deal with those
hundreds of components individually.  (If I were doing it repeatedly, I
would probably use a Perl script instead -- higher initial cost but less
incremental cost each time I created a new ASSOCIATE statement.)]

Perhaps I am misjudging the extent of your problem domain, but its special
characteristics, i.e.,
a) the existence of extensive code that you wish to change from applying to
variables to applying to components without textual modifications,
b) the lack of need to access other variables in the surrounding
environment, and
c) the lack of need to deal with more than one instance of the structure at
at time,
collectively strike me as being relatively unusual.

--
Kurt W Hirchert                                  [log in to unmask]
UIUC Department of Atmospheric Sciences                  +1-217-265-0327