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