[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).