Thanks for the very interesting and knowledgeable history lesson.  I do
not hestitate in repeating it below.

Along with others, I still find % difficult to read even surrounded by
white space.  And alot of new code I've seem does not use white space,
it's purely a local "standard".

Luckily for us, portability is not a major issue.  Our mainstream
programs are on VMS boxes and we port some programs to CVF for our
engineers who travel abroad.  Both these use "STRUCTURES" with the more
aesthetic dots.

With changes like .LT. to <, I cannot understand why conflict with the
logical operators was deemed a problem.  I'm sure the standard could
have said something to the effect that defined types need only be
supported by vendors if the notational operators were used in
conditionals.  Vendors like Digital/Compaq could have maintained their
total support (and SL has said that they still find the odd problem).
Other vendors who had never used the dot notation, could now use it with
the proviso that notational operators only could be used in conjunction
with defined types.  None of this would have caused any backward
compatability problems: notational operators were not previously
standard, nor were defined types.

Regards, Paddy

[log in to unmask] wrote:
> 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.



***********************************************************************

"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above.  If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender.  You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.

If you have received the email in error, please notify TransGrid
immediately.  Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid.  TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.

Please note the email address for TransGrid personnel is now
[log in to unmask]"

***********************************************************************