Rename: NullEle -> Placeholder Element

[ax3l]

Removed Ele suffix, as I think the sporadically used Ele suffix is repetitive, abbreviated/unclear, inconsistent, and simply not needed in practice..

Renamed from Null because Null/null/None/none are reserved keywords in the file formats and programming languages we support in PALS. Related to #86

Votes

• No suffix: adopted
• New name of this element

[DavidSagan]

I think Empty is too generic. Better is EmptyEle.

[mattsignorelli]

When it comes to including Ele at the end, I feel like there is a threshold when something is understandable as an "Element" or not. Words like "Quadrupole" and "Sextupole" pass that threshold. But "Empty" is far too generic and applicable in other contexts - e.g. an Empty set, or an isempty array or tuple, etc. Unless all elements are defined with something like Element.Quadrupole and so Element.Empty, I agree with David that the Ele at the end is much clearer here

[ax3l]

I think the sporadically used Ele suffix is repetitive, abbreviated/unclear, inconsistent, and simply not needed in practice.

Element kinds do not float as individual words around in PALS, they are only defined in a context.

PALS Files that Users Exchange (YAML/JSON/etc.)

In PALS files the elements will always appear after an element kind, unmistakenly clear.

my_drift:
  kind: Drift
do_nothing_element:
  kind: Empty
my_quad:
  kind: Quadrupole

APIs

In language implementations, people will create name spaces like kinds or elements to collect all element kinds, e.g., Python

pals.kinds.Drift(...)
pals.kinds.Empty(...)
pals.kinds.Quadrupole(...)

or C++:

pals::kinds::Drift(...);
pals::kinds::Empty(...);
pals::kinds::Quadrupole(...);

It is really not a problem once you look at in which context this will be used in practice.

[DanielWinklehner]

I agree with Axel.

Maybe another option would be to use "Dummy" instead of "Empty"?

[ax3l]

Thanks, @DanielWinklehner!

The challenge with Dummy is that it is discouraged by linguists to be used (e.g., google's developer guidlines; IIRC it can be interpreted as ableist lingo).

[ax3l]

Another option could also be to call this element kind Invalid if we want to use it really mostly as status indicator (and encourage users in their files to use Markers instead for do-nothing).

[DavidSagan]

To my mind EmptyEle is much clearer than Empty. In any case, there should be a poll to see what people think.

[DavidSagan]

I made a PR #104 to explain that NullEle is just used for bookkeeping.

[DanielWinklehner]

Yea, I was actually worried about the linguistic implications of Dummy right after writing the comment.

"Proto," "Mock," or "Stub" are AI suggestions.

[DavidSagan]

I like "null" over "empty" since "null" emphasizes that this element, in one sense, does not exist and is only being used as a placeholder.

[ax3l]

Yep, I generally like "null" (and "none") too, but it will collide with keywords reserved in yaml/json as well as programming languages...

[DavidSagan]

NullEle is not a reserved word.

[ax3l]

Yes, but a spurious sporadic Ele suffix for kinds is repetitive, abbreviated/unclear, inconsistent, and simply not needed in practice.

We can simply collect the rationale and our best ideas and vote on the best name.

[DavidSagan]

It is not spurious nor unclear (it is much clearer than using Null or the like). If you don't like NullEle how about NullElement? Also it is not a question of whether it is needed. That was never the issue. The issue is does it make things clearer for Users in general? I would argue that for Users who are relatively new to PALS, this does make things clearer.

[DanielWinklehner]

I personally like "Stub"

But...
What about "Nihil" (Latin for "nothing"). That shouldn't interfere with existing programming syntax.
What about "Placeholder?" It's too long for my taste, but not longer than NullElement.

[ax3l]

spurious sporadic: we use the suffix only in a few elements.

NullElement would still be spuriously used for these few elements, but at least would not abbreviate, which is better than Ele.

Yes, I think we need an element like this, this PR is just about the naming scheme we want to apply to elements that are in the "book-keeping" category.

[DavidSagan]

We need to take a poll on this. And the wording should reflect all sides.

[ax3l]

Fully agreed. I would like to find a nice naming scheme for the three book-keeping elements in #86.

And in general, I like that we avoid repetitions and abbreviations, to make the schema readable and accessible :) That is what drives my proposal in #86

[DavidSagan]

The definition of "spurious" is "not being what it purports to be; false or fake." Not using the suffix elsewhere does not make it spurious.

[ax3l]

Ah, the word I was looking for is sporadic, as in inconsistent. Sorry for the translation error from German.

[mattsignorelli]

If it is always in the context Axel describes in #101 (comment), where it is never unclear that Empty refers to an empty element, then I would agree with Axel that this is the cleaner more consistent solution.

[ax3l]

Voted on PALS meeting of November 5th (16 participants):

Poll options:

• with *Ele suffix -- received 1 vote
• without *Ele suffix -- received 7 votes

[ax3l]

Focusing on descriptive names, what do people feel is a good new name for NullEle?
Here is its description.

Please "react" to this post (use button below this text):

• 👍 kind: Empty
• 🎉 kind: Placeholder
• 🚀 kind: Nothing
• 😆 kind: Mock
• ❤️ kind: Stub
• 😕 kind: Invalid
• 👎 do not like either (please comment)
• 👀 I saw this poll but have no opinion on it / absent from voting

Multiple reactions are ok. Please ignore the emotion behind the emoji, just using them as a quick polling vehicle.

[EZoni]

@DavidSagan

Any final objections against merging this?

[DavidSagan]

@EZoni No.

[EZoni]

@ax3l

There's a tie between kind: Empty and kind: Placeholder - which one do you want to pick? I'm fine with the PR as is.

[ax3l]

@pals-project/pals-technical-committee @pals-project/pals-contributors please feel free to vote here for the new name of the NullEle, as discussed per last meeting :)

[ax3l]

Currently Placeholder is in the lead. I will update the PR and wait for the meeting tomorrow with the merge.

[EZoni]

It's a tie again - Placeholder is not in the lead anymore.

[jsberg-bnl]

On Placeholder: an element of this name exists in MAD-X. I tend to use it as "this is a thing, it doesn't do anything at the moment, but will someday when I bother with the implementation." It could, for instance, represent a feedback kicker, the crab cavity space placeholder in the EIC since I don't know the actual cavity layout, etc. In Bmad I tend to use pipe for the same thing. So I'm not a big fan of Placeholder.

[jsberg-bnl]

I'm a bit unclear on what we accomplish by having this element. It seems like you could reference some other object just as easily for superpositions. Creating an element that is for "internal structures" is mixing lattice definition with implementation, which I think we should avoid.

[mattsignorelli]

The purpose of this element still isn't fully clear to me - it seems like this is just a "Marker" that gets removed during "expansion". If this functionality is really needed by a user , then why not just add a flag to a generic element to specify removal? That said, I don't understand why a user would want this, could you share a use case for that behavior?

[ax3l]

We discussed this quickly in the @pals-project/pals-technical-committee today and since this element is doing nothing, there is no big harm of leaving it in for now. It is a literal NO-op.

We can revisit if really nobody uses it in the future and remove it if so.