Derived types and initialisers

[mn416]

Consider the program:

module pair
  type :: pair
    integer :: x, y
  end type
  type(pair) :: p = pair(1, 2)
end module

In the PSyIR symbol table for this module, the variable p is an UnsupportedFortranType. The reason is that the datatype of p does not pass the following check in the frontend:

PSyclone/src/psyclone/psyir/frontend/fparser2.py

Lines 2207 to 2210 in 2c73638

	if not isinstance(
	datatype,
	(ScalarType, ArrayType, UnsupportedType)):
	raise NotImplementedError

It's not clear to me whether the behaviour is intentional or not. If we wanted to allow p to have an initial value then we'd have to allow allow DataTypeSymbol in the check and also allow Call as a valid node inside the DataSymbol.initial_value setter. Would this be somehow bad? It would permit some invalid Fortran, such as calling a function rather than a data constructor, but that could be potentially checked by the frontend or permitted under the assumption that the input code is valid fortran without leading to major issues?

I encountered this issue while trying to understand why the following program gives an error:

module pair
  type :: pair
    integer :: x, y
  end type
  type(pair) :: ps(1) = [pair(1, 2)]
end module

This program passes the frontend check (because it's an array not a DataTypeSymbol) but then hits the lack of support for Call in DataSymbol.initial_value. I'm trying to figure out what might be the right current solution for PSyclone:

1. allow Call nodes in initial values, or
2. disallow initial values for derived types.

[LonelyCat124]

I didn't realise this was a functionality available in Fortran so nice to learn.

A Call node is a valid initial_value - in fact we use this in many places (e.g. if you have a pointer => null() then we already create an IntrinsicCall as an initial_value).

I'm not sure why the latter case gives an InternalError - if that is a valid declaration (which I think it must be) we should at worst make an UnsupportedType.

I think we can maybe now (@sergisiso changed this recently) allow a Call to a Reference, so if we create a Reference to the DataTypeSymbol of pair, then it might just work - could be worth a try, but will need some work.

The reason why we currently hit the ValueError is two-fold:

1. We explicitly disallow it in datasymbol.py:

            if not isinstance(self.datatype,
                              (ScalarType, ArrayType, UnsupportedType)):
                raise ValueError(
                    f"Error setting initial value for symbol '{self.name}'. "
                    f"A DataSymbol with an initial value must be a scalar or "
                    f"an array or of UnsupportedType but found "
                    f"'{type(self.datatype).__name__}'.")

This is either because we didn't know it was valid, or chose to not allow it for now. I don't see why we couldn't allow it if necessary now that we can support a Call to any Symbol.
2. The second issue (that may need fixing somewhere, maybe the backend) is that we need to ensure we output the Call node correctly, and don't output type(pair) :: p = call pair(1, 2)

[mn416]

Thanks @LonelyCat124. The second issue was introduced by my recent array constructors PR, but missed by testing. I feel obliged to fix it! It should be straightforward but I was just wondering which way to solve it. Thanks for your input about permitting Call (not just InstrinisicCall) in intialisers. I will try that approach first and see how it goes, as I think it would be preferable.

[LonelyCat124]

Hi @mn416, I think I meant that Call should already be allowed as an initial value (at least according to the symbol's type, as I think that allows Node). I think instead the limitation is entirely in the frontend/backend because we disallow the creation of initial value for DataTypeSymbols there, which is probably not a necessary limitation. I'm not sure if or how we can check the initial value is valid, but we probably can just go with bad Fortran input leads to bad Fortran output.

…

On Fri, 24 Jul 2026, 16:52 mn416, ***@***.***> wrote: *mn416* left a comment (stfc/PSyclone#3502) <#3502 (comment)> Thanks @LonelyCat124 <https://github.com/LonelyCat124>. The second issue was introduced by my recent array constructors PR, but missed by testing. I feel obliged to fix it! It should be straightforward but I was just wondering which way to solve it. Thanks for your input about permitting Call (not just InstrinisicCall) in intialisers. I will try that approach first and see how it goes, as I think it would be preferable. — Reply to this email directly, view it on GitHub <#3502?email_source=notifications&email_token=AAXHESVLYEY75UQJ6B56LXL5GNZ2JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXGEYTQNRQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5071186070>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHESWV6XZUSTBUVUKLFAL5GNZ2JAVCNFSNUABEKJSXA33TNF2G64TZHM4DGNJUGE2DMNR3JFZXG5LFHM2DSNBYGEYTIMZXHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAXHESWMPO7LPABDH7LKQYD5GNZ2JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXGEYTQNRQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAXHESRDTC2ND7NYGO2T2TD5GNZ2JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXGEYTQNRQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[mn416]

Thanks @LonelyCat124, I think we are on the same page. I will try allowing DataTypeSymbol in the datatype of the initialiser, and promoting IntrinisicCall to Call in the check of nodes that are allowed inside an inintialiser here:

PSyclone/src/psyclone/psyir/symbols/datasymbol.py

Lines 241 to 243 in 2c73638

	if not isinstance(node, (Literal, Operation, Reference,
	CodeBlock, IntrinsicCall,
	ArrayConstructor)):