evancz

type Point3D = { x : Float, y : Float, z : Maybe Float }
    deriving Json, New, Binary

-- Resulting in the folliwing derived values:

Point3D.Json.encode : Point3D -> String
Point3D.Json.decode : String -> Maybe Point3D

Point3D.New : Float -> Float -> Maybe Float -> Point3D

evancz

module History where

data Step a = Undo | Redo | Checkpoint a | NoCheckpoint a

foldp : (a -> b -> b) -> b -> Signal (Step a) -> Signal b

-- It could also be interesting to have custom strategies for keeping track
-- of history. Maybe you want to have a fixed size stack, infinite stack,
-- stack with exponential decay, etc.

evancz

module History where

type History state value =
  { state | undo   : History s a -> Maybe (History s a)
          , redo   : History s a -> Maybe (History s a)
          , add    : a -> History s a -> History s a
          , value  : History s a -> Maybe a
          }

type Infinite a = { past : [a], future : [a] }

evancz

import Math.Vector3 (..)
import Math.Matrix4 (..)
import Graphics.WebGL (..)


-- This is the main function
-- It renders the triangle then prints the points 
-- of the triangle
-- Notice how the points change but the render doesn't
main = flow down <~ ( combine [ render <~ updateTriangle

evancz

-- Thanks to The PaperNES Guy for the texture:
-- http://the-papernes-guy.deviantart.com/art/Thwomps-Thwomps-Thwomps-186879685

import Graphics.WebGL (..)
import Http (..)
import Math.Vector2 (Vec2)
import Math.Vector3 (..)
import Math.Vector3 as V3
import Math.Matrix4 (..)
import Mouse

evancz

Focus

A Focus is a way to work with particular parts of a large chunk of data. On the most basic level, it lets you get and set fields of a record in a simple and composable way. This means you could avoid writing special record update syntax and use something that composes much more elegantly.

This API is inspired by the concept of Bidirectional Lenses as described by Nate Foster and seen in a modified form in Haskell as "lenses" and in ClojureScript as "cursors". My personal opinions and understanding comes from this talk by Simon Peyton Jones, discussions with @seliopou, and a basic understanding of Nate Foster's PhD thesis on bidirectional lenses. I chose the name "Focus" for this outline because it is sort of like a lens that only lets you see in one direction.

Here's the pseudocode that describes the basic API:

modul

evancz

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

evancz

Command Line Refresh for Elm

With the upcoming improvements to elm-server and elm-get, it is becoming clear that the names of the various command line tools do not actually match what they do. This is a proposal of how to sort this out.

Proposal

I propose that the typical workflow will include the following tools:

• elm-repl - exactly the same as before
• elm-reactor - combination of elm-server and the debugger

evancz

Haskell Style Guide for Elm

Goal: a consistent style throughout all Elm projects that is easy to read and produces clean diffs to make debugging easier. This means valuing regularity and simplicity over cleverness.

Line Length

Keep it under 80 characters. Going over is not the end of the world, but consider refactoring before you decide a line really must be longer.

Variables

evancz

Elm Hackathon 1

Theme: exploring and using elm-html

I want us to make some cool stuff together. First, I think it will be fun, but I think we may begin to learn interesting ways to improve and extend elm-html so that we can all be more productive.