Re: Converting fixed-to-free format

On Tue, 07 Mar 2006 11:47:17 -0500, Joe Krahn <krahn@xxxxxxxxxxxxx>
wrote:


I mentioned 'archaic' at the beginning of this thread. Fixed format is
archaic due to it's white-space insensitivity, not because of the
indentation rules. But, I think 'archaic' is an accurate term.

It was equally judgemental and annoying then.


From Dictionary.com:
1. Of, relating to, or characteristic of a much earlier, often more
primitive period, especially one that develops into a classical stage of
civilization.
2. No longer current or applicable; antiquated.
3. Of, relating to, or characteristic of words and language that
were once in regular use but are now relatively rare and suggestive of
an earlier style or period.

So anything beyond a certain age is archaic?

As far as the "relatively rare" in #3 goes, how about all of the
existing code?

I suppose I could go to dictionary.com and look up "transient" and
"unstable." :-)

My original idea was to have a fixed-to-free converter that also detects
white-space problems, as well as converting F66/F77 hacks and
non-standard extensions, like an assumed-size array dimension of 1
instead of *.

That is a fallacious analogy. * does more than 1. It adds something
of significant use, well beyond what 1 lets you do. Although I used
to use the 1 trick a lot, it's not the same as assumed shape. * does a
lot more. And I'm not entirely sure that 1 worked with all
compilers.

Free format appeals to some people's sense of style. Maybe a lot of
people's sense of style. Personally, I can't stand it, but I'm not
going to run around describing it as "the new crap these kids today
use."

The idea assumes that people who continue to use fixed format do so
because they have a large amount of existing fixed-format. That's not
just my idea: F2003 declares fixed-format as obsolecent which means it
is still supported, but destined for deletion.

I will bet you that, no matter what the standard says, no commercial
compiler will abandon support for fixed format.

Alternatively, the same tool could also allow people to continue
fixed-form programming if they really want to.

Why do people need a tool to continue doing what they've been doing?

FWIW, standards should not take the role of "allowing" or "not
allowing." Their proper role is to harmonize and engender trust. If
someone follows a standard, they should be able to trust that what
they're doing will continue to work.

Now, that's not always possible if a language is going to grow. For
example, introduction of character variables pretty much trashed the
old fashioned way of stuffing ASCII patterns into numeric variables.
But the old fashioned way of doing characters was (like setting the
last dimension to 1) kind of a hack that tended to work. So there was
payoff of having something standard and guaranteed.

On the other hand, the flip-flop(s) in whether or not do loops are
executed at least once was a real pain in the ***, and there was no
payoff. I have recently discovered that the traditional rule of how
blanks are handled in fixed input fields has changed. Another case of
zapping existing code and data decks with no particular benefit.

There is absolutely no reason to pull the rug out from under people
unless there is an unavoidable conflict, and the changed feature is
significantly better. Not just a little better, but enough better to
make up for the displacement.

That you need a tool to convert your existing fixed form files to free
form makes you a victim in this, too.

Ken Plotkin

.