The problem

Look at this snippet:

it=get(bd=block_data(b), 'Items[]'))

Dependent upon how many items are in the block tile, the following code will return either

1. null,
2. [{item1...},{item2...}]
3. {item1}

This is annoying, because the result cannot be passed to map(), filter() and so on directly, without doing some extra fluff code to check type and retype.

The null is reasonable, however, the case 3: {item1} is questionable.

Ideas for fixes

Make get(b, 'Items[]') always return a list, even if it's a 1-item list.

This is in my opinion the correct behavior and the correct bugfix.

I have been told that this behavior of demoting 1-item lists to scalars is inherited from Vanilla data queries. Still this appears inconsistent/puzzling/annoying.

Make map and similar functions accept scalars as input

map({item1}, ...) would then be equivalent to map([{item1}], ...). There is some concerns regarding loosening the typing of the language. I don't think type checking is critical in Scarpet, but one may think otherwise and make a convincing argument.

Do nothing

With no changes to Scarpet, the case can be handled with the following snippet:

if(null != (it=get(bd=block_data(b), 'Items[]')), if(!has(it, 0), it=l(it)); map(it, ...)
(I have been told that type() could also work here).

It is not nice or logical, but it works just fine.

Duplicate issue

I have been told that this is a preferable place to file this issue, compared to the scarpet repo. Feel free to close whichever is a duplicate w.r.t. gnembon/scarpet#185

I get that. Currently scarpet is just passing the query path to the vanilla parser, and that's what happens with vanilla code. But that bothered me for a very long time as well, it adds one unnecessary line to the code (if(type(result)!='list', result = [result]);).

We could be checking if the path ends with [] and convert to singleton in case that happens. loop functions working on scalars seems like a bad idea.

I know it's a bit late, but opinions on #820? (it resolves this)