On Fri, Feb 27, 2009 at 1:19 AM, Darren Duncan <dar...@darrenduncan.net> wrote: > Jon, I like all of your stated ideas in general. I also don't care about > the postfix %; that was just a concept example pulled from the inexact > comparison thread. The idea of using zero is also appropriate conceptually > with shades of how calculus works. I actually prefer the existing Range > constructor of .. visually, as long as it works unambiguously in both roles.
Yeah; I was thinking of calculus when I made that suggestion; still, it's intuitive enough of an approach that I don't think that someone who lacks calculus training would have a problem with it. And I was aiming for an unambiguous way of distinguishing between Range construction and Interval construction. > It does make a lot of sense for Range to do Set. So we just need some way, > probably a role, to distinguish whether this broader definition of a set is > enumerable or not on a case by case basis. When talking about any/all/etc > this also means that junctions would have to work with the non-enumerable > set. -- Darren Duncan I'm not sure that it [i]does[/i] make sense for Range to do Set: in S02, Range is among the immutable types that are said to do Positional, while Set is among the ones that are said to do Associative; and I'm leery about mixing Positional and Associative without good reason. More generally, though, both Positional and Associative carry an unstated assumption that the object in question will be using a discrete type such as Int or Str as the index or key. In the abstract, what we're talking about here is how one would handle an object that uses a continuous type such as Num as the index or key. As mentioned before, "loop through the members" (or, in the case of Junctions, "autothread the members") simply isn't feasible with a continuous key. One question is whether Intervals should be Positional (i.e., list-like) or Associative (i.e., Set-like). The former has the advantage that Ranges are Positional, meaning that Intervals would conform closely to Ranges, which is the intuitive result of having them share a constructor. The latter is what we both jumped to when we first considered the idea of Intervals in their own right: we want the Set operations, which Positional objects don't have; and indices aren't particularly useful for Intervals. As well, your concept about "disjoint intervals" maps quite nicely to a Set of Nums (or other continuous types such as Rat or Instant); with that concept, I'm not sure that we would actually _need_ an Interval type: we could just have the .. constructor return a Set of Num (or Rat, or Instant, etc.) when the step is zero, and a Range object otherwise. This, of course, assumes that Set is up to the task of handling the continuous nature of Num, and doesn't merely collect a bunch of discrete points on the Num line. So start by addressing the issue of how to handle continuous indices and/or keys. Are lists conceptually compatible with the notion of continuous indices, or is the whole idea too much of a divergence from the underlying concept? A basic assumption about lists is that if you provide custom indices for a list, they can be mapped one-to-one to non-negative integers; and continuous values, by definition, cannot be so mapped. So I'd say that whether or not continuous indices in general are viable, they are _not_ viable for List. Keys, OTOH, don't have any such requirement; so continuous keys may very well be doable. If they _are_ doable, you have to ask questions such as "how do I assign values to a continuous interval of keys?" To truly be robust, we ought also answer this question in terms of multidimensional keys, which can be a nightmare. -- Jonathan "Dataweaver" Lang
