Dr W.W. Schulz writes:

 > The backward compatibility problem must be divided into two parts:
 > a) syntactic    a reasonably smart converter should do the trick
 > 		I think users must be expected to do some updating
 > 		as well, of course, with the help of some tools.

But what percentage of the users will agree with this?  I'll wager
quite low.  It would be one matter to require code conversion if it
is required for major new functionality.  Even for major new
functionality, there tends to be a lot of resistance to such.  What
I'm seeing here is mostly "syntactic sugar" and personal preferences,
plus possibly a few minor functionalities.  To add such stuff in a
compatable manner is one thing.  To require old code to be converted
for such reasons simply will not pass (in my opinion, of course).

I think this illustrates far too casual dismisal of compatability
issues.  I don't think that a suggestion for a change like this would
have any chance of passing (or even coming close) if it required
conversion of old codes.  I predict that if it did somehow pass the
committee, the standard would fail to be adopted due to overwhelming
public comment.  You just can't dismiss compatability that casually;
not if you expect it to pass.  Introducing an incompatable change
requires very strong argument and defense of why the functionality
can't be achieved compatably.  I personally don't think any of this
comes close.

I think it extremely prejudices the whole proposal to even suggest
that it might be done in an incompatable manner and require a
converter for existing codes.  That frankly makes it hard for me to
take the rest of the proposal very seriously.  I certainly would have
a hard time keeping a straight face while trying to explain to my
users exactly why they were being forced to make such a change.
In my experience with users, one of the most significant benefits of
f90 is its compatability with f77.  I invariably tell them that they
can use their f77 code as is for now and gradually learn new f90
features.

 > How about this?
 > We should go for a really regular syntax that makes the procedure statement
 > into a full blown interface for the procedure, something like
 > 
 >   FUNCTION, <fct-name-attr> :: fct-name(           &
 > 	      <var-type>, <var-attr> :: var_list   &
 > 				       )           &
 >             RESULT( <res-type>, <res-attr> :: res_name )
 > 
 >   END FUNCTION fct-name

Well, first you'd have to define how this works with multiple
arguments; I don't see how they are delimitted, though presumably that
could be solved.

But more significant is that this is just a matter of personal taste.
And (perhaps one might guess) my taste happens to run otherwise.  I've
seen proposals much like this before, and I don't like them.  For a start,
it makes the function/subroutine statement quite lengthy when the
argument list is long.  This, in turn, means that simple typographical
errors can sometimes be difficult to locate because the compiler might
not diasgnose them until quite a few lines later.  I always though of
this as one of the poor parts of several other languages.

Then there is a consistency issue.  Consistency is so often in the eye
of the beholder.  (I am reminded of the many arguments about treatment
of zero-sized arrays, where pretty much everyone was arguing that they
should be treated consistently with non-zero sized ones, but there
seemed to be quite a lot of viewpoints about exactly what would be
consistent - I lost that argument - I think they look pretty
inconsistent - oh well).  In the case of dummy arguments, they are
local variables, so if the above proposal was passed, I would wonder
why they couldn't be declared like in their own statements like other
local variables instead of being declared in the middle of the
function statement.  (And if you are going to try to tell me that
dummy arguments are not really local variables, then you'd be getting
into revisions of the basic semantics of the language - and a part
with lots of subtleties).

I don't see any particular point in arguing matters of taste.  People
will, rather by definition, disagree on them and there is nothing
wrong with such disagreement.  So if you think my taste is "poor"
in this matter, I'll not argue.

My point is that this *IS* a matter of personal preference, not a
clearly objective measurement of "consistency."

 > We could leave the older syntax in place for a while, but set a date for
 > obsolescence and provide conversion tools.

 > Now we can ask in the F90 style
 > 
 >    xprec = KIND(x)
 > 
 > but in the OOP style this would be
 > 
 >    xprec = x%Kind

Let me end on a note of some agreement.  I like this one.  So did enough
other people that it passed (not that there wasn't minority disagreement).
This is currently being worked as part of the f2k proposal.

I might note, however, that there was no suggestion to phase out the
function notation where it already exists.  I strongly suspect that if
such a phase-out plan had been proposed, it would have caused the
whole proposal to fail.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%