For comprehension for Sodium in Scala - would be nice to have, wonder how to do

[jhegedus42]

Dear Sodiumers,

I am thinking about making Sodium a bit more Scala friendly and turning these lift-s into some sort of applicative functor or something, to begin with ... any thoughts ?

Something like this :

import cats.Functor

trait Applicative[F[_]] extends Functor[F] {
  def ap[A, B](ff: F[A => B])(fa: F[A]): F[B]

  def pure[A](a: A): F[A]

  def map[A, B](fa: F[A])(f: A => B): F[B] = ap(pure(f))(fa)
}

in any casy, I will just use lift for now, for a while, but eventually might look into cats and see if I can use some nice applicative syntax instead of lift-s...

Cheers

Jozsef

[jhegedus42]

Ok, this seems to compile :

  implicit val functorForCell: Functor[Cell] = new Functor[Cell] {
    def map[A, B](fa: Cell[A])(f: A => B): Cell[B] = fa.map(f)

  }

jhegedus42/irie/blob/ec41a021ac55705785f5e7a4b84946637b09863c/modules/client/src/main/scala/client/cache/relationalOperations/RelationalOperations.scala#L14-L14

so with cats we can have a proper Functor for Cell.

need to see if I can implement Applicative like this...

but that would need a pure, @the-real-blackh , how can I get a pure for Cell ?

Cheers,

Jozsef

[jhegedus42]

this what I have now :

jhegedus42/irie/blob/5d5b7bbe89134297c355028c4762dc48880ad371/modules/client/src/main/scala/client/cache/relationalOperations/CellOptionMonad.scala#L14-L14

It is a Cell[Option[_]] monad.

@the-real-blackh is the memory leak with switch bad ?

case class CellOption[A](co: Cell[Option[A]]) {

    def map[B](f: A => B): CellOption[B] = {
      new CellOption(co.map(_.map(f)))
    }

    def flatMap[B](f: A => CellOption[B]): CellOption[B] = {
      val g: A => Cell[Option[B]] = (a: A) => f(a).co

      val res1: Cell[Option[Cell[Option[B]]]] = co.map(_.map(g))
      val res2: Cell[Cell[Option[B]]] =
        res1.map(_.getOrElse(new Cell(None)))

      val res3: Cell[Option[B]] = Cell.switchC(res2)
      new CellOption[B](res3)
}

Any ideas how to write this without switch ?

I don't think it is possible.

[the-real-blackh]

@jhegedus42, hello!

pure is easy. It's just a constant cell.

It can't be written without switch. There will only be a leak on implementations that use the referencing counting memory management system (Javascript) if B contains a Sodium object.

[jhegedus42]

hi @the-real-blackh,

How bad is that leak?

I did run the Scala tests on node.js.

I did not see memory consumption rise... it was around 100M.

Has that kind of leak ever been "benchmarked" ? For example, some sort of counter which is incremented every time a Cell is created, and somehow decremented if the Cell gets collected ?

Is there an easy way to count the Sodium objects?

Cheers,

Jozsef

ps: Sodium with React on Scala.js is sweet, super stweet. I think it outdoes cycle.js, easily. It's a pure bliss. I compile stuff, and it works. Amazing.

[the-real-blackh]

@jhegedus42 First, just to re-state the issue so it's clear to anyone reading this:

Compiling the Scala version of Sodium to Javascript using Scala.js will give you an implementation that leaks because Scala.js does not compile finalizers properly - because it can't. Javascript just doesn't support them. To avoid this, you should use the Javascript version of Sodium, which implements memory management correctly for Javascript.

How bad is this leak? When he switch primitive performs a switch, an old object is replaced by a new one. The old object won't be cleaned up. But even worse, it will still process events for the old object, so it will leak CPU time as well.