How to redefine a PARAMETER in one easy lesson

Compare and contrast the two following snippets of code ...

FTN95 v6 issues several errors (as it should) if asked to compile this:

        program parammed
        use param
        integer i, six (six)
        six (:) = 6
        write (*, '(i10)') (six (i), i = 1, 6)
        end program parammed

        module param
        integer, parameter :: six = 6
        end module param

On the other hand, it is happy to compile and run the following without error, even using /CHECKMATE:

        program parammed
        use param
        call sixy
        end program parammed

        module param
        integer, parameter :: six = 6
        contains
        subroutine sixy
        integer i, six (six)
        six (:) = 6
        write (*, '(i10)') (six (i), i = 1, 6)
        end subroutine sixy
        end module param

It manages to use the PARAMETER declaration of six to redefine six as an integer array with six elements. I know that there are no reserved names in FORTRAN, but I think a compiler ought to recognise when a program attempts to redefine its own terminology (as it does in the first example). Ask not how I came by this perverse concept 😃 but seems a pretty clear bug to me. What do others think?

I doubt if the Fortran standard has anything to say about this.

The reason this works OK is that, internally, module variable names are decorated according to which module they come from. So internally the two representations for 'six' look quite different. They are also stored in a different way.

Quoted from PaulLaidler The reason this works OK is that, internally, module variable names are decorated according to which module they come from. So internally the two representations for 'six' look quite different. They are also stored in a different way.

Hmmm ... on that basis, I would expect the first code snippet to be OK and the second one not, but it's the other way around?

And it's not working OK - if you follow it in SDBG, the program does not know about a parameter called six. It's not in the variables window, even with the option checked to show parameters - and any attempt to use six rather than 6 (as it were) causes compile or run time errors.

Your code sample works OK for me provided, of course, that you change the order so that the module is defined first. This means that the declaration six(six) causes no problem.

The fact that parameters cannot be seen in SDBG is a known bug that still needs fixing. As far as I know parameters can never be seen as intended within SDBG.

If your code is changed by replacing 6 by six, at either point, the code does produce a compilation error but in these contexts the compiler thinks six is the array.

Quoted from PaulLaidler Your code sample works OK for me provided, of course, that you change the order so that the module is defined first. This means that the declaration six(six) causes no problem.

Hmm ... well, I have my module and my main program in separate files, so order of definition is not a factor for me. And based on what you say about internal decoration, order of definition ought not to matter - the internal decoration ought to resolve the apparent ambiguity.

The declaration does not cause a problem; that's what I don't understand. The compiler knows what six is for the purpose of declaring the array, but by the time it reaches executable statements it has 'forgotten'.

Quoted from PaulLaidler The fact that parameters cannot be seen in SDBG is a known bug that still needs fixing. As far as I know parameters can never be seen as intended within SDBG.

It seems to be flakey - I have had problems with it sometimes. At the moment I have a project open and can see the parameters just fine. Which is why I knew something was amiss yesterday, once I realised I had inadvertently declared an array with the same name as a parameter - when I ran the code, I could still see other parameters but not the one that had been 'redefined'.

Quoted from PaulLaidler If your code is changed by replacing 6 by six, at either point, the code does produce a compilation error but in these contexts the compiler thinks six is the array.

And yet from what you say, it ought to be able to distinguish the two incarnations of 'six', because internally they do not have the same name?

I figured maybe the issue was being clouded because one 'six' was a parameter and the other 'six' was a variable. So I wrote this snippet, which fails to compile because 'six' has already been declared in module param - as I would expect. But you say this ought not to trouble the compiler because the two declarations are made in separate modules?

        module param
        integer six
        end module param

        module parammed
        use param
        integer six
        end module parammed

Sorry but I cannot take this any further. It will all make sense in the detailed order of various passes through the code whilst parsing and compiling.