Problem-specifications: rational-numbers: abs() is already builtin in some environments

[wolf99]

https://github.com/exercism/problem-specifications/blob/dab442f119d7a7196e27840cf8b5c7dc5c6e57fa/exercises/rational-numbers/canonical-data.json#L205

"abs" is used as the property for taking the absolute value of a rational number.
abs() is a builtin in some environments (e.g. C on clang) which prevents the tests and implementation from matching the problem specifications.

Per https://github.com/exercism/c/pull/417

Proposing a change all property values to full words instead of abbreviations.

Will submit a PR shortly for this.

[sshine]

It's okay that a property overlaps with a built-in in some language.

It is basically an unreasonable constraint.

This was covered in some discussion a few months ago that I can't remember the issue for, but I remember @SleeplessByte was also in it. The TL;DR is that test generators can take this into account.

Also, please remember that #1560 effectively prevents updates like these.

[yawpitch]

I'm going to close this one because @sshine is correct, this was discussed previously and conflicting with a builtin name is not, on its own, a sufficient reason to rename a property, as that would require us to validate every property name against every language. Instead the property name can be translated as required to remove the conflict in the track's implementation / generator.

[sshine]

I've looked and looked for the discussion that covers this, and I simply cannot find the reference to the issue which details the argument, so I'll repeat it in short summary in case it needs to be referred to in the future:

It is impossible to avoid hitting some built-in in some language at some point in time, and it is not necessary to try and avoid it:

1. When test suites are generated manually, the track can pick a custom name that does not conflict with the built-in name, and the manual process of bumping the test suite can take that renaming into account without additional effort.
2. When test suites are generated automatically, the track can pick a custom name that does not conflict with the built-in name, and the test generator can specialize the generated test cases so that they refer to the specialized name.

Such renames are typical for when a track or a presumed culture around a language has a different casing or naming convention than in canonical data.

[yawpitch]

I've looked and looked for the discussion that covers this, and I simply cannot find the reference to the issue which details the argument, so I'll repeat it in short summary in case it needs to be referred to in the future:

@sshine I seem to remember at least part of that discussion happening on Slack, and also that it was quite some time ago ... unfortunately we seem to only have a history as far back as August 29th.

[sshine]

Slack :crying_cat_face:

[SleeplessByte]

I just want to add that, yes @wolf99 you're absolutely right that _if_ a track _must_ match a property name, this would be an issue, but that is not a correct assumption, which means that

which prevents the tests and implementation from matching the problem specifications.

isn't true.

My main contention was that as exercism grows (woooot 51+ languages in v2 right now!!!), it is _inevitable_ that names clash, even when using abbrevations, or other names. It would be sorta ridiculous to keep track of all built-in or defacto community libraries (but standards, so we use them) for matching properties and change them when we find one. It will be an never-ending endeavour and we rather focus on making cool and interesting exercises than this :)