The online hangout for Göteborg Functional Programming Group and everybody interested.

just for fun I implemented my minimax thingy without typeclasses too https://gist.github.com/553263d12bc00a4902b12a0dc289b725

still wanted the extensibility though, so I used explicit dictionary passing with all the functions needed

this looks great to me! very readable while still extensible and without requiring extra pragmas :p

yeah, I've seen some people think this is better than typeclasses... I guess it has some benefits. More to write though

isn't that basically what type-classes do under the hood anyways?

yeah

but it's interesting that you don't need any of the extensions when doing it this way

I guess this is how you'd do it in Elm for example?

(this is the article I was thinking about http://www.haskellforall.com/2012/05/scrap-your-type-classes.html)

it would be interesting to try to port this to Elm and see if that works, but I think Elm did not support higher order data types

(except the build-in ones)

ah

elm-lang/elm-compiler#396

also elm-lang/elm-compiler#1039

touchy subject ^^

still something similar should be possible with Elm's records

(my intuition tells me)

ah no what will happen is you'll have to make s and m concrete right?

ok I'll play with this a bit :p

oh! it works actually?

```
type alias Player = Int
type alias Score = Int
type alias Solver m s =
{ evalFn : s -> Player -> Score
, branchFn : s -> List m
, moveFn : s -> m -> s
, currentPlayerFn : s -> Player
, getState : s}
```

hey! I was wrong and you were right @eriksvedang ! this works in elm!

```
type alias Player = Int
type alias Score = Int
type alias Solver m s =
{ evalFn : s -> Player -> Score
, branchFn : s -> List m
, moveFn : s -> m -> s
, currentPlayerFn : s -> Player
, getState : s}
minimax :: Solver s m -> Player -> Int -> Score
minimax solver me depth = let state = (.getState solver) in
case depth of
0 -> ((.evalFn solver) state me)
_ -> let finder = if ((.currentPlayerFn solver) state) == me then List.maximum else List.minimum
moves = ((.branchFn solver) state)
in case moves of
[] -> ((.evalFn solver) state me)
_ -> case (finder (List.map (\move -> minimax solver {me | getState = ((.moveFn solver) state move) } (depth - 1)) moves)) of
Nothing -> 0
Just n -> n
```

cool!

I love to be wrong that means I learned something :) so what does it mean to not support "higher kinded types"? I have not understood the meaning

no, me neither apparently, since I believed you :)

perhaps one of @ocramz or @magthe could share some knowledge there?

@eriksvedang @Jell your Lisp educations shines through: too many parentheses : D Haskell has variable fixity operators

@Jell higher-kinded: when the type requires more than one type parameter

e.g.

`Functor`

is `(* -> *) -> Constraint`

IIRC
yes

that is, you can only make types that have exactly one type parameter to be instances of Functor

same for Applicative and Monad

@ocramz hey we love parentheses here! :D It's usually up to ghc-mod to straighten me out

Anyone else going to the Propositions as Types https://www.meetup.com/Papers-We-Love-Gothenburg/events/235666159/ meetup?

@Zalastax I am going! super happy this is happening

Nice! See you there!

@ocramz I still don't understand, isn't

`Solver`

such a type then?
Solver requires 2 parameters

I should re-read TaPL https://www.cis.upenn.edu/~bcpierce/tapl/ because I think I might not have fully grasped the meaning of "kinds"

isn't solver of kind

`* -> * -> *`

?
no that doesn't seem right...

yes, that's the kind of Solver

so you say that Elm is not supposed to support those?

oh... then is Solver a higher order kind?

the code above is valid Elm code and I wrote it with

`Solver m s`

then I don't understand this: elm-lang/elm-compiler#396

Ah, understood. It's because each type parameter in Solver is of kind

`*`

, but you can't have parametric types as parameters
as in

`(* -> *)`

another way of saying it: parameters can only be concrete types

oh! ok I see

IIUC

yes that makes sense to me now

@Zalastax I really wanted to go to that papers we love meetup, but I'm not in town :( super sad face

ooooh! perhaps @vlopezj can try to live-stream it? :p

so this is interesting: http://www.haskellforall.com/2012/05/scrap-your-type-classes.html

the one you share earlier @eriksvedang

opened my mind and the trade-offs Elm is making are starting to make more sense

it's easier to look at what's not possible instead of looking at what's possible :p

that's because P != NP

I think

deep

thanks for the clarifications @ocramz , I think I get it too now

yes thanks indeed @ocramz !

I started working on a Haskell presentation, haha

:thumbsup: let's schedule something in january then? :p

um, if it's still looking promising after I've typed it all out... sure! ^^

:p

you should do the follow up first though ,right?

intro to FP pt 2

yep that's be in february though based on ReactJS constraints

aha

@Jell I don't know if we will manage to do that, but I will post the slides at least :)

@vlopezj that would also be great! :)