[cells-devel] Next Steps

[rpgoldman at real-time.com]

>>>>> "KT" == Kenny Tilton <ktilton at nyc.rr.com> writes:

    KT> Thomas F. Burdick wrote:

    >> Kenny Tilton writes:
    >> 
    >> > (b) eliminate the check for looping in which one setf of a cell leads 
    >> > back to setf of the same cell (the scroll bar scenario). I will leave 
    >> > the code behind in case I decide to simply enhance cycle detection as 
    >> > opposed to wiping it out entirely.
    >> 
    >> I think The Right Thing is to allow looping by default, assuming that
    >> the programmer knows what they're doing,
    >> 
    KT> done.

    >> and to be able to optionally
    >> declare a certain cell to be non-cyclic
    >> 
    KT> for debugging? ie, How are non-cyclic cells to be handled?

Perhaps I'm missing something, but I would have thought that cyclic
cells would have been the unusual case, and the one you want to trap
by default.  I.e., it would make more sense to default to acyclic, and
then allow users to explicitly declare cycles.

I suppose there are two colliding philosophies here:

1.  the cyclic case is the one likely to cause inefficiencies and/or
    bugs.  So make it exceptional, and require your user to declare it
    explicitly.  Also this lets your users find cycles using Cells as
    a tool.

2.  Things should mostly work w/o declarations, so the cyclic case
    should be the default.  You should be able to declare acyclicity
    specifically, as a way of providing more efficiency (but do we
    know how to do this?).

Cheers,
R