ford

ford copied to clipboard

I would like to add support for the 2008 standard's block construct. However, I am not quite sure how to do this. Should variables declared within a block go in a separate list of variables? Should they be displayed in the main list but treated as though they are private? Or should I just ignore them altogether?

Hi Chris, I have not yet extendively use this feature. I can check what the standard says about it. However, I think that the block variables should be volatile: they live only into the block, thus are special in some sense, maybe private or listed separately.

Well, they're not volatile in the sense that they don't have the volatile attribute. But yes, they only exist inside the block.

On 15-12-22 12:49 AM, Stefano Zaghi wrote:

Hi Chris, I have not yet extendively use this feature. I can check what the standard says about it. However, I think that the block variables should be |volatile|: they live only into the block, thus are |special| in some sense, maybe private or listed separately.

— Reply to this email directly or view it on GitHub https://github.com/cmacmackin/ford/issues/96#issuecomment-166504368.

Chris MacMackin cmacmackin.github.io http://cmacmackin.github.io

Sure, volatile in the second sense.

I think that if you go to list them within standard variables this could create confusion. Indeed, it is difficult to figure out how/where they can be listed clearly.

I think for the upcoming release I'm just going to make FORD ignore variables declared in block constructs. I'll keep this thread open, though, in case anyone can suggest something better.

Wise decision. It is not really simple to figure out a clear listing of them.

With some delay... I will just give my opinion here (no clear solution indeed). I have just read the definition of the BLOCK construct from NAG website and the draft of 2008 standard (from GNU web site, maybe outdated). I'm not sure this kind of variable should really be documented. It seems to me that they are local (even if they have the SAVE attribute).

So I think you should let the responsibility to the developer concerning the documentation of such variables. In the worst case, they can be documented in the parent unit.

Anyway, I agree with Stefano, they should not be listed within standard variables.

The tricky thing is also that there are at least two types/flavors:

1. Aliases
2. Temporary new variables

You can also write more general expressions, which I guess is similar to the alias idea, or maybe a C-like macro.

I think it would be super useful to have variables, named expressions etc. declared in an alias block be clickable, to take you to their definition (at the top of the block construct) Then if you have one variable aliasing another, perhaps the variable being aliased would be clickable in the declaration section at the beginning of the block.

It might also be helpful to indicate in the documentation of procedures whether or not they use the block construct. This would make anyone reading the code more aware of the possibility of this aliasing, and local temporary variables.

By aliasing, do you mean the associate construct? As far as I could tell from the standard, the block construct is only for temporary variables. From what you're saying, it sounds like handling of associate constructs would be more useful that of block constructs.

oops, I'm really sorry, I was conflating the two... I'm trying to get too much done at the same time.

On that note, what is the support, if any, for associate blocks in Ford?

(p.s. PR is in with homebrew to update the formula for FORD to the latest 4.5.0 release.)

At present, there is no support for the associate construct. If people are interested then I may look to add it for the next release. However, that could be a few months from now...

Yes, support for the associate construct would be great!

Also for me, :+1: for associate

Now that I'm looking to implement them, I don't really see why associate constructs should be documented when block constructs aren't. In both cases you have transient variable identifiers. If I do identify them, then there really isn't much to show, just a list along the lines of

Alias		Original
alias1	=>	this%sub%object
alias2	=>	real_array(1,5:10,:)
alias3	=>	func_result()

Making clickable links out of all of these is not easy, either, as there are a bunch of different possibilities as to what they could be.