One can make up a set of, perhaps arbitrary, rules, and apply them consistently only to end up with something unintelligible and difficult to use. Enclose "turns into a scalar" rather than enclose "adds a level of boxing" is the perfect example.
I programmed in APL for five years. Not having access to APL2, I wrote my own equivalent of boxing and unboxing functions in plain APL that were very, very useful. I'm sure my functions were slow. I was looking forward to native and fast support for the same capabilities. If I can find APL2 idioms to do the same thing (simple and uniform boxing and unboxing) as I asked in my previous email to Jürgen, I would be happy indeed. Thanks. Blake On Mon, May 12, 2014 at 10:46 AM, Elias Mårtenson <[email protected]> wrote: > My experience is only 29 years, sadly. With only a few months of APL. > > That said, there are certainly lots of things in APL that I would like to > improve and change. I want to understand the design decisions first before > I criticise them. > > All I've been trying to do is to explain my understanding of how things > work. I found it confusing at worst, but it kind of makes sense. It kinda > "clicked" for me when I understood that scalars are essentially atomic > values without dimension, which is why enclosing them results in the value > itself. > > That said, a "scalarified" array (i.e. the result of ⊂'foo') *can* be > wrapped inside another layer of enclosing. That's pretty stupid in my > opinion. The only explanation I have for that one is the desire to preserve > the X≡⊃⊂X invariance. > > Regards, > Elias > > > On 12 May 2014 23:37, Blake McBride <[email protected]> wrote: > >> Having 35 years programming experience, it is my opinion that languages >> should work to maximize human's expressiveness rather than the other way >> around. >> >> Blake >> >> >> >> On Mon, May 12, 2014 at 10:34 AM, Elias Mårtenson <[email protected]>wrote: >> >>> Well, I would argue that you are trying to solve a non-existent problem. >>> If you look at all the existing APL functions, none of them behave in the >>> way you are attempting to create. It could be argued that it would make >>> more sense to not try to be too smart about this and instead let the >>> developer decide how to feed the input to the function. >>> >>> In other words, if the users wants to pass in a string as a single >>> object, he would use the enclose function to make it so, just like one >>> would have to do with, say, the ∊ function. >>> >>> I find the APL2 documentation formulates it very succinctly: >>> >>> *Z←⊂R* >>> * Creates a scalar array whose only item is R.* >>> >>> Regards, >>> Elias >>> >>> >>> On 12 May 2014 23:28, Blake McBride <[email protected]> wrote: >>> >>>> Dear Elias, >>>> >>>> Having many years of APL (not APL2) under my belt, I understand and >>>> appreciate the difference between a scalar (zero dimension array) and >>>> a vector (one dimension array) - (both arrays). >>>> >>>> I started to solve the problem with ravel as you suggest, but there are >>>> two problems with it. First, you must be careful not to ravel a matrix or >>>> higher dimension array - only a scalar, i.e. ravel is not a general >>>> solution. Second, discovering the wacky behavior of disclose this morning >>>> makes the fight for rationality and consistency with respect to nested >>>> arrays ongoing. >>>> >>>> I am not arguing that the original APL (with respect to the difference >>>> between scalars and vectors) is inconsistent. I am arguing that, if >>>> enclose and disclose, acted to simply add and remove layers of boxing, all >>>> would work without the never ending fight that appears to be the case. >>>> >>>> Thanks. >>>> >>>> Blake >>>> >>>> >>>> >>>> On Mon, May 12, 2014 at 10:18 AM, Elias Mårtenson <[email protected]>wrote: >>>> >>>>> Blake, >>>>> >>>>> APL is actually quite consistent. What you are complaining about is >>>>> the fact that the *parser* interprets 'x' as a character, as opposed >>>>> to a one-character string. I agree this can be confusing. >>>>> >>>>> It's all a syntax thing, once your text has been read into the >>>>> interpreter, characters vs. strings are completely consistent. To work >>>>> around this inconsistency there is really only a single rule to keep in >>>>> mind: >>>>> >>>>> *When specifying a one-character string in source, type ,'x' >>>>> instead of 'x'* >>>>> >>>>> That's really all there is to it. Again, once your text has been >>>>> processed, APL itself is consistent. >>>>> >>>>> Personally, I'd have preferred to have 'x' result in a string and >>>>> some other syntax, say #\x like in Lisp, or something like that. >>>>> >>>>> Regards, >>>>> Elias >>>>> >>>>> >>>>> On 12 May 2014 23:11, Blake McBride <[email protected]> wrote: >>>>> >>>>>> '333' '55555' is shorthand for (⊂'333'), ⊂'55555' and would give you >>>>>> what it does now (presuming neither is a scalar!!) >>>>>> >>>>>> ⊃'333' '55555' would be meaningless because you'd end up with two >>>>>> independent values. APL deals with one at a time. >>>>>> >>>>>> You could do: ⊃('333' '55555')[1] to give '333' >>>>>> >>>>>> Perhaps something like (a b)←⊃'333' '55555' might make sense. >>>>>> >>>>>> APL is not valuable because every imaginable sequence produces some >>>>>> non-error. I had a simple problem which would have been trivial to solve >>>>>> if nested arrays worked in a straight forward way. I believe you were >>>>>> the >>>>>> person that pointed out that: >>>>>> >>>>>> '22' '22' >>>>>> '333 '333' >>>>>> '4444' '4444' >>>>>> '55555' '55555' >>>>>> '22' 5 5⍴⍳25 >>>>>> >>>>>> are all treated in a consistent fashion, but: >>>>>> >>>>>> '1' '1' >>>>>> >>>>>> is treated differently. That means, in order to get consistent >>>>>> behavior, one has to have special case code all over the place. Look at >>>>>> all the gyrations David was going through trying to make it work >>>>>> consistently. >>>>>> >>>>>> Perhaps there is some logic behind how it works. It is just >>>>>> impossible to work with in straight forward cases, and wherever their >>>>>> logic >>>>>> applies is beyond my ability to comprehend. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Blake >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, May 12, 2014 at 9:50 AM, Elias Mårtenson >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> The only way to make it more consistent is to make behaviours that >>>>>>> today are allowed into an error. >>>>>>> >>>>>>> What would you expect ⊃'333' '55555' to do? >>>>>>> >>>>>>> Regards, >>>>>>> Elias >>>>>>> >>>>>>> >>>>>>> On 12 May 2014 22:43, Blake McBride <[email protected]> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 12, 2014 at 5:08 AM, Jay Foad <[email protected]>wrote: >>>>>>>> >>>>>>>>> APL2's Disclose (Dyalog calls it Mix) will convert a vector of >>>>>>>>> vectors >>>>>>>>> into a matrix: >>>>>>>>> >>>>>>>>> ⊃'timor' 'mortis' >>>>>>>>> ┌→─────┐ >>>>>>>>> ↓timor │ >>>>>>>>> │mortis│ >>>>>>>>> └──────┘ >>>>>>>>> >>>>>>>>> Your second application of Disclose is applied to a 1-vector of >>>>>>>>> 1-vectors (,⊂,7), so it returns a 1x1 matrix. >>>>>>>>> >>>>>>>>> Jay. >>>>>>>>> >>>>>>>>> On 12 May 2014 06:03, Blake McBride <[email protected]> wrote: >>>>>>>>> > ⊃⊃⊂,⊂,7 >>>>>>>>> > ┌→┐ >>>>>>>>> > ↓7│ >>>>>>>>> > └─┘ >>>>>>>>> > ⍴⊃⊃⊂,⊂,7 >>>>>>>>> > ┌→──┐ >>>>>>>>> > │1 1│ >>>>>>>>> > └───┘ >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
