Mason Kramer wrote:
> I'd like to anticipate one objection to this - the existence of the 'hyper'
> operator/keyword. The hyper operator says, "I am taking responsibility for
> this particular code block and promising that it can execute out of order and
> concurrently". Creating a Bag instead of an Array says, "there is no meaning
> to the ordering of this group of things, ever". Basically, if I know at
> declaration time that my collection has no sense of ordering, then I
> shouldn't have to annotate every iteration of that collection as having no
> sense of ordering, which is nearly what hyper does (though, I readily admit,
> not quite, because there are unordered ways to create race conditions).
My understanding of the hyperoperator is that its primary use is to
say "operate on the individual elments of this collection, instead of
on the collection itself". In that regard, it's just as applicable to
Bags and Sets as it is to lists. Except...
Except that the hyperoperator assumes that the collections are
ordered. It matches the first element on the left with the first
element on the right; the second element on the left with the second
on the right; and so on. Bags and Sets don't have a useful notion of
"first", "second", etc. So what should happen if I try to apply a
hyperoperator with a Bag or Set on one side?
The cross operators should also be looked at in this regard, though I
anticipate fewer problems there.
> This, however, probably requires a change to S03, which says that the @ sigil
> is a means of coercing the object to the "Positional (or Iterable?)" role.
> It seems to me, based on the guiding principle that perl6 should support
> functional idioms and side-effect free computing, the more fundamental and
> important aspect of things with @ in front is that you can go through them
> one by one, and not that they're ordered (since ordering is irrelevant in
> functional computing, but iterating is not). My feeling is that we should
> reserve the special syntax for the more fundamental of the two operations, so
> as not to bias the programmer towards rigid sequentiality through syntax.
I tend to agree here - though to be clear, "my @x" should still
normally result in a list, sans further embellishments (e.g., "my Bag
@x").
> Second, I would be even more likely to replace my ordered lists with Bags if
> there were a convenient operator for constructing Bags. I can't think of any
> good non-letter symbols that aren't taken right now (suggestions welcome),
> but, at least, &b and &s as aliases to bag and set would be convenient.
Such a character ought to be some sort of punctuation, preferably of a
type that's similar to the comma and semicolon. For a Bag, you might
consider an emdash ("—"), with the ascii equivalent being infix:<-->.
So:
1 -- 2 -- 3
Would be a Bag containing three elements: 1, 2, and 3.
Personally, I wouldn't put a high priority on this; for my purposes,
Bag(1, 2, 3)
works just fine.
--
Jonathan "Dataweaver" Lang
