Newsgroups:   comp.lang.apl
Path: utzoo!censor!geac!itcyyz!yrloc!intern
From:         loc@yrloc.ipsa.reuter.COM (Leigh Clayton)
Subject:      bracket indexing .vs. merge
Message-ID: <1991Jan17.194702.21887@yrloc.ipsa.reuter.COM>
Sender: intern@yrloc.ipsa.reuter.COM (Intern via QUADRAM)
X-Telephone:  +1 (416) 364-5361 Fax +1 (416) 364-2910 Telex 0622259
Organization: Reuter:file Ltd.
X-Mail:       1900/2 First Canadian Place, Toronto, Canada, M5X 1E3
Date:         17 Jan 91 19:24:18 UT

  A message from Bob Bernecky, 'Snake Island Research', late of IPSA


>no. 4852279 filed 19.14.21  thu 17 jan 1991
>from rbe@ipsa
>to   loc@ipsa
>cc   clapl hui@ipsa kei@ipsa
>subj bracket indexing and space wars
>
>@transferred from ipsa  no. 4674958 filed 19.14.18  thu 17 jan 1991
>
>A major advantage of merge is that it IS functional, allowing compilers
>to do swell things without side effects getting in the way.
>
>As an implementor of APL interpreters and compilers (appeal to
>authority, doncha know...), I claim it's not very hard to map
>many merge expressions into expressions which will not generate
>copies of arrays at run time.
>
>Note that APL interpreters already make checks of this sort. For example,
>
>a assign b assign  iota 5
>
>(I'm using words, so that the net won't eat apl symbols)
>
>will create only one copy of iota 5, and point BOTH a and b to it,
>at least in SHARP APL. indexed assign into b ...    b[3] assign 55
>has to check the reference count for iota 5 before doing the assign.
>In this case, it would start by copying the array, and giving b its
>own copy of the array.
>
>Similar problems arise when type changes force coercions: b[3] assign 5.678.
>
>These are fairly trivial to check for, and a compiler should not have much
>trouble with copy avoidance.
>
>On a related topic, that of functional languages creating and destroying
>lots of temps, I recommend looking at some of the work in SISAL and
>that area(I have a reference to a paper which talks about that work,
>but it is buried somewhere in the Mt. Fuji paper pile on my desk.
>When it surfaces, I'll forward the reference. Basically,
>a bit of compile time analysis (hard to do this with an interpreter)
>allows functional languages to match or beat Fortran on supercomputers.
>
>Bob
>PS: I agree that a much more accessible introduction to the language
>is required if J is to ever become more than a curiousity. Also required
>are more formal definitions of the primitives -- As an implementor of
>a compiler, I am left in the dark even after reading the documentation.
>I guess I feel it's fine to make puzzle books, and it's fine to make
>computer manuals, but I derive little pleasure from "tinkering" my
>way through a definition, when a few words would make things a LOT
>more obvious to the untutored.
>
>RBE
>

-----------------------------------------------------------
loc@tmsoft.UUCP                     uunet!mnetor!tmsoft!loc
loc@ipsa.reuter.COM                         (Leigh Clayton)