*Are you implying that array slice make lists and arrays don't?*

*Yes.*

How do you reconcile that with the fact that both the array and the array slice perform exactly the same action in list context: they put their members on the stack. Either they both make a list or neither does.

*Following that model, in: $r = ($a, $b) = 0..11 ; the right-hand assignment: ($a, $b) = 0..11 happens first, so we get ($a=0, $b=1), then ***that** is assigned to $r.... leaving to one side whether ($a, $b) is or isn't a list (given that for the right-hand assignment there's List Context, and in the left-hand one Scalar Context).... since the result is $r=12, right-associativity doesn't appear to be the whole story.

I bolded the mistake.
Just like the right-hand `**` doesn't return `3` in `2**3**4`, The right-hand assignment doesn't return `($a, $b)` in `$r = ($a, $b) = 0..11`. A list assignment in scalar context returns the number of items it was given to assign. 12, in this case.

`>perl -le"print( scalar( ($a, $b) = 0..11 ) );"
12
`

*Just for a moment, let's consider integers and floats as two different sorts of value. Now, '%' is an integer operation -- one could say it has "Integer Context" -- and the floating point argument is implicitly coerced to an integer, suitable for the '%' operation. At least that is a common understanding of what happens.*

There are two different sort of value. Three even.

NVs hold floats (which could technically be integers, but not relevant).

IVs hold machine signed integers.

UVs hold machine unsigned integers.

I wouldn't say it has integer context, because that would imply a parallel with scalar vs list context. Scalar and list context force operands to returns a scalar and a list respectively. Integer coercion doesn't force operands to returns an integer.

Let's look at an example. Given `f() % 3`, `f()` is executed in scalar context and in "integer context".

Scalar Context | Integer Coercion |

The scalar context will force `f()` to return a scalar. |
The integer conversion doesn't force `f()` to return an integer. |

`f()` is unable to return a list. |
`f()` is free to return undef, a string, a reference, a float, etc. |

`%` never converts a list to a scalar. |
The conversion to integer is performed by `%`. |

The scalar context is forced onto the operands before they are evaluated. |
The integer coercion is performed on the operands after they are evaluated. |

Your argument relies on the premise of a parallel between scalar context and integer coercion, but it's very clear there isn't one. The premise is false, so the argument is moot.

This isn't relevant, but I thought you'd be interested in an additional difference: some operators (such `|`, `&` and `^`) behave differently based on whether they're given a string or an integer. Some operators behave differently based on the length of the list they are given, but you won't find an operator that can accept both a scalar and a list.

**Update**: Formatting changes. Minor typo correction.

Comment onRe^5: If you believe in Lists in Scalar Context, Clap your HandsSelectorDownloadCode