Mutability vs Laziness

2006-09-25 Thread Aaron Sherman

Carried over form IRC to placeholder the conversation as I saw it:

We define the following in S06 as immutable types:

ListLazy Perl list (composed of Seq and Range parts)
Seq Completely evaluated (hence immutable) sequence
Range   Incrementally generated (hence lazy) sequence
Set Unordered Seqs that allow no duplicates
JunctionSets with additional behaviours
PairSeq of two elements that serves as a one-element Mapping
Mapping Pairs with no duplicate keys

It seems to me that there are three core attributes, each of which has 
two states:


Mutability: true, false
Laziness: true, false
Ordered: true, false

There are, thus, eight types of containers, but two (unordered, mutable, 
lazy/eager) don't really work very well, so let's say 6:


Ordered,   Immutable, Eager:  Seq
Ordered,   Immutable, Lazy:   Range and/or Seq of Range?
Ordered,   Mutable,   Eager:  ?
Ordered,   Mutable,   Lazy:   Array
Unordered, Immutable, Eager:  Set
Unordered, Immutable, Lazy:   x and/or Set of x?

In that last example, x is an unordered range, though we don't have 
such a type. Basically, this is something like any(a..b).


The real question in my mind, though is this: do we need to call 
something Lazy (as we currently do in S29), or should we just call it 
List or Array depending on its mutability?





Re: Mutability vs Laziness

2006-09-25 Thread Dave Whipp

Aaron Sherman wrote:
It seems to me that there are three core attributes, each of which has 
two states:


Mutability: true, false
Laziness: true, false
Ordered: true, false


I think there's a 4th: exclusivity: whether or not duplicate elements 
are permitted/exposed (i.e. the difference between a set and a bag). 
This is orthogonal to orderedness.


Re: Mutability vs Laziness

2006-09-25 Thread Sam Vilain
Aaron Sherman wrote:
 Carried over form IRC to placeholder the conversation as I saw it:
 
 We define the following in S06 as immutable types:
 
 ListLazy Perl list (composed of Seq and Range parts)
 Seq Completely evaluated (hence immutable) sequence
 Range   Incrementally generated (hence lazy) sequence
 Set Unordered Seqs that allow no duplicates
 JunctionSets with additional behaviours
 PairSeq of two elements that serves as a one-element Mapping
 Mapping Pairs with no duplicate keys
 
 It seems to me that there are three core attributes, each of which has
 two states:
 
 Laziness: true, false
 Mutability: true, false
 Ordered: true, false

I don't think Ordered is an attribute of a collection other than in
the abstract, user-centric sense - it is a type parameter difference
(though also there are method differences etc).  Things that are not
ordered map from items to presence (or themselves, if you prefer).
Things that are ordered map from array indices to items.

 There are, thus, eight types of containers, but two (unordered, mutable,
 lazy/eager) don't really work very well, so let's say 6:

Mutable sets don't work?  I don't see why not.

 Ordered,   Immutable, Eager:  Seq
 Ordered,   Immutable, Lazy:   Range and/or Seq of Range?
 Ordered,   Mutable,   Eager:  ?
  Ordered,   Mutable,   Lazy:   Array
 Unordered, Immutable, Eager:  Set
 Unordered, Immutable, Lazy:   x and/or Set of x?
 
 In that last example, x is an unordered range,

Sounds a bit like an iterator.

Sam.