View source for Talk:Long literals, with continuations

== quote by the task's author ==

''The point of the task is to show how to code a (as a literal) list of tokens, with (or without) continuation(s), and to verify the list by showing the number of elements, and also by showing the last element name in the list.  Opinions such as the above should probably be better voiced in this task's talk page.''  --''Anonymous edit dumped on the main task page unattributed'' Moved here as suggested. --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 10:13, 24 March 2020 (UTC)

: That was a quote by me as I was trying to address the remarks entered on that page. &nbsp; It was those comments and opinions that I was trying to address, which, I believe. should have been entered here, on the ''discussion'' page.
 

==Enforcing imaginary rules==

The task states:

;Task:
:* Write a computer program (by whatever name) to contain a list of the known elements.
:* The program should eventually contain a long literal of words &nbsp; (the elements).
:* The literal should show how one could create a long list of blank-delineated words.
:* The "final" (stored) list should only have a single blank between elements.
:* Try to use the most idiomatic approach(es) in creating the final list.
:* Use continuation if possible, and/or show alternatives &nbsp; (possibly using concatenation).
:* Use a program comment to explain what the continuation character is if not obvious.
:* The program should contain a variable that has the date of the last update/revision.
:* The program, when run, should display with verbiage:
:::* The last update/revision date &nbsp; (and should be unambiguous).
:::* The number of chemical elements in the list.
:::* The name of the highest (last) element name.

'''Nowhere''' does it state the list must contain '''only''' the element names. Nowhere does it state what the capitalization of the element names must be. Yet the task author flagged the Raku entry as incorrect for not following those imaginary rules. Interestingly the task was '''not''' flagged for not having a single blank  between elements after it is read into memory. (It doesn't because that is nonsensical, there isn't really really a way to have blanks between elements in memory; but that ''is'' a requirement of the task) As the point of the task seems to be "quote a string" and the Raku entry does that, I am not inclined to change it. --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 10:13, 24 March 2020 (UTC)

: Somethings are implied, such a list (or a literal containing a list) was shown what it should contain, a list of words (names or tokens) that were indeed, chemical elements, and it even had a partial example of what was expected. &nbsp; The literal was to contain a &nbsp; ''list'' &nbsp; of element names and was to be a character string stored in a variable, &nbsp; and have just one space between the element names (in the final form). &nbsp; If this wasn't clear, it could be changed by anyone who can express this better than I, as it seems, not everyone understood what was meant. &nbsp; A '''list''' means different things to different people, based on what computer programming language is being used. &nbsp; This example clearly shown the names of the first few elements with no capitalization. &nbsp; The task never said anything about "reading" into memory, &nbsp;  but from my use of the word, &nbsp; I wouldn't have used "read" but "assigned/defined/set/initialized/or somesuch". &nbsp; as one would assign a literal to a variable which contained a list of words. &nbsp; I am aware that some computer programming languages define a '''list''' differently, and with this in mind, I tried to define a list by example. &nbsp; I had intentionally stated that the most idiomatic approach should be used in creating the list &nbsp; (when it would eventually be stored/created as the finalized list as being used/utilized by the computer program). &nbsp; I tried to use general terms as each language has their own definitions and verbiage for such things. &nbsp; A '''list''' in one language may be defined (somewhat completely) different in another language, and I tried to make it clear that the list was a literal (character) string of blank-delineated words (chemical elements). &nbsp; Since this is a wiki, you are free to add/clarify what was meant. &nbsp; If one were to add other information to the list &nbsp; (the element symbol, atomic number, other isotopes, specific gravity, half-life if radioactive, alternate spellings, date of discovery, etc), &nbsp; it would make comparisons of computer programming languages harder and possibly even obfuscated, and be in keeping with the Rosetta Code, er, ... tradition. &nbsp; Believe it or not, the whole point was to make the list as simple (and pure) as possible (and show how a computer programming language handles literals that don't "fit" on a single (source) line (and possibly use some form of continuations showing a multi-line assignment), &nbsp; and not have the list embellished to the point it would be hard to compare it to other programming solutions. &nbsp; Sometimes, the most simple thing is hard to describe such that each computer programming language does the same thing, or at least, a similar thing or process. &nbsp; I would prefer to have the program simplified to address/adhere (to) the task's requirements and example, and if you feel that your entry better shows off the languages capabilities, then you could add the current version as an enhanced/embellished version. &nbsp; Calling the stated rules "imaginary" doesn't help the discussion here on Rosetta Code or facilitate compromises. &nbsp; I'm trying to be civil here and address your concerns, but at least try to solve the task in the spirit it was created, &nbsp; or even possibly just mimic what other solutions have done. &nbsp; The ''elements in memory'' as you put it was not meant to be elements of an array (which can be thought of as a ''list'', &nbsp; but part of a literal ("stored" in a literal with intervening blanks between element names). &nbsp; Your contributions are always welcome here, but refusing to change (simplify) your entry is rather surprising. &nbsp; You also have seemed to miss the whole point of this task, it was not to just "quote a string". &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 15:46, 24 March 2020 (UTC)

:: I'm not going to get in to a protracted argument over what is wrong with this task. Rather I'll summarize my points.

::* The task name is "Long literals, with continuations", but the actual task set for us is almost completely besides the point.

:::* The requested string isn't long, except maybe for some incredibly contrived definition.
:::* The requested operation (find the last element, count the elements) has nothing to do with how the string was stored.
:::* The other requirement ( have a "revision date" ) can't even make a ''weak'' case that it is a "long literal". Why is that even part of the task?

::* Admittedly, my (Raku) entry has some extra stuff in an attempt to make the task less boring, but it still follows the exact letter of every pointless, irrelevant constraint. 

:: If you really want the task to be about a comparison of how different programming languages handle literal data '''then why isn't that the task?''' See [[Quoting constructs]] for what the task ''could'' have been. --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 14:46, 25 March 2020 (UTC)

::: Because I choose to have the task to be about how (different) computer programming languages handle &nbsp; (or specify, define, express) &nbsp; long literals with continuations. &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 15:24, 25 March 2020 (UTC)

::: Your comments about pointless and irrelevant constraints isn't germane to the task's description and/or requirements. &nbsp; Adding code to make the task less boring just makes it harder to compare computer programming languages (in regards to how other entries solve the task at hand. &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 15:24, 25 March 2020 (UTC)