ANY-ARRAY! vs. ANY-LIST! ... any-final-thoughts?

Development Naming
1

Historical Rebol said that BLOCK!s and PAREN!s and ANY-PATH!s were all members of the ANY-BLOCK! category.

Red maintained that:

red>> any-block!
== make typeset! [block! paren! path! lit-path! set-path! get-path! hash!]

But broke out the BLOCK! and PAREN! (and HASH!) to a new group, ANY-LIST!

red>> any-list!
== make typeset! [block! paren! hash!]

Ren-C has sound reasons for having eliminated the idea of "sameness" for PATH!s(/TUPLE!s) and arrays, due to radically different constraints and properties. (Forced immutability, limited set of legal elements, requirement of having at least 2 items)

Ren-C's ANY-BLOCK! actually means any block, giving you [plain blocks], [set blocks]:, :[get blocks], and @[whatever these are]. Similarly for ANY-GROUP!. More appropriate, clear, and vastly more flexible.

But Red's ANY-LIST! category is the spiritual analogue to what Ren-C calls ANY-ARRAY!...which is to say "ANY-BLOCK! or ANY-GROUP!"

Which is Better, ANY-LIST! or ANY-ARRAY! ?

The conventional wisdom we've gone with is that to a computer programmer, if you call something a LIST! they might expect it to be a linked list at an implementation level. Rebol's implementation of these values is fundamentally an indexed array.

But other choices have been made biased toward common language and away from comp-sci terms. What would you imagine sounds better in a tutorial:

Let's imagine you have two lists of values. But one is a GROUP! and another is a BLOCK!

 group: '(<a> #b %c)
 block: [<a> #b %c]

vs.

Let's imagine you have two arrays of values. But one is a GROUP! and another is a BLOCK!

 group: '(<a> #b %c)
 block: [<a> #b %c]

When I imagine the various things that might make new programmers feel a twinge, that "array" word causes a teeny bit more anxiety. Which might mean that you'd use the "list" language. But if you're going to use the list language, then it would help if it matched what the types were.

I'll point out that at the superclass level, even though TEXT! has replaced STRING! in Ren-C (which I'm pleased with), it's a member of ANY-STRING! along with TAG! and friends. The category isn't used as often.

It's a really minor point. But what I worry over here is that Red's choice might have an edge, and I don't want to give them any advantages, anywhere. :slight_smile:

I don't think I want to change it, though I'd like to collect up any good certain reasoning as to why not. The best "why not" remains being faithful to a computer-science technical reality about the type that over the long run, is worth knowing...which is what earl pushed for in this case, over the more common English word.

Any other arguments I should know about?

2

Not sure it will help much, but in English, "array" infers (at least, and most commonly exactly) two-dimensionality. Because of the newline-preserving property, I have always seen the block-likes as arrays, and never as lists, which are one-dimensional only (and your code needs to be rewritten if a non-nested list wraps around :slight_smile:). It is too bad that most examples, for obvious conciseness reasons, use no newlines.

2 Likes
3

I wouldn't say I've had any association of that. But your point is taken that the existence of the newline markers kind of throw a bit of a distinction onto what the type is.

While I was hesitant to suggest the dialect usage of newlines, I've kind of changed my thinking on that... inspired by cases like the tuple and path test dialect:

"(a b)/c"  ->  [@(a b) c]
"(a b) /c"  ->  @(a b)  [_ c]

Being able to leave off a container there just to have a variable number of things on the right felt good. So I started wondering about what kind of signaling you would use in a dialect to say "continued on next line"

With .. and ... being a valid TUPLE!, they aren't necessarily bad options, if they're out of band from whatever your values are:

"(a b)/c"  ->  [@(a b) c]
"(a b) /c"  ->  @(a b)
                ... [_ c]

Back to your point though: it's an odd type. That oddity may speak to favoring what might be for some people a more unfamiliar term, vs. trying to mask it in something they'd presume to be dimensionless.

4

For me the distinction between list and array is more about they are used, not the internal implementation.

Which doesn't help at all in this case, because it seems to me that blocks are mostly built like lists (append, insert), and accessed like arrays (by index).

2 Likes
5

For me a list is text items and array number items.
I'll put more thinking about the difference between list and array on my to do array.