Slices of collections are themselves places, and they can be decomposed further into even finer places. In Common Lisp the subseq function describes such places: (setf (subseq coll start end) slice). Injective functions have an in degree regularity of one, which means that they are trivial place forms. As such, the original programming idiom can be described as a process that moves an object to a place, runs some functions, and then moves back to the starting place.
@a = (10, 5, 9, 6, 20, 17, 1);
@slice = @a[0, 1, 3, 6];
@state[1,2,3,5,6,7,9,10,11,13,14,15] =
@state[5,10,15,9,14,3,13,2,7,1,6,11];
@a = (10, 5, 9, 6, 17, 1);
@a[3,5,1] = qw(yes no maybe);
print "@a";
>> "10 maybe 9 yes 17 no"
@a = (10, 5, 9, 6, 17, 1);
@a[0,4] = @a[4,0];
print "@a";
>> "17, 5, 9, 6, 10, 1"; @array[@indices]
%hash = (foo => "bar", one => "two", alpha => "beta");
@keys = ('alpha', 'one');
@hash{@keys} == ('beta', 'two'); a = [10 5 9 6 20 7];
slice = a([1 2 4 7]);
Too bad it's wicked expensive, proprietary and slow. I quite enjoy the paradigm.
# perl -e "print join ' ', (10,5,9,6,20,17,1)[0,1,3,6]"
10 5 6 1
(map [1 2 3 4 5 6 7 8 9 10] [0 3 4])
=> (1 4 5)(pmap [1 2 3 4 5 6 7 8 9 10] [0 3 4])
instead? pmap being defined as "Like map, except f is applied in parallel" [1]
That said, I'm too ignorant to understand the deeper benefits of the parallel approach. It seems it enables nifty things according to some other comments in this thread, yet I've been unable to understand quite why so far.
1: http://clojure.github.com/clojure/clojure.core-api.html#cloj...
pmap mentioned above probably has too much overhead for what you are thinking as it is intended for more coarse distribution of workload.
> 6 5 4 3 2 1 0 { 10 5 9 6 20 17 1
Stored in an array? Because if it is, when I do this:
> 2 3 4 5 6 { 10 5 9 6 20 17 1
Won't I have to rearrange the whole array? (deleting two of the index parts)
* It's now open-source at https://github.com/openj/core, but I have a hard time following their C style -- it's legal C, but written like J.
APLs have memory allocators that are designed with arrays in mind, making this less expensive than you might expect. See this post I wrote about the memory management for Kona (https://github.com/kevinlawler/kona/), an open-source implementation of K: https://groups.google.com/forum/#!topic/kona-dev/fs5GoSBtF3Y... .
I don't know J at all, but I'd assume that the result of the '{' is a _new_ array. All I've seen about J is very much rooted in mathematics and therefor I'd expect a functional/immutable language. Nothing would be 'deleted', no array changed/rearranged and a new array without the first two elements created/returned.
Note the fat 'no idea about J' disclaimer, of course.
[(10,5,9,6,20,17,1)[i] for i in (6,1,3,2,0,5,4)]It's one thing to say, "yeah, I can kinda do this in [language]", it's quite another when your whole language is based on it, as the APL family are. If you can do array slicing in parallel, you can work with permutation vectors rather than sorts (as he notes), and guess what? The same idiom works for relational joins, among many other things. (The killer app for Q, kdb+, is an in-memory, column oriented relational database. NoSQL, before it was cool.)
Maybe slightly late for that.
A different guy with the same deficiency: "Wrong, it's a common idiom in (list of obscure languages)".
Plus: array slicing, in 95% of the languages mentioned (and 99% of common languages) is NOT what he talks about. It just returns a sub-array and it only takes an uper/lower bound.
This is an idiom in a subculture you aren't a part of, in languages you do not speak. There are a lot of them. The author assumed that because J is not really a "mainstream language" that the people reading his blog would probably not be familiar with its idioms.