Newsgroups:   comp.lang.apl
Path: watmath!watserv1!utgpu!utzoo!censor!geac!itcyyz!yrloc!intern
From:         loc@tmsoft.UUCP (Leigh Clayton)
Subject:      Reply to merge message
Message-ID: <1991Jan14.184104.27987@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:         14 Jan 91 17:54:50 UT


 The following is from Roger Hui, Iverson Software.

>Reply to the following msg re merge.
>
>> From: sam@kalessin.jpl.nasa.gov (Sam Sirlin)
>> Newsgroups: comp.lang.apl
>> Subject: Re: Reassignment in J
>> Message-ID: <1991Jan10.180110.4244@jato.jpl.nasa.gov>
>> Date: 10 Jan 91 18:01:10 GMT
>>
>> Thanks. I looked at merge, but the description is so obscure that
>> I didn't see this simple application. I'm just beginning to understand
>> the boxing necessary in I for indexing. It seems much more complicated
>> than the indexing function from APL 75 (the model for this?).
>>
>> This way of changing values is also less powerful than reassignment, since
>> a duplicate copy of the whole array must be created (unless the language
>> recognizes the idom), which could take substantial memory and time. Of
>> course this mainly affects slow machines with little memory. You
>> also need more characters for both the indexing ( A[2;3] versus (<2;3)}a ).
>> and the copy of "A."
>>
>> --
>> Sam Sirlin
>> Jet Propulsion Laboratory         sam@kalessin.jpl.nasa.gov
>
>First, regarding the description of merge in the Dictionary, I think
>it'd be more accurate to say that it is "terse" rather than "obscure".
>(There is a difference.)  In fact, the description of merge is rather
>distinguished in that it actually contained some examples!
>
>Second, I don't see how merge is "less powerful than reassignment"
>("indexed assignment"), even from the writer's own arguments in the msg.
>The implementation may well be smart enough (for all we know) to avoid
>making a duplicate of the right argument.  In any case, concern about
>possible temporary implementation inefficiencies ought not influence
>the language design.
>
>Third, arguing for merge vs. indexed assignment:
>(0) merge follows the syntax of the rest of J; indexed assignment
>has anomalous syntax.  The benefits of this are twofold: first,
>a consistent syntax makes for simple parsing rules; and second,
>merge, being an ordinary adverb, can be combined readily with other
>constructs in the language.
>(1) merge has no side effects, which among other things bodes well
>for its implementation on non-sequential machine architectures.
>(2) merge permits any verb to be used to select the positions to be
>replaced. e.g. replace the diagonal of a matrix.
>(3) merge permits replacement of multiple subarrays by an identical
>subarray. e.g. replace multiple rows with a single row.
>
>Conclusion: merge is superior to indexed assignment, in syntax and
>in semantics.

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