Re: [stack] disallowing recursive definitions

>  > 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,
>
>  why isn't a stream a list?

Well, if by "list" you mean "lazy linked list", Factor doesn't work
like that for input because it'd require memoizing past input values,
and it wouldn't flush output well. If you mean something else I don't
understand. As far as making input something you can iterate over with
"each", that's something I'm working on (though it won't extend to
map).
>
>  lower-to-upper case in k:
>
>  u:_ci@[!256;97+!26;-;32]
>  i:_ic"a99*bc"
>  u i
>  "A99*BC"
>
>  no loops, no recursion. depends on - being defined on arrays.
>
>  look, this is what i meant when i said that the power of the array
>  approach is not obvious -- it can't be "read off" the definitions of
>  the primitives. or if i didn't say that, that's what i meant. as
>  i *have* been trying to say for several years now is that with the
>  right set of primitives and datatypes, all sorts of non-obvious
>  solutions arise. that's why the k sudoku is so short (i think it's
>  down to 54 characters now.)

Umm, well, in the general Unicode case, there's some more complicated
table lookup involved, and a bunch of corner cases. My Factor
implementation is somewhat inelegant, and it'd be interesting to see
something in K like that. Your implementation could be written in
Factor as

: >upper ( string -- newstring )
    [ dup CHAR: a CHAR: z between? [ CHAR: A CHAR: a - + ] when ] map ;

These definitions have basically the same token count, so this example
doesn't present an advantage or disadvantage of K.

Dan