Would it be possible to add pragmas on TYPE declaration?

[PTKu]

Hi! We have come across this issue:

The compiler gives error when declaring pragma on TYPE.

Tracking also here

ix-ax/axsharp#75

[sjuergen]

Hi @PTKu, thanks for your question. Directly, I can't answer that. But let me ask the experts ;-)

[theBadT]

Hi @PTKu,

I'm one of the product owners for SIMATIC AX responsible for the implementation of the IEC 61131-3 ST standard.

Currently, we do not allow pragmas in every location, but only dedicated ones.
Given the definition of the TYPE construct, I'm not particularly sure, in how far and why you'd want to be able to put a pragma on top of it. Could you please elaborate on that?

I'm telling you this, because I assume there is a misconception of the concept of a TYPE vs. a type (and yes, the casing is important to make that point).
TYPE END_TYPE is nothing but a container. Like a section that says "within this particular part of the file, I'm going to declare types that are not known to the system, e.g. user defined types. The user could for one, declare multiple types inside that container and he could also declare multiple different types.
For example:

TYPE
    Colors : INT (Red := 1, Green := 2, Blue := 3) := Red;
    Name : STRUCT    
        f : INT;        
    END_STRUCT;    
END_TYPE

This is a perfectly valid declaration within our engineering. It causes two concrete types to be declared. Colors (a named value type) and Name (a structured type). This gives the user the possibility to arrange his declarations any way he wants, without restricting him too much when it comes to structure.

Having said that and while looking at your usage of the pragma above, this would either mean, the semantics of the pragma shall be applied to all different types declared inside that container, or you did what I would call single type declarations (one type per TYPE construct only).

Hence I assume, you'd want to add the pragma on top of the structured type instead of the whole TYPE container, i.e.

TYPE
  {some-id:some-meaning}
   Name : STRUCT
        f : INT;
    END_STRUCT;
END_TYPE

And this is perfectly valid in our engineering.

[theBadT]

But doesn't this only add information which you already have?

Given your type declaration, you'd want to be able to translate the names of the values to some meaningful expression that could be understood by multiple nationalities. Correct?
If so, the names of the values are already known and could be extracted via the API (which, tbh, I'm not sure whether it would be working already, but I assume it). The other part of the usecase of "translate this is into that" is something which is also already known and which should be of no concern for the source itself. Correct?

So in an ideal world, I would want to pass the type (the name of something) to some other thing that creates screens based on various languages. See my roughly sketched out code snippet

TYPE
    {ix-set:Translation-Required}
    ColorsAsNamedValues : INT (Red := 1, Green := 2,Blue := 3) := Red;
END_TYPE

foreach typeAttributedAsTranslateable
  list members = GetMembers(translateableType)
  foreach member m in members
    tuple<language, text>[].add(ExtractTranslation(m, requestedLanguages)); // This could even facilitate some fancy ChatGPT API
  end_foreach
end_foreach

I hope you get the idea. The point is, to have a degree of freedom when it comes to the destination language and its configuration by, annotating a translateable as whole and separating out the defined/ required languages to some config file.

What do you think?

[PTKu]

You're right. If it were only for the translation, it would address the problem. However, the idea is also to annotate the code with human-readable strings. Any symbol in the program must comply with a format and a limited number of characters (no spaces, some not allowed characters etc.) Now imagine you'd have an application you don't need to localize, but you want to give a human-readable format (to display for the user) and automate the UI rendering. We also have other kinds of attributes: tooltips, rendering directives, etc... (basically, we can inject any .NET CLR attribute for the annotation).

The idea is to have a single source of truth in the PLC program.

The example may make the idea more clear.

Here we have a PLC code

 {#ix-attr:[Container(Layout.Wrap)]}
   CLASS ChinaTown
       VAR PUBLIC
           {#ix-set:AttributeName = "Kung Fu Panda"} 
           Panda : KungFuWarrior;
           {#ix-set:AttributeName = "Kung Fu Dragon"} 
           Dragon : KungFuWarrior;
           {#ix-set:AttributeName = "Kung Fu Snake"} 
           Snake : KungFuWarrior;
           {#ix-set:AttributeName = "Kung Fu Leopard"} 
           Leopard : KungFuWarrior;
           {#ix-set:AttributeName = "Kung Fu Crane"} 
           Crane : KungFuWarrior;
           {#ix-set:AttributeName = "Kung Fu Tiger"} 
           Tiger : KungFuWarrior;
       END_VAR
       
   END_CLASS

   {#ix-attr:[Container(Layout.Stack)]}
   {#ix-attr:[Group(GroupLayout.GroupBox)]}
    CLASS KungFuWarrior 
        VAR PUBLIC    
            {#ix-set:AttributeName = "Current state of health"}            
            State : eWarriorState; 
            {#ix-set:AttributeName = "Enemy kills"} 
            EnemiesKilledCount : ULINT;
            {#ix-set:AttributeName = "Enemies to kill"} 
            EnemiesToKillCount : ULINT;
        END_VAR                
    END_CLASS

    TYPE
        eWarriorState : (Strong, Weak, Wounded, Dying, Dead);
    END_TYPE

Here in the case of eWarriorState are, the members pretty clear and understandable, but we could have an enum that would not be that clear to the user, and we may want to give a more user-friendly name.

That will be rendered using this single line in the UI application

<RenderableContentControl Context="@Entry.Plc.Context.ChinaTown" Presentation="Control" PollingInterval="1000"></RenderableContentControl> 

Like this:

[PTKu]

@theBadT just for more context, here is the
repo https://github.com/ix-ax/ix
and some raw documentation https://www.ixcite.tech/#/
All under development, we are refurbishing ideas from the previous framework based on TwinCAT3

[theBadT]

Minor update: In case this is blocking you currently, you bypass the problem of pragmas not being supported at particular position, by using a comment instead.

TYPE
        ColorsAsNamedValues : INT 
        (
            // {ix-set:AttributeName = "<#Rot#>"}
            Red := 1, 
            // {ix-set:AttributeName = "<#Grün#>"}
            Green := 2, 
            // {ix-set:AttributeName = "<#Blau#>"}
            Blue := 3) := Red;
END_TYPE

A developer of my team pointed out correctly, that, using the analyzer API grants you access to the syntax level as well, so you could identify the entites by looking at comments that adhere a dedicated layout/ structure. Hence the above notation would be syntactically/ semantically correct while not loosing the information you'd require. Although I'm pretty well aware that it would lead to a specific implementation of extracting the information since it is not yet supported by the language natively.

[PTKu]

Thanks, @theBadT it is not really too big of a pain... using the solution you propose would also not be a problem if there was not another way, we can deal with that.