Type class with just point and map?

[Tomas Mikula]

Hi,

is there a type class with just the operations `map` and `point`? Functor is too weak, Applicative seems too strong.

To add more context to what I'm trying to do:

I want to lift a function K => F[V] which, for a given key, fetches the value (from disk, internet, ...), into a function that first tries to look up the value in the cache (of type Map[K, V]), and if not found, fetches the value and adds it to the cache. I thought of threading the cache as the state of the state monad. This is what I've got:

type CacheT[F[_], K, V] = StateT[F, Map[K, V], V]

def lift[F[_]: Applicative, K, V](fetch: K => F[V]): K => CacheT[F, K, V] =
  k => StateT(cache => {
    cache.get(k) match {
      case Some(v) => (cache, v).point[F]
      case None    => fetch(k) map { v => (cache + (k -> v), v) }
    }
  })

As you can see, I require F to be Applicative, but I'm really just using point and map in the implementation, so Applicative seems unnecessarily constraining.

Thanks,

Tomas

[Derek Chen-Becker]

Just taking a quick look at the source, I don't think there is such a beast. Out of curiosity, what do you find too constraining about Applicative?

Cheers,

Derek

[Colt Frederickson]

The idea does exist, it's called a "Pointed Functor". If I recall the reason it doesn't exist in Scalaz is because it has no laws beyond what Functor provides.

I was trying to come up with a way that Coyoneda could solve your problem, but it doesn't have point either.

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
Visit this group at http://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.

[Tomas Mikula]

Hi Derek,

I just felt that I should not ask for more than I need. Namely, if I
only need point and map, I should not ask for an Applicative. That's
all.

Tomas

[Tomas Mikula]

Interesting. Thanks for the name.

Wouldn't the following be a desired law?

point[A](a) map f = point[B](f(a))


Tomas

[Derek Chen-Becker]

Thanks, Tomas!

I'm all for minimal type requirements, I just didn't know if there might be some other issue I wasn't considering.

Cheers,

Derek

You received this message because you are subscribed to a topic in the Google Groups "scalaz" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalaz/D3onUKvvaRw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalaz+un...@googlegroups.com.

[Tony Morris]

Consider: are you able to provide an instance that violates this law?

[Tomas Mikula]

I am, but only in a way that also breaks the functor laws.

Tomas

[Tony Morris]

Exactly :)

[Tomas Mikula]

Meaning the law I made up does not add any extra information.

[Tony Morris]

The history of this question follows.

Edward Kmett and I were working on similar problems in parallel. I was
working for a small product company, trying to make sense of the
software world in that context. The need for "Pointed" came up. This
situation is probably similar to what you might have at the moment.

Ed and I independently pondered the utility of the Pointed type-class. I
wrote it into Scalaz. I saw that Ed had written it in Haskell. Here it
is in the old Scalaz 6:

http://scalaz.github.io/scalaz/scalaz-2.9.1-6.0.4/doc.sxr/scalaz/Pointed.scala.html

For myself, I had not asked the question of whether or not there were
laws for Pointed. I just assumed, "yeah probably; someone smarter than
me can work those out."

After some time using Pointed in practice, I started bumping into some
of the consequences of the absence of laws on Pointed. I would wonder to
myself if this thing truly is useful. Then I watched someone demonstrate
to me that the only possible law (the one you gave), is given by
parametricity anyway.

Ed was quick to withdraw support for this type-class (on the basis of no
laws I think?), but I did not. I was not convinced that this was
justification for such a drastic action. However, I was argued into it
by others and I hold that position today.

However, since then, the Pointed type-class has been reintroduced by Ed
and I think it is used in the lens package.

https://github.com/ekmett/pointed

I don't know of the reasons specifically for this change.

On 25/05/15 13:15, Tomas Mikula wrote:

[Tomas Mikula]

Thanks for the background on this!

On Sun, May 24, 2015 at 11:24 PM, Tony Morris <tonym...@gmail.com> wrote:
> The history of this question follows.
>
> Edward Kmett and I were working on similar problems in parallel. I was
> working for a small product company, trying to make sense of the
> software world in that context. The need for "Pointed" came up. This
> situation is probably similar to what you might have at the moment.
>
> Ed and I independently pondered the utility of the Pointed type-class. I
> wrote it into Scalaz. I saw that Ed had written it in Haskell. Here it
> is in the old Scalaz 6:
>
> http://scalaz.github.io/scalaz/scalaz-2.9.1-6.0.4/doc.sxr/scalaz/Pointed.scala.html
>
> For myself, I had not asked the question of whether or not there were
> laws for Pointed. I just assumed, "yeah probably; someone smarter than
> me can work those out."
>
> After some time using Pointed in practice, I started bumping into some
> of the consequences of the absence of laws on Pointed. I would wonder to
> myself if this thing truly is useful.

Should I read this as: after refactoring your code, the need for
Pointed disappeared?

Tomas

[Derek Chen-Becker]

Thanks for the history on this!

You received this message because you are subscribed to a topic in the Google Groups "scalaz" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalaz/D3onUKvvaRw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalaz+un...@googlegroups.com.

[Jed Wesley-Smith]

some related conversation:

https://groups.google.com/forum/#!topic/scalaz/Io_mqe5iB8U

[Jed Wesley-Smith]

and here is an excellent post on the subject:

https://www.fpcomplete.com/user/gbaz/building-up-to-a-point-via-adjunctions

[Tomas Mikula]

Thanks, Jed,

I read through the links. My conclusion is that the argument against
Pointed is not that "it does not add any laws to Functor", but rather
that "it does not add enough laws to ensure uniqueness of point" (it
just so happens that it does not add any laws at all). The latter is a
more convincing argument; "some additional laws" per se seem to me no
better than "no additional laws". To make sure the same argument
cannot be used to rule out Applicative, I checked, as an exercise,
that Applicative laws guarantee uniqueness of point.

Tomas