rtfeldman

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

module GameState
    exposing
        ( Game(..)
        , GameDefinition
        , PlayState
        , loading
        , updateGameDefinition
        , updatePlayState
        , updateScore
        , toReady

rtfeldman

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

rtfeldman

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

module Script exposing (spec) --where


import ElmTest as Test exposing (onFail, test)
import Component.Util exposing (..)
import Html exposing (span, text)
import Dom exposing (htmlToString)

{-

rtfeldman

require 'open3'
require 'tempfile'

class ElmCompiler < Sprockets::Processor
  def self.default_mime_type
    'text/x-elm'
  end

  def evaluate(context, _locals)
    pathname = context.pathname.to_s

rtfeldman

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

rtfeldman

1. Enable developer options on your phone and turn on USB debugging.
2. Connect the phone to a computer with a USB cable.
3. Do this (on OS X):

brew install android-platform-tools
adb shell
pm hide com.sec.android.inputmethod

rtfeldman

# Elm Sprockets Integration for Rails 3
#
# I'm working on turning this into a Gem - see https://github.com/NoRedInk/sprockets-elm - but
# I know a lot more about Elm than I do Rails, and haven't gotten that version working yet.
# If you know how to help Gemify this, by all means please hit me up! https://twitter.com/rtfeldman
# I could definitely use the help.
#
# Anyway, in the meantime, this is what we're using at NoRedInk to integrate Elm into our asset
# pipeline, and it works like a charm. Just copy this into config/initializers/elm_sprockets.rb
#

rtfeldman

Keybase proof

I hereby claim:

• I am rtfeldman on github.
• I am rtfeldman (https://keybase.io/rtfeldman) on keybase.
• I have a public key whose fingerprint is 0739 55F3 77B6 314B 8D74 7443 CB96 9B2A 26E7 5548

To claim this, I am signing this object: