Re: A few syntax questions

Joe Krahn <jkrahn@xxxxxxxxx> wrote:

What is the purpose of an optional comma after the type specifier
CHARACTER*(n) ?

I forget, but I think it is mostly a historical anomaly.

In the numbered syntax rules, why are END (FUNCTION|SUBROUTINE|PROGRAM)
listed under action-stmt? They seem no more an action statement than
ENDDO, and require several Constraints to exclude them from normal
action statements.

Because they can have the effect of stop or return statements. Personal
styles vary as to whether or not you actually use them that way. I
don't, but other people do.

Does F2003 still require space-insensitive parsing of free-form source code?

Huh? No version of the standard has ever had space insensitivity of
free-form source. Did you get something backwards here? Free form is
space sensitive. Fixed form is space insensitive.

This is never likely to change. Fixed form is obsolescent and, as such,
mostly for compatibility with existing code. As long as it is considered
obsolescent, it doesn't make much sense to be diddling with it in ways
that will break that compatibility. If anyone ever proposed making free
form space insensitive, such a proposal would not likely be taken very
seriously, in my opinion; its chances would be pretty much zero.

Now if you are talking about allowing spaces in some specific places,
that's a different matter. For example, I've heard suggestions here that
spaces be allowed in numeric literal constants. No such feature is in
the standard, but that's one that I would not expect to be rejected out
of hand. I don't know whether it would pass, but at least it would be
considered as a serious suggestion.

Is there still no constant attribute? A parameter is a Fortran constant,
but can you have, for example, a pointer that points to a constant? It
looks like F2003 adds only a few special constant attributes, KIND and
LEN. Why not just have a general purpose CONSTANT attribute?

A few confusions in what you mean by terms here. You need to do more
than just throw out the term "constant attribute" and assume we know
what you are talking about. As you note, yes, Fortran has constants,
both literal and named, although the named ones are spelled "parameter".
I'd rather see it spelled "constant" for several reasons (partly that
"parameter" is so often confused with "argument"), but that's not the
way it is. You don't sound like you are talking about my preference for
adding an alternate spelling for the same thing.

No, you can't have a pointer that points to a constant, either a literal
constant or a named one. A constant isn't a data object at all - that is
it doesn't necessarily have a run-time existance to point to. I have
heard several suggestions relating to data objects with restrictions on
changing their values. Perhaps you are talking about one of them. But
there have been several distinctly different ones. Just saying
"constant" doesn't tell me which one you mean. There is one such thing
in f2003 - the protected attribute. I wouldn't think that would be what
you mean, but it is the closest thing I can think of where the answer
might be yes.

And bringing up KIND and LEN doesn't help, because they don't have much
to do with any of them. KIND and LEN are type parameters. They aren't
fundamentally new to f2003. What is new in f2003 is that user-defined
types can have type parameters much like the intrinsic types, but this
is more an integration of an existing concept of KIND and LEN. I have
been known to comment that it is possible to use a LEN type parameter in
obscure ways as a kind of read-only component, but that's not really
what it is for and most people haven't even noticed the hack. I can't
see a way to do anything corresponding with KIND type parameters.

Anyway, I think that the answer is probably that "no", whatever you are
asking about isn't there, but I can't really tell what you are asking
about.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.