[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 22 14:55:12 1992 
Subject:Dynamic List Implementation 
From:Steve Knight 
Volume-ID:921223.03 

I've always been puzzled why POPLOG implements dynamic lists using
pairs rather than a separate dpair key.  In fact, a dynamic list
is represented using a pair whose back is a procedure and whose
front is true.

Because POPLOG uses this representation, many simple operators go
slower in the common case of non-dynamic lists.  For example, the
operator -null-, which is almost always applied to non-dynamic pairs, 
determines the speed of -for- loops.  But it has to be coded like 
this

    define null( x ); lvars x;
        if ispair( x ) then
            isprocedure( fast_back( x ) ) and 
            dnull( x )    ;;; you can imagine the code for this.
        else
            x == [] or mishap( 'LIST NEEDED', [^x] )
        endif
    enddefine;

 
In the common case, this version of null is obliged not only to inspect
the key of -x- but also the fast_back(x) for being a procedure.  If we
compare with the version which uses dpairs to indicate dynamic pairs.

    define null( x ); lvars x;
        not( ispair( x ) ) and
        (    
            x == [] or
            isdpair( x ) and dnull( x )
        )
    endefine;

Now the common case is significantly quicker -- only inspecting the key
of -x- to return a result.

As far as I can tell, the same analysis follows through for all the 
list operators.  The dynamic list operations are slightly worsened in
performance, it is true, but looking at the statistics there it is
a very small amount indeed.  

Is there some subtle detail about dynamic lists that I am overlooking?
I would be grateful for any facts or insights into this aspect of
POP.  What motivates me is that I love having dynamic lists around
but I hate having to pay -any- performance penalty for them if there is
no necessity for it.  So my question boils down to, where is the 
necessity?

Steve