Re: [stack] disallowing recursive definitions

>  my sense is that programmers (and language designers) *still* do not
> appreciate
>  the power of array programming. here's an example i posted the other day on
>  comp.lang.functional, a general sudoku solver written in q by arthur
> whitney.
>  for readability, i've replaced the case statement of q ($[x;y;z]) with
> if-then-
>  else pseudocode.
>
>  f:{if all x then enlist x else raze f each amend[x;i]each where 27=x[raze p
> i:x find 0]find til 10]}
>
>  note the explicit tail-recursion on 'f' in the else clause. also note that
> this is
>  the standard algorithm used in sudoku solvers written in java, python,
> ruby, ocaml,
>  &c. compression is achieved through the use of a handlful of array
> primitives
>  (til, find, raze, where, all), one iterator (each), a primitive for
> updating
>  positions of an array (amend), and a single primitive extended from scalars
> to
>  arrays (=).

I'm having a little trouble parsing this example. Do you think you
could translate this example to XY, or at least insert parens so it's
clear where the grouping is, and explain what 27=x... means? The
resistance of Factor to add array primitives comes from the idea
within the community that explicit, strongly typed array operations
are sufficient. (There are words like v* to multiply two sequences of
numbers.) Replacing v* with * is something that looks prettier but
doesn't directly add more functionality. Maybe there's someplace in
the middle, where functions like raze can be added without going to
full-blown array primitives. Another problem with array primitives is
that, generalized, they make arrays a little less first-class, but
this may be a misunderstanding on my part.

Thanks,

Dan