Skip to content

Instantly share code, notes, and snippets.

View etorreborre's full-sized avatar
🏠
Working from home

Eric Torreborre etorreborre

🏠
Working from home
View GitHub Profile
@dominictarr
dominictarr / readme.md
Created November 26, 2018 22:39
statement on event-stream compromise

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.

@broros

otherwise why would he hand over a popular package to a stranger?

If it's not fun anymore, you get literally nothing from maintaining a popular package.

One time, I was working as a dishwasher in a restu

@parsonsmatt
parsonsmatt / haskell-app-layers.md
Created December 11, 2017 15:48
A basic draft of a future blog post

The question of "How do I design my application in Haskell?" comes up a lot. There's a bunch of perspectives and choices, so it makes sense that it's difficult to choose just one. Do I use plain monad transformers, mtl, just pass the parameters manually and use IO for everything, the ReaderT design pattern, free monads, freer monads, some other kind of algebraic effect system?!

The answer is: why not both/all?

Lately, I've been centering on a n application design architecture with roughly three layers:

Layer 1:

newtype AppT m a = AppT { unAppT :: ReaderT YourStuff m a } deriving ............ The ReaderT Design Pattern, essentially. This is what everything gets boiled down to, and what everything eventually gets interpreted in. This type is the backbone of your app. For some components, you carry around some info/state (consider [MonadMetrics](https://hackage

@mtesseract
mtesseract / haskell-records.md
Last active March 8, 2023 22:25
Working around Haskell's namespace problem for records

The Problem

Defining records in Haskell causes accessor functions for the record's fields to be defined. There is no seperate namespace for these accessor functions.

The Goal

Be able to

  • use records in Haskell, which share field names.
  • use lenses for accessing these fields
@drexin
drexin / Macros.scala
Last active October 27, 2016 09:41
macros to get current file and line, inspired by ruby's __FILE__ and __LINE__
import java.io.File
import language.experimental.macros
import scala.reflect.macros.Context
object Macros {
def LINE: Int = macro lineImpl
def lineImpl(c: Context): c.Expr[Int] = {
import c.universe._
@tonymorris
tonymorris / SKI_Applicative.scala
Created August 2, 2012 04:59
Applicative Functor / SKI combinator calculus
object SKI_Applicative {
/*
First, let's talk about the SK combinator calculus and how it contributes to solving your problem.
The SK combinator calculus is made of two functions (aka combinators): S and K. It is sometimes called the SKI combinator calculus, however, the I combinator can be derived from S and K. The key observation of SK is that it is a turing-complete system and therefore, anything that can be expressed as SK is also turing-complete. Here is a demonstration that Scala's type system is turing-complete (and therefore, undecidable) for example[1].
The K combinator is the most trivial of the two. It is sometimes called "const" (as in Haskell). There is also some discussion about its evaluation strategy in Scala and how to best express it[2]. The K function might be paraphrased as, "takes a value and returns a (constant) unary function that always returns that value."
*/
def k[A, B]: A => B => A =
a => _ => a
@mslinn
mslinn / sbtDeps
Created July 12, 2012 21:13
Shows all dependencies of an SBT project
#!/bin/bash
echo "Direct dependencies"
sbt 'show all-dependencies' | \
gawk 'match($0, /List\((.*)\)/, a) {print a[1]}' | \
tr -d ' ' | tr ',' '\n' | sort -t ':' | \
tr ':' '\t' | expand -t 30
echo -e "\nAll dependencies, including transitive dependencies"
sbt 'show managed-classpath' | tr -d ' ' | tr ',' '\n' | \
@channingwalton
channingwalton / TypeClass.scala
Created May 8, 2012 20:39
Typeclass in the presence of subtypes
import scala.xml.NodeSeq
object RenderExample {
object Model {
trait Toy
case class Bike extends Toy
case class Train extends Toy
@raichoo
raichoo / gist:2345414
Created April 9, 2012 18:50
Monads vs. implicit values in Scala
case class Config(host: String, port: Int) {
def prettyPrint(prefix: String, msg: String): String =
List(prefix, ": ", msg, " on ", host, ":", port.toString).mkString
}
/**
* Passing a configuration with implicits is like
* working in the state monad. You can "put" a
* new configuration even though we don't want that
* to happen in this particular example. We don't
@chrislewis
chrislewis / comprehensible.scala
Created March 11, 2012 23:32
general type and implicit conversion to add support for using a general Bind instance in a for comprehension
trait Bind[M[_]] {
def fmap[A, B](ma: M[A], f: A => B): M[B]
def bind[A, B](ma: M[A], f: A => M[B]): M[B]
}
trait Monad[M[_]] extends Bind[M]{
def unit[A](a: => A): M[A]
@chrislewis
chrislewis / interpreter.scala
Created March 10, 2012 15:39
quick interpreter for nescala
package necsala.embedded
import scala.tools.nsc.interpreter.AbstractFileClassLoader
import scala.tools.nsc.{Global, Settings}
import scala.tools.nsc.util.BatchSourceFile
import scala.tools.nsc.io.{AbstractFile, VirtualDirectory}
import java.io.File
import java.util.jar.JarFile
import java.net.URLClassLoader