The following is a list of programming languages and their syntax for doing metaprogramming.
Macros in C are just glorified string substitution.
------------------------------------------------ | |
-- GLOBAL VARIABLES TO PLAY WITH | |
------------------------------------------------ | |
-- number of iterations of the Julia Set | |
maxIterations : Int | |
maxIterations = 100 | |
-- The constant c used in the julia function |
type alias Bounds = { | |
left : Float, | |
right : Float, | |
top : Float, | |
bottom : Float | |
} | |
bounds : Bounds | |
bounds = Bounds 0 0 0 0 |
// EXTRA STUFF TO MAKE IT RUN | |
var __2_TAGGER = 'tagger'; | |
var __2_THUNK = 'thunk'; | |
var __2_LEAF = 'leaf'; | |
var __2_PARENT = 'parent'; | |
function F2(fun) { | |
function wrapper(a) { | |
return function(b) { |
This document describes how to build a statically linked binary of Elm 0.19.0 for Linux x64 using docker. The binary is built using Alpine Linux in order to easily link it statically to musl libc. This is how the official Elm 0.19.0 Linux binary was built.
Elm is currently distributed using npm
. For Linux x64 (but this applies to any architecture), this requires to have a single x64 binary that works on all Linux x64 distributions. This is considerably easier to achieve by building a statically linked binary that will only depend on the Linux kernel ABI and System Call Interface but not on userpace libraries (see here for a compatibility survey of a dynamically built executable).
This document describes how to build a statically linked binary of Elm 0.19.1 for Linux x64 using docker. The binary is built using Alpine Linux in order to easily link it statically to musl libc. This is how the official Elm 0.19.1 Linux binary is built.
Elm is currently distributed using npm
. For Linux x64 (but this applies to any architecture), this requires to have a single x64 binary that works on all Linux x64 distributions. This is considerably easier to achieve by building a statically linked binary that will only depend on the Linux kernel ABI and System Call Interface but not on userpace libraries (see here for a compatibility survey of a dynamically built executable).
# make sure every time only one file is re-compiled | |
echo "time\t\tlines\timports\tfile" | |
for f in `find src -name *.elm` | |
do | |
elm-make $f --output=/dev/null > /dev/null | |
sleep 1 | |
touch $f | |
a=`wc -l $f | awk '{print $1}'` |
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:
I personally like to have discussions in the spirit of the Socratic method. Instead of declaring my opinion, I ask a relevant question. How about this situation? What about this case? This has two possible outcomes.
In both cases, it could have been a conflict, egos crashing together. But by asking questions, it becomes a collaboration to find the best answer. Even the simple act of asking a question in the first place says, "I care what you have to say, we can agree on this." That said, I have noticed that it is definitely still possible for things to go wrong within this framework. How can this happen?
There was a passage from [The
{- | |
This file is a reaction to the article "A small dive into, and rejection of, Elm": | |
https://hackernoon.com/a-small-dive-into-and-rejection-of-elm-8217fd5da235#.9w3ml4r6b | |
I think constructive criticism is very welcome in the Elm community. Pointing out | |
possibilities for documentation improvements, mentioning missing features or ways | |
in which the language could evolve etc. are imho a vital part of a good community. | |
However, the article above is neither well informed nor constructive. IMHO ranting |