Skip to content

Instantly share code, notes, and snippets.

@rtfeldman
rtfeldman / README.md
Created March 8, 2022 12:02 — forked from j-maas/README.md
Roc: Open and closed tag unions

Roc: Open and closed tag unions

Motivation

The goal of open and closed tag unions is to allow both exhaustiveness checking and composition of tags. The main motivating pieces of code are:

getSettings = \filename ->
    rawData <- Task.await (File.readUtf8 filename)
 settings &lt;-
@rtfeldman
rtfeldman / GameState.elm
Created April 1, 2020 12:15 — forked from rupertlssmith/GameState.elm
Exploring State Machines with phantom types in Elm
module GameState
exposing
( Game(..)
, GameDefinition
, PlayState
, loading
, updateGameDefinition
, updatePlayState
, updateScore
, toReady
@rtfeldman
rtfeldman / Main.elm
Created May 24, 2017 06:32 — forked from anonymous/Main.elm
Field Generation Algorithm for Evan
module Main exposing (..)
import Html exposing (pre, text, Html)
main : Html a
main =
-- List.range 0 200
-- List.range 3364 3388
-- List.range 216358 216375

Elm Style Guide

Purpose

The goal of the style guide is foremost to promote consistency and reuse of pattern from other languages in order to improve readability and make Elm easier for beginners. This includes moving Elm away from Haskell’s indentation style and even making some parts look closer to JavaScript. These decisions are intentional.

We would like Elm to look friendly and familiar to users of any language — especially JavaScript — so they can discover Elm’s powerful features without being overwhelmed. This does not intend to weaken or discourage any features of Elm, but instead to make them more accessible.

A secondary goal of the style guide is to encourage short diffs when changes are made. This makes changes more clear, and helps when multiple people are collaborating.

Whitespace

@rtfeldman
rtfeldman / Signal.create.md
Last active October 7, 2015 22:32 — forked from mgold/proposal.elm
Elm mailbox revamp

This is proposed as a simplified alternative to https://gist.github.com/mgold/f3527359996fdf295843 - what if instead of renaming Mailbox, we just didn't have a name for that thing?

Rationale:

  1. From an API perspective, it's important that the function for instantiating a Signal returns two distinct values: the Signal and a way to send a Message to it.
  2. Mailbox (and alternatively Dispatcher) give a type alias to that return value.
  3. In practice, we never compose Mailboxes or Dispatchers directly; we simply read the two values out of them and then immediately discard them.
  4. Despite this, I hear people saying things like "Do I need a Mailbox for that?" when the real question is "I want to create a Signal; how do I do that?" The type alias seems to be a red herring that leads people down the wrong path.
  5. I've gotten the best results from telling people "Focus on the Signal. Do you need to create a new Signal out of thin air? If so, here's the function that does that." (Currently that fun