Alexander Mikhailov
> Is it reasonable to have boxing/unboxing operations to be done
> implicitly in the case like above
The short answer is you must do all boxing and unboxing explicitly. It is
possible for languages to hide this kind of detail [1], but J chooses not to
do this (for a variety of good reasons, mostly stemming from troublesome
experiences with APLs which did). The effect is that have a lot of control
over when and how to box and unboxing, and J provides you a rich suite of
tools for doing so.
These tools make the explicit boxing and unboxing pretty trivial and
comfortable (which is a stone's throw from "implicit"). For example,
] boxes =. 1 2 ; 3 4 5 6 ; 7 8 9 NB. Use link to partition
unlike things
+---+-------+-----+
|1 2|3 4 5 6|7 8 9|
+---+-------+-----+
; boxes NB. Use link's brother, raze, to combine unlike lengths
1 2 3 4 5 6 7 8 9
> boxes NB. Or make a rectangular array out of them by filling
1 2 0 0
3 4 5 6
7 8 9 0
12 +&.> boxes NB. Open each box, process identically, then
close the box
+-----+-----------+--------+
|13 14|15 16 17 18|19 20 21|
+-----+-----------+--------+
12 +&> boxes NB. Open each box, process identically, remove
contents
13 14 0 0
15 16 17 18
19 20 21 0
NB. Use L: and S: to process deeply and heterogenously nested
boxes or process trees
] deep =. (<3;<4;<<<5 6 7)
+-----------------+
|+-+-------------+|
||3|+-+---------+||
|| ||4|+-------+|||
|| || ||+-----+||||
|| || |||5 6 7|||||
|| || ||+-----+||||
|| || |+-------+|||
|| |+-+---------+||
|+-+-------------+|
+-----------------+
]deep2 =. 17 +L:0 deep
+----------------------+
|+--+-----------------+|
||20|+--+------------+||
|| ||21|+----------+|||
|| || ||+--------+||||
|| || |||22 23 24|||||
|| || ||+--------+||||
|| || |+----------+|||
|| |+--+------------+||
|+--+-----------------+|
+----------------------+
deep +L:0 deep2
+----------------------+
|+--+-----------------+|
||23|+--+------------+||
|| ||25|+----------+|||
|| || ||+--------+||||
|| || |||27 29 31|||||
|| || ||+--------+||||
|| || |+----------+|||
|| |+--+------------+||
|+--+-----------------+|
+----------------------+
deep +S:0 deep2 NB. S: is like L: but removes all the boxes
(viz &.> vs & >)
23 0 0
25 0 0
27 29 31
{:: deep NB. MAp the depths
+----------------------------+
|+----+---------------------+|
||++-+|+------+------------+||
||||0|||++-+-+|+----------+|||
||++-+||||1|0|||+--------+||||
|| ||++-+-+|||++-+-+++|||||
|| || |||||1|1||||||||
|| || |||++-+-+++|||||
|| || ||+--------+||||
|| || |+----------+|||
|| |+------+------------+||
|+----+---------------------+|
+----------------------------+
('';1;1;'';'') {:: deep NB. Fetch the treasure using our map
5 6 7
|.@:($:&.>)`...@.(1=L.) {:: deep NB. Keep on digging until we can
see rock bottom
+----------------------------+
|+---------------------+----+|
||+------------+------+|++-+||
|||+----------+|++-+-+||||0|||
||||+--------+||||1|0|||++-+||
|||||++-+-+++|||++-+-+|| ||
|||||||1|1|||||| || ||
|||||++-+-+++||| || ||
||||+--------+|| || ||
|||+----------+| || ||
||+------------+------+| ||
|+---------------------+----+|
+----------------------------+
etc. Futhermore, lots of primitives produce or consume boxes natively (e.g.
;: as a producer and |: as a consumer, and C. as both), both because
of their homogenizing properties and because a box is a different "type",
which value-processing code can detect and treat differently (viz ^:a: and
[2]). That's one reason gerunds are boxes (and several primitives define
useful behavior for gerundial arguments).
Once you get more familiar with J, you'll start seeing the value in explicit
boxing (and you'll also find your need for boxes decrease as you start
thinking in [rectangular] arrays).
-Dan
[1] You're probably familiar with languages like VB with "autoboxing", and
the "Variant" datatype, which can wrap any type (like J's box), and which
furthermore is implied if no type is given (and I think most or all native
functions can accept Variants?). Or C with its non-commital void* .
But did you know some old APLs also had a form of "implied boxing"? For
example, they permitted strand notation, so that 1 2 3 'hi there' ('a' 2 3
(function 2)) 17 was like 1 2 3 ; 'hi there' ; (< 'a' ; 2 3 ; (<function
2)) ; 17 in J? Furthermore, they had "pervasive" operations, so that 3 +
<<<<<3 4 5 would act like 3 +L:0 <<<<<3 4 5 and result in <<<<<6 7 8
. I also believe (but don't know) that these APLs only boxed where they
"needed" to, automatically, so that for example it wasn't possible to box a
scalar (the reasoning being that the fundamental cell of an array is a
scalar, and if you want to make an item part of an array all you have to do
is make it a scalar, which is what boxing is for, so boxing scalars seemed
redundant).
[2] Roger notes boxes would allow an otherwise incompatible extension and
if he had his druthers he'd change some other primitives to accept boxes as
well:
http://www.jsoftware.com/pipermail/programming/2009-December/017317.html .
This is analogous to how |: admits boxes to distinguish "special"
arguments while still having a useful rank and doing the right thing for
"normal" (unboxed) arguments.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
