zipped & map2 & friends

Hi Paul,

On Thu, 2009-11-19 at 08:25 -0800, Paul Phillips wrote:
> This expression would be much clearer if we had either of the following
> two functions. (Either of them would improve the above expression, but
> I think they both merit an addition.)
>
> 1) A generalization of Iterable.sameElements which doesn't assume ==.
> If we had something like
>
> def sameElementsUsing[B >: A](f: (B, B) => Boolean)(that: Iterable[B]): Boolean

Isn't this similar to the deprecated Seq.equalsWith (but in Iterable
instead)? And regarding the suffix, "With" is used in sort when we pass
a comparison function, is there some similarity here or do we want to
introduce the "Using" suffix?

Best,
Ismael

On Thu, Nov 19, 2009 at 04:42:58PM +0000, Ismael Juma wrote:
> Isn't this similar to the deprecated Seq.equalsWith (but in Iterable
> instead)?

It is. I wouldn't have deprecated the functionality (although the name
is suboptimal.)

> And regarding the suffix, "With" is used in sort when we pass a
> comparison function, is there some similarity here or do we want to
> introduce the "Using" suffix?

Yeah sorry, I wasn't trying to propose a name but a use.

On Thu, 2009-11-19 at 08:56 -0800, Paul Phillips wrote:
> On Thu, Nov 19, 2009 at 04:42:58PM +0000, Ismael Juma wrote:
> > Isn't this similar to the deprecated Seq.equalsWith (but in Iterable
> > instead)?
>
> It is. I wouldn't have deprecated the functionality (although the name
> is suboptimal.)

Yeah, it sounds useful. If it's resurrected, I suggest updating the
deprecation text in equalsWith to refer to the new method instead of
what's there at the moment.

Best,
Ismael

On Thu, Nov 19, 2009 at 6:09 PM, Ismael Juma wrote:
> On Thu, 2009-11-19 at 08:56 -0800, Paul Phillips wrote:
>> On Thu, Nov 19, 2009 at 04:42:58PM +0000, Ismael Juma wrote:
>> > Isn't this similar to the deprecated Seq.equalsWith (but in Iterable
>> > instead)?
>>
>> It is.  I wouldn't have deprecated the functionality (although the name
>> is suboptimal.)
>
> Yeah, it sounds useful. If it's resurrected, I suggest updating the
> deprecation text in equalsWith to refer to the new method instead of
> what's there at the moment.
>
equalsWith was deprecated mainly because the name was so misleading.
It has nothing to do with equality. I am open to other suggestions how
to replace it.

Cheers

Scalaz does it this way.

// instance ContravariantFunctor
trait Equal[-A] {
def equal(a1: A, a2: A): Boolean
}

Then provides a method === (that's 3 =) on an Identity type e.g. case
class Identity[+A](a: A) that takes an implicit Equal.

If you wish to override the Equal for some type T, then: case class U(t:
T); implicit val Equal[U] = ... then unwrap after the operation.

martin odersky wrote:
> On Thu, Nov 19, 2009 at 6:09 PM, Ismael Juma wrote:
>
>> On Thu, 2009-11-19 at 08:56 -0800, Paul Phillips wrote:
>>
>>> On Thu, Nov 19, 2009 at 04:42:58PM +0000, Ismael Juma wrote:
>>>
>>>> Isn't this similar to the deprecated Seq.equalsWith (but in Iterable
>>>> instead)?
>>>>
>>> It is. I wouldn't have deprecated the functionality (although the name
>>> is suboptimal.)
>>>
>> Yeah, it sounds useful. If it's resurrected, I suggest updating the
>> deprecation text in equalsWith to refer to the new method instead of
>> what's there at the moment.
>>
>>
> equalsWith was deprecated mainly because the name was so misleading.
> It has nothing to do with equality. I am open to other suggestions how
> to replace it.
>
> Cheers
>

I'd suggest Equivalent, but that doesn't seem to be a very common word in English. Similar? Comparable?

On Fri, Nov 20, 2009 at 7:07 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, Nov 19, 2009 at 6:09 PM, Ismael Juma <mlists@juma.me.uk> wrote:
> On Thu, 2009-11-19 at 08:56 -0800, Paul Phillips wrote:
>> On Thu, Nov 19, 2009 at 04:42:58PM +0000, Ismael Juma wrote:
>> > Isn't this similar to the deprecated Seq.equalsWith (but in Iterable
>> > instead)?
>>
>> It is.  I wouldn't have deprecated the functionality (although the name
>> is suboptimal.)
>
> Yeah, it sounds useful. If it's resurrected, I suggest updating the
> deprecation text in equalsWith to refer to the new method instead of
> what's there at the moment.
>
equalsWith was deprecated mainly because the name was so misleading.
It has nothing to do with equality. I am open to other suggestions how
to replace it.

Cheers

 -- Martin

--
Daniel C. Sobral

Veni, vidi, veterni.

On Fri, Nov 20, 2009 at 2:21 PM, Daniel Sobral wrote:
> I'd suggest Equivalent, but that doesn't seem to be a very common word in
> English. Similar? Comparable?

But that's not what it is, in general. For instance, one possible usage is this:

(xs equalsWith ys) (_ * _ > 100)

There's no trace of similarity or comparability here.

Cheers

On Fri, 2009-11-20 at 11:21 -0200, Daniel Sobral wrote:
> I'd suggest Equivalent, but that doesn't seem to be a very common word
> in English.

The Scala library has a class called Equiv, actually.

Best,
Ismael

Martin~

How about "matchesPredicate" or "fitsPredicate"?

Matt

On Fri, Nov 20, 2009 at 8:35 AM, martin odersky wrote:
> On Fri, Nov 20, 2009 at 2:21 PM, Daniel Sobral wrote:
>> I'd suggest Equivalent, but that doesn't seem to be a very common word in
>> English. Similar? Comparable?
>
> But that's not what it is, in general. For instance, one possible usage is this:
>
>  (xs equalsWith ys) (_ * _ > 100)
>
> There's no trace of similarity or comparability here.
>
> Cheers
>
>  -- Martin
>

On Fri, Nov 20, 2009 at 1:35 PM, martin odersky wrote:
> On Fri, Nov 20, 2009 at 2:21 PM, Daniel Sobral wrote:
>> I'd suggest Equivalent, but that doesn't seem to be a very common word in
>> English. Similar? Comparable?
>
> But that's not what it is, in general. For instance, one possible usage is this:
>
>  (xs equalsWith ys) (_ * _ > 100)
>
> There's no trace of similarity or comparability here.

I think the problem with equalsWith is that it has confusing echoes of
"x is equal with y" which would typically be read as meaning something
different from what we're trying to capture here.

I suggest,

equalsUnder

or,

equivalentsUnder

Cheers,

Miles

I thought we were moving from map2 & the like to zipped.<method>. It seems we're going backwards, reinventing forall2 under a different name.

iulian

On Fri, Nov 20, 2009 at 2:53 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Nov 20, 2009 at 1:35 PM, martin odersky <martin.odersky@epfl.ch> wrote:
> On Fri, Nov 20, 2009 at 2:21 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
>> I'd suggest Equivalent, but that doesn't seem to be a very common word in
>> English. Similar? Comparable?
>
> But that's not what it is, in general. For instance, one possible usage is this:
>
>  (xs equalsWith ys) (_ * _ > 100)
>
> There's no trace of similarity or comparability here.

I think the problem with equalsWith is that it has confusing echoes of
"x is equal with y" which would typically be read as meaning something
different from what we're trying to capture here.

I suggest,

 equalsUnder

or,

 equivalentsUnder

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Then that's just forall2.

On Fri, Nov 20, 2009 at 11:35 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Fri, Nov 20, 2009 at 2:21 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
> I'd suggest Equivalent, but that doesn't seem to be a very common word in
> English. Similar? Comparable?

But that's not what it is, in general. For instance, one possible usage is this:

 (xs equalsWith ys) (_ * _ > 100)

There's no trace of similarity or comparability here.

Cheers

 -- Martin

--
Daniel C. Sobral

Veni, vidi, veterni.

On Fri, Nov 20, 2009 at 3:00 PM, Iulian Dragos wrote:
> I thought we were moving from map2 & the like to zipped.. It seems
> we're going backwards, reinventing forall2 under a different name.
>
The main issue is that zipped truncates operands that are longer than
the mimimum one (and List.forall2 did the same thing), whereas
equalsWith returned false if the sequences have different length. But
in principle you are right. How about just forall on tuples? I.e.

(xs, ys) forall (_ < _) ?

Reads OK doesn't it? This would mean that tuples now support three methods:

zip
zipped
forall

Furthermore,

(xs, ys) forall p

is not the same as

(xs, ys).zipped forall p

if the lengths of xs and ys differ.

Cheers

>>>>> "martin" == martin odersky writes:

martin> The main issue is that zipped truncates operands that are
martin> longer than the mimimum one (and List.forall2 did the same
martin> thing), whereas equalsWith returned false if the sequences have
martin> different length. But in principle you are right. How about
martin> just forall on tuples? I.e.
martin> (xs, ys) forall (_ < _) ?
martin> Reads OK doesn't it? This would mean that tuples now support
martin> three methods:
martin> zip zipped forall
martin> Furthermore,
martin> (xs, ys) forall p
martin> is not the same as
martin> (xs, ys).zipped forall p
martin> if the lengths of xs and ys differ.

I don't think it's worth adding a method to tuples over. Let people
test the sizes separately if they need them to be equal. How often
can this come up?

On Fri, Nov 20, 2009 at 08:25:33AM -0600, Seth Tisue wrote:
> I don't think it's worth adding a method to tuples over. Let people
> test the sizes separately if they need them to be equal. How often
> can this come up?

You are morally obligated to assume that if I start a thread about it,
it comes up often enough. Perhaps the silence of the hundred threads a
day I DON'T start has been insufficiently deafening. (That's right, try
to make sense of that, I dare you.)

On Fri, Nov 20, 2009 at 03:00:41PM +0100, Iulian Dragos wrote:
> I thought we were moving from map2 & the like to zipped.. It
> seems we're going backwards, reinventing forall2 under a different
> name.

I should reiterate that I am overall really happy with the .zipped
regime and I don't want to go backwards. Martin is correct that this is
only about finding a clean way to express the requirement that there are
no leftover elements.

On Fri, Nov 20, 2009 at 03:12:00PM +0100, martin odersky wrote:
> How about just forall on tuples?

That would sound fine except for:

> (xs, ys) forall p
>
> is not the same as
>
> (xs, ys).zipped forall p
>
> if the lengths of xs and ys differ.

Unfortunately that feels more like a bug than a feature. It wouldn't be
a problem for me but for a change of pace I'm looking out for New Guy.

I would prefer some other name, forallTuples? Nothing good coming to
mind but I'm leery of reusing forall like that.

Isn't this just "forAllPairs" or something like that?

> Subject: Re: [scala-internals] zipped & map2 & friends
> From: mlists@juma.me.uk
> To: dcsobral@gmail.com
> CC: martin.odersky@epfl.ch; paulp@improving.org; scala-internals@listes.epfl.ch
> Date: Fri, 20 Nov 2009 13:41:45 +0000
>
> On Fri, 2009-11-20 at 11:21 -0200, Daniel Sobral wrote:
> > I'd suggest Equivalent, but that doesn't seem to be a very common word
> > in English.
>
> The Scala library has a class called Equiv, actually.
>
> Best,
> Ismael
>

View your other email accounts from your Hotmail inbox. Add them now.

Apols - sent too soon:

(xs forallPairs ys) ( _ * _ > 100)

From: oxbow_lakes@hotmail.com
To: mlists@juma.me.uk; dcsobral@gmail.com
CC: martin.odersky@epfl.ch; paulp@improving.org; scala-internals@listes.epfl.ch
Subject: RE: [scala-internals] zipped & map2 & friends
Date: Fri, 20 Nov 2009 17:36:46 +0000

.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Verdana;} Isn't this just "forAllPairs" or something like that?

> Subject: Re: [scala-internals] zipped & map2 & friends
> From: mlists@juma.me.uk
> To: dcsobral@gmail.com
> CC: martin.odersky@epfl.ch; paulp@improving.org; scala-internals@listes.epfl.ch
> Date: Fri, 20 Nov 2009 13:41:45 +0000
>
> On Fri, 2009-11-20 at 11:21 -0200, Daniel Sobral wrote:
> > I'd suggest Equivalent, but that doesn't seem to be a very common word
> > in English.
>
> The Scala library has a class called Equiv, actually.
>
> Best,
> Ismael
>

View your other email accounts from your Hotmail inbox. Add them now.
Add other email accounts to Hotmail in 3 easy steps. Find out how.

How about

(xs corresponds ys) (p) ?

That's more neutral than equalsWith and at the same time expresses (somewhat)
that lengths are taken into account.

Cheers

No one answered, but it was the best so far, in my opinion.

On Fri, Dec 11, 2009 at 4:54 AM, martin odersky <martin.odersky@epfl.ch> wrote:

How about

(xs corresponds ys) (p)  ?

That's more neutral than equalsWith and at the same time expresses (somewhat)
that lengths are taken into account.

Cheers

FWIW, we use a generalisation of map2 (see Applicative Programming with
Effects):

trait Applicative[F[_]] extends Functor[F] {
def pure[A](a: A): F[A]
def apply[A, B](f: F[A => B], a: F[A]): F[B]
}

From which a general map2 can be derived:

def map2[A, B, C](f: (A, B) => C, a: F[A], b: F[B]): F[C]

It also generalises to run over any Traversable over C.

Ultimately, the client code looks like:

xs ⊛ (ys ∘ p)

Daniel Sobral wrote:
> No one answered, but it was the best so far, in my opinion.
>
> On Fri, Dec 11, 2009 at 4:54 AM, martin odersky
> > wrote:
>
> How about
>
> (xs corresponds ys) (p) ?
>
> That's more neutral than equalsWith and at the same time expresses
> (somewhat)
> that lengths are taken into account.
>
> Cheers
>
> -- Martin
>
>
>
>

scala> val i = Stream(1,2,3) ⊛ (Stream(4, 5, 6, 7) ∘ ((_: Int) + (_:
Int)).curry) toList // standard flatMap-like applicative functor
i: List[Int] = List(5, 6, 7, 6, 7, 8, 7, 8, 9, 8, 9, 10)

scala> val j = (Stream(1,2,3) ʐ) ⊛ ((Stream(4, 5, 6, 7) ʐ) ∘ ((_: Int) +
(_: Int)).curry) toList // zip-list applicative functor (no
corresponding monad)
j: List[Int] = List(5, 7, 9)

Tony Morris wrote:
> FWIW, we use a generalisation of map2 (see Applicative Programming with
> Effects):
>
> trait Applicative[F[_]] extends Functor[F] {
> def pure[A](a: A): F[A]
> def apply[A, B](f: F[A => B], a: F[A]): F[B]
> }
>
> >From which a general map2 can be derived:
>
> def map2[A, B, C](f: (A, B) => C, a: F[A], b: F[B]): F[C]
>
> It also generalises to run over any Traversable over C.
>
> Ultimately, the client code looks like:
>
> xs ⊛ (ys ∘ p)
>
>
> Daniel Sobral wrote:
>
>> No one answered, but it was the best so far, in my opinion.
>>
>> On Fri, Dec 11, 2009 at 4:54 AM, martin odersky
>> > wrote:
>>
>> How about
>>
>> (xs corresponds ys) (p) ?
>>
>> That's more neutral than equalsWith and at the same time expresses
>> (somewhat)
>> that lengths are taken into account.
>>
>> Cheers
>>
>> -- Martin
>>
>>
>>
>>

Tony, the problem consists in finding out the following:   For Traversables t1, t2, ... tn, t1.size == t2.size == ... == tn.size && for every index i of these traversables, p(t1(i), t2(i), ... tn(i)).   For instance, the sample code written by Paul at the very beginning of the thread:    (types.length == other.types.length) &&
 ((types, other.types).zipped forall ((t1, t2) => t1 <:< t2 || t2 <:< t1))   Also, one of his suggestions:   1) A generalization of Iterable.sameElements which doesn't assume ==.

On Wed, Dec 16, 2009 at 9:37 AM, Tony Morris <tonymorris@gmail.com> wrote:

scala> val i = Stream(1,2,3) ⊛ (Stream(4, 5, 6, 7) ∘ ((_: Int) + (_:
Int)).curry) toList // standard flatMap-like applicative functor
i: List[Int] = List(5, 6, 7, 6, 7, 8, 7, 8, 9, 8, 9, 10)

scala> val j = (Stream(1,2,3) ʐ) ⊛ ((Stream(4, 5, 6, 7) ʐ) ∘ ((_: Int) +
(_: Int)).curry) toList // zip-list applicative functor (no
corresponding monad)
j: List[Int] = List(5, 7, 9)


Tony Morris wrote:
> FWIW, we use a generalisation of map2 (see Applicative Programming with
> Effects):
>
> trait Applicative[F[_]] extends Functor[F] {
>   def pure[A](a: A): F[A]
>   def apply[A, B](f: F[A => B], a: F[A]): F[B]
> }
>
> >From which a general map2 can be derived:
>
> def map2[A, B, C](f: (A, B) => C, a: F[A], b: F[B]): F[C]
>
> It also generalises to run over any Traversable over C.
>
> Ultimately, the client code looks like:
>
> xs ⊛ (ys ∘ p)
>
>
> Daniel Sobral wrote:
>
>> No one answered, but it was the best so far, in my opinion.
>>
>> On Fri, Dec 11, 2009 at 4:54 AM, martin odersky
>> <martin.odersky@epfl.ch <mailto:martin.odersky@epfl.ch>> wrote:
>>
>>     How about
>>
>>     (xs corresponds ys) (p)  ?
>>
>>     That's more neutral than equalsWith and at the same time expresses
>>     (somewhat)
>>     that lengths are taken into account.
>>
>>     Cheers
>>
>>      -- Martin
>>
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>
>

--
Tony Morris
http://tmorris.net/

--
Daniel C. Sobral

I travel to the future all the time.

On Fri, Dec 11, 2009 at 07:54:11AM +0100, martin odersky wrote:
> (xs corresponds ys) (p) ?
>
> That's more neutral than equalsWith and at the same time expresses
> (somewhat) that lengths are taken into account.

Can I jump to the conclusion that you really mean something like:

(xs, ys).zipped corresponds p

? As written up top it would have to be a method on Traversable and it
doesn't move naturally to higher arities. If corresponds is a method on
Tuple2#Zipped and friends then everything is in the right place. And
zipped already has all the relevant machinery, so corresponds ends up
being forall && (all iterators are empty).

Although this is obviously not the most general imaginable function, I'd
find it pretty useful.

On Wed, Dec 16, 2009 at 3:56 PM, Paul Phillips wrote:
> On Fri, Dec 11, 2009 at 07:54:11AM +0100, martin odersky wrote:
>> (xs corresponds ys) (p)  ?
>>
>> That's more neutral than equalsWith and at the same time expresses
>> (somewhat) that lengths are taken into account.
>
> Can I jump to the conclusion that you really mean something like:
>
>  (xs, ys).zipped corresponds p
>
No, I meant the binary only method on Traversable. On second thought,
yes, we could add corresponds to zipped. This would let it be extended
to higher arities, which is good. But the name corresponds is less
natural than for the binary version. How about:

(xs, ys).zipped uniformly p

Cheers

On Wed, Dec 16, 2009 at 04:35:33PM +0100, martin odersky wrote:
> No, I meant the binary only method on Traversable. On second thought,
> yes, we could add corresponds to zipped. This would let it be extended
> to higher arities, which is good. But the name corresponds is less
> natural than for the binary version. How about:
>
> (xs, ys).zipped uniformly p

I feel like the ideal name is some variation on forall, although no good
one comes to mind. forallEven? Or even forallUniformly. That's a bit
hideous but the method is so close to forall, it seems a shame to use a
name from the other end of the dictionary.

forallSameLength? forallEquallySized? Now we are back at the beginning. But corresponds on Traversable isn't bad.   As a side note, I like very much the _1 tangent.

On Wed, Dec 16, 2009 at 1:50 PM, Paul Phillips <paulp@improving.org> wrote:

On Wed, Dec 16, 2009 at 04:35:33PM +0100, martin odersky wrote:
> No, I meant the binary only method on Traversable. On second thought,
> yes, we could add corresponds to zipped. This would let it be extended
> to higher arities, which is good. But the name corresponds is less
> natural than for the binary version. How about:
>
>   (xs, ys).zipped uniformly p

I feel like the ideal name is some variation on forall, although no good
one comes to mind.  forallEven? Or even forallUniformly.  That's a bit
hideous but the method is so close to forall, it seems a shame to use a
name from the other end of the dictionary.

--
Paul Phillips      | It is hard to believe that a man is
Moral Alien        | telling the truth when you know that you
Empiricist         | would lie if you were in his place.
slap pi uphill!    |     -- H. L. Mencken

--
Daniel C. Sobral

I travel to the future all the time.

Sorry, when I say Traversable I mean:

trait Traversable[T[_]] {
def traverse[A, B](t: T[A], f: A => F[B])(implicit a: Applicative[F]):
F[T[B]]
} // see The Essence of the Iterator Pattern

Daniel Sobral wrote:
> Tony, the problem consists in finding out the following:
>
> For Traversables t1, t2, ... tn, t1.size == t2.size == ... == tn.size
> && for every index i of these traversables, p(t1(i), t2(i), ... tn(i)).
>
> For instance, the sample code written by Paul at the very beginning of
> the thread:
>
> / (types.length == other.types.length) &&
> ((types, other.types).zipped forall ((t1, t2) => t1 <:< t2 || t2 <:<
> t1))/
>
> Also, one of his suggestions:
>
> /1) A generalization of Iterable.sameElements which doesn't assume ==./
>
> On Wed, Dec 16, 2009 at 9:37 AM, Tony Morris > wrote:
>
> scala> val i = Stream(1,2,3) ⊛ (Stream(4, 5, 6, 7) ∘ ((_: Int) + (_:
> Int)).curry) toList // standard flatMap-like applicative functor
> i: List[Int] = List(5, 6, 7, 6, 7, 8, 7, 8, 9, 8, 9, 10)
>
> scala> val j = (Stream(1,2,3) ʐ) ⊛ ((Stream(4, 5, 6, 7) ʐ) ∘ ((_:
> Int) +
> (_: Int)).curry) toList // zip-list applicative functor (no
> corresponding monad)
> j: List[Int] = List(5, 7, 9)
>
>
> Tony Morris wrote:
> > FWIW, we use a generalisation of map2 (see Applicative
> Programming with
> > Effects):
> >
> > trait Applicative[F[_]] extends Functor[F] {
> > def pure[A](a: A): F[A]
> > def apply[A, B](f: F[A => B], a: F[A]): F[B]
> > }
> >
> > >From which a general map2 can be derived:
> >
> > def map2[A, B, C](f: (A, B) => C, a: F[A], b: F[B]): F[C]
> >
> > It also generalises to run over any Traversable over C.
> >
> > Ultimately, the client code looks like:
> >
> > xs ⊛ (ys ∘ p)
> >
> >
> > Daniel Sobral wrote:
> >
> >> No one answered, but it was the best so far, in my opinion.
> >>
> >> On Fri, Dec 11, 2009 at 4:54 AM, martin odersky
> >>
> >>
> wrote:
> >>
> >> How about
> >>
> >> (xs corresponds ys) (p) ?
> >>
> >> That's more neutral than equalsWith and at the same time
> expresses
> >> (somewhat)
> >> that lengths are taken into account.
> >>
> >> Cheers
> >>
> >> -- Martin
> >>
> >>
> >>
> >>
> >> --
> >> Daniel C. Sobral
> >>
> >> I travel to the future all the time.
> >>
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>