Thanks. I have to say, with no reflection on
present company, I am about as frustrated and disgusted with
nested arrays, as defined by IBM, as I could be. Having
enclose do one thing for all arrays and another for scalars has
caused me endless hours of frustration. (Isn't a scalar just a
zero dimension array?) How much time has one to spend making
enclose do what comes naturally to ones mind? Now I find that
disclose actually modifies data beyond the ability to
reconstruct it. In your example, if one string were a different
length than the other, APL will lengthen it to match the longest
upon disclose. The original length of each string is lost
forever. Why stop there? Why not change a 4 to a 7?
Having enclose and disclose uniformly add and remove layers
of boxing only is simple, consistent, predictable, useful, and
easy to understand. If I add 3 and then subtract 3 I end up
with the same number. But if I enclose and then disclose, I
end up with something different - sometimes. Imagine that!
'333' '55555'
┌→────────────┐
│┌→──┐ ┌→────┐│
││333│ │55555││
│└───┘ └─────┘│
└∊────────────┘
⊃'333' '55555'
┌→────┐
↓333 │
│55555│
└─────┘
(⊃'333'
'55555')[1;]
┌→────┐
│333 │
└─────┘
⍴(⊃'333'
'55555')[1;]
┌→┐
│5│
└─┘
There are ways to rationalize almost anything. IMO, the
IBM nested array approach is confusing, unpredictable, and
renders it a tool of very careful last resort.
I know there has been debate about this in the past, and
I am not looking to resurrect it. It is a real shame IBM
chose the path it chose.
Blake