Re: [stack] disallowing recursive definitions

>  note that in f, there is only one "array primitive": in x=y, x and y
>  are either scalars or, if both are arrays, they must be arrays of the
>  same "shape" (a scalar is considered to be the same shape as any array.)
>
>  perhaps this a misunderstanding about the term "array primitive". in APL,
>  +, <, =, &c. are extended to arrays, but they are all scalar primitives,
>  i.e. they are defined on scalars. primitives like 'find' and 'where' are
>  array (or list) primitives: they take arrays as arguments and return arrays
>  or scalars as results.

You're right, there is some misunderstanding. What I was talking
about, and what Factor's missing, is the property of things like "+"
to denote both scalar and vector addition; how, in APL-based
languages, certain operators like +, =, <, etc are defined to map
their operation to atoms within vectors (assuming that shapes match).
Everything else can be fairly easily defined in the library with no
modifications to existing code, if it doesn't already exist. I might
be misunderstanding the nature of array languages, but here's my
problem with this: it creates a primitive, difficult-to-extend concept
of an array which isn't quite first-class as far as I can tell.

Anyway, I'm in the process of decoding the example given (since I
don't know Q) and translating it directly to Factor to see if adding
any idioms would be appropriate. Stevan, could you tell me what the
function f is supposed to take as an argument? Either way, when I find
myself writing explicit tail recursion (which is fairly but not
extremely rare in Factor) I often try to abstract it into a
combinator. When I make these abstractions, it's only because the
existing ones (the higher order functions like each, map and reduce
that Factor and APL basically share) can't express it. I can't imagine
a situation where the fact that + operates on vectors as well as
scalars would change whether I would have to write explicit tail
recursion.

I use tail recursion when I'm either (a) interfacing with non-arrays
that still have to be iterated over in some way, for example an I/O
stream (b) doing something weird that'd be awkward to express in terms
of the abstractions I know. So (a) would be hard to eliminate, and (b)
is more of a cause for concern. I encountered a lot of (b) cases in
implementing things like Unicode normalization and case conversion,
and in those cases I built some semi-general abstractions using tail
recursion. I wonder if some of these should be moved to a more
general-purpose library, but even if they should, that's not a case
for array primitives in the sense of + to be integrated deeply into
the language.

(Just for the record, it's very annoying that there are two languages
named Q, and the one relevant here has a very small online footprint,
and that in that small website, the maintainers can't be bothered to
type out "docs", instead calling the directory "d". Also, I just had a
sort of "whoa" moment when I realized that the same guy who came up
with the first good polynomial-time tree diffing algorithm is the same
guy who's doing all this K/Q stuff...)

Dan