g meredith scala

Monadic Design Patterns for the Web

Session 1

Monday, October 17, 2011

Lucius Gregory Meredith, Managing Partner, Biosimilarity LLC -- SDEC 2011

Agenda

• What to expect

• Who is the audience

• Why monads

• The monadic toolbox

• A simple example

• Another simple example



Agenda (cont)

• Hinting at a more complex example

• Where we might go from here

• Questions?



What to expect

• Fun!

• Simplicity!

• Engagement!

• Ok... and some challenge

• Occasionally, people’s brains do melt out of their ears...



What to expect

Browser

Container

Resource

Domain Logic

Service



What to expect

Browser

Container

Resource

Domain Logic

Service

Monads for managing streams



What to expect

Browser

Container

Resource

Domain Logic

Service

Monads for managing requests




What to expect

Browser

Container

Resource

Domain Logic

Service


Monads for domain model




What to expect

Browser

Container

Resource

Domain Logic

Service


Monads for domain model


Monads for accessing store



What to expect

Browser

Container

Resource

Domain Logic

Service

Parsing combinators

Algebraic data types

streams and continuations

LINQXQuery

SQL



What to expect

• Monads provide a practical abstraction for everyday sorts of control flow and data structure in modern web app

• If objects were supposed to be the packaging of control and structure that provided optimal reuse, then monads seem to be a better object than object



Who is the audience

• People who write code that serves a purpose

• Monads will feel natural to those with 2yrs functional programming

• Or, people who have 2yrs with distributed and network programming

• Nota bene: all code examples in Scala!



Who is the audience

• But, really, monads are everywhere!



Why monads

• To manage complexity

• Monads help your code scale

• Abstract structure and control

• Engage the compiler more

• Compositional



The monadic toolbox

• What is a monad?

• Shape, wrap and roll, baby!

• Monads in a larger context

• Comprehensive comprehensions!


• Three key ingredients in a monad

• Shape

• wrap

• roll

Shapely monads


Embracing shape

“eh?”

“eh?”

“eh?”

“monads”

“eh?”

“monads,”wrap

roll

Shape


• Monads may be canonically thought of as a way to structure an interface to “colored” braces

• Shape -- the color of the braces

• wrap -- putting things between braces

• roll -- flattening nested braces (i.e. rolling them up)

Embracing shape

[ ]

[ ]“eh?”

[ ]“monads” [ ]“eh?”[ ]

“monads” “eh?”[ ],


Shape : <red> ... </red>

wrap : queen => <red>queen</red>

roll : <red><red>knight</red><red>queen</red></red>

=>

<red>knight queen</red>

Embracing shape


Shape : <list> ... </list>

wrap : queen => <list>queen</list>

roll : <list><list>knight</list><list>queen</list></list>

=>

<list>knight queen</list>

Data structures as “colored” braces


Shape : <set> ... </set>

wrap : queen => <set>queen</set>

roll : <set><set>knight</set><set>queen</set></set>

=>

<set>knight queen</set>

Data structures as “colored” braces


• List and Set are actually the same structure up to a certain point -- the difference can be captured by a set of equations that Sets obey and Lists don’t

• a + b = b + a

• a + a = a

• How do we relate these equations to Shape, wrap and roll?

Monads refactor container code


a + b could just as easily be written +( a, b )

which could just as easily be written <+> a b </+>

which could just as easily be written

roll( <+><+>a</+><+>b</+></+> )

which could just as easily be written

roll( <+> wrap( a ) wrap( b ) </+> )

or

roll( wrap( a ) + wrap( b ) )



wrap( a ) + wrap( b )

in the case of both List and Set

as long as we have safely ‘wrapped’ everything, then ‘+’ is the natural polymorphic interpretation in the ‘container’

Set1 + Set2 := Set1 U Set2

List1 + List2 := List1 append List2



Set1 U Set2 == Set2 U Set1 (not true of Lists)

Set1 U Set1 == Set1 (not true of Lists)



wrap( a ) + wrap( b )

<set><set>a</set> <set>b</set></set>

if this is really Set then this has to be the same as

<set><set>b</set> <set>a</set></set>

aka

wrap( b ) + wrap( a )



• So List and Set can actually be thought of as factored into two pieces of information

• ( M, equations )

where

• M is the colored brace structure (Shape-wrap-n-roll)

• the equations give additional constraints about how braces behave.

• Lists have no additional equations -- such structures are called free.



Every monad can be seen as a version of a data structure that has a ‘+’ and a unit for the ‘+’, 1.

We’ve seen how the brace metaphor gives a simple model of how the extra structure of wrap and roll allow to extend

‘+’ over entities we put inside the monadic container

roll( wrap( a ) + wrap( b ) )

It also relates the unit, 1, of the ‘+’ to wrap (which is often called the unit of the monad)



The unit of the ‘+’ has a canonical representation as the empty braces:

<red> </red>

roll( <red><red> </red> <red> queen </red></red> )

=

<red> queen </red>

=

roll( <red><red> queen </red><red> </red></red> )




A simple exampleclass MList[A]( elems : A* )

extends List[A]( elems ) {

def wrap ( a : A ) : MList[A] = {

new MList( a )

}

def roll ( mma : MList[MList[A]] ) : MList[A] = {

( Nil /: mma )( ( acc, ma ) => acc.append( ma ) )

}

}



A simple example (cont)

• What can we say about this code?

• What about legacy uses of List?

• What about future uses of List?



A simple example

trait Option[+A]

case class Some[+A]( a : A ) extends Option[A]

case object None extends Option[Nothing]

for( Some( a ) <- optA ) yield { f( a ) }



Another simple example

trait LeftRightTree[A]

case class Leaf[A]( a : A )

extends LeftRightTree[A]

case class Branch[A](

left : List[LeftRightTree[A]],

right : List[LeftRightTree[A]]

) extends LeftRightTree[A]



Another simple example (cont)

• We have a choice when we implement unit

def wrap( a : A ) : LeftRightTree[A] = {

Branch( List( a ), Nil )

}

or

def wrap( a : A ) : LeftRightTree[A] = {

Branch( Nil, List( a ) )

}


Lucius Gregory Meredith, Managing Partner, Biosimiliarity LLC

The Monadic API as a View

trait Monad[M[_]] {

def unit [A] ( a : A ) : M[A]

def bind [A,B] ( ma : M[A], fn : A => M[B] ) : M[B]

}

shape

wrap

jelly roll

if you google for Shape, wrap and roll, you’ll only find my

presentations; if you use unit/yield/return and mult/bind,

you’ll find lots of hits



A word about presentations

def bind [A,B] ( ma : M[A], f : A => M[B] ) : M[B] = {

mult( fmap( f )( ma ) )

}

def mult [A] ( mma : M[M[A]] ) : M[A] = {

bind[M[A],A]( mma, ( ma ) => ma )

}

def fmap [A,B] ( f : A => B ) : M[A] => M[B]

i confess! this is all a plot to expose you subliminally to

Category Theory




class ListM[A] extends Monad[List] {

override def unit [S] ( s : S ) : List[S] = { List[S]( s ) }

override def bind [S,T] ( ls : List[S], fn : S => List[T] ) = {

( ( Nil : List[T] ) /: ls )( { ( acc, e ) => { acc ++ fn( e ) } } )

}

}


• Extensional

• We can explicitly give each element of the collection

• Intensional

• We must specify the elements programmatically -- such as by a rule

Two kinds of collections


Shape : <red> ... </red>

wrap : queen => <red>queen</red>

roll : <red><red>knight</red><red>queen</red></red>

=>

<red>knight queen</red>

Embracing shape


• Extensional -- examples

• { a, b, c }

• ( 1, 2, 3 )

• f(1) + g(2) + h(3)

• Intensional

• { a in Nat | a % 2 == 0 }

• fibs = 0 :: 1 :: zipWith (+) fibs (tail fibs)

• ∑ fi( i )

Two kinds of collections


• Infinite collections -- fibs, primes, etc, and also languages!

• Compressed collections -- individual elements are more easily computed than stored or otherwise expressed

• Collections calculated from data from the environment -- such as user input

Situations and intensions


• Infinite collections require some form of laziness or “just-in-time-ness” to avoid consuming all available memory

• Compressed collections can make use of laziness to avoid consuming compute cycles until it’s necessary

• Lazy also blurs the boundary between computing something just in time and waiting on i/o

Intensionally lazy


In the stream...

• More importantly the web 2.0 is teaching us that what initially looks like a small thing

type TwitterMsg = Char [140] // not legal Scala

becomes pretty valuable when it is iterated into a stream

abstract class TwitterStream

case class Twitterful( msg : TwitterMsg, strm : TwitterStream ) extends TwitterStream


{ pattern | generator1, ..., generatorM, condition1, ..., conditionN }

≈for( generator1; ...; generatorM; condition1;...; conditionN )

yield { pattern }

≈SELECT pattern FROM generator1, ..., generatorN

WHERE condition1, ..., conditionN

Intensions and comprehensions


Consider Set[A]

{ a, b, c, ... }

the language of extensional collections comes from the constructors of the type, A, we said we’d put in the collection, together with the Set operators


where does the language of patterns and conditions come from?



If monads are like containers, where’s the “take something out of the container interface”?





trait Monad[M[_]] {

def unit [A] ( a : A ) : M[A]

def bind [A,B] ( ma : M[A], fn : A => M[B] ) : M[B]

}

shape

wrap

jelly roll


Q: When can you check an element out of a monad?

A: With map you can check out (anything) any time you want, but you can never leave!

f : A => B

M[f] : M[A] => M[B]

Intensions and the Ruby Slippers


def transformResults(

normalizeResults : A => B

) : Option[B] = {

val intermediateRslts : Option[A] = getRawResults( ... )

for( rslt <- intermediateRslts ) yield {

normalizeResults( rslt )

}

}

Intensions and the Ruby Slippers


for( ptn <- src ; if condition ) yield { e( ptn ) }

≈src.map(

p => p match {

case ptn => if condition { e( ptn ) }

case _ => throw new Exception( “” )

}

)




≈src.map(

p => p match {



}

)

Intensions and comprehensionsSELECT pattern FROM generator1, ..., generatorN



Comprehension syntax

for( x <- expr1 ; y <- expr2 ; <stmts> ) yield expr3 = expr1 flatMap(

x => for( y <- expr2; <stmts> ) yield expr3

)

for( x<-expr1 ; y = expr2 ;<stmts> ) yield expr3 =

for(

( x, y ) <-

for( x <- expr1 ) yield ( x , expr2 ); <stmts>

) yield expr3

for( x <- expr1 if pred ) yield expr2 =

expr1 filter(x => pred) map (x => expr2 )


• Stuff goes in but never comes out -- the IO-monad

• Stuff goes in and sometimes comes out -- nearly all standard collections

• Every thing that goes in is matched by something coming out -- linearly typed collections

Notice that these correspond to transactional modes!

Three kinds of monad?



Towards a more complex example

• Parsing

• Moral: the dog doesn’t bark

• Evaluation

• Moral: the dog barks quietly -- even in a distributed setting

• Storage?



REPLs and Web Apps and DSLs, oh my!

Browser

Container

Resource

Domain Logic

Service




Browser

Container

Resource

Domain Logic

Service

Non-blocking continuation-based request handling




Browser

Container

Resource

Domain Logic

Service

User actions become expressions

in a DSL





Browser

Container

Resource

Domain Logic

Service


in a DSL

Domain model = abstract syntax of

DSL





Browser

Container

Resource

Domain Logic

Service


in a DSL

Domain model = abstract syntax of

DSL


Evaluation as a service



Parsing - compositional at multiple levels

Expressions in a DSL Parser

Syntax tree



ParsingConcrete syntax

Normalization

Abstract syntax



ParsingAbstract syntax

Evaluation

Domain value



Parsing (DSLs)

• The surface API for parsing doesn’t (have to) change

• Grammars are already compositional: grammars are algebras!

• The programmatic API changes: parser combinators



Parsing (DSLs)

• Internal vs External

• Parsing combinators vs higher level abstraction

• Domain requirements



Internal vs External DSLs

• External

• independent, self-contained language with own grammar and semantics

• Example: SQL is a DSL for accessing relational storage



Internal vs External DSLs

• Internal

• embedded or hosted DSL

• makes use of expressions and computations in ambient language

• examples

• lex/yacc -- semantic actions in C

• LINQ -- internal DSL for accessing storage



Parsing combinators vs higher level abstraction

• Parsing combinators

• provide compositional mechanism

• work well in embedded situation

• BNF and other higher level abstractions

• considerably more concise

• target multiple platforms



Exampleclass TermParser extends JavaTokenParsers {

def term : Parser[Any] =

application | list | ground | variable

def list : Parser[Any] =

"["~repsep( term, "," )~"]"

def ground : Parser[Any] =

stringLiteral | floatingPointNumber | "true" | "false"

def variable : Parser[Any] = ident

def application : Parser[Any] =

ident~"("~repsep( term, "," )~")"

}



Domain requirements

• When DSL supports service-based/program-to-program computing

• language is “closed” -- no expression sublanguage

• When DSL supports human-interaction

• language is often “open” -- containing some expression sublanguage



DSLs and algebras

• An algebra is a domain model (and don’t you forget it!)

• An algebra is the abstract syntax to the ...

• ... concrete syntax of a DSL



Algebras

• Algebras and types are closely related

• Functional types are algebraic data types

• Understanding how these are related and languages for manipulating them will get you far

• Most importantly -- algebras are monads!


• List and Set are actually the same structure up to a certain point -- the difference can be captured by a set of equations that Sets obey and Lists don’t

• a + b = b + a

• a + a = a

• How do we relate these equations to Shape, wrap and roll?


Remember this?


• So List and Set can actually be thought of as factored into two pieces of information

• ( M, equations )

where

• M is the colored brace structure (Shape-wrap-n-roll)

• the equations give additional constraints about how braces behave.

• Lists have no additional equations -- such structures are called free.


And this?


Monads and algebras

• An algebra is expressed entirely as a set of generators

• ≈ constructors

• ≈ grammar

• and relations aka equations

• Generators and relations are 2/3’s of the specification of a DSL



Where we might go from here

• We haven’t talked about control flow

• So, let’s talk a little about it...



Why monads -- did we do what we promised?

• To manage complexity

• Monads help your code scale

• Abstract structure and control

• Engage the compiler more

• Compositional Actually... monads don’t necessarily

compose!



Questions?


g meredith scala

Technology