Drew McCormack <[log in to unmask]> wrote:

> I am generally a fan of Fortran symbols....
> But what I absolutely deplore is the % symbol used to distinguish
> components of a user defined type.... I am sure an expert in the textual
> arts would confirm for me that this results from the separation symbols....
> I can't help but think the % symbol was used in Fortran just to be
> different to C. I sure hope there was a better reason than that,

I also have heard the story given earlier that % was a placeholder that the
committees intended to replace with a better symbol, but none was agreed.

Lawrie prefers component%structure.

I advocated component(structure).  At the meeting where I advocated this,
it was rejected.  The argument given was "Fortran programmers like to see
what they're getting."  This was already recommended by experts such as
Parnas to be absurd.  When different representations have different syntax
for reference, the best advice is Parnas's:  Wrap up all references to an
abstraction in procedures, to hide the differences in syntax.  Then, as the
program's useful live evolves, if you have to change the representation of
the abstraction, you only have to change its declaration and the access
procedures.

Geschke and Mitchell, Ross, and others, recommended to design programming
languages such that the reference to data has the same syntax no matter
what the representation.  This work preceeded Parnas's by three years, and
the Fortran 90 standard by 22 years.  The consequence of this design is
that you don't need the access procedures if you don't need the access
procedures, and when you do need them, you only have to provide them, not
change every reference to the abstraction.

Only much later (ca. 1998) did I learn that at least for one committee
member the issue was "name space pollution."  That is, if two types have
components of the same name, say "component", then component(structure_1)
and component(structure_2) would "clash"  (assuming structure_1 and
structure_2 have different types).  When I pointed out that the generic
resolution rules could have been beefed up to make sense of the apparent
clash, I witnessed a "slap the forehead" moment.

Some might say "But that's just as [even more] ugly!"  That's fair enough,
since beauty is in the eye of the beholder, at least as far as aesthetic
preferences go.

But suppose that you discover after a few years' time that you need to
change the representation of that component of your abstraction from a
structure to a procedure.  VOILA! Delete the component and write the
procedure, and you're done -- no need to change the references.

Well ... almost.  Assigning values to it look like component(structure)=42.

Another idea that was at least 22 years old in 1990 rides to the rescue.
The MESA language (described by Geschke and Mitchell) and POP-2 and CURL
(I don't remember who described them) all provided for a program unit
that some called an "updater."  This is a procedure that has a syntax of
reference that looks like a component reference, but it appears in a
value-definition context, e.g. component(structure)=42.  Parnas would
have had you change this to "call store_component(structure,42)."  That's
effectively what an updater does.  It could be implemented under the covers
as a subroutine with a "hidden argument" that provides it the value to be
"stored."

So, if you had a function-like syntax to reference components, and if you
could put these references in value-definition contexts, you could change
representation painlessly between structure and function/updater without
the need to wrap the abstraction in brain-dead access procedures if/when
it is simple enough to be represented as a structure component.

Now that we're stuck with structure%component, but the "component" thing-o
can actually be a function, we're halfway there.  We don't yet have type-
bound updaters.  So, instead of writing "structure%component", what
you should really do is write a function named "get_component(structure)"
and a subroutine named "store_component(structure)" and clench your teeth
and use the function and subroutine everywhere to access the abstraction --
just in case you might discover some time later that you need to change
its representation.  At least that's what Parnas recommended in 1972, and
what Computer Science professors have been teaching ever since.

So the % choice is irrelevant.  You should see it in exactly two places
for each component:  The reference function and the store subroutine, each
having one executable statement.

--
Van Snyder                    |  What fraction of Americans believe
[log in to unmask]       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.