# Literal expression for array of vectors
**URL:** https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184
**Category:** General Usage
**Tags:** question, array, syntax, vector
**Created:** [June 24, 2025, 8:39pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184 "2025-06-24T20:39:25Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [June 24, 2025, 8:39pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/1 "2025-06-24T20:39:25Z")
Is there an array literal that gives me this object (and a variation with some integer elements in some of the vectors)?
```julia-repl
julia> ...
3×5 Matrix{Vector{Int64}}:
[] [] [] [] []
[] [] [] [] []
[] [] [] [] []
```
My use case is writing unit tests where I expect a specific matrix of vectors as output, which I wanted to write literally. Of course I can construct the matrix step by step, but for small matrices, writing the literals makes the tests more readable in my opinion.
What I tried so far:
When I have a matrix of vectors, e.g.
```julia-repl
julia> m = [Int[] for _ in 1:3, _ in 1:5]
3×5 Matrix{Vector{Int64}}:
[] [] [] [] []
[] [] [] [] []
[] [] [] [] []
```
I can `@show` it, giving
```julia-repl
julia> @show m
m = [Int64[] Int64[] Int64[] Int64[] Int64[]; Int64[] Int64[] Int64[] Int64[] Int64[]; Int64[] Int64[] Int64[] Int64[] Int64[]]
```
However, pasting this literal back into the REPL, I get a different object:
```julia-repl
julia> new_m = [Int64[] Int64[] Int64[] Int64[] Int64[]; Int64[] Int64[] Int64[] Int64[] Int64[]; Int64[] Int64[] Int64[] Int64[] Int64[]]
0×5 Matrix{Int64}
```
I think I get what’s going on – the individual arrays in the literal are directly concatenated together to form a “flat” array instead of an array of vectors, like here:
```julia-repl
julia> [[1] [2] [3] [4]; [5] [6] [7] [8]]
2×4 Matrix{Int64}:
1 2 3 4
5 6 7 8
```
This (presumably?) is intended to make concatenating rows/columns into larger matrices more convenient, but I think it would be great if copy-pasting the expression from `@show` would give the correct object, like for many other objects. I tried different variations of the above literal to parse to a matrix of vectors, but so far without success.
Any help or pointers would be greatly appreciated! I feel like I’ve read something about this somewhere, but I couldn’t find it right now…
---
### Author:  [@mcabbott](https://discourse.julialang.org/u/mcabbott)
#### Post date: [June 24, 2025, 8:55pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/2 "2025-06-24T20:55:41Z")
You can reshape a vector of vectors:
```julia
julia> m = [Int[i+10j] for i in 1:3, j in 1:5];
julia> vec(m) |> println
[[11], [12], [13], [21], [22], [23], [31], [32], [33], [41], [42], [43], [51], [52], [53]]
julia> reshape([[11], [12], [13], [21], [22], [23], [31], [32], [33], [41], [42], [43], [51], [52], [53]], 3, 5)
3×5 Matrix{Vector{Int64}}:
[11] [21] [31] [41] [51]
[12] [22] [32] [42] [52]
[13] [23] [33] [43] [53]
```
> [@Sevi](#):
>
> intended to make concatenating rows/columns into larger matrices more convenient,
Yes. The syntax goes to `hvcat`, and this unfortunately makes assembling block matrices easy, and matrices of arrays hard. The syntax I wrote above is `Base.vect` which is not a concatenation function.
It’s arguably a bug that `println(m)` produces something which doesn’t parse back to the same.
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [June 24, 2025, 9:08pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/3 "2025-06-24T21:08:06Z")
> [@mcabbott](#):
>
> You can reshape a vector of vectors:
Right. That still requires one extra “mental step” to look at the flat vector and the dimensions and conclude that the resulting shape makes sense.
I think I am looking for some literal syntax that preserves the “visual shape” of the matrix. With `reshape` I can kind of make it work, but one has to take care about the right order of the dimensions (that’s exactly the extra mental step I wanted to avoid 😅 )
E.g. this is one of the matrices that I am actually testing in my code (the eltype is not relevant for this test):
```julia
5×2 Matrix{Vector{Any}}:
[1] [2]
[3] []
[] []
[] []
[4] []
```
This is how I would like to write it with reshape (to get visually similar to the REPL output):
```julia-repl
julia> reshape([
[1], [2],
[3], [],
[], [],
[], [],
[4], [],
], (5, 2))
5×2 Matrix{Vector{Any}}:
[1] []
[2] []
[3] []
[] [4]
[] []
```
But of course it’s not right, since the vector elements are parsed in column-major order. So I would need an additional transpose:
```julia-repl
julia> reshape([
[1], [2],
[3], [],
[], [],
[], [],
[4], [],
], (2, 5)) |> permutedims
5×2 Matrix{Vector{Any}}:
[1] [2]
[3] []
[] []
[] []
[4] []
```
This is kind of clunky, but probably good enough for me.
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [June 24, 2025, 9:10pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/4 "2025-06-24T21:10:06Z")
> [@mcabbott](#):
>
> It’s arguably a bug that `println(m)` produces something which doesn’t parse back to the same.
That’s what I thought, but if it turns out that having a parser with “concatenation of rows/columns is convenient” is just not compatible with “arrays of vectors are convenient”, then perhaps there is no way around this inconsistency?
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [June 24, 2025, 9:10pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/5 "2025-06-24T21:10:38Z")
It’s ridiculous, but you can wrap it in another layer of 1-element vectors to be `hvcat`-ed because it’s not recursive:
```julia
julia> [[Int64[1]] [Int64[]];
[Int64[]] [Int64[1]]]
2×2 Matrix{Vector{Int64}}:
[1] []
[] [1]
julia> [Int64[1] Int64[];
Int64[] Int64[1]]
ERROR: DimensionMismatch: mismatched height in block row 1 (expected 1, got 0)
```
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [June 24, 2025, 9:17pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/6 "2025-06-24T21:17:45Z")
Wow… I tried regular parentheses, but somehow nesting the vectors in another vector didn’t cross my mind. Thanks!
I’m not sure if it makes the test code more confusing in the end, but at least it’s an answer to my question 🙂
On the matter of `@show`, it would probably also too confusing if `@show` would print the nested output (?)
```julia-repl
julia> m = [[[1]] [Int64[]]; [[2]] [[3]]]
2×2 Matrix{Vector{Int64}}:
[1] []
[2] [3]
julia> @show m
# current behavior
m = [[1] Int64[]; [2] [3]]
# desired
m = [[[1]] [Int64[]]; [[2]] [[3]]]
```
---
### Author:  [@mcabbott](https://discourse.julialang.org/u/mcabbott)
#### Post date: [June 24, 2025, 9:18pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/7 "2025-06-24T21:18:01Z")
You can also print tuples instead of vectors:
```julia
julia> [(11,) (21,) (31,) (41,) (51,) # from Tuple.(m)
(12,) (22,) (32,) (42,) (52,)
(13,) (23,) (33,) (43,) (53, 54, 55) ] .|> collect
3×5 Matrix{Vector{Int64}}:
[11] [21] [31] [41] [51]
[12] [22] [32] [42] [52]
[13] [23] [33] [43] [53, 54, 55]
```
If they are all the same length, then writing a literal 3D array & slicing it might be another option:
```julia
julia> eachslice([11 12 13;;; 21 22 23;;; 31 32 33;;; 41 42 43;;; 51 52 53]; dims=(2,3))
3×5 Slices{Array{Int64, 3}, Tuple{Colon, Int64, Int64}, Tuple{Base.OneTo{Int64}, Base.OneTo{Int64}}, SubArray{Int64, 1, Array{Int64, 3}, Tuple{Base.Slice{Base.OneTo{Int64}}, Int64, Int64}, true}, 2}:
[11] [21] [31] [41] [51]
[12] [22] [32] [42] [52]
[13] [23] [33] [43] [53]
```
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [June 24, 2025, 9:24pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/8 "2025-06-24T21:24:14Z")
> [@Sevi](#):
>
> On the matter of `@show`, it would probably also too confusing if `@show` would print the nested output (?)
Yeah, the nicer matrix printout is `display`, and the one-liner `@show` uses `print`. They’re supposed to resemble each other, not how we’d write an array literal (or paste from a printout). There could be another `pastable_literal_expr` function, but I don’t know of one. It’s generally not always possible for a runtime value to produce an expression that can be parsed and evaluated to an equal value; for mutables, it’s trivially impossible to make an identical value.
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [June 24, 2025, 9:41pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/9 "2025-06-24T21:41:53Z")
> [@Benny](#):
>
> It’s generally not always possible for a runtime value to produce an expression that can be parsed and evaluated to an equal value; for mutables, it’s trivially impossible to make an identical value.
I understand. It’s just very convenient that `show` often _does_ give something that is more or less the same object (e.g for comparison with `==` and if it’s not a mutable struct field or so), and now I know that it would also be possible to print arrays of vectors in such a way that they could be parsed back to something `==` the original object.
So I was just wondering if there are any downsides of changing `show`/`print` for such arrays of arrays (other than that it might look confusing with the nested vectors)?
It would be a bit closer to what the docstring of `show` suggests:
```julia
The representation used by show generally includes Julia-specific formatting
and type information, and should be parseable Julia code when possible.
```
(Granted, the docstring doesn’t say _to what object_ the code should be parseable…)
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [June 25, 2025, 3:01am UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/10 "2025-06-25T03:01:39Z")
> [@Sevi](#):
>
> (Granted, the docstring doesn’t say _to what object_ the code should be parseable…)
Indeed, here’s another example with views:
```julia
julia> m = view(collect(1:10), 1:2:10)
5-element view(::Vector{Int64}, 1:2:9) with eltype Int64:
1
3
5
7
9
julia> show(m)
[1, 3, 5, 7, 9]
julia> m2 = eval(Meta.parse(repr(m))) # repr returns show's String
5-element Vector{Int64}:
1
3
5
7
9
julia> m == m2
true
julia> parent(m) == parent(m2) # the similarities don't go far
false
```
We just have to live with Julia-looking printouts we can’t expect to evaluate to an equivalent result.
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [June 25, 2025, 6:41am UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/11 "2025-06-25T06:41:55Z")
But the example above doesn’t parse to a real object at all (I guess it parses, but without the extra nesting the concatenation just doesn’t work):
```julia-repl
julia> @show m;
m = [[1] Int64[]; [2] [3]]
julia> m = [[1] Int64[]; [2] [3]]
ERROR: DimensionMismatch: mismatched height in block row 1 (expected 1, got 0)
```
My point is not whether we can get printouts to _always_ evaluate, but whether it’s possible in this particular case (matrix/array of vectors) to get closer to “consistent” printouts. I’m fine if this is something that not many people care about though. If I find some time I might open a separate question about this or look on Github for existing issues.
Thanks for the replies!
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [June 25, 2025, 9:19am UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/12 "2025-06-25T09:19:15Z")
> [@mcabbott](#):
>
> Yes. The syntax goes to `hvcat`, and this unfortunately makes assembling block matrices easy, and matrices of arrays hard. The syntax I wrote above is `Base.vect` which is not a concatenation function.
It’s kind of sad that `typed_hvcat` can’t figure out that elements of the output type shouldn’t be iterated over for concatenation. This is less than optimal:
```julia
julia> Vector{Int}[Int[1] Int[2]; Int[3] Int[4]]
ERROR: MethodError: Cannot `convert` an object of type Int64 to an object of type Vector{Int64}
The function `convert` exists, but no method is defined for this combination of argument types.
```
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [June 25, 2025, 1:06pm UTC](https://discourse.julialang.org/t/literal-expression-for-array-of-vectors/130184/13 "2025-06-25T13:06:12Z")
> [@Sevi](#):
>
> But the example above doesn’t parse to a real object at all (I guess it parses, but without the extra nesting the concatenation just doesn’t work)
The technically correct phrasing here is it parses to a valid Julia expression `:([[1] Int64[]; [2] [3]])`, but evaluating that expression makes `typed_hvcat` throw a `DimensionMismatch` error. “Parseable” is a lot less than we’d hope it means.
> [@GunnarFarneback](#):
>
> `typed_hvcat` can’t figure out that elements of the output type shouldn’t be iterated over for concatenation
My interpretation of concatenation is that it takes elements out of input arrays and puts them in a larger array e.g. `hcat([1], [2]) == [1 2]`, so opting out of iteration doesn’t sound like concatenation to begin with. I’d take a macro for array literals that opts out of concatenation though, just evaluates the expressions as written for elements in a multidimensional array e.g. `[1:3 2:4]` makes a `3×2 Matrix{Int64}` but `@nocat [1:3 2:4]` makes a `1×2 Matrix{UnitRange{Int64}}`. Hopefully it doesn’t add the overhead of instantiating a bunch of 1 element vectors to be concatenated.