I Still want INITIALIZED? !

[Jonathan A Rees <JAR@MIT-MC>]

    Date: Mon, 25 Mar 85 18:39:33 EST
    From: Larry Hunter <Hunter at YALE.ARPA>

	JAR:
        I hope you realize that the system doesn't make any guarantee
        that this is the case, and if you're depending on the
        implementation strategy for tables (or any kind of datum, for
        that matter, whether created by T or not!) then you are
        violating a data abstraction.  It may work this week, but it's
        not a good habit to get into.  You really ought to be
        complaining that the table abstraction doesn't support any kind
        of copy operation; that would meet with more sympathy.

    Hunter:
    I thought that WAS what I was complaining about.

I don't think so; you were complaining about a perceived deficiency in
the "structure" data abstraction, not about the "table" abstraction.

    The point of that message is that I want to copy tables and NOT
    worry about what they are.

Your notion of "copying" tables and structures is not likely to be the
same as someone else's.  The leaf/node distinction, what's atomic and
what's not, whether or not to worry about circularity, and so on, are
all application-dependent.  You seem to be making the mistake of
assuming that "copying" is a well-defined operation; for your purposes,
it may be, but in general, it is not.  This is why there is no COPY
operation in T, and why the "tree" operations are not generic.

    If anything, I would prefer that a table NOT
    answer T to STRUCTURE? and I would certainly love it if the
    implementors-that-be provided a copy method for tables.  Since they
    didn't, it would be nice if a reasonably defined generic copy-structure
    could copy any structure (including things that T exports as structures
    but I don't know are exported as such, like tables).

The intent was that structures, like (OBJECT ...)-closures, be a way to
implement new opaque types, so that any object, including pairs,
symbols, and numbers, could in principle be implemented using structures
(some numbers are, I think).  It's clear that the inclusion of
STRUCTURE?, STRUCTURE-TYPE, and COPY-STRUCTURE in the language
frustrates this goal, and I think they should have been left out.  (Note
that STRUCTURE-TYPE is defined only in the "debugging utilities"
section; that doesn't seem to make much difference to most people,
although I was hoping it would.)  For example, what if certain numbers
were implemented as circular data structures? - Your generic copier would
probably diverge if it encountered one, and this event might not happen
until after you believed the program working.  What if symbols were
structures?  Then "copying" one would create non-EQ instances of the
"same" symbol; that's probably not what you want.

    If I had a predicate like UNINITIALIZED? I could do it without
    violating any data abstraction (or at least without knowing that I
    have).  I thought that my solution (making T tables into my own
    table-objects which do not answer T to STRUCTURE? and have their own
    copy method) was a way of refusing to violate a data abstraction --
    or did I miss something?

Encapsulating tables would be a good intermediate solution, but you
would still need a way to copy the table.  You could maintain a list or
population of the keys in the table, and traverse that to copy the
entries.  (So a COPY-TABLE would be redundant, modulo efficiency.)  If,
however, your code depended on the fact that tables were structures, it
might break when the representation changed (and it has in the past).

Jonathan