ISSUE: Mutable Mixin

REVISION HISTORY: Version 1, 7/5/95, Ram

STATUS: ???

RELATED ISSUES: flush mutable collections (Harlequin approx name)

CATEGORY: Change and Clarification

PROBLEM DESCRIPTION:

Currently mutability is mixed into abstract classes near the top of the
collection heterarchy.  This forces subclasses of most predefined classes to
also be subclasses of <mutable-collection>.  This causes problems both for
implementors and for users:
 -- Users are prevented from defining immutable subclasses of open standard
    classes in situations where this would otherwise be quite natural. 
    All <string>s, <vector>s, <table>s, <array>s are supposedly mutable.
 -- Implementations are prevented from introducing immutable subclasses of
    predefined classes such as <pair> and <simple-object-vector>.  This would
    be a natural way for implementations to enforce immutability of literals.

As is, it seems highly likely that users (and perhaps implementors) will
choose to define subclasses of <mutable-collection> which are effectively
immutable, and have element-setter methods that signal an error.  This can
work, but makes the <mutable-collection> protocol completely vacuous: "Will
support element-setter unless it doesn't."


PROPOSAL:
 -- Change <array>, <string>, <deque> and <list> to be direct subclasses of
    <sequence>. Change <table> to be a direct subclass of
    <explicit-key-collection>.
 -- Retain <mutable-collection>, <mutable-explicit-key-collection> and
    <mutable-sequence> as a nominally disjoint subtree.  These classes can
    still be used in protocol descriptions to say that arguments must be
    mutable.  Furthermore, collection classes that actually are mutable should
    mix in the appropriate mutable class.
 -- In the cases where make is documented to return a mutable collection, be
    "explicitly vague" about whether the resulting object will be a direct
    instance of the instantiable class.  This is actually not a new
    implementation freedom, since instantiable abstract classes already
    magically instantiate some subclass.  What is relevant here is that an
    implementation could choose to e.g. have the class <simple-object-vector>
    immutable, and when instantiating, return an instance of
    <internal-mutable-simple-object-vector>.


RATIONALE:
 -- Allows users to define immutable strings, tables, etc.
 -- Allows the implementation to define immutable subclasses of standard
    instantiable classes such <simple-object-vector>.  This provides a way to
    enforce immutability of #[] literals without having to be hopelessly vague
    about that the class of a #[] literal is.


COST TO IMPLEMENTORS:
    This proposal merely gives new implementation freedom, so any negative
    effect is unlikely.

COST TO USERS:
    The mixin point of mutability is not precisely defined, so you can't draw
    the collection heterarchy as easily.

PERFORMANCE IMPACT: 
    No negative impact that I can see.  Having a special class for immutable
    literals could enable some optimizations.  Future documented immutable
    collection classes could aid optimization by eliminating side-effects.

BENEFITS:
    Gives <mutable-collection> a useful protocol; as it is, the idea of a
    separate mutability protocol might as well be deleted.  Provides a clear
    way to document how there could be immutable lists and vectors.

AESTHETICS:

FUTURE FEATURES:
    Would allow standardization of user-instantiable immutable vector and list
    classes.