[stack] array theory question

John Nowak <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
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).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.