On Feb 24, 12:56 pm, Jimmy Miller <CaptainThun...@[EMAIL PROTECTED]
> wrote:
> On Feb 24, 5:50 am, Jane Sullivan <j...@[EMAIL PROTECTED]
>
> wrote:
>
>
>
> > In message
> > <cc9b9b01-dd94-40a8-b311-94373dcb5...@[EMAIL PROTECTED]
>,
> > Jimmy Miller <CaptainThun...@[EMAIL PROTECTED]
> writes
>
> > >On Feb 5, 12:29 pm, gavino <gavcom...@[EMAIL PROTECTED]
> wrote:
> > >> is anyone even working on one?
>
> > >I'm working on a BSD APL interpreter that I hope to run on a variety
> > >of platforms (it's written in Java, but it does use a Swing GUI for
> > >rendering APL characters, so that may damper ****tability). It won't
> > >be completely standards conformant (no workspaces, just Unicode text
> > >files), but it will offer a few language extensions (e.g, nested
> > >arrays).
>
> > When you say "nested arrays", will they be
> > - nested arrays (enclose of a scalar is identical to the scalar)
> > - boxed arrays (enclose of a scalar is not identical to the scalar)
>
> > This difference is quite im****tant.
> > --
> > Jane Sullivan
>
> I do intend to have actual nested arrays, not the boxed arrays that
> are found in J.
On Feb 24, 12:56 pm, Jimmy Miller <CaptainThun...@[EMAIL PROTECTED]
> wrote:
> On Feb 24, 5:50 am, Jane Sullivan <j...@[EMAIL PROTECTED]
>
> wrote:
>
>
>
> > In message
> > <cc9b9b01-dd94-40a8-b311-94373dcb5...@[EMAIL PROTECTED]
>,
> > Jimmy Miller <CaptainThun...@[EMAIL PROTECTED]
> writes
>
> > >On Feb 5, 12:29 pm, gavino <gavcom...@[EMAIL PROTECTED]
> wrote:
> > >> is anyone even working on one?
>
> > >I'm working on a BSD APL interpreter that I hope to run on a variety
> > >of platforms (it's written in Java, but it does use a Swing GUI for
> > >rendering APL characters, so that may damper ****tability). It won't
> > >be completely standards conformant (no workspaces, just Unicode text
> > >files), but it will offer a few language extensions (e.g, nested
> > >arrays).
>
> > When you say "nested arrays", will they be
> > - nested arrays (enclose of a scalar is identical to the scalar)
> > - boxed arrays (enclose of a scalar is not identical to the scalar)
>
> > This difference is quite im****tant.
> > --
> > Jane Sullivan
>
> I do intend to have actual nested arrays, not the boxed arrays that
> are found in J.
http://delivery.acm.org/10.1145/100000/97842/p161-girardot.pdf?key1=97842&key2=9073683021&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=6184618
Arrays And References
Jean-Jacques Glrardot
Ecole des Mines
158 Cows Fauriel
42023 Saint-Etienne C6dex, France
girar&t@[EMAIL PROTECTED]
fr
Abstract
Generalized arrays in APL have been for long a very
controversial subject. Since we are now taking the redaction
of an extended standard for APL, it seems legitimate to recpen the
old debate.
An analysis of both nested and boxed array systans, in the
light of a new development in APL which consists of the
introduction of a new data-type in the language, shows the interest
of having both systems with their own specificities.
1 INTRODUCTION
The problem of generalized arrays has been for long
a very controversiaml atter. In the past ten years,t wo
different systems of generalized arrays, Grounded
Arrays and Floating Arrays, that are currently called
Boxed Arrays, or BA, and Nested Arrays, or NA, have
progressivelye merged.
An immediate and negative effect of having two
different array systems is that a program written for
one system is very unlikely to operate under the
other. Implications of both systems have been
thoroughly examined by many experts in the domain.
Although everybody has tried to reach a consensus,
and certainly, every user has hoped that such a
consensus be reached,we are now faced with many
different extended APL systems, such as Sharp APL,
SAX, APL*PLUS Unix, APL2, Vax APL, Dyalog
APL, APL90, and probably a few others.
All these
permission to CoPy WithOUt fee all or part of this material is granted
provided that
the coPI am not made or distributed for direct commercial advantage,
the ACM
CoPyright n&x and the tile of the publication and its date appear, and
notice
is given that copying Is by permssion of the Association for Computing
Machinery. To cow otherwise. or to republish, requires a fee and/or
specific
permission.
l 1990 ACM 099791-371+/90/M09/0161..,$1.w
APL QUOTE QUAD 161
extended APL systems differ on many points, but
each can be classified as a representative of one or
the other array system. We won't discuss about the
many details that render these systems incompatible,
but about the more fundamental point of these array
systems.
The reasons why it seems to me useful and
necessaryto reopent he old debate are multiple :
l We have now gained experience in using both
array systems. The old argument that "it is too
early to discuss these things" is turning to "it's
now or never".
l We are faced with the problem of defining an
extended standard of APL. Although the
committee currently working on the extended
APL standard has carefully tried to avoid the
subject, by postponing any decision to a future
do***ent, this standard will have of course to
include the notion of generalized arrays.
The subject is quite serious, and is, I believe, of
concern of most people. For example, in A survival
strategyfor APL, [Bowman 871, one can read :
"...lhe faca d an IS0 auwiml existing is
justifiiott not for e work lmc satber to
advma on wital WC have. spccllically, lherc iuc
tectraicrl differences bctwecn APLs which need to
be a&erred, bolh quickly and eff&vely :
a) FiIing &ems...
b) Emor HandI@[EMAIL PROTECTED]
) Gaserdized Anays. llte dd 'floating' and
'gtOUft~UgUULCtlt-docnil~rodcPnWG
ever agree at one ryslan? What ahoot the
suggcstioas th8t either we allow bo& or putting
flesh amund rhe aviations by the mpeaive
prupalaltath u anulNiaIsof rbe 'OppoEing'
syacm ate achievahlc"
Jean-Jacques Girardot
Unfortunately, we have seen very little progressin Some im****tant
questions are :
am boxed arrays
this last domain, and I really am afraid that the better than nested
arrays ?
Are they the same thing ?
absence of consensus on the subject might become yet Do we need both?
Do we need any of them?
These
another cause of the decline of APL.
However, I still questions are not new. They were the subject of a
have some hope that discussion will progress,either workshop held
during the APL 79 congress
with new people or with new arguments. [Jenkins 791, and ten years
after, are yet unsolved.
2 THE ARRAY SYSTEMS
All these new APL systems I have mentioned differ
by so many bells and whistles that they can hardly be
compared at all. However, notwithstanding all the
new functions, operators, commands, notions and
widgets that have been introduced, it seems to me
that the fundamental point on which these systems
differ is the notion of generalized arrays.
The fact that
some functions or operators are missing is not that
im****tant, because each system is powerful enough
to allow the simulation of any missing operation. But
the influence of the array system is pervasive, and
has repercussions on almost every operation of the
interpreter.
Many authors have proposed a critical analysis of
the two systems. I will quote here the work of Karl
Ruehr [Ruehr 821, just to sketch the problem :
"Although then is in general much agreement that
nested arrays are the logical extensions to APL
data Structure,s..o. ne major issue still divides the
community of search on working in this area : the
so-called "Floating vs Grounded" army
camuveny.
This controversy hinges on. the
definitions of the two funaions which are
fundamental to the manipubim of nested arrays,
and in particular on the effect of these functions on
simple scalars... In the "floadng" theory d nested
arrays, the enclose or disclose of a simple sular is
again a simple scalar, implying a sorl of infinitdy
recursive nesting of these entities. In the
"grounded" story, the enclose of a scalar is
different from that scalar... Although there may
seem like minor points, they critically aBe13 the
behavior and flavor of the two systems... TO make
matters even . more confusing, the two
implantations sometimes use teh same symbols for entirely different
meanings.
Such
diversification may be especiall unwelcome at a
point when the language is undergoing its first
major standardization process."
Another comparison very complete although now
slightly out of date, can be found in [Orth 811.
Arrays and References
Having managed the realization of APLW7, a
system using BA [Bertin 811, and of APL 90, a
system using NA [Girardot 851, and having used both
systems to build (small) applications, 1 personally
think that, when dealing with generalized arrays, the
features of NA systems are slightly mom attractive
for the end user.
A similar conclusion is offered in [Jordan 871 :
"From the viewpoint of programming users of APL,
the more central role of data structures in the APL;!
style is preferable." But this author also says that
"Neither direction (APL2/IPSA) have a monopoly of
right or wrong."
From a very pragmatic point of view, one have to
admit that both array systems are roughly equivalent.
For example, one customer migrated a rather large
application (about 10 Mega-bytes of APL source
code) from APL\15 [Amran 731, which used the strict
enclose system, to APL90 which uses the permissive
system. Apart from replacing a few hundreds of <
and > by c and 3, we found no incompatibility
between the two systems, and no other problem was
found because of the array systems.It must be noted
however that the application made no use of the new
functions or operators specific to the Sharp system.
because these were not available in APL/IS, and used
only box, open, and the "classical" structural
functions.
The fact is that there are no strong arguments in
favor of one or the other system, and that no system
has proven to be clearly superior.
However, when
designing a new application that needs generalized
arrays, it is clear that the only choice is either to use a
very restricted set of operations (such as enbox and
debox, preferably encapsulated in user defined
functions), with the hope that the application will be
****table, or to use the whole set of functions and
operators available on a specific system, knowing
that you will be unable to easily ****t your application
to an other system.
162 APL90
3 NESTED ARRAYS AND THE APL
STANDARD
The IS0 extended APL standard working group is
the place, if any, whered iscussionis in progressO. ne
can read in [Morrow 831:
"The standard is going to be I valuable asset for
she APL commuttity... It will also set a
bedrock for the dmhpmcnl of a future standard
that I see as the only means of bringing together
the various dialect of APL with nested arrays that
ue being developed."
What ate the points of view of participating
people ?
An IS0 working do***ent by K.Iverson
and EE.McDonnell [Iverson 871 suggests to have
two sets of functions :
strict functions :
l Box: Z[gets]<B provides a scalar
encoding of B ; Z is always different
from B.
.. Open :Z[gets]>B returns B if B is
simple, otherwise an array formed by
removing the scalar encoding from
the items of B and conforming these
items.
Permissive functions :
l Enclose : Z[gets]<B provides a scalar
encoding of B ; Z always differs
from B except when B is a simple
scalar.
l Disclose : Z[gets]>B returns B if B is
simple, otherwise an array formed by
removing the scalar encoding from
the items of B and conforming these
items.
As can be seen, open and disclose describe the
same functionality, although they differ, strangely
enough, by their inverse functions, while box and
enclose differ only on their handling of simple
scalars. The fact that <B returns B itself for B a
simple scalar is therefore considered in this do***ent
as a property of the enclose function, whereas it is
generally presented as a property of simple scalars by
the proponents of NA. The im****tant point is that this
do***ent suggests two implications :
l The arrays of APL2 and Sharp APL are
equivalent.
APL QUOTE QUAD 763
l The APL2 implementation is somewhat deficient,
since it is currently unable to produce <B for B a
simple scalar.
A different vision is offered by J.Brown and
B.Hawks in an other IS0 working do***ent
[Brown 881. While they stick to the principle of the
simple scalar being unaffected by the enclose
function, they think of box as an encoding function
[but this term is also used by Iverson] that creates
true simple scalars, of depth 0 and unaffected by
pervasion, and enclose as a structural function that
createsn on-simples calars,o f depth greatert han zero
and on which pervasiona pplies. A consequenceis
that the following identity of [Iverson 871:
><A = A
is changedto :
><A = <A
We are therefore once again in the case of two
different points of view resulting in two contradictory
do***ents.
Is there some possible compromise ?
I
am not sure we can expect good or even acceptable
results from compromises.
One reason is that the IS0 group refuses any new
design, and insists that any new facility introduced in
the standard has been in use for some time in some
widely used system. Any solution has therefore to be
a common subset of existing implementations, and
would be deficient in some borderline cases, since
these cases are handled differently in these
implementations.
For example, [McDonnell 881
proposes a definition of the match function, 5. Since
the expression:
[character empty] = [numeric empty]
returns 1 on Sharp APL and 0 on APL2, the text
resolves the incompatibiity by saying that march
returns a domain error when its operands are two
empty armys of the same dimensions. While this
proposal is clearly done in a spirit of conciliation
(since any implementation can define a conforming
extension by returning 0 or 1 in this case), it means
that what the standard defines as a conforming
program should not use A=B without first checking
the case of empty operands of the same dimensions,
with an expression such as :
[apl expression]
Jean-Jacques Girardot
(which anyway is supposed to fail if A and B are both
scalars !). Such a proposal therefore turns match, an
operation which should never return an error, into a
totally unusable function !
In the same spirit, why not propose, instead of box
and enclose, a unique function to define generalized
arrays, which will apply on any object, except on
simple scalars, for which it will return a domain
error ? After all, any system can then provide a
conforming extension of this function, that will return
a result instead of an error in this specific case ! Such
kinds of compromises do not look very serious,
because they don't offer a strong basis on which
programs can be safely built.
4 WHAT DO THEY CALL ARRAYS
4.1 SHARP ARRAYS
The recent apparition of a new APL system from
Sharp, the SAX System [SAX 881, gives an
op****tunity to get an insight of what the designers of
the system call boxed arrays.
4.1.1 Boxed Arrays
An element of a boxed array is either an elementary
object, such as a number or a character either another
boxed array. A simple array is an array where all
elements are elementary objects.
4.1.2 The box function
The box function, known in Sharp terminology as the
box verb, has very often been presented as an
encoding function : "The monadic verb < boxes its
argument, thereby encoding it as an item" ([SAX 881,
44). The result of < is itself presented as a new
data-type : "SAX permits arrays whose members have
different types (numeric, character or boxed),
relaxing the requirement in Sharp ApL~'370 that items
within an array be of one of those three types
exclusively" ([SAX 881, 14).
4.1.3 Fill elements
In the definition of the verb wand, it is stated that :
"occurrences of a 0 [in the left argument] produce
fill items appropriate to the type of the array you are
expanding. Fill items are :
1 T for character arrays,
0 for boxed arrays, where 0 is < 'L 0,
0 for other arrays (mixed or numeric).
The tolerant cell extension mechanism is defined
SO that unused positions in a numeric array are filled
out with 0, in a character array with blanks, and in a
boxed or mixed array with OS, the boxed empty List."
([SAX 881,4-&J).
In the same way, Overtake, afw is defined to add
fill values, which am :
0 when o is mixed or entirely boxed,
T f when w is entirely character,
0 when w is mixed or entirely boxed.
Note the small ambiguity representedb y the case
of mixed arrays, for which the fill element is 0 for
expand, and 0 for take. The notion of fill element is
further complicated by the fact that (to my
understanding)the result of an operation that returns
an empty array is always numeric. This gives (if I
interpret correctly the reference manual) the
following non-standardb ehavior :
1 1 1 \ 1 1 1 / 'MC'
MC
0 0 0 \ 0 0 0 / 'MC'
000
However, if we don't take into account the case of
mixed or empty arrays, the fill elements are defined
for the three data-types as T ), 0 and 0.
4.2 APL2 ARRAYS
Many do***ents are available, that describe in depth
nested arrays of APL2, Iike [Brown 841 or
[Brown 873. Here again, I will quote the APL2
reference manual [APL2 851.
43.1 Nested Arrays
In ApL2, arrays are collections of numbers and/or
characters Arrays have two properties: structure and
data ([APL2 851, p. 49). An item of an array is itself
an array. If every item in the array is a simple scalar
(a single number or a single character), the army is
called a simple array. If one or more items in the
army is not a simple scalar, the array is called a
nested array. ([APL2 851, p. 52). The treatment of
nested arrays is based on J.Brown's dissertation
[Brown 711 and T.More's theory of arrays
(IMU 851, p. 37).
Arrays and References 164 APL90
The degree of nesting of an array is called depth.
A simple scalar has a depth of 0. A simple vector has
a depth of I. This means that all its items are simple
scalars, that is either single numbers or single
characters A depth of 2 means that at least one of the
items has a depth of 1 ([APL2 851, p. 53).
42.2 The enclose function
The enclose function, Z+cR creates a scalar array
whose only item is R If R is a simple scalar, CR id
R If R is not a simple scalar, the depth of CR is
l+zR ([APL2 851, p. 174).
42.3 Fill element
In APL2, the notion of fill element is strongly related
to the notions of type and prototype. The type of a
numeric scalar is 0, the type of a character scalar is
* T,and the type of an array is an array with the
same dimensions, where every item of the original
array is replaced by its type. The prototype of an
array is the type of its first item. Therefore, there is
nothing like a "typical element" or a "ffl element"
for an enclosed array. Rather, a more complex, but
usually more convenient algorithm is used for
functions such as eqand or take that need iill items,
and these items are obtained from the type of
appropriate sub-armys of the original array. For
example, if Mis :
MC2 3p'A',l,'B','C',2,'D'
M
AlB
c2 D
then (in index origin 1) :
(1 1 1 O\M)[;d) c+ ' ',' '
(1 1 waC3;l c-) ' ',O,' '
4.3 A FIRST CONCLUSION
From this brief examination, it seems that, although
BA and NA look similar, they in fact exhibit very
Merent properties. A first difference is shown in the
notion of penasiveness: scalar functions are
pervasive in APLZ, while they are not in Sharp APL.
However, this may be interpreted as a simple design
choice, and is repeatedly presented as such by
McDonnell [ISO 881. Another clue is given by the
way overtake is handled in both systems. Note also
that different symbols were chosen for creating and
revealing enclosed arrays.
APL QUOTE QUAD 165
The IS0 APL Standard cunently defines two
data-types in APL, numeric and character,and a data
structure, the array. Arrays of IS0 APL axe flat and
homogeneous While we can think of an IS0 APL
numeric array such as
A+2 5 3p130
as a representative of the numeric data-type,or even
as a representative of the "?uuneric arrq [2;5;3]"
data-type, & la mode Pascal, it is probably better to
consider an array as a data s&&e that can hold a
set of values. and has some other properties, like its
ran& and its dimension.
It is now clear that we can reach the following
conclusions :
APL2 hast two data-types: numeric and
character, and an extended data
structure, known as the nested array. An
item of a nested array can be a number,
a character or another array.
SAX has three different data-types : numeric,
character, and boxed. Arrays of SAX
are extended to admit items of the three
different data-types.
5 REFERENCES
After this presentationo f the array systems,w e can
introduce the notion of references. Some previous
works of this author [Girardot 871, [Girardot 881
attempted to show the interest of objects for APL
(what we call objects here correspond to the simple
scalars such as the numbers or the characters of IS0
APL, but also to the instances of primitive or user
defined data-types)In such a perspective we are not
faced with a single new data-type, like boxed arrays,
but with an infinite number of new data-types, that
can be defined by the user. Such an object extension
has been introduced in APL 90, which is an extended
APL system based on nested arrays. Since the
description of this object extension is not the precise
subject of this paper, I will just refer the interested
reader to the aforementioned do***ents.
Within this framework, it was found useN to
define a new primitive data-type which is the
Reference : an object of this type is a "pointer" to an
APL array.
A reference to a copy of an array A can be
created by a reference function, noted ref :
Rcref A
Jean-Jacques Girardot
The result R has the properties of a simple scalar, and
in particular, its depth is 0. Note also that R is always
different from A A copy of the army A is returned by
the unrerence function unref :
Z+unref R
The value of Z is identical to the value of A
However, an interesting property of references is
that an object such as R can be modified to reference
a copy of another array B by :
(ref R)tB
In the APL 90 system,numbers and characters are
immutable objects,while references have an internal
state that can be changed by the appropriate function.
These objects were introduced to provide the notion
of pointer, which was found to be quite useful in
many other programming languages. Here is an
illustration of the use of references:
At5
5ref A
C'B
Dcunref B
Etref A
In this example, B and C reference the same array, a
copy of A, while E referencesa different copy of A
D receives a copy of the array rcferenccd by 8,
therefore the value 5.
VFX
Cl1 (ref X)+3
V
The F function modifies its parameter, so that it
designates the number 3. When applied to 8, it
modifies accordingly this variable :
FB
unref B
3
unref C
3
A
5
D
5
unref E
5
Since B and C share the same reference, when this
array is modified by the function F, this modification
is visible in C. Of course, neither A, D or E are
altered by this process.
References provide therefore a convenient way to
pass an argument by address rather than by value to
a function. Of course, since references are scalars,
you can create arrays of references or mixed arrays
containing references,but also numbers,characters,
or any other kind of object.
A similar notion is described in [Johnson 811,
where two functions were proposed, > to create a
pointer to an object, and < to 'de-reference' such P
pointer. The author notes :
"Pointer arays bear sane nsw.nblance to the
generalized arrays... the reference creation
function > in the pointer array framework CreatES a
scalar through which access may be gained to an
array. as does the enclose functions in the
generalized array framework. In both approaches a
left inverse of this process is provided. Some of the identities and
theorems of the generalized array
theory might have analogues in the pointer
framework Then are a few key differences
berween the two approaches which make the
pointer approach more appropriate [to some
problems]... Most significant.. is the fact that with
pointer arrays one object may be accessible
through any number of paths."
In spite of some different syntactic choices, like
the reversed use of C and >, and a modification in the
semantic of the indexing function to access objects,
the concepts are very close to ours.
Similitudes may also be noted with some
data-types of other languages. For example, the
Cedar Language[S winhart 851 introduces a new class
of pointer type, similar to Mesa's pointers. A
reference, called a REF, holds the address of a
dynamically allocated memory area.References may
be freely replicated and discarded, by assignment or
procedure parameter binding. Just as in our
implementation, REFs are s@[EMAIL PROTECTED]
pointers, which
always designate a valid memory bloc (in most
compiled languages, like C, Pascal or Ada, pointers
are unsafe : a pointer may be uninitialized, or may
point to an obsolete address, and be the cause of
hard-to-track run-time errors).
Arrays and References 166 APL90
5.1 A COMPARISON OF NESTED ARRAYS,
BOXED ARRAYS AND REFERENCES.
So far, we have briefly presented the notions of
nested arrays, boxed arrays, and references. The
following examples will enlighten some of their
properties.
5.1.1 Application on arrays 5.1.4 Scalar functions
All these fimctions mum scalars
Ai- 3 5
B-CA
PPB
0
C'<A
WC
0
Dcref A
PPD
0
Scalar functions are pervasive in APL2, while they
are not in Sharp APL, hence the domain error. Since
a reference is not a numeric array (in this case, it is a
non numeric simple scalar), we also get a &main
error when a scalar function is applied to a reference.
+CA
235
+<A
almain error
+ref A
domain error
Of course, since c and < are available on different
systems, it is difficult to compare B and C !
However, in APL 90, D is always different from A
and B.
5.12 Action on scalars
These results are obvious from the definitions of the
different array systems and functions used :
3 z c3
1
(c3) f cc3
1
3 E t3
0
((3) E <<3
0
3E ref 3
0
(ref 3) E ref ref 3
0
5.1.3 Depth of results
The notion of depth is absent in SAX or Sharp/ML
there is no depth function like the one of APL2, and
the notion itself is not used). Note that the result of
the ref function, as any object in APL 90, is always
a simple scalar.
5.1.5 Default printing
Default printing is of course defined for both NA and
3A. Depending on the value of the system variable
UPS, boxed arrays may print inside a box. There is
currently no printing method defined for references in
APL 90. The default action is to print the type and
the address of the object.
CA
235
<A
235
ref A
#ref:3C5:4OF6D8#
5.1.6 Interactions of these functions
We are now partly in the domain of design, since
there is currently no implementation with both box
and enclose. The disclose function is nilpotent on
simple scalars. The disclose of a reference is
therefore identical to the reference itself,
3cA
235
XA
undqked
3ref A
identical to ref A
APL QUOTE QUAD 167 Jean-Jacques Girardot
The open of a nested array is undefined, and so is Since <A belongs to
a new data-type, and is always
the result of the open of a reference. different from A
>CA
undefined
><A
235
>ref A
undtfined
CA cl+ <A
A +/+ <A
<A +/+ <<A
For A a simple array, since unref is defined as
permissive,
A ++ >A
The unref of anything that is not a reference is
an ermr. However, this function could be extended to
be permissive, and to return its operand when it is not
a referencer athert han signal an error.
unref CA
domain error
unref <A
undefined
unref ref A
235
For A an array of references, >A retums an array
formed by tmmferencing each item, then conforming
these items, Note that a different effect can be
obtained by >"A, where the items are umtzfemnced,
but the result retains the original rank and shape Of
the argument.
Finally, if A is not a referencew, e have :
>cA ++ CA
5.2 DISCUSSION
The reason is here again that > is defined to be
permissive on any array whose items are not
references.
From this presentationo, ne can seet hat theree xistsa
profound analogy between NA and References Some
minor changes can be brought in the behavior of
referencess o that they perfectly mimic boxed arrays:
the unref function can be made permissive, so that it
returns its argument when it is not a reference, and
builds an array when applied to an army of
references; the default printing or formatting of a
reference can be changed so that it prints or formats
the referencedv alue, and so on.
Note that this proposal differs from [Brown 881
only by this last identity, and from [Iverson 871 by :
><A ++ <A
>cA ++ CA
CA c/+ <A
53 PRACTICAL USE OF REFERENCES
Let's suppose that these changes have been done,
and let's therefore represent ref and unref by <
and > respectively (as this is actually the case in
APL 90). We will now study the integration of boxed
arrays in the universe of nested arrays.
We have shown that BA and NA were different
objects, and that they can coexist in a single
implementation. Now the question arises :
do we
really need both of them?
We will now point out
some useful combinations of nested an boxed arrays.
53.1 Boxed Arrays as a codification
Hem is a list of identities. By definition :
A f-+ ><A
A ++ >CA
Since CA is a simple scalar, it has the follow@[EMAIL PROTECTED]
:
10 t-) P<A
0 ++ E<A
<A l + c<A
<A f+ ><A
The box function has often been presented as a
"codification" function, with the example of a text
of characters being partitioned into words, then
phrases, etc. The purtifion hnction, or the cut
operatorc an be usedt o break a characterv ector such
as 'I am happy' into a vector of words
equivalent to (C'1'), (<'-'I 9
( C t happy' ) . Such a vector of words can itself be
broken into a vector of sentencest,h en a vector of
paragraphs, and so on Note that < appears in this
context very similar to the prom&on function t
mjiya 831, with the difference that
Arrays and References 168 APL90
While it is true that ~'1' is 'I', and <'I' is
different from ( I', this doesn't give us a better clue
to what an object such as XtC ( I' really is, or really
means to the programmer. X can of course represent
the word "I". In a different context, it can also be
interpreted as a country name (on the international
license plaque of a car that comes from Italy), as the
chemical symbol of Iodine, or even as the boxed
character "I", which is probably the best
interpretation. In fact, using boxed arrays as a
codification is probably a weak form of programming
since a single new data-type cannot be used as a
codification for many unrelated kinds of entities. This
is very evident in the case of APL 90, where user
defined data-types are available.
53.2 Boxed Arrays and the pervasion mechanism
Different authors have suggested the use of a depth
operator,to apply a function on some sub-arrays of a
nested array. A deep each operator has been proposed
in [Jenkins 781 or [Gull 791. The problem of the deep
each operator is that it applies a function to the leaves
of a structure,which are simple scalars.It is therefore
of little practical utility, because most primitive and
defined functions usually have to be applied to amVS
of rank greater than zero, possibly variable, rather
than to scalars.
A slightly different device, the depth operator, has
been suggested in [Benkard 861. However, it is
somewhat difficult to design a general purpose
operator that applies a function to items that may
appear at variable depths in a structure. The reason is
that these objects do not necessarily have a structure
that can be easily recognized : it may vary in size,
rank or depth.
The boxed arrays provides us with an adequate
mechanism. Items, viewed by the programmer as the
objects on which the function should apply, can be
boxed and put anywhere in a nested array. The depth
operator can then be used to apply an operation to the
leaves of the structure, which are now boxed arrays.
Therefore, the combination of nested and boxed
arrays provides us with a new and powerful tool to
build new kinds of structures and algorithms. This
aspect has also been studied by FWip Benkard and
James Brown [Benkard 891 who wrote a paper that
"explores the possibility of including box-like
functions in APL2 as a way to control pervasion
through data' '.
5.33 Display of boxed arrays
A nice feature of the Sharp system is its display of
boxed atrays when OPS is set to the appropriate
value. While the APL2 default display is convenient
for most applications,t herea re casesw herei t may be
useful to reveal the structure of the object being
printed. The DISPLAY function of APL2, available
as OOISP in APL 90, is useful for debugging or
teachingp urposesb, ut the boxedd isplay of Sharpi s a
better tool in a production environment, or even in a
final product.
For example, the array A that displays as :
A
135 oxFoms 115
265
LZw 105
LOJLFERS 150
SNEAKERS 85
SANDAW 60
PUMPS 95
can be very simply enhanced by :
<"A
135
WOMEN 265
CHILDREN 105
OXFORDS 115
LOAFERS 150
SNEARZRS 85
SAhDALS 60
PDMPS 95
53.4 Boxed arrays as Safe Pointers
We have already presented references as "safe
pointers". This is maybe the most original pan of the
proposal, and unfortunately the one that is the most
subject to discussion. It represents a new kind of
feature in an APL system,and it may be necessary to
experiment with it before we understand its
possibilities and its shortcomings A system may also
choose not to implement this extended facility in a
first time,
Two do***ents point out the interest of
introducing the notion of pointer in APL. Johnson
[Johnson8 11a dvocatesth e useo f pointer variablest o
allow multiple access paths to objects. Thornburg
[Thomburg 861 shows the advantage of pointers to
create and manipulate direct acyclic graphs, which
are a much more general data suuctute than the trees
which are offered by generalized arrays.
APL QUOTE QUAD 169 Jean-Jacques Girardot
Here is a part of a session that shows some
interesting uses of references. The SBOW function
displays recursively the contents of an array,
representing a reference as a numbered box :
SHOW (<'ABC'), (<'MC')
p&j Fiq
SEOW 2p<'ABC'
pI.iq pJ
Note that the SEOW function makes the difference
between the first case, a vector of two di_gerent
references that happen to point to similar data, and
the second case, a vector of two identical references.
In this last case, the sharp sign and the boxed number
1 indicate that the contents of the reference are
identical to the contentso f the referencen umbered1 .
The next exempled escribesh ow a circular list (a
brand new structurei n APL) can be constructed" a la
LISP" :
L+(CONS '1ST' (CONS '2ZVD'
(CONS '3RD' m)))
SHOW L
(RPLACD w L)
#REF:28:796#
SHOW L
The tail of the third element of the list (the box
numbered "6") has been changed with the RPLACD
function to point to L. Such a data structure is called
a circular hi in Lip, or an infinite tree in Prolog..
(CDR (CDR L))
The variable L is first built as a "classical" list. In
this expression, the variable m is defined as the
prototype of references,a nd was previously defined
by an expressions ucha s "~fOp<l",
(CAR (CDR L))
2ND
m(CDR (CDR L))
SHOW w
Note that at this point, L and Wphysically share some
data : any modification in W is visible in L, and
reciprocally. Let's modify W :
6 REFERENCES, ARRAYS AND
STANDARD
Let's come back to the APL Standard. It is clearly
unsatisfactory at least for one of the parties,to adopt
in the extended standard either NA or BA. It is also
very unlikely that companies like IBM or I.P.Sharp
carry out a complete transformation in their products
just to conform to a standard.
THE
As we have also seen, the compromise of
choosing only the behaviors that are common to all
systems is even worse, at least for users, and is
almost equivalent to having no standard at all.
However, a new kind of solution is proposed by
APL 90 : combine both systems, and try to catch the
best of the two worlds. In fact, adopting the scheme
that is suggested in this do***ent might prove to be
the correct thing to do. On can read in [Benkard 891
that including box-like functions in APL2 and
enclose-like functions to other systems would
enhance the possibility of the convergence of major
systems.
Arrays and References 170 APL90
l The op****tunity of a solution satisfactory to both
parties is not to be rejected. Moreover, if we are
truly willing to unify both systems ths is solution is
probably the most economical one.
l Within this framework, current APL
implementations appear incomplete rather than
divergent, which is a better point to start with. It is
much simpler to add a new feature than to
transform an existing one.
l APL, enhanced by the combination of NA and
BA, may prove to be a better tool yet,
7 CONCLUSION
We have tried to show that there was room in APL
for both nested and boxed arrays, and that both had
different properties.
Although the interest of box as an encoding
device is somewhat lessened by the availability of
enclose on one side, and, in APL 90, the ability to
create an arbitrary number of new data-types on the
other, boxed arrays can be viewed as a pervasian
stopping device, and present also the great interest of
introducing the notion of safe pointer in APL.
I hope that when people are agreed that nested
arrays and boxed arrays are different, and both can
coexist in an implementation, maybe we can stop
arguing why one system is better than the other, or
how the same thing can be done with BA and NA,
and start exploring the fantastic things that can be
done when both tools are combined. This can be a
matter of survival for APL.
8 ACKNOWLEDGMENTS
Discussions with the members of the IS0 Working
group, and specially Phil Benkard and Eugene
hkDonne~, and also with John Sansom, were the
inspiration for writing this paper. I hope they will
pardon me for leading astray some of their ideas, but
this was done, as the French says, pour faire avuncer
le shmilblic.
9 REFERENCES
[Amran 731 Y. Amran, B. de Cosnac, J.L.
Granger, A. Smoucovit, An APL Interpreter for
Mini-computer ; A Microprogrammed APL
Machine, APL Congress 1973. August 22-24,
1973. Copenhagen, North Holland Publi****ng
Company.
[APL2 853 APL2 Programming >Lunguage Reference
Release2 , SH20-9227-1D, ecember1 985.
lsenkard 861 J. Philip Benkard, Analysis offunction
application in deep arrays, APL 86 Conference
proceedings, APL Cl 16, 4, Manchester, July
1986.
lsenkard 891 J. Philip Benkard, James A. Brown,
User Defined Data Types in APL2, APL 86
Conference proceedings, APL II 16, 4,
ManchesterJ, uly 1986.
[Beti 813 Christian Berth, Aspects de la
rt!alisation dun systt?me APL optimist, Ph. D.
Thesis, Ecole des Mines, 42023 St. Etienne,
France, December 198 1.
[Bowman 871D ick Bowman, A survival Strategyfo r
APL, APL 87 ConferenceP roceedingsi,n APL
Cl 17,4, Dallas, May 1987.
fI3rown 711 James A. Brown, A GeneraZization of
APL, Ph.D. Dissertation, 1971, Dept. of
Computer and Information Science, Syracuse
University, Syracuse, New York, Clearing
House7 4hOO494A2D -770488J5.
[Brown 841 James A. Brown, The principles of
APL;!, IBM Santa Teresa Technical Re****t, 'I'R
03.247. March 1984.
[Brown 871 James A. Brown, Why APL2 : A
discussion of Design Principles, APL 87
ConferenceP roceedingsi,n APL Cl 17,4, Dallas,
May 1987.
[Brown 881 James A. Brown & Brent Hawks.
ISO-ECCIJTC IISC 22iWG 3 N199, August
1988.
[Dumontier 861 Michel Dumontier, personal
communication, July 1986.
[Girardot 871 JJ. Girardot, S. Sako, An Object
Oriented Extension To APL, APL 87 Conference
Pnxxedings, in APL Cl 17,4, Dallas, May 1987.
APL QUOTE QUAD 171 Jean-Jacques Girardot
[Girardot 881 JJ. Girardot, M. Amarti, An Object
Extension To APL, Research Re****t 88-4,
October 1988, Ecole Nationale Sup&ieure des
Mines de Saint-Etienne, 158 Cours Fauriel,
42023 Saint-Etienne( Xdex, France.
[Gull 793 W. E. Gull & M. A. Jenkins, Recursive
data structures in APL, Communications of the
ACM, Vol22,1, January 1979.
US0 881 E. E. McDonnell, Drqft Minutes of
ISO-APL Working Group Meeting, London,
October l-4.1988.
[Iverson 871 K. E. Iverson & E. E. McDonnell,
ISO-ECCIJTC I/SC 22iWG 3 NZ12,
[Jenkins 791 Michael A. Jenkins, Chairman, Nested
Arrays as an extension for APL, Workshop. APL
79 Conference, 30 May - 1 June 1979,
RochesterN, .Y.
[Jenkins 791 Michael A. Jenkins, Jean Michel,
Operators in APL Including Nested Arrays, TR
78-60, Dept. of Computing and Information
Sciences, Queen's University, Kingston,
Canada.
[Johnson 811 Greg Johnson, APL in Operating
System Research, APL 81 Conference
Proceedings, in APL l!l 12, 1, San Francisco,
October 198 1.
[Jordan 871 Maurice H. Jordan, APL Extensions, A
User's View, APL 87 Conference Pmceedings,
in AF'L PI 17,4, Dallas, May 1987.
[Kajiya 831 James T. Kaji y a, Designing and
Implementing an Array Theory Incor****ating
Abstract Data-types, APL 83 Conference
proceedings, APL PJ 13, 3, Wa****ngton, April
1983.
[McDonnell 881 E. E. McDonnell, ISO-ECCU7'C
1ISC 22lWG 3 N200,
morrow 831 L. Alex Morrow, APL Standardization,
APL 83 Conferencep roceedings,A PL p11 3, 3,
Wa****ngton, April 1983.
[Orrh 811 Don L. Orth, A Comparison of the IPSA
and STSC General Arrays hnplementation, IBM
ResearchR e****t, October1 981.
[Orth 841 Don L. Orth, Empty Arrays in Extended
A% IBM Journal of Research and
Development, Vol22,1, July 1984.
/?vluir 771 Frank Muir, What-a-Mess, Carousel
Book 0 552 520151, Transworld Publisher Ltd,
Century House, 61-63 Uxbridge Road, Ealing,
London W5.1977.
[Ruehr 821 Karl Fritz Ruehr, A survey of extensions
w APL, APL 82 Conference Pmceedings, in
APL I!/ 13, 1, September1 982.
[SAX 881 Sharp APUVX Rt$erence Mawal 1988.
[Swinehart 851 Daniel C. Swinhart, PoUe T.
Zellweger & Robert B. Hagmann, The
Structure of Cedar, Symposium on Language
Issues in Programming Environment, in S&plan
Notices, 20,7, July 1985.
[Thornburg 861 Jonathan Thornburg, Representing
Data Structures in APL with an Extended
Enclose Function, APL II 17,2, December 1986.
Arrays and References 172 APL90
|
