Thanks to Aaron Sloman for for the historical review of dynamic lists.
It is always insightful to see how a language flows from equal
measures of design and experiment!
Aaron writes:
> One problem with having a different record type for dynamic lists is
> that if you expand a dynamic list you would then have to change the
> type of the record, since lots of things can be pointing to that
> list.
This isn't strictly necessary. The DPAIR could be implemented exactly
the way dynamic PAIRs are currently implemented. In other words, they
could have a procedure for their back if they were dynamic and false
if they were an expanded null.
Aaron makes another point concerning the optimisation
unless null( x ) then ... destpair( x ) ... endunless
to
unless null( x ) then ... fast_destpair( x ) ... endunless
and this point is preserved using the implementation suggested above.
John Gibson's point, that the current implementation of dynamic
pairs only costs another memory access is plainly true. However,
the performance different is measurable -- I wrote a note on this
a while back I think.
There can't be many programs that would be broken if we were to
change the representation of dynamic lists. (In fact, such programs
are already broken by my way of thinking.) The only examples I can
think of are list operators such as expandlist which plainly have
to change when one changes the representation.
Steve
|