Re: A few syntax questions

Richard E Maine wrote:
Joe Krahn <jkrahn@xxxxxxxxx> wrote:
....
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.
So, it seems that they are included due to the presence of an implicit RETURN, if reached, even though they are themselves not really an action statement. Still, I think putting them in the 'action-stmt' syntax rule is an unneeded complication. Maybe a note about implicit returns would be better.


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.
OOPS! Yes, space-insensitive fixed-format is what I meant.


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.
I was thinking about the added parsing complexities as Fotran adds new features. If space-insensitive free format remains fully supported, then space-insensitive syntax issues have to be considered for new constructs as well. Because it is for backwards compatibility, it seems that it would be realitvely easy to restrict newer constructs to being used only in case sensitive (free-form) source code.
....


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.

By 'constant', I mean an actual data item with an actual defined place in memory, but not modifiable. I think the problem with 'not modifiable' is that it may pertain to a specific scope, like intent(in) and protected, or may mean never changed for the life of the program, like a parameter. Or, it can mean it never changes for the life of the data item.

My meaning for CONSTANT is data that never changes for the life of the object, which is the duration of the program for non-allocatables. But, unlike parameters, they can be used like regular variables. SOmetimes this seems a lot easier than dealing with parameters not being real variables, but a constant attribute does bring up issues, For example, you should be able to point a pointer-to-constant at non-constant data, but not the otjher way around.

For an allocatable item, it seems only the LEN integer is this type of constant. A general constant can be simulated outside of the scope of a small module that defines the data as PROTECTED and takes care not to write to it.

Thanks,
Joe
.

Quantcast