Added constants, functions, and rearranged sections.

[DavidSagan]

No description provided.

[ax3l]

Like set, I would discuss a matching syntax separately.

There is an argument to make if this belongs in PALS syntax or can be a language-specific API and we need to weight the pros and cons.

[ax3l]

(Not saying we do not need either. I just think this will need a separate discussion of options and syntax and it will get long if you mix it into a PR that defines constants and rearranges sections.)

[DavidSagan]

Let's start a discussion and if needed I can move.

Element selection is important to make PALS flexible in terms of parameter setting, etc. and to this end it is important to have a standard way to select things. A language-specific API here would create a tower of Babel.

[DavidSagan]

Simply put, if arithmetical expressions are to be part of PALS, there needs to be a standard syntax to select elements.

[DavidSagan]

Also if setting of element parameters after the element definition is to be part of PALS, there needs to be a standard syntax to select elements.

[ax3l]

Maybe I misremember, but I was always under the impression that selecting and manipulating a lattice file's definitions would be done outside of PALS in libraries/tools/frameworks.

[DavidSagan]

It depends upon what you mean by "manipulating". In any case, element matching is needed to simplify the setting of element parameters. The bottom line is that PALS is for promoting portability of machine information and element matching syntax is needed for this.

[DavidSagan]

@meneken17 Thanks for the info. Do you have any ideas how this should fit in with the PALS standard itself considering that the PALS standard is language (YAML, XML, etc.) agnostic?

[danielkallendorf]

Concerning element selectors: If we (instead of yaml) think of a pals file in xml structure, we can use CSS-selectors or XPath.
With the former one, every web developer is familiar and it can be converted into the latter one.
There are XPath implementations for python/julia/...

Making up some not yet existing .pals.xml of alternating quadrupoles:

<branch name="main_branch">
<element kind="quadrupole" name="QF1"> ... </element>
<element kind="quadrupole" name="QD1"> ... </element>
<element kind="quadrupole" name="QF2"> ... </element>
<element kind="quadrupole" name="QD2"> ... </element>
</branch>

one could then select

• All quadrupoles element[kind="quadrupole"]
• All quadrupoles in the main_branch branch[name="main_branch"] element[kind="quadrupole"]
• All QD* element[name^="QD"]
• The third element element:nth-child(3)

and a lot more

[danielkallendorf]

Thanks for the info. Do you have any ideas how this should fit in with the PALS standard itself considering that the PALS standard is language (YAML, XML, etc.) agnostic?

It is only language agnostic in terms of the file format.
Inside of the PALS implementation the lattice needs to be represented in some kind of DOM-tree for the selectors to work.
I will look for some examples.

[ax3l]

Maybe I misremember, but I was always under the impression that selecting and manipulating a lattice file's definitions would be done outside of the PALS standard, and instead in libraries/tools/frameworks.

Example: pals-project/pals-python#26

That also has the benefit that we do not need to implement a custom syntax parser & manipulator, based on some strings we pop into attributes. But instead, we just define clean, documented APIs in reference implementations for this job. Imho, it is not important that the C++, Python and Julia select & manipulate syntax look the same, since we can exchange scripts and PALS files as needed.

[DavidSagan]

@ax3l I don't remember this being discussed. In any case, what would you have for an API for YAML files?

[ax3l]

I don't remember this being discussed

I remember from early discussions, but am definitely open to revisit.

In any case, what would you have for an API for YAML files?

For YAML (or JSON or XML or any) files, you read it in the reference implementation (e.g., for Julia/Python/C++) and manipulate it there.

It is super common that scripts (or tools) are used to generate/manipulate lattice files, we do not need to reinvent the wheel for this, I think, and can keep generation/selection/removal/manipulation outside of the PALS standard.

If people disagree on the last aspect, we could just unify how we name central APIs (e.g., select/filter methods) and their arguments across languages. For example what @danielkallendorf wrote above is 90% identical to pals-project/pals-python#26

[DavidSagan]

We need to have the capability to do element selection in lattice files and it is very important that this be standardized at least for a given language.

[DavidSagan]

• main_branch branch[name="main_branch"] element[kind="quadrupole"]

There is certainly no problem with the PALS standard, to use some agnostic syntax like main_branch>>quadrupole::.* and for, say, XML the corresponding syntax can be branch[name="main_branch"] element[kind="quadrupole"].