Changes between Version 8 and Version 9 of ArrayTasklist

Timestamp:

10/13/09 09:56:25 (12 years ago)

Author:

kurahaupo

Comment:

--

ArrayTasklist

@@ -15 +15 @@
 = Questions =
 
+== Fixed Arrays ==
+
+ * Should fixed-sized arrays support push, pop, shift and unshift?
+   * ''(probably not)''
+
+ * Should there be special cases for very small arrays, such that no separate memory block is needed? These could be useful to implement vectors in mathematical operations, and tuples generally.
+
+ * Should fixed-sized arrays automatically become resizable arrays when resizing operations are attempted?
+   * ''(maybe)''
+
 == Resizable Arrays ==
 
- * Do any HLL's use Resizable Arrays without extending them to include initialization of unset elements?
+ * Do any HLL's use the current resizable array types without extending them to include initialization of unset elements?
 
- They were originally included as counterparts to the Fixed Arrays, but extended to support pop, push, shift, unshift and set-integer. However it seems that the lack of initialization is a misplaced optimization that is probably of no use to any HLL, forcing every HLL to override this behaviour.
+ They were created as extensions of fixed-sized arrays, extended to support pop, push, shift, unshift and set-integer, but ''not'' extended to guarantee initialization. However it seems likely that the lack of initialization is a misplaced optimization that is probably of no use to any HLL, forcing every HLL to override this behaviour. Does anyone implementing a language say otherwise?
 
- * Is there room to make new types of Resizable Arrays that target their use as a queue (optimized for push, pop, shift & unshift) rather than for indexability?
+ * Is there room to make new types of resizable array that target their use as a queue (optimized for push, pop, shift & unshift) rather than for indexability?
 
  The current versions implement shift and unshift by doing bulk memmove, which is quite expensive. A ring-buffer approach that uses head and tail indexes would be far more efficient, ''if'' that's what we're really targetting by having the content uninitialized.
 
- * Is there room to make new types of Resizable Arrays that target raw buffer use and ''don't'' allow push, pop, shift and unshift?
+ * Is there room to make new types of resizable array that target raw buffer use and ''don't'' allow push, pop, shift and unshift?
+
+ * The current implementations of resizable array PMC's are derived from fixed-sized array PMC's. However the (current) use of the "size" field -- provided by the base PMC -- is arguably incorrect, in that it does not track the allocated size as it would for the fixed-sized version. Instead of changing the meaning of "size" in the base PMC, we should call it "allocated_size", and then in the derived PMC have "logical_size". This means that the memory-safety of the "allocated_size" bound is then implemented only once, within the base PMC.
+
+ * A general-purpose resizable array would need these attrs:
+   * allocated_size
+   * initialized_size
+   * logical_size
+   * index_offset (used to make shift and unshift operate efficiently, not to allow arbitrary base indexing)
+
+ * My dictionaries can't agree whether the spelling is "resizable" or "resizeable"; if the latter, should we fix the spelling now, later, or never?
+
+== Role separation ==
+
+Arrays are overloaded to perform several roles:
+
+ * Indexable ("Hashes with Integer Keys")
+ * Stack (Push and Pop, or Shift and Unshift)
+ * Queue (Push and Shift, or Unshift and Pop)
+
+Should we have separate PMC's that optimize for each of these roles?
 
 = Tasks =