I would like to declare what I think of as naming victories on these two. GROUP! is perfect and speaks for itself...we don't call blocks BRACK!.
I'm sad that legacy and migration concerns don't let us use NONE directly at this moment:
spaced [
if all [a | b | c] [
"a, b, c wound up being all truthy"
]
if none [d | e | f] [
"d, e, f were all falsey"
]
]
The operation is available as NONE-OF, for now. But I guess I want to say that I feel it is clear NONE is the wrong part of speech for what it used to do. BLANK! seems to be the hero we need, whose main drawback is being too close to BLOCK! in spelling. But otherwise, I dig it.
Anyone who feels differently should speak up now, as I mostly consider this matter closed.
BRICK!
I like GROUP! better than PAREN! for that is an odd abbreviation of parenthesis which is a very difficult word for the round hooks it refers to.
BLANK is fine with me, NONE is the NULL value isn't? (Though NONE-OF is not really bad)
BLANK and BLOCK are different enough for me.
I am very happy with GROUP! & BLANK! changes, these are definitely improvements. I don't see any issue with BLANK! being close to BLOCK!
I'll also add that I've come to love _ for BLANK! I've always liked it's semantic meaning but it has taken me a while to stop typing none in place of it
I'm happy if NONE eventually becomes NONE-OF. I think for little while longer you should keep it has deprecation.
On another note... is there a difference between REFORM and SPACED ?
I feel that if I asked you "were all the conditions true" or "were none of the conditions true", or "would you like all the toppings, or none of the toppings"...that is what the word is for.
We prefer the brevity of ALL instead of ALL-TRUTHY or NONE-FALSEY. And I think NONE instead of ALL-FALSEY or NONE-TRUTHY works.
But it's too soon, since too many people would make mistakes given the old meaning of NONE. So for now, NONE is just phased out. It was a bad part of speech for "nothing".
In any case, more support for the idea that this pattern is not something out of left field. I think it's a good change, and NONE! never pleased me as the datatype... just how UNSET! seemed to me to be the state of a variable, not the state of a value. So I'll count VOID as another terminology victory.
I certainly agree that PAREN! has got to go, but I have some reservations about GROUP!:
it is too general a term for this usage
it has too many other meanings in conversation
unlike BLOCK, the phrase "group of code" just doesn't roll trippingly off the tongue for me
So I would like to propose the following alternate choices, in reverse order of my happiness with them:
CRUMB
SHRED
STRIP
PIECE
All still better than GROUP, all work fairly well before "of code" and "of data". But IMO they are not quite good enough ...
WEDGE
From Wikipedia: "A wedge is ... one of the six classical simple machines. It can be used to separate two objects or portions of an object, lift up an object, or hold an object in place."
Paraphrasing, one can easily imagine a WEDGE! "lifting up" some code or data, or "holding in place" some.
And a WEDGE! in a path does separate the path from the code/data inside the ()s.
I am not super happy about the niceness of the phrases "wedge of code" and "wedge of data", but I am happier with them than with their "group" variants.
CHUNK
Firstly, "chunk of code" and "chunk of data" are at least as good as their "block" variants, so big win there.
Secondly, consider its definitions:
as a noun, it means "a thick, solid piece of something" -- pretty good!
as a verb, in North America at least, it means "to divide something into chunks" -- maybe not perfect, but not too too bad
as a verb, in psychology (or linguistic analysis!!!), it means "to group together (connected items or words) so that they can be stored or processed as single concepts" -- almost ridiculously perfect!
Thirdly (and this is the least important argument), in some ways, CHUNK! is actually better than BLOCK!. The only thing "block" has over it is that it already is an accepted term in computer science. But I can easily imagine some CS pioneer in the bygone days choosing "chunk" instead of "block" to describe his set of code units, and if that had happened nobody would today think of "block" as a nice term for it, at least in some of its definitions: as a noun, "an obstacle to normal progress", or as a verb, "to make flow impossible".
I am happy to hear about anything I have failed to consider here, and will gladly bow to the majority opinion.
I don't know that it is any moreso than anything else ("SET"). And PATH! has a tremendous amount of overloading, with the use in the filesystem. If one is going to get worried about something, I'd sooner worry about that (and do).
I'm sympathetic to the idea of overuse of a general term. It's one of the reasons I sometimes pick undesirable names for things as a first cut. (e.g. REDESCRIBE) Easier to change later and you can keep the term back.
But I don't think it's been a problem. In the domain of chat, it really is only otherwise a "group of people":
By "too general a term" I simply meant that since what we need here is a grouping term, settling for "group" is kind of ... the trivial solution. I think a more specific grouping term, if there is one, would be advantageous.
Well, you don't really need the exclamation point then, you're already shouting -- nobody says "there's a GROUP of people doing ...". But to your main counter, groups of people actually come up a lot in chat, so why muddy the waters if we can reasonably avoid it?
Of course! And "chunk of values", also works fine for that case, as does "block of values". But for when it's going to be evaluated, it may could be more helpful to have a better name. Think about "there's (chunks of) code in that path" versus "there's (groups of) values in that path".
In my book chunk is the only acceptable word from this list.
If it had come up in the original discussion, I might have voted for it. But now, I'm just not sure it's worth the hassle.
Well, I am cheered by whatever support you can provide @IngoHohmann ... I too am sorry I did not think of it back then. And yes, it may indeed be too late to be worth it.
One more thing, there's fundamental difference between block and group, inert vs active. So while a group of code sounds suboptimal, in actual conversation it will much more often be: put it in a group. And here group wins against chunk and all others mentioned.
Okay. But note that "group" as a verb is a grouping term. So I'd argue people would want to say "group it" or "group it up" not "put it in a group", and in that case "chunk it"/"chunk it up" work even better.
As mentioned above, I'm sympathetic to the desire to create new terms for new things. And I fret over details like BLANK! and BLOCK! both being five characters and starting with B and ending with K.
Despite my sensitivities, nothing that seems to be triggering concern for you over GROUP! is triggering any concerns for me--I've used it and like it quite a lot. It is meaningful and effective enough for this purpose, and I've had zero problems with its name colliding with any other intent.
But as mentioned, I've found a lot of other things that are problems, which if you want to put your naming attentions on please...do. PATH! is a very real one, and NewPath needs a lot of design thinking. I think PATH! is the right name, but the question is how to mitigate its collisions with file system paths and name functions that intend to be working with them and translating them to FILE!, and what is a file (many people are going to be confused that FILE! is actually FILENAME!, how to reconcile that? Where's the philosophy document on how to name functions that work with files or paths?)
So any brain cycles that could be spent on that would be time worth spending.
