Ivano Pagano ivanopagano

Revisiting Tagless Final Interpreters

Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).

The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA

I recently switched over to neovim (see my screenshots at the bottom). Below is my updated config file.

It's currently synchronized with my .vimrc config except for a block of neovim-specific terminal key mappings.

This is still a work in progress (everyone's own config is always a labor of love), but I'm already extremely pleased with how well this is working for me with neovim. While terminal mode isn't enough to make me stop using tmux, it is quite good and I like having it since it simplifies my documentation workflow for yanking terminal output to paste in a markdown buffer.

These days I primarily develop in Go. I'm super thrilled and grateful for fatih/vim-go,

Applied Functional Programming with Scala - Notes

1. Mastering Functions

A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.

val square : Int => Int = x => x * x

Scoped Implicit Lifetimes

All things considered, our experience in Scala Native has shown that resource management in Scala is way harder than it should be. This gist presents a simple design pattern that makes it resource management absolutely hassle-free: scoped implicit lifetimes.

The main idea behind it is to encode resource lifetimes through a concept of an implicit scope. Scopes are necessary to acquire resources. They are responsible for disposal of the resources once the evaluation exits the

https://github.com/adamw/quicklens
- com.softwaremill.quicklens quicklens_sjs0.6_2.11
  - 1.4.2
  - 1.3.1
  - 1.4.0
  - 1.4.5
  - 1.4.6
  - 1.4.1
  - 1.4.3
1.4.4

Collections Redesign Proposal

I'm going to start off by motivating what I'm doing here. And I want to be clear that I'm not "dissing" the existing collections implementation or anything as unproductively negative as that. It was a really good experiment, it was a huge step forward given what we knew back in 2.8, but now it's time to learn from that experiment and do better. This proposal uses what I believe are the lessons we can learn about what worked, what didn't work, and what is and isn't important about collections in Scala.

This is going to start out sounding really negative and pervasively dismissive, but bear with me! There's a point to all my ranting. I want to be really clear about my motivations for the proposal being the way that it is.

	package omdb.client;

	/**
	* Created by Ivano Pagano on 09/02/16.
	*
	* Espone i valori presenti nella risposta json delle API
	*/
	public interface OpenMovie {
	public String title();
	public String year();

	// let's imagine you have an algebra that has a constructor like the following
	sealed trait Algebra[A]
	case class Ext[E, A](e: E, f: E => A) extends Algebra[A]

	/*
	* Not at all an uncommon pattern! Basically, this is going to show up any time you're
	* doing GADTs or GADT-like things, or any sort of type-aligned sequence (in any form).
	* The problem is that the pattern matcher affixes types in a linear fashion, and thus
	* will not unify the solution to E between the two parameters. For example:
	*/

	import scalaz._, Scalaz._

	// Adjunction between `F` and `G` means there is an
	// isomorphism between `A => G[B]` and `F[A] => B`.
	trait Adjunction[F[_],G[_]] {
	def leftAdjunct[A, B](a: A)(f: F[A] => B): G[B]
	def rightAdjunct[A, B](a: F[A])(f: A => G[B]): B
	}

	// Adjunction between free and forgetful functor.

	import scala.language.experimental.macros
	import scala.reflect.macros.whitebox

	class FreeMacros(val c: whitebox.Context) {
	import c.universe._

	def smartName(name: String): String = (
	name.toList match {
	case h :: t => h.toLower :: t
	case Nil => Nil