Re: [stack] array theory question

this was a hot topic in the 70s, during which time several 
vendors proposed different extensions to the APL\360 type
system.  in boxed or grounded array systems, enclosure of an
atom (a "simple scalar" of depth 0) has depth 1.  in nested
or floating or ungrounded array systems, enclosure of an
atom is a no op.  Sharp APL and J are boxed systems, IBM's
APL2 and STSC's Nested Arrays are floating systems.  

the most immediate effect of grounded vs. ungrounded systems
is that in the latter, but not the former, a simple scalar
can be an element of a nested array.  e.g. where <x is the
enclosure of x

    (<1 2 3;4)

is possible in APL2, but not in Sharp APL, which requires

    (<1 2 3;<4)

K is grounded, but strictly speaking has lists and not arrays.
K can have

    (1 2 3;4)

also see trenchard more's work on array theory:

http://domino.research.ibm.com/tchjr/journalindex.nsf/0/415fa6b9fe085ed785256bfa0068419d?OpenDocument


----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: "concatenative" <[email protected]>
Sent: Monday, December 22, 2008 6:32 PM
Subject: [stack] array theory question


>I know some of your here are familiar with APL, Nail, etc, so I  
> thought I'd ask.
> 
> My question is this: Am I correct in thinking that single element  
> arrays in Nial (and I believe also APL2) are equivalent to their  
> contents? In other words, does {42} == 42? Also, does anyone know  
> anything about the history of this question as it pertains to APL?  
> Thanks in advance.
> 
> The rest of this email is confusing, but I left it in anyway. It may  
> help explain why I'm interested in the question of {x} == x.
> 
> - - -
> 
> The reason I ask is that this has implications for the "constructive"  
> language I recently mentioned. There seem to be five ways of passing N  
> arguments to a function:
> 
> 1. Use curried functions (not an option here)
> 2. Pass tuples when N > 1 (what I proposed previously, but has  
> limitations)
> 3. Pass null-terminated lists when N > 1 (the approach of FP)
> 4. Pass null-terminated lists (stacks) in all cases (the concatenative  
> approach)
> 5. Pass arrays in the style of Trenchard More's array theory (as in  
> Nial, possibly APL2)
> 
> The first option (currying) is out because there's just no way I can  
> see to combine such an approach with pointfree programming without  
> making it horribly painful (like it is in Haskell).
> 
> The second approach (tuples) seems to have annoying limitations,  
> although its simplicity is appealing.
> 
> The third approach (lists) is nicer than using tuples but it is still  
> impossible to write a generic function that does partial application.  
> The reason is that when partially applying to a function that takes  
> two values, you need the resulting function to enlist the second  
> argument passed to it before consing on the first. If the function  
> takes three values however, you do not need to enlist because a list  
> is already being passed in and you can just cons on the partially  
> applied value and then apply as normal. I hope that makes sense...
> 
> The fourth approach is out because it makes the form of "construction"  
> useless: If everything takes and returns a stack, then using  
> construction will always result in a stack of stacks. For example,  
> '[sq, sq] 5' would return '[[25][25]]'. Getting at the values  
> afterwards is a huge pain.
> 
> The fifth approach has the benefits of the third but also allows  
> partial application. If we decide that {x} == x, then we can have  
> generic partial application because it will "automatically" enlist the  
> object passed to the function resulting from the partial application  
> if necessary. This sort of auto-enlisting also makes it much easier to  
> generalize scalar operations to arrays (i.e. we can view a function  
> like 'square' as one that operates on all elements of an array, but  
> since the single element array is the same as the element it contains,  
> we can also pass it scalar values).
>