I hereby claim:
- I am hsavit1 on github.
- I am henry_s (https://keybase.io/henry_s) on keybase.
- I have a public key ASBehtOERO0XSzcL87y6jBqgpvrxRE2XOHqBxl2LZc4Z5Qo
To claim this, I am signing this object:
import { buildSchema, graphql } from "graphql"; | |
// Construct a schema, using GraphQL schema language | |
let graphqlSchema = buildSchema(` | |
type Query { | |
recipes: [Recipe] | |
recipes_by_pk(id: Int!): Recipe | |
} | |
type Recipe { | |
id: ID! |
defmodule SqlParser do | |
def run() do | |
input = "select col1 from ( | |
select col2, col3 from ( | |
select col4, col5, col6 from some_table | |
) | |
) | |
" | |
IO.puts("input: #{inspect(input)}\n") | |
IO.inspect(parse(input)) |
I hereby claim:
To claim this, I am signing this object:
// connect() is a function that injects Redux-related props into your component. | |
// You can inject data and callbacks that change that data by dispatching actions. | |
function connect(mapStateToProps, mapDispatchToProps) { | |
// It lets us inject component as the last step so people can use it as a decorator. | |
// Generally you don't need to worry about it. | |
return function (WrappedComponent) { | |
// It returns a component | |
return class extends React.Component { | |
render() { | |
return ( |
If you want a run-down of the 1.3 changes and the design decisions behidn those changes, check out the LonestarElixir Phoenix 1.3 keynote: https://www.youtube.com/watch?v=tMO28ar0lW8
To use the new phx.new
project generator, you can install the archive with the following command:
$ mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez
Phoenix v1.3.0 is a backwards compatible release with v1.2.x. To upgrade your existing 1.2.x project, simply bump your phoenix dependency in mix.exs
:
extension Array { | |
var match : (head: T, tail: [T])? { | |
return (count > 0) ? (self[0],Array(self[1..<count])) : nil | |
} | |
} | |
func map<A,B>(f: A -> B, arr: [A]) -> [B] { | |
if let (head,tail) = arr.match { | |
return [f(head)] + map(f, tail) | |
} else { |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen conflate side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
defmodule Server do | |
def start(callback_module, state \\ nil) do | |
parent = self | |
spawn fn -> | |
loop(callback_module, parent, state) | |
end | |
end | |
def loop(callback_module, parent, state) do | |
receive do |
defmodule Speaker do | |
def speak do | |
receive do | |
{:say, msg} -> | |
IO.puts(msg) | |
speak | |
_other -> | |
speak # throw away the message | |
end | |
end |
defprotocol Functor do | |
def fmap(data, func) | |
end | |
defprotocol Applicative do | |
def pure(data) | |
def run(wrapped_func, data) | |
end | |
defprotocol Monad do |