Discussion: Introducing new operators for matrix computation

[Bjorn Pettersen]

Gareth McCaughan wrote:
> 
> Paul Prescod wrote:
> 
> [I said:]
[snip]
> >
> > Today, the list comprehension syntax is syntactic sugar for
> >
> > a=[]
> > for i in firstloop:
> >       for j in secondloop: ...
> >               a.append( i, j )
> >
> > I don't see any easy way to guess what type you want as "output" so it
> > has to default to a fixed type. You could of course do this:
> >
> > Matrix( [...] )
> >
> > I would be curious about ideas for allowing the output object to be
> > specified or inferred. What would the protocol be?
> 
> Well, I was making a broken assumption about the meaning of
> multiple comprehension indices: namely, that
>   [(i,j) for i in [1,2], j in [1,2]]
> would evaluate to [(1,1), (2,2)] rather than [(1,1), (1,2), (2,1), (2,2)].
> If it's supposed to go the other way, then some of my other
> assumptions stop working. :-)

Personally, I think the paralell iteration would be easier to explain
(which is why I would prefer that semantics to list-comprehensions with
cartesian product and zip for paralell iteration).

> However: I had been thinking along the following lines.
> [expr for var in val] should produce something of the same
> type as val, with the property that result[i] == expr(val[i])
> for each legal index i. (Or something of the sort.)

That would indeed be nice, and perhaps even doable for single
iteration...

[snip]

> With more than one collection being iterated over, as in
> [blah blah blah for x in xs, y in ys], the simplest thing
> would be to use the first collection mentioned as template
> and source of valid indices. (This is the thing that fails
> totally if we're doing cartesian products rather than parallel
> iteration.)

Nah, this won't work... The second collection would be just as valid for
a template, and -- "In the face of ambiguity, refuse the temptation to
guess."

-- bjorn