shajra

package learning


trait Functor[F[_]] {
  def map[A,B](a: F[A])(f: A => B): F[B]
}


trait Monad[M[_]] extends Functor[M] {
  def point[A](a: A): M[A]

shajra

package implicits {

  package a {

    case class Foo(i: Int)

    object FooApp extends App {
      Foo(1).rich
    }

shajra

When scala.util.Try first came out, there was a lot of discussions about the validity of it's implementation. Some discussions got distracted with issues beyond the facts. Ultimately, the issue came down to the following:

1. Is Try a monad?

2. Does referential transparency (RT) apply in the presence of possible non-terminating or errant functions -- those returning ⊥?

Not requiring Try to be a monad is an easy solution to the whole problem. If

shajra

import concurrent.{ExecutionContext, Future => SFuture, Promise}                 
import util.Try                                                                                                 
                                                                                                                
import _root_.scalaz.\/                                                                                         
import _root_.scalaz.concurrent.{Task => ZTask}                                                                 
                                                                                                                
                                                                                                                
object Task {                                                                                                   
                                                                                                                
  def fromScala[A]                    

shajra

def newExistential[S]
    (producer: Inputs => S, consumer: S => Output)
    : Existential = {
  type SS = S
  val producer_ = producer
  val consumer_ = consumer
  new Existential {
    type S = SS
    def producer(is: Inputs) = producer_(is)
    def consumer(s: S) = consumer_(s)

shajra

Questions in Response to Rod Johnson's "Scala in 2018" Scala Days 2013 Keynote Talk

The following is a list of controversial quotes from the talk with time markers. Interspersed among these quotes are questions many in the Scala community would like for Rod to respond to.

This may be useful for a panel discussion with Rod.

shajra

trait CallStrategy[C, E] {

  type State[_]

  def call
      (desc: CallDesc[C],
        state: State[C],
        pool: ExecutionContextExecutorService)
      : Task[E \/ Media]

shajra

import scalaz._
import Scalaz._
import Free._

/** "Pure" interactions with a console. */
sealed trait Console[+A]
case class GetLine[A](k: String => A) extends Console[A]
case class PutLine[A](s: String, a: A) extends Console[A]

object Console {

shajra

Type Erasure Is Good

let's stick the the facts

A lot of the answers thus far are overly concerned with the Twitter user. It's helpful to keep focused on the messages and not the messenger. There is a fairly consistent message with the even just the excerpts mentioned thus far:

It's funny when Java users complain about type erasure, which is the only thing Java got right, while ignoring all the things it got wrong.

I get huge benefits (e.g. parametricity) and nil cost (alleged cost is a limit of imagination).

shajra

-- The package version.  See the Haskell package versioning policy (PVP)         
-- for standards guiding when and how versions should be incremented.            
-- http://www.haskell.org/haskellwiki/Package_versioning_policy                  
-- PVP summary:      +-+------- breaking API changes                             
--                   | | +----- non-breaking API additions                       
--                   | | | +--- code changes with no API change                  
version:             0.1.0.0