Fw: Rejected posting to APL-L@LISTSERV.UNB.CA 
Author Message
 Fw: Rejected posting to APL-L@LISTSERV.UNB.CA

        There is a substantial difference between "order of execution" and
"order of precedence": what the APL standard says is that in  "a+b-c", "b-c"
gets evaluated first, but it does NOT specify that "c" gets evaluated before
"b". This is left to the implementation to decide, and DOES make a
difference where reassignments occur... And APL programs relying on such
implementation-dependent side-effects would be termed {*filter*}ographic.

        The implementation mechanism that makes a difference is how
references to variables are managed: for example, if an APL/360-style
interpreter processes the statement "(x {<-} a) + x",  it's going to scan it
right to left:
    - see variable "x" and stack a pointer to the "Symbol Table" (ST) entry
      for "x"
    - see "+" and stack it
    - see ")" and decide it's a delimiter for a left argument to "+"
    - see variable "a"
    - see <-
    - see "x". The ST entry for "x" will be changed to point to a new copy
      of the value for "a". The old value for "x" is discarded, and a ST
      pointer
      to "x" stacked
    - unstack  <ST pointer to "x">,  <+>,  <ST pointer to "x">
    - execute it with, obviously, the same values on both sides.

        More recent (that is, from the early 70's) interpreters are more
clever at avoiding dumb and useless copying around of chunks of values, and
they do that by sharing the value blocks.
       This is done by associating data segments with a use-count: when a
statement like X {<-} Y (and Y is a variable), then the data segment
containing the values for Y will simply have its use-count incremented, and
both X and Y will "use" it.  When X or Y get reassigned, the previous
segment's use-count will get decremented.  The segment will eventually get
discarded when its use-count drops to zero.
        This way of doing things incur pretty different side-effects:  If we
process the same statement "(x {<-} a) + x" with our modern interpreter, we:
    - see variable "x" , follow the pointer to the ST, read and stack the
      pointer to the value segment for "x"; increment that segment's
      use-count
    - see "+" and stack it
    - see ")" and decide it's a delimiter for a left argument to "+"
    - see variable "a"
    - see <-
    - see "x", follow the pointer to the ST then to the value segment for
       "x" and decrement it. Now, since there still is a "user" of that
       segment on the stack, the segment won't be discarded (yet!).
       ST entry for "x" then gets connected to the value segment for "a"
       and the segment's use-count is incremented.
    - unstack  <pointer to the values for new "x">,  <+>,  <pointer to
       values for old "x">
    - execute it with the new and old values

        The bad thing with the "old" technique is that anything could happen
between an argument was "seen" by syntax analysis and actually used: if you
have a statement like "r {<-} a f b" and "a" is a monadic function, "f" a
dyadic function and "b" a variable, then if during execution of  "a" you
expunge "b" or "f", or turn them into a function or a variable respectively,
then very bad side-effects are bound to occur! (don't try that at home!)

        Most recent APL's do use use-counts for sharing segments that
contain both descriptor (type, rho etc) and data for variables.
        This can in fact be much more powerful if you separate descriptor
and data in different segments: then for example X,  1{drop}X  ,  ,X  and  3
5 {take} {reverse} {transpose}X   can each have their own descriptor (and
access matrix) but share the same data segment. Data then don't need to be
copied needlessly and execution time is improved!
        Sadly, even if the technique was proposed in Phil Abram's thesis (ca
1970), implementers have generally not taken the step of splitting
descriptors from data. In particular, neither APL2, Dyalog APL, APL2000 or
SAX do it.

Quote:
----- Original Message -----


Sent: Monday, July 02, 2001 9:23 PM
Subject: order of evaluation in apl -- a surprising example that doe

> In "Handbook of APL Programming" by Clark Wiedmann, there appears in
> the middle of page 54, the following example

>        Q{<-}2
>        (Q{<-}3)xQ
> 9

> Even though I've learned that APL evaluated from RIGHT to LEFT, this
> example was intended to show that parenthesised expressions are
> evaluated before unparenthesised ones. The only problem is that the
> answer, when typed in IBM APL2 and in Dyalog APL is 6, as expected,
> rather than 9, as mentioned in the book, demostrating that both
> important implementations evaluate simply from right to left.

> So:
> - Is this something that has been changed in APL?
> - Is the current behaviour of IBM APL2 and Dyalog the correct one?
> Can someone please explain this??
> Thanks,
> Mayer



Mon, 22 Dec 2003 04:46:39 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Rejected posting to APL-L@UNBVM1

2. Rejected posting to APL-L@UNBVM1

3. UseNet news to listserv gateway for comp.lang.apl moving [No

4. Toronto APL SIG and APL97 - Announcement Listserv Facility

5. HELP: bit.listserv.apl-l ?

6. Rejected postings to INFO-CLS

7. Rejected posting to INFO-M2@UCF1VM

8. Fw: Graphic Possibilities of APL

9. Fw: What is APL\11 (A Simple Question)

10. Fw: APL to and from Excel

11. FW: interesting feature in Dyalog APL/W

12. Fw: Automatic reading of bottom posting (4ePost)?

 

 
Powered by phpBB® Forum Software