Marco Perone marcosh

Front-end development is evolving very rapidly, with new frameworks appearing and then declining very rapidly. Among the many options that a developer has for developing the graphical user interface of its web application, Elm steps out as one of the most original and most promising approaches. It combines the principles of reactive programming with the elegance of strongly typed functional programming, still providing a nice integration with javascript code.

In this talk Marco will present Elm digging into at a real project built with it, exploring the best features of the language and focusing on the architecture that naturally emerges building Elm applications, which is great for modularity, code reuse and testing.

A monad is a particular construction that emerges in the branch of mathematics called category theory. Despite category theory being one of the most abstract field in mathematics, monads are heavily used in functional programming as a design pattern that allows, for example, to manage side-effects. Why should such a powerful design pattern be used only in functional programming languages? Is it possible to apply it also in an Object Oriented paradigm?

In this talk we will try to answer these questions, exploring in parallel the notion of monad in category theory, in functional programming and in object oriented programming, with the help of various examples taken from all the three different worlds.

I am following the discussion that is happening these days on the PHP-FIG mailing list (https://groups.google.com/forum/#!msg/php-fig/vTtGxdIuBX8/KvNgEeiACgAJ).

Some interesting points emerged and I'd like to try to sum them up.

The discussion started from this proposal

interface MiddlewareInterface
{
 public function __invoke(

Characterize recursable data structures

Recursion

Recursion is a procedure that allows us to iterate through certain data structure. For example we can iterate through lists

sum : List Nat -> Nat
sum list =

	<?php

	namespace MyTestNamespace;

	//relevant use clauses
	use ...

	final class AddItemIntegrationTest extends \PHPUnit_Framework_TestCase
	{
	public function testAddItem()

	PDO::FETCH_FUNC without validation

	10: 0.001568078994751
	0.00071001052856445
	0.00085306167602539
	0.00087618827819824
	0.00083112716674805

	100: 0.0012631416320801
	0.0014598369598389

	module Hanoi

	import Data.Vect

	data Peg
	= First
	\| Second
	\| Third

	-- TODO : can we do better here?

	module Application where

	import Data.Profunctor

	newtype Application request response = Application {unApplication :: request -> IO response}

	instance Profunctor Application where
	dimap actOnRequest actOnResponse application = Application $ (fmap actOnResponse) . (unApplication application) . actOnRequest

	{-# LANGUAGE AllowAmbiguousTypes #-}
	{-# LANGUAGE MultiParamTypeClasses #-}
	{-# LANGUAGE FlexibleInstances #-}
	{-# LANGUAGE ScopedTypeVariables #-}
	{-# LANGUAGE TypeApplications #-}

	module NamedTypeclass where

	import Prelude hiding (Monoid, mempty, (<>))

	{-# LANGUAGE LambdaCase #-}
	{-# LANGUAGE FunctionalDependencies #-}
	{-# LANGUAGE MultiParamTypeClasses #-}

	module Graph where

	import Control.Comonad

	-- we need to separate `a` and `b` because `a` is covariant while `b` is contravariant => this is actually a profuctor
	data PointedGraph moves b a = PointedGraph