loc@yrloc.ipsa.reuter.COM (Leigh Clayton) (01/18/91)
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)