DEV Community: e_ntyo

fp-ts ユーザが Scala with Cats を読み終えたので、fp-ts と Cats の違いをまとめてみた

e_ntyo — Mon, 28 Feb 2022 03:26:19 +0000

tl; dr

Scala の fp ライブラリ Cats と、TypeScript の fp ライブラリ fp-ts を比較してみました。主に言語仕様の違い（評価戦略の違いや型コンストラクタの有無など）によって、高カインド型や型クラスの実装方法に違いがあることや、Cats でのみ提供されている型クラスがあること等がわかりました。

この記事を書くことにした経緯

この記事を書くことにしたきっかけは、勤務先の株式会社 HERP で、Cats の教材 "Scala with Cats"の輪読会を開催したことです¹。弊社では Cats ではなく fp-ts を Web フロントエンド・サーバサイドで全面的に使用しているのですが²、 fp-ts は比較的まだ若いライブラリであり³、Learning Resource もさほど充実していないという課題意識がありました。そこで、「fp-ts は Cats から影響を受けている⁴し、Cats の Learning Resource に良いものがあればそれを勉強してもよいのでは？」と考えた次第です。

輪読会を終えて、「普段 fp-ts を使っている人から見た Cats あるいは Scala」という観点で記事を書いたら面白いのではないか、と考えこの記事を書き始めるに至りました。

対象読者

まず前提として、この記事は「明日から使えるプログラミングテクニック」について書かれたものではありません。この記事はいわば「読み物」ですので、暇なときに読んでいただき「へ〜」と思っていただけたら良いなと思って書いております。

そしてこの「読み物」の対象読者ですが、以下のうち、一つ以上に当てはまる方を想定しております：

fp-ts を使ったことがある
Cats を使ったことがある
（プログラミング言語を問わず）Functional Programming を実践している

Scala with Cats

Scala with Cats は Web 上で無料で公開されており、随時内容が更新されています。英語のリソースですが、全体的に平易な英語で書かれている印象でした。この記事の執筆時点（2021 年 12 月）では、全七章⁵で以下の内容が扱われています。

The Type Class
Monoids
Semigroups
Functors
Monads
Monad Transformers
Semigroup and Applicative
Foldable and Traverse

そもそも私は Scala を書いたことがほぼなかったのですが、Scala with Cats では逐次 Scala の言語仕様そのものについても解説されているため、無理なく読み進めることができました。

私が Scala with Cats を読んで良かったことは、まず「fp-ts にもあることは知っているけれど、よく理解していなかった型クラス」について知ることができたことです。上に挙げたとおり、Scal with Cats では主要な型クラスについての解説が一通り用意されています。

また、それらの型クラス同士の関係性（e.g. Functor と Applicative と Monad の関係性、Semigroup と Applicative の関係性）についても説明されており助かりました。偏見ですが、「Functor と Applicative と Monad の関係性」なんかは、圏論の本を読んだりしないとなかなか知る機会がないのではないかと思っています。

さらに、普段筆者は業務で fp-ts を使っているため、「fp-ts ではこういう面倒くさいことをしなければならないが、Cats (Scala) では同じようなことがより簡潔に書けるのか」といった気づきがありました。以降のセクションには、そうした「気付き」をそれぞれできるだけ具体的にまとめました。

fp-ts と Cats の比較

本題の比較に入ります。なお、fp-ts (TypeScript) および Cats (Scala) のヴァージョンは以下を想定しています。

fp-ts: 2.11.8 (TypeScript: 4.5.5)
- 執筆時点での最新のヴァージョンを想定しています
Cats: 2.1.0 (Scala: 2.13.1)
- 執筆時点での Scala with Cats の最新版に対応したヴァージョンを想定しています

高カインド型と型コンストラクタ

Cats では、Functor や Monad の定義において、Type Constructor （型コンストラクタ）という言語機能が用いられています。以下は Cats における Functor の定義です（一部省略しています）：

package cats

import simulacrum.{noop, typeclass}

/**
 * Functor.
 *
 * The name is short for "covariant functor".
 *
 * Must obey the laws defined in cats.laws.FunctorLaws.
 */
@typeclass trait Functor[F[_]] extends Invariant[F] { self =>
  def map[A, B](fa: F[A])(f: A => B): F[B]
  ...
}

trait Functor[F[_]] と書くことで、ブロックの内側で F[A] や F[B] という型を使うことができています。ここでは、Type Constructor F はカインドが * -> * の型（例えば、Option[A] や List[A] ）をエミュレートしています。このおかげで、Functor の Option[A] 型や List[A] 型のインスタンス（FunctorForOption[A]、FunctorForList[A]）を個別に定義する必要がなくなっています。

TypeScript における高カインド型の実装

一方、TypeScript には Type Constructor （相当の機能）がありません。ではどのように Functor などの型クラスを実装しているのでしょうか⁶。

超シンプルな型： type Identity<A> = A について、 fp-ts の Functor のインスタンスを導出する方法を、例として見ていきます。

// Identity.ts

import { Functor1 } from "fp-ts/lib/Functor";

export const URI = "Identity";

export type URI = typeof URI;

declare module "fp-ts/lib/HKT" {
  interface URItoKind<A> {
    readonly Identity: Identity<A>;
  }
}

export type Identity<A> = A;

// Functor instance
export const identity: Functor1<URI> = {
  URI,
  map: (ma, f) => f(ma),
};

ここで、 fp-ts の Functor1 の定義は以下の通りです：

// fp-ts/lib/Functor.ts

export interface Functor1<F extends URIS> {
  readonly URI: F;
  readonly map: <A, B>(fa: Kind<F, A>, f: (a: A) => B) => Kind<F, B>;
}

では、 URItoKind、 URIS、 Kind はそれぞれ何でしょうか？

URItoKind は type-level map です。型 URI をある特定の型に map します。TypeScript の module augmentation を利用して、それぞれの型を URItoKind に登録しています。

具体的には、HKT.ts に URItoKind が定義されていて：

// fp-ts/lib/HKT.ts

export interface URItoKind<A> {}

module augmentation を用いて、 Identity.ts に、以下のように「Identity を URItoKind に登録する」コードを書くことができます：

// Identity.ts

declare module "fp-ts/lib/HKT" {
  interface URItoKind<A> {
    readonly Identity: Identity<A>; // maps the key "Identity" to the type `Identity`
  }
}

URIS は keyof URItoKind<any> であり、 Functor1 interface において URItoKind に登録されていない HKT が Functor1 の instance だということにされないよう、型レベルの制約として機能しています（interface Functor1<F extends URIS>）。

Kind<F, A> は Kind<URI extends URIS, A> = URI extends URIS ? URItoKind<A>[URI] : any です。例えば URI = 'Identity' のとき、 Kind<URI, number> は Identity<number> へと写されます。URI が URI extends URIS を満たさない、例えば HOGEHOGE という値だった場合には、 any 型となります。

ここで、 Identity は kind が * -> * (Option や List と同じ) でしたので Kind<F, A> というシグネチャになっていましたが、 kind が * -> * -> * であるような型はどのように表現されるのでしょうか。

そのような型のために URItoKind2, URIS2, Kind2 が定義されています。 Either を例として、その使われ方を見てみます：

// Either.ts

import { Functor2 } from "fp-ts/lib/Functor";

export const URI = "Either";

export type URI = typeof URI;

declare module "fp-ts/lib/HKT" {
  interface URItoKind2<E, A> {
    readonly Either: Either<E, A>;
  }
}

export interface Left<E> {
  readonly _tag: "Left";
  readonly left: E;
}

export interface Right<A> {
  readonly _tag: "Right";
  readonly right: A;
}

export type Either<E, A> = Left<E> | Right<A>;

// Functor instance
export const either: Functor2<URI> = {
  URI,
  map: (ma, f) => (ma._tag === "Left" ? ma : right(f(ma.right))),
};

ここで、 Functor2 の定義は以下の通りです：

// fp-ts/lib/Functor.ts

export interface Functor2<F extends URIS2> {
  readonly URI: F;
  readonly map: <E, A, B>(fa: Kind2<F, E, A>, f: (a: A) => B) => Kind2<F, E, B>;
}

では、Functor のような HKT を扱う関数、すなわち Cats では Type Constructor を使って定義されるような関数を、fp-ts を使う場合ではどう定義するのでしょうか？以下の lift 関数を例に見ていきます：

import { HKT } from "fp-ts/lib/HKT";

export function lift<F>(
  F: Functor<F>
): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B> {
  return (f) => (fa) => F.map(fa, f);
}

実はここまでに触れられてこなかった HKT という型がようやく登場しました。定義は以下の通りです。

// fp-ts/lib/HKT.ts

export interface HKT<URI, A> {
  readonly _URI: URI;
  readonly _A: A;
}

HKT 型は、kind が * -> * であるような型のための Type Constructor を表現しています。もうお気づきの方もいらっしゃるかもしれませんが、Functor<n> や URITtKind<n> と同様に、 HKT<n> が fp-ts/lib/HKT.ts に定義されています。ただし、fp-ts では HKT4 （kind が * -> * -> * -> * -> * の型）にまで対応しています。

さて、 HKT 型を定義したので、これでようやく lift のような関数の型定義を書くことができる…と言いたいところですが、実はもうひと工夫必要です。

const double = (n: number): number => n * 2;

//                             v-- the Functor instance of Identity
const doubleIdentity = lift(identity)(double);

以上のコードは、以下のように compile error となります：

Argument of type 'Functor1<"Identity">' is not assignable to parameter of type 'Functor<"Identity">'

Functor1<"Identity"> と Functor<"Identity"> はあくまで別の型なので、lift の型定義を書く上でオーバーロードを定義する必要があります：

export function lift<F extends URIS2>(
  F: Functor2<F>
): <A, B>(f: (a: A) => B) => <E>(fa: Kind2<F, E, A>) => Kind2<F, E, B>;
export function lift<F extends URIS>(
  F: Functor1<F>
): <A, B>(f: (a: A) => B) => (fa: Kind<F, A>) => Kind<F, B>;
export function lift<F>(
  F: Functor<F>
): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B>;
export function lift<F>(
  F: Functor<F>
): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B> {
  return (f) => (fa) => F.map(fa, f);
}

lift が Functor, Functor1, Functor2 に対応できるようオーバーロードを定義したので、以下のように lift は Identity のインスタンスも Either のインスタンスも引数に取ることができます：

// `doubleIdentity` has type `(fa: Identity<number>) => Identity<number>`
const doubleIdentity = lift(identity)(double);

// `doubleEither` has type `<E>(fa: Either<E, number>) => Either<E, number>`
const doubleEither = lift(either)(double);

だいぶ長くなりましたが以上です。HKT を実装することができありがたいのですが、この手法には二点弱点があります。

fp-ts の HKT 実装の弱点その 1 「型レベルで部分適用できない」

１つめの弱点としては、「HKT2<"URI", A, B> を「型レベルで部分適用」して、HKT1 をつくる」ということができません。

「型レベルで部分適用」というのは、例えば Either 型は kind が * -> * -> * ですが、proper な型（例えば、String）を渡すことで、kind が * -> * の型となります。Haskell の REPL には:kというコマンドがあり⁷、型の kind を調べることができます。以下は Either を「型レベルで部分適用」していく例です。

Prelude> :k Either
Either :: * -> * -> *
Prelude> :k Either String
Either String :: * -> *
Prelude> :k Either String Int
Either String Int :: *

他方、TypeScript では「型レベルで部分適用」ができません。

kind が * -> * -> * の型 HKT2<"either", A, B> について、A = string として type EitherAsHKT1<B> = HKT2<"either", string, B> という型を定義したとします。

EitherAsHKT1<B> は型パラメータを 1 つだけ取るため、一見 kind が * -> * のようですが、実際のところ HKT2<"either", string, B> のエイリアスですので、kind は * -> * -> * という扱いになってしまうのです。

ちなみに、Scala の REPL にも :K が実装されており⁸、使ってみると以下のようになります：

scala> :k Int
Int's kind is A

scala> :k Either
Either's kind is F[+A1,+A2]

scala> :k Option
Option's kind is F[+A]

scala> type IntOrA[A] = Either[Int, A]
defined type alias IntOrA

scala> :k IntOrA
IntOrA's kind is F[A]

kind は Type Constructor の F を用いて表現されており、* -> * -> * は F[+A1, +A2] で、* -> * は F[+A] で、そして * は A で表現されています。そして問題の「型レベルで部分適用」ですが、Scala では type IntOrA[A] = Either[Int, A] として定義した型の kind が F[A] となっていることがわかります。

fp-ts の HKT 実装の弱点その 2 「HKT を使う上で必要になるボイラープレートコードが多すぎ」

2 つ目の弱点は、HKT を使ったコードを書くために必要なオーバーロードが多すぎるという点です⁹。すでに見てきたように、例えば lift 関数は次のようにたくさんのオーバーロードを定義する必要がありました。

// 再掲
export function lift<F extends URIS2>(
  F: Functor2<F>
): <A, B>(f: (a: A) => B) => <E>(fa: Kind2<F, E, A>) => Kind2<F, E, B>;
export function lift<F extends URIS>(
  F: Functor1<F>
): <A, B>(f: (a: A) => B) => (fa: Kind<F, A>) => Kind<F, B>;
export function lift<F>(
  F: Functor<F>
): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B>;
export function lift<F>(
  F: Functor<F>
): <A, B>(f: (a: A) => B) => (fa: HKT<F, A>) => HKT<F, B> {
  return (f) => (fa) => F.map(fa, f);
}

これは大変なことですが、fp-ts とは別の Effect-TS というライブラリでは、この問題を考慮した HKT の実装が採用されているようです。具体的には、* -> *, * -> * -> * などの複数の kind について、fp-ts の実装のように Kind1, Kind2, ... と個別に型を定義するのではなく、共通した 1 つの型を定義しています。例えば、kind を * -> * から * -> * -> * -> * までに限定して対応するとしたら、type Kind<F extends URIS, S, R, E> = URItoKind<S, R, E>[F]　です。もう少し詳しく見ていきます：

export interface URItoKind<S, R, E> {
  Effect: Effect<R, E, A>; // * -> * -> * -> *　な型の一例
  Either: Either<E, A>; // * -> * -> *　な型の一例
  Option: Option<A>; // * -> * な型の一例
}

export type URIS = keyof URItoKind<any, any, any, any>;

export type Kind<F extends URIS, S, R, E, A> = URItoKind<S, R, E, A>[F];

export interface Functor<F extends URIS> {
  URI: F;
  map: <A, A2>(
    f: (a: A) => A2
  ) => <S, R, E>(fa: Kind<F, S, R, E, A>) => Kind<F, S, R, E, A2>;
}

export function lift<F extends URIS>(
  F: Functor<F>
): <S, R, E, A, B>(
  f: (a: A) => B
) => (fa: Kind<F, S, R, E, A>) => Kind<F, S, R, E, A> {
  return (f) => (fa) => F.map(f)(fa);
}

こちらの lift の定義では、Kind1, Kind2 などのために個別にオーバーロードを定義する必要がなくなっています。一方で、個人的には初見で URItoKind や Kind の定義を見たときの認知的負荷は、扱う型パラメータの数が増えた分こちらのほうが比較的きつい印象があります。ただし、fp-ts での実装を理解してからこちらの実装を見ていく流れであればほとんど気にならないかなとも思います。

implicit キーワード

Scala の個人的にすごいと思う言語機能として、implicit キーワードがあります。Cats のような型クラスを提供する類のライブラリにとっては、implicit キーワードのおかげで、「ある型 A とある型クラス T について、A のための T のインスタンスを（実装されていれば）コンパイラが勝手に見つけてきてくれる」という嬉しさがあります。

Cats が提供するすべて型クラスは apply[A] というメソッドを提供していて、これは A のための T のインスタンスを返してくれるスマートコンストラクタです。例えば Cats の提供する Eq 型クラスについて、自分が定義した Cat 型や Dog 型のインスタンスを手に入れるためには次のようにします：

// EqInstances.scala
object EqInstances {
  // `implicit val` というキーワードで `Eq` のインスタンスを定義する
  implicit val catEq: Eq[Cat] =
    Eq[Cat] { (cat1, cat2) =>
      cat1.name === cat2.name && cat1.age === cat2.age && cat1.color === cat2.color
    }

  implicit val dogEq: Eq[Dog] =
    Eq[Dog] { (dog1, dog2) =>
      dog1.cry === dog2.cry
    }
}

// Main.scala
import EqInstances.EqInstances._
import cats.Eq

// コンパイラは、apply[A] の A から、自動的に対応する instance を見つけてくれる
val eqCat = Eq.apply[Cat]
eqCat.eqv(cat1, cat2)
val eqDog = Eq.apply[Dog]
eqDog.eqv(dog1, dog2)

// `eqv` を使いたいだけであれば、インスタンスを作らなくとも operator として`===` が提供されている
// === の実態は `eqv` なので（後述）、やはり自動的に対応する `Eq` の instance を見つけてくれる
// `cat1 === cat2` と書くと `catEq.eqv` が使われるし、`dog1 === dog2` と書くと `dogEq.eqv` が使われる
cat1 === cat2
dog1 === dog2

TypeScript には implicit val 相当の言語機能は存在しないため、 fp-ts に Eq.apply[T] 相当のスマートコンストラタはありません。fp-ts で Eq のインスタンスを実装し、使うには以下のように書きます：

// eq-instances.ts
export const eqCat: Eq<Cat> = {
  // fp-ts では `eqv` ではなく `equals` という名前のメソッドを定義する
  equals: (cat1, cat2) =>
    cat1.name === cat2.name &&
    cat1.age === cat2.age &&
    cat1.color === cat2.color,
};

export const eqDog: Eq<Dog> = {
  equals: (dog1, dog2) => dog1.cry === dog2.cry,
};

// main.ts
import { eqCat, eqDog } from "eq-instances";

// Eq.apply[Cat] みたいなことはできないので、`eqCat`, `eqDog` をそれぞれ直接 import している
eqCat.equals(cat1, cat2);
eqDog.equals(dog1, dog2);

また、implicit キーワードはメソッド定義の際にも使うことができ、「A のための T のインスタンスを使うメソッド」を簡潔に定義することができます。以下のコードは Scala with Cats からの引用です：

package Json
// Define a very simple JSON AST
// sealed: 同一ファイル内からのみ継承可能
sealed trait Json
final case class JsObject(get: Map[String, Json]) extends Json
final case class JsString(get: String) extends Json
final case class JsNumber(get: Double) extends Json
final case object JsNull extends Json

// オレオレ型クラス
// The "serialize to JSON" behaviour is encoded in this trait
trait JsonWriter[A] {
  def write(value: A): Json
}

// オレオレ型クラス `JsonWriter` のインスタンスを定義する場所
object JsonWriterInstances {
  // `implicit val` を用いて、`A = String`, `A = Person`, ...のインスタンスを実装している
  implicit val stringWriter: JsonWriter[String] =
    new JsonWriter[String] {
      def write(value: String): Json =
        JsString(value)
    }

  implicit val personWriter: JsonWriter[Person] =
    new JsonWriter[Person] {
      def write(value: Person): Json =
        JsObject(
          Map(
            "name" -> JsString(value.name),
            "email" -> JsString(value.email)
          )
        )
    }

  // `implicit def` を用いることで、`optionWriter` の実装において `JsonWriter[A]` を使うことができる
  implicit def optionWriter[A](implicit
      writer: JsonWriter[A]
  ): JsonWriter[Option[A]] =
    new JsonWriter[Option[A]] {
      def write(option: Option[A]): Json =
        option match {
          case Some(aValue) => writer.write(aValue)
          case None         => JsNull
        }
    }
  // etc...
}

object Json {
  // **implicit parameter** は、ここでいう `w`。
  // 型クラスを扱うメソッドをこれだけで定義できる（`JsonWriter` の `A` の実装はコンパイラが勝手に見つけてくれる）
  def toJson[A](value: A)(implicit w: JsonWriter[A]): Json =
    w.write(value)
}

final case class Person(name: String, email: String)

object Main extends App {
  import JsonWriterInstances._
  // 1. Json.toJson は implicit parameter として `w: JsonWriter[A]` をとる
  // 2. `JsonWriter[A = Person]` の実装を、`implicit val` で `JsonWriterInstances.personWriter` に定義済みのため、コンパイラはそれを見つける
  println(Json.toJson(Person("Dave", "dave@example.com")))
  println(Json.toJson("hello!"))
  println(Json.toJson(Option("Hoge")))
}

Scala with Cats では、この implicit キーワードについて、

Working with type classes in Scala means working with implicit values and implicit parameters.

とさえ書かれています。

直感的に、implicit キーワードを用いて、型クラス T の、型 A のインスタンスを、コンパイラに見つけさせようとするとコンパイルスピードの低下を招きそうですが、コンパイラはソースコードを何も考えずに端から端まで見て回るのではなく、実際には import 済みの object 内などの場所を優先的に見て回るため、上記のコード例のようにそういった場所で A のインスタンスを定義していればコンパイルスピードに大きな影響はないのかもしれません。

`implicit` と拡張メソッド

Cats における implicit の活用例として、拡張メソッドがあります。例えば cats.syntax.either では、任意の型 A の値から Either[A, B] のインスタンスをつくるための Smart Constructor asLeft[B] を拡張メソッドとして提供しています。

import cats.syntax.either._

"Error".asLeft[Int].orElse(2.asRight[String])
// res12: Either[String, Int] = Right(2)

上記のコードでは、String が本来実装していないはずのメソッド asLeft を呼び出しており、また Int が本来実装していないはずのメソッド asRight を呼び出しています。

Cats はどのようにしてこれを実現しているか、cats/core/src/main/scala/cats/syntax/either.scala のコードを読んで調べてみます（一部を簡略化しました）：

// cats/core/src/main/scala/cats/syntax/either.scala
trait EitherSyntax {
  // 2. implicit def を使うことで、`a: A` を `a: EitherIdOps` にキャストしている
  // これをもって `a` から `asLeft` などの `EitherIdOps` のメソッドが呼び出すことができる
  implicit final def catsSyntaxEitherId[A](a: A): EitherIdOps[A] = new EitherIdOps(a)
}

// 1. `AnyVal` を継承したクラス `EitherIdOps` を定義する
// `EitherIdOps` はコンストラクタの引数に型 `A` の値 `obj` を取る
final class EitherIdOps[A](private val obj: A) extends AnyVal {
  /**
   * Wrap a value in `Left`.
   */
  def asLeft[B]: Either[A, B] = Left(obj)

  /**
   * Wrap a value in `Right`.
   */
  def asRight[B]: Either[B, A] = Right(obj)

  // and more!
}

cats/core/src/main/scala/cats/syntax/either.scala では、まず AnyVal を継承したクラス EitherIdOps を定義しています。EitherIdOps はコンストラクタの引数に型 A の値 obj を取りますが、この obj に asLeft 等のメソッドを生やしていこうという魂胆です。

次に、EitherSyntax という trait を定義し、ここで implicit final def catsSyntaxEitherId[A](a: A): EitherIdOps[A] = new EitherIdOps(a) を定義しています。これは任意の型 A の値 a を EitherIdOps 型にキャストしており、したがって cats.syntax.either を import した場合には、そこと同じ/そこより内側のスコープにおいて、任意の型 A の値には asLeft 等の EitherIdOps に定義したメソッドが生えることになります。

個人的には、別に A のメソッドとして定義しなくても right(a) や left(a) を使えばよいのでは…？と思ってしまいますが、先の例： "Error".asLeft[Int].orElse(2.asRight[String]) のようなコードを（pipe 演算子なしで）書きたい場合には、括弧のネストが深くならなくて済むという点では良いのかもしれません。もし他のメリットをご存じの方がいらっしゃいましたら教えてください。

また、Scala においてはオペレータはメソッドなので、cats/syntax/XXX.scala ではメソッドと同様にオペレータも提供されています。以下は Eq 型クラスの例で、メソッド eqv を、オペレータ === として提供しています：

// cats/syntax/eq.scala
package cats
package syntax

trait EqSyntax {
  implicit def catsSyntaxEq[A: Eq](a: A): EqOps[A] = new EqOps[A](a)
}

final class EqOps[A: Eq](lhs: A) {
  def ===(rhs: A): Boolean = Eq[A].eqv(lhs, rhs)
  def =!=(rhs: A): Boolean = Eq[A].neqv(lhs, rhs)
  def eqv(rhs: A): Boolean = Eq[A].eqv(lhs, rhs)
  def neqv(rhs: A): Boolean = Eq[A].neqv(lhs, rhs)
}

// 使うとき
import cats.syntax.eq._ // for === and =!=
123 === 123
123 =!= 234
// type mismatch;
// 123 === "123"

この「eqv メソッドを中置演算子 === としても定義し、使うことができる」という Scala の言語仕様は TypeScript にはなく、結構便利そうな印象です。他には cats.syntax.semigroup の |+| などがあります。

評価戦略

Cats と fp-ts の違いというよりは、Scala と JavaScript の言語レベルでの違いの一つとして、評価戦略があります。

Scala の評価戦略と Cats の `Eval`

Scala には、変数・メソッドを定義するためのキーワードとして val, def, lazy val があり、それぞれ以下のようにして使われます：

val x = {
   println("Computing X")
   math.random
 }
 // Computing X
 // x: Double = 0.15241729989551633

 x // first access
 // res0: Double = 0.15241729989551633
 x // second access
 // res1: Double = 0.15241729989551633 <- 一度目の access での評価の結果が記憶されている（Memoization）

 def y = {
   println("Computing Y")
   math.random
 }

 y // first access
 // Computing Y
 // res2: Double = 0.6963618800921411
 y // second access
 // Computing Y
 // res3: Double = 0.7321640587866993 <- 一度目の access での評価の結果は記憶されていない。

 lazy val z = {
   println("Computing Z")
   math.random
 }

 z // first access
 // Computing Z
 // res4: Double = 0.18457255119783122
 z // second access
 // res5: Double = 0.18457255119783122 <- 一度目の access での評価の結果が記憶されている

このコードからもわかる通り、val, def, lazy val は、

右辺がいつ評価されるか
評価結果はメモ化されるかどうか

の二点において異なります。この違いを以下の表に改めてまとめました。

	`val`	`def`	`lazy val`
キーワードの役割	creates an immutable variable (like `final` in Java)	define a method	文字通り lazy な `val`
評価のタイミング	即時	遅延	遅延
評価結果はメモ化される？	yes	no	yes

Cats では、これらの評価戦略を抽象化する目的で、Eval という型クラスが提供されています。Eval のインスタンスは、Eval.now, Eval.always, Eval.later　を用いて生成することができます（いわゆる Smart Constructor）：

import cats.Eval

 val x = Eval.now {
   println("Computing X")
   math.random
 }
 // Computing X
 // x: Eval[Double] = Now(0.681816469770503)

 x.value // first access
 // res10: Double = 0.681816469770503
 x.value // second access
 // res11: Double = 0.681816469770503

 val y = Eval.always {
   println("Computing Y")
   math.random
 }
 // y: Eval[Double] = cats.Always@414a351

 y.value // first access
 // Computing Y
 // res12: Double = 0.09982997820703643
 y.value // second access
 // Computing Y
 // res13: Double = 0.34240334819463436

 val z = Eval.later {
   println("Computing Z")
   math.random
 }
 // z: Eval[Double] = cats.Later@b0a344a

 z.value // first access
 // Computing Z
 // res14: Double = 0.3604236919233441
 z.value // second access
 // res15: Double = 0.3604236919233441

コードを実行した際の挙動（コメントアウトされている箇所）からもわかるとおり、三種類のスマートコンストラクタはそれぞれ val, def, lazy val に対応しており、[Eval のインスタンス].value にアクセスした際の挙動が異なっています。

私個人として、Eval を用いて複数の評価戦略を抽象化することのメリットは、以下の二点だと考えています：

Eval のインスタンスが map メソッド及び flatMap メソッドを持つ
Eval のインスタンスに対して for expression (fp-ts や Haskell 　の Do-notation 相当のもの)を使うことができる

以下のコードに例を示します：

val ans = for {
  a <- Eval
    .now { println("Calculating A"); 38 }
    .map(a => { println("map a to a'"); a + 2 })
  b <- Eval
    .always { println("Calculating B"); 1 }
    .map(b => { println("map b to b'"); b + 1 })
} yield {
  println("Adding A and B")
  a + b
}

println(ans.value)
// Calculating A
// map a to a'
// Calculating B
// map b to b'
// Adding A and B
// 42

1 については、A => B な関数や A => Eval[B] な関数があったとき、Eval のインスタンスがどの評価戦略を抽象化したものであっても同じように使うことができるという強みがあります。上記のコード例では実行順序をわかりやすくするために、 Eval.now({...}).map() に渡す式と、Eval.always({...}).map() に渡す式を別のものにしましたが、同じ式を渡すことも可能だったということです。

2 についてはまさにこのコードの通りで、Eval[Int] 型の変数 a と b 　は、その「中身」にかかわらず同じように for expression の内部で bind できる点が嬉しいです。

fp-ts にも `Eval` はあるの？

fp-ts に Eval はありません。そもそも TypeScript には lazy val 相当のキーワードが存在しないため、仮に fp-ts で Eval を提供するのであれば、lazy val 相当の機構を実装する必要があります。

過去に fp-ts の GitHub リポジトリに「Memoize をサポートしませんか？」という旨の issue が立ったことがあるようですが¹⁰、「caching はそれ単体で困難な課題であり、fp-ts が扱う範疇を超えている」という理由から close されています。

まとめ

Scala の言語仕様（評価戦略、高カインド型、implicit キーワード、etc.）に着目して、Cats と fp-ts の主な違いを確認していきました。まとめというよりは私の感想になりますが、やはり言語仕様のレベルでやろうとしていないことをライブラリで頑張るのは大変なのだなと思いました。今回扱ったトピックの中では、特に高カインド型のセクションをお読みいただくとその大変さの一端が伝わるのではないかと思います。ライブラリの開発・メンテナンスをしてくださっている人々には頭が上がらないぜという気持ちです。

株式会社 HERP では fp-ts をヘビーユースしており、また Haskell などの他の関数型プログラミング言語の採用実績もあります。Haskeller も開発チームに多く在籍しています（私は Haskell をほとんど使えませんが…🥺）。弊社の技術スタックやエンジニア組織に興味がある方は、Twitter DM や、マシュマロ（匿名で私に質問を投稿できるサービス）を通してご連絡ください。

Twitter: https://twitter.com/e_ntyo

マシュマロ： https://marshmallow-qa.com/e_ntyo

株式会社 HERP エンジニア向け採用資料： https://github.com/herp-inc/engineering-careers

また、テキストでのやり取りは面倒なのでオンラインでさくっとお話したい、という方は Meety をご利用ください。

Meety: https://meety.net/matches/obYSNNmaztSy

COVID-19 Pandemic の状況が改善次第、ぜひランチなどもいたしましょう。皆様とお話ができることを楽しみにしております。

ここまで記事をお読み頂き本当にありがとうございました！

iintyo on Twitter: "社内で "Scala with Cats" の輪読会を始めました。輪読会の第一回で使用したノートを HERP TechNote で公開しております📓 https://scrapbox.io/herp-technote/Scala_with_Cats_%E8%BC%AA%E8%AA%AD%E4%BC%9A" https://twitter.com/e_ntyo/status/1395296546346868737 ↩
"Who's using fp-ts? · Issue #1124 · gcanti/fp-ts" https://github.com/gcanti/fp-ts/issues/1124#issuecomment-583457360 ↩
Cats は最初のリリース（the first non-snapshot version of the Cats library）が2015 年 11 月で、fp-ts の最初のリリース（Initial experimental release）は 2017 年 2 月でした。また、Cats には前身のライブラリとして Scalaz があり、こちらの最初のリリースは 2010 年です。 ↩
fp-ts のいくつかの実装は、Cats から porting されています。v2.0.0 の時点では、Semigroup と Monoid のコードに "Adapted from https://typelevel.org/cats" とありますし、思想や設計などについても Cats やその他のライブラリ・プログラミング言語から影響を受けていると思われます。 ↩
本当は全 11 章で、第 9 章から第 11 章までは Case Study （第 8 章までの内容を踏まえて、Real World な問題・仕様をどう Functional な実装に落とし込むか)的な内容になっており、今回の輪読会では扱いませんでした。 ↩
以下の内容を日本語訳し、補足を加えました。 "How to write type class instances for your data type" https://github.com/gcanti/fp-ts/blob/2.11.8/docs/guides/HKT.md ↩
"3. Using GHCi — Glasgow Haskell Compiler 9.0.1 User's Guide" https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/ghci.html#ghci-cmd-:kind ↩
"猫番 — 型を司るもの、カインド" https://eed3si9n.com/herding-cats/ja/Kinds.html ↩
この指摘は、こちらの記事で書かれていた内容です： "Encoding HKTs in TS4.1 - DEV Community 👩‍💻👨‍💻" https://dev.to/matechs/encoding-hkts-in-ts4-1-1fn2 ↩
"Add memoize · Issue #1138 · gcanti/fp-ts" https://github.com/gcanti/fp-ts/issues/1138 ↩

fp-ts 2.8.0 で追加された bind, bindTo について

e_ntyo — Sun, 23 Aug 2020 10:34:55 +0000

tl; dr

fp-ts-contrib の do notation に代わって、fp-ts 2.8.0 では Option, Either などの各種の Monad に bind, bindTo というメソッドが生えた。
- CHANGELOG
- fp-ts-contrib の依存なしに、do notation 的なコードがかけるようになった
do notation と同様に、bind, bindTo を使うことで複数の Monadic な値の計算でコールバックによりネストが深くなる問題を解決できる。

do notation

PureScript など、一部のプログラミング言語には do notation と呼ばれる記法があります。PureScript の公式ドキュメントからコード例を引用します。

maybeSum :: Maybe Number -> Maybe Number -> Maybe Number
maybeSum a b = do
  n <- a
  m <- b
  let result = n + m
  pure result

maybeSum は Maybe Number な値を 2 つ取って、和を求めて Maybe Number で返す関数です。do キーワードを使うと、その下のブロックでは例えば n <- a と書くことで Maybe Number な a を Number 型の変数として n に束縛できます。これの何が嬉しいかは、do notation を使わなかった場合の例を考えるとわかります。

maybeSum :: Maybe Number -> Maybe Number -> Maybe Number
maybeSum a b =
  bind a \n ->
    bind b \m ->
      let result = n + m
      in pure result

bind a \n ->, bind b \m -> によりネストが二段深くなってしまいました。do notation を使った場合のコードとプログラムの内容が同じであるとすると、bindキーワードがどのようなはたらきをするかは直感的にわかるでしょう。今回の Post において重要なことは、「do notation を使うことで bind を使わずに済んでいる」、ということです（もしくはその逆）。PureScript の公式ドキュメントでは、bind x \a -> ... が a <- x の糖衣構文であることが明記されています。

a <- x which desugars to bind x \a -> ...

fp-ts における do notation

話を PureScript から TypeScript というプログラミング言語に移します。TypeScript には標準で Monad や do notation のサポートがありません。しかし、 gcanti/fp-ts などのライブラリを利用することで Monadic なコードが書けるようになります。

ただ、do notation については gcanti/fp-ts-contribという別パッケージに切り出されていました。fp-ts-contrib が提供していた Do 、次のようにして使われていました。

import { Do } from "fp-ts-contrib/lib/Do";
import { option, some } from "fp-ts/lib/Option";

const result = Do(option)
  .bind("a", some(1))
  .bind("b", some(2))
  .return(({ a, b }) => a + b);

ここからようやく本題に入っていくのですが、上記のコードが fp-ts 2.8.0 からは以下のように書けるようになりますよというのが今回共有したかった話です。

import * as O from "fp-ts/lib/Option";
import { pipe } from "fp-ts/lib/function";

const result = pipe(
    O.bindTo("a")(O.some(1)),
    O.bind("b", () => O.some(2)),
    O.map(({ a, b }) => a + b)
  );
}

Option などの各モナドごとに bind, bindTo が提供され、 fp-ts-contrib に依存せず do notation 的なコードが書けるようになりました。

O.bind("b", () => O.some(2)) を O.bindTo("b", O.some(2)) と書きたくなりますが、O.bind と O.bindTo は引数の取り方が違う上、bindTo では pipe で流れてくる Option<A> の A の情報を引き継ぐことができません。（{ a: O.some(1) }を引き継ぐことができない）

上記のコードのようなケースでは、 bindTo もしくは bind を pipe の先頭で使い、以降は bind で繋いでいくという方針で書いていくと良さそうです。

おわりに

この記事はアルバイト先の株式会社 HERP のまざっちさん（@mazamachi）に勧められて書きました。また、まざっちさんには執筆の上でのアドバイスをいただきました。ありがとうございます 🙌

HERP では、TypeScript の高度な型システムや fp-ts などの関数型プログラミングのライブラリを駆使して、混沌とした Web フロントエンドの世界をともに生き抜いていくソフトウェアエンジニアを募集しております。オフィスは東京・京都・つくばにあってフルリモートも多分可能です。いい会社です！

elm-tsでReactの代わりにPreactを使う

e_ntyo — Sun, 26 Jul 2020 14:03:23 +0000

TL; DR

gcanti/elm-ts というライブラリがあり、fp-tsでElm Architectureを実装している
elm-tsはvirtual-domの代わりにReactを使っているがPluggableである
- > React instead of virtual-dom (pluggable)
- しかし、具体的にどのように他のVirtual DOMの実装を使えばよいか具体的な記述はない
- この記事ではPreactを使う場合の具体的なやり方を紹介する。おそらく同じやり方で他のVirtual DOMの実装（snabbdom-modulesなど）も使うことが出来るはず

やり方

一言で言えば、elm-ts/lib/React の Html インターフェースの代わりにPreact Compatibleな Html インターフェースを自前で定義して使えばok。

/**
 * `Dom` is a `ReactElement`.
 * @category model
 * @since 0.5.0
 */
export interface Dom extends ReactElement<any> {
}
/**
 * `Html` has `Dom` type constrained to the specialized version for `React`.
 * @category model
 * @since 0.5.0
 */
export interface Html<Msg> extends html.Html<Dom, Msg> {
}

elm-ts/lib/React の Html インターフェースの定義はこんな感じなので、Dom(=ReactElement<any>)をPreact相当のものに差し替えればよさそう。

// Instead of Html, use PreactHtml
export type PreactHtml<Msg> = Html<h.JSX.Element, Msg>;

よしなにview functionの定義で PreactHtml を使う。

export function view(model: Model): PreactHtml<Msg> {
  return <div>...</div>
}

あとは program を run するだけだが、React.program を使うことはできないので elm-ts/lib/Html の program を次のようにして使う。

import { programWithDebuggerWithFlags } from "elm-ts/lib/Debug/Html";

import { Flags, Model, Msg, flags, init, update, view } from "./App";
import { programWithFlags, run } from "elm-ts/lib/Html";
import { VNode, h, render } from "preact";

// React.programはもういないんだ
const program = process.env.NODE_ENV === "production" ? programWithFlags : programWithDebuggerWithFlags;

// もうあの時間は終わって、君も人生と向き合う時なんだ
// programのGenericsの4つ目にpreactの VNode を使っているところに注意
const main = program<Flags, Model, Msg, VNode>(init, update, view);

const app = document.getElementById("app");
if (app === null) {
  throw new Error("id=appな要素がない");
}

run(main(flags), dom => render(dom, app));

おわり。

おことわり

elm-tsはできて間もないライブラリなので仕様がすぐ変わり、このやり方では動かなくなるかも
- 公式のREADMEにPRを出さずにBlog Postにした理由はこれ

小規模なSPAをつくってみてわかったFable(F# -> JS)の良いところ

e_ntyo — Sun, 29 Mar 2020 05:03:03 +0000

突然ですが私、「論文等の書誌引用データのフォーマットを変換するための SPA」をつくりました✌️

RIS形式の書誌引用データをSIST02形式に変換するツールをつくった - いいんちょのブログ

開発には Fable という AltJS を使ったのですが、Fableは素晴らしいツールであるにもかかわらず、あまりWeb開発者に知られていない印象を受けます。この機会にFableを紹介する日本語記事を書こうと思います💁‍♂️

Fable とは

Fable is a compiler powered by Babel designed to make F# a first-class citizen of the JavaScript ecosystem
https://fable.io/

Fable は F#のコードを Babel compatible な AST に変換するツールです。つまり TypeScript のように、最終的に JavaScript のコードに変換されるプログラミング言語を書くことができます。

F#の良いところについては、@cannorinさんの「F# を知ってほしい」が詳しいです。

この記事では、Fable の良いところ、すなわち F#を Web フロントエンド開発で使うとどのような点が嬉しいのかなどについて書いていきます。また、Fable というツールそのものの良い点にも触れていきます。

Fable(F#) のよいところ

Fable でなくても、TypeScript という非常に便利で手軽で強力な AltJS がありますし、他にも Elm や ReasonML、PureScript があります。ただし、私は Elm, ReasonML その他の AltJS による開発の経験がないため、以降でも比較対象には TypeScript と PureScript が使われます。あしからず 🙇‍♂️

私個人が Fable を選んだ理由は、以下の条件を満たす AltJS が欲しかったためです。

TypeScript と PureScript の中間くらいの抽象度で
TypeScript で普段感じている不満点を解消してくれて
ESModules な JS のコードを出力可能で
Language Server の実装やいい感じのビルドツールが存在する

1. 適当な抽象度

この項目については、私が過去に PureScript を使って SPA を開発した際の経験に基づいています。

PureScript は Row Polymorphism などを実現するための非常に高度な型システムを備えていますが、そのせいか公開されているライブラリを使って開発しようとするとコンパイルを通すことがとても大変で、正直フラストレーションを感じることもありました。

PureScript には TypeScript のような漸進的型付けの仕組みはありませんし、 tsconfig.json の compilerOptions ようにコンパイル時の設定を細かく設定するということもできないため、これは私にとっては大きな問題でした。むしろ Haskell のバックグラウンドをお持ちの方や、言語仕様の学習にたくさんの時間を確保できる方にとっては非常に良い選択肢だと考えています。

F#にも漸進的片付けの仕組みはありませんが、以下の理由から PureScript のコードを書くときほどの頭の痛さはありませんでした。

型クラスがありません
型レベルプログラミングを強いられることがほぼありません
- PureScript のライブラリでは、「Record の型定義から対応する JSON エンコーダを導出する」といった型レベルプログラミングを割とバンバンやっています
デフォルトではモナドがありません
- Computational Expression を使うことでやろうと思えば実装できます
- 実際にFSharpPlus というライブラリで提供されていますが、Fable ではまだ使えないようです

2. TypeScript で普段感じている不満

私は普段 TypeScript を書いていて、開発体験にある程度満足しているのですが、「もっとこうなってほしい」と思う点がいくつかあります。

パターンマッチがほしい
Template literals(sprintf)は Type Safe であってほしい
関数合成が手軽にできてほしい

ただし、PureScript や ReasonML でもこれらの不満は解消されます。

2.1 パターンマッチ

まずパターンマッチについてですが、TypeScript でも次のようにして書くことはできます。

function maybe<A, B>(
  whenNone: () => B,
  whenSome: (a: A) => B,
  fa: Option<A>
): B {
  switch (fa._tag) {
    case "None":
      return whenNone();
    case "Some":
      return whenSome(fa.value);
  }
}

(コードはfp-ts のドキュメント内のものです)

ただし、JavaScript における Switch は式ではなく文ですから、パターンマッチ部分の処理を変数に束縛できません。
fp-ts の作者 @gcanti さんのブログ記事では、もう少しパターンマッチを宣言的に書く方法("'poorman' pattern match")が紹介されています。 List では onNil と onCons 、 Option では onSome と onNone の時に評価される関数を定義して使う、という考え方です。

//        ↓ type parameter
type List<A> = { type: "Nil" } | { type: "Cons"; head: A; tail: List<A> };
//                                                              ↑ recursion

const fold = <A, R>(
  fa: List<A>,
  onNil: () => R,
  onCons: (head: A, tail: List<A>) => R
): R => (fa.type === "Nil" ? onNil() : onCons(fa.head, fa.tail));

const length = <A>(fa: List<A>): number =>
  fold(
    fa,
    () => 0,
    (_, tail) => 1 + length(tail)
  );

(コードはFunctional design: Algebraic Data Types - DEV Community 👩‍💻👨‍💻中のものです)

このやり方の欠点は代数的データ型 1 つにつきこういった関数を毎回用意しなければならないということです。fp-ts では Option , Either などの代数的データ型については fold などを提供しており便利ですが、自前で代数的データ型を宣言した際にはやはり対応した fold を定義して使うことになります。

一方で、F#は言語仕様としてパターンマッチを定義しているため、自前の代数的データ型についてもふつうにパターンマッチを使うことができます。しかも、以下の match は文でなく式です。

[<Literal>]
let Three = 3

let filter123 x =
    match x with
    // The following line contains literal patterns combined with an OR pattern.
    | 1 | 2 | Three -> printfn "Found 1, 2, or 3!"
    // The following line contains a variable pattern.
    | var1 -> printfn "%d" var1

for x in 1..10 do filter123 x

(コードはF#のドキュメント内のものです)

2.2 Template literals(sprintf)は Type Safe であってほしい

これは言語仕様というよりはもう少し具体的な、特定の機能についての話ですが、ES2015 specification から導入された Template literals を TypeSafe に扱いたいという思いがあります。

（以下のコードの一部に誤りがあったことを @otofuneから教えて頂き、修正しました。）

const displayName = "e_ntyo";
const user = { displayName };
const tagged = `Hello! I am ${displayName}`; // "Hello! I am e_ntyo"
const tagged2 = `Hello! I am ${user}`; // "Hello! I am [object Object]" <- 勝手にtoString()されている

FSharp ではこの機能は sprintf という関数として提供されており、Type-Safe です。

type User = { DisplayName: string }

let displayName = "e_ntyo"
let user = { DisplayName = displayName; }
let tagged = displayName |> sprintf "Hello! I am %s"; // "Hello! I am e_ntyo"
let tagged2 = user |> sprintf "Hello! I am %s"; // The type 'User' does not match the type 'string'

2.3 関数合成が手軽にできてほしい

TypeScript では関数合成がやや面倒で、Type-Safe にやっていくためには次のような合成用関数を定義する必要があります。

function compose<A, B, C>(f: (arg: A) => B, g: (arg: B) => C): (arg: A) => C {
  return x => g(f(x));
}

interface Person {
  name: string;
  age: number;
}

function getDisplayName(p: Person) {
  return p.name.toLowerCase();
}

function getLength(s: string) {
  return s.length;
}

// has type '(p: Person) => number'
const getDisplayNameLength = compose(getDisplayName, getLength);

// works and returns the type 'number'
getDisplayNameLength({ name: "Person McPersonface", age: 42 });

(コードはTypeScript のドキュメントからです。)

F#では、関数合成用のオペレータが最初から提供されており、より簡潔に記述できます。

// Write code or load a sample from sidebar
type Person = {
    Name: string;
    Age: int;
}

let getDisplayName (p: Person) =
  p.Name.ToLower()

let getLength (s: string) =
  s.Length

let getDisplayNameLength = getDisplayName >> getLength

getDisplayNameLength { Name = "Person McPersonface"; Age = 42 };

2 つ以上の関数を合成する場合でも、コードは綺麗です。

compose(compose(compose(f, g), h), i);

f >> g >> h >> i

3. target の Module System

AltJS としては、コードを書いている際に、「こういう JS のコードにコンパイルされるのだろうな」というイメージができると理想的です。

例えば、以下の PureScript のコードをトランスパイルするとします。

module Main where

import Prelude

import Data.Either (Either(..))
import Data.Maybe (Maybe(..))
import Effect (Effect)
import Effect.Console (log)

f :: Maybe Boolean -> Either Boolean Boolean -> String
f a b = case a, b of
  Just true, Right true -> "Both true"
  Just true, Left _ -> "Just is true"
  Nothing, Right true -> "Right is true"
  _, _ -> "Both are false"

main :: Effect Unit
main = do
  log $ f (Just true) (Right true) -- Both true

このような CommonJS モジュールの JS のコードに変換されます。
（※@oreshinyaさんから「掲載されているコードは CommonJS モジュールのコード（ purs build によって生成されるコード）ではなく、 purs bundle によって生成されるiife形式のコードになっている」というご指摘を頂き修正いたしました。）

// Generated by purs version 0.13.6
"use strict";
var Data_Either = require("../Data.Either/index.js");
var Data_Maybe = require("../Data.Maybe/index.js");
var Effect_Console = require("../Effect.Console/index.js");
var f = function (a) {
    return function (b) {
        if (a instanceof Data_Maybe.Just && (a.value0 && (b instanceof Data_Either.Right && b.value0))) {
            return "Both true";
        };
        if (a instanceof Data_Maybe.Just && (a.value0 && b instanceof Data_Either.Left)) {
            return "Just is true";
        };
        if (a instanceof Data_Maybe.Nothing && (b instanceof Data_Either.Right && b.value0)) {
            return "Right is true";
        };
        return "Both are false";
    };
};
var main = Effect_Console.log(f(new Data_Maybe.Just(true))(new Data_Either.Right(true)));
module.exports = {
    f: f,
    main: main
};

一方で、F#ではだいたい同じ処理をこのように書くことができます。

// http://www.fssnip.net/ji/title/Either-in-F
[<AutoOpen>]
module Either

type Either<'a, 'b> =
    | Left of 'a
    | Right of 'b

type either<'a, 'b> =
    Either<'a, 'b> // lower-case alias like option

let isLeft = function
  | Left _ -> true
  | _      -> false

let isRight = function
  | Right _ -> true
  | _      -> false

let f (fa: Option<bool>) (fb: Either<bool, bool>) =
  match fa, fb with
  | (Some true), (Right true) -> "Both true"
  | (Some true), (Left _) -> "Some is true"
  | None, (Right true) -> "Right is true"
  | _, _ -> "Both are false"

f (Some true) (Right true) |> printfn "%s"

Fable 用の Webpack の Loader である fable-loader などを使うことで、デフォルトの設定では次のような ESModules 形式の JS のコードに変換されます。

import { declare, Union } from "fable-library/Types.js";
import { union } from "fable-library/Reflection.js";
import { toConsole, printf } from "fable-library/String.js";
export const Either$00602 = declare(function Either_Either(
  tag,
  name,
  ...fields
) {
  Union.call(this, tag, name, ...fields);
},
Union);
export function Either$00602$reflection($gen$$1, $gen$$2) {
  return union("Either.Either`2", [$gen$$1, $gen$$2], Either$00602, () => [
    ["Left", [$gen$$1]],
    ["Right", [$gen$$2]]
  ]);
}
export function isLeft(_arg1) {
  if (_arg1.tag === 0) {
    return true;
  } else {
    return false;
  }
}
export function isRight(_arg1$$1) {
  if (_arg1$$1.tag === 1) {
    return true;
  } else {
    return false;
  }
}
export function f(fa, fb) {
  var $target$$7;

  if (fa == null) {
    if (fb.tag === 1) {
      if (fb.fields[0]) {
        $target$$7 = 2;
      } else {
        $target$$7 = 3;
      }
    } else {
      $target$$7 = 3;
    }
  } else if (fa) {
    if (fb.tag === 0) {
      $target$$7 = 1;
    } else if (fb.fields[0]) {
      $target$$7 = 0;
    } else {
      $target$$7 = 3;
    }
  } else {
    $target$$7 = 3;
  }

  switch ($target$$7) {
    case 0: {
      return "Both true";
    }

    case 1: {
      return "Some is true";
    }

    case 2: {
      return "Right is true";
    }

    case 3: {
      return "Both are false";
    }
  }
}

(function() {
  const arg10 = f(true, new Either$00602(1, "Right", true));
  const clo1 = toConsole(printf("%s"));
  clo1(arg10);
})();

SPA 開発のように生成される JS をブラウザで動かしたい場合、Tree Shaking ができるなどの理由から ESModules 形式で出力したくなるケースがあります。

PureScript は現状 CommonJS Modules 以外のモジュールシステムをターゲットにできず、ES modules · Issue #3613 · purescript/purescriptで今後の対応が議論されています。

また、Fable は仕組みとして F#のコード -> F# AST -> Babel AST -> JS のコード の順に変換していくため、Bundler などを使う際に Babel のオプションを噛ませることも可能です。例えば Webpack(Fable/src/fable-loader at master · fable-compiler/Fable) で Babel の @babel/preset-env を使う場合は、次のように webpack.config.js を記述します。

const path = require("path");

module.exports = {
  mode: "development",
  entry: "./src/App.fsproj",
  devtool: "  source-map",
  output: {
    path: path.join(__dirname, "./public"),
    filename: "bundle.js"
  },
  devServer: {
    publicPath: "/",
    contentBase: "./public",
    port: 8080
  },
  module: {
    rules: [
      {
        test: /\.fs(x|proj)?$/,
        exclude: "/node_modules/",
        use: {
          loader: "fable-loader",
          options: {
            babel: {
              presets: [
                [
                  "@babel/preset-env",
                  {
                    modules: false
                  }
                ]
              ]
            }
          }
        }
      }
    ]
  },
  optimization: {
    usedExports: true
  }
};

Source Map や Tree Shaking を有効にするための設定が一部含まれています。fableconfig.json (TS の tsconfig.jsonに相当) にもそういった設定を記述する必要があります。

{
  "sourceMaps": true,
  "targets": {
    "production": {
      "sourceMaps": false
    }
  },
  "module": "es2015",
  "ecma": "es2015"
}

これで TypeScript を使うときと変わらず、Tree Shaking や sourcemap が利用できます。素晴らしいですね。

2.4 Language Server の実装やいい感じのビルドツールが存在する

F#にはどちらもあります。ビルドツールは dotnet というものがあり、Language Server の実装は Vim や VSCode の拡張から使われています。ナイスなパッケージマネージャの paket というものもあります。詳しくは@cannorinさんの「F# を知ってほしい」をご覧ください。

Mono と同じく, .NET Core は Windows, OS X, Linux のどのプラットフォームでも全く同じ開発・実行環境を使うことができます.

.NET Core には dotnet という CLI ツールが同梱されており, Rust における cargo コマンドと同様の立ち位置・同等の強力な機能を備えています.

SDK 自体に同梱されているので何もしなくても使えますし, コンパイラを作っているのと同じところが作っているので余計な互換性問題を考えなくて済むのも利点です(cargo と同じように).

Q. Visual Studio Code がないと書けないのでは？

A. Vim プラグインや Emacs mode があり, IntelliSense 補完やオンザフライでのシンタックス/コンパイルエラーチェック, 定義されているソースへのジャンプなどを使うことができます.

また, Ionide という VSCode 用の F# 拡張機能があり, こちらでは上に加えて CodeLens での型シグネチャ表示やマウスオーバーでの型表示, GUI でのデバッグなどもすることができます.

なお搭載されている補完エンジン自体はすべて共通のもので, Visual Studio のものよりは賢くないですが十分便利です.

まとめ

Fable という F#のコードを Babel compatible な AST に変換するツールがある
- Babel を使うことで TypeScript 同様、target などを自由に指定できる
- バンドラを使う際にはTree Shakingやsourcemapを利用できる
Fable によって、F#で Web フロントエンド開発をすることができる
- Type-Safe で Functional なプログラミングができるようになる
- 現段階で JavaScript にはないパターンマッチなどの機能を使うことができる

TypeORMにおいて、`date` は `Date` でなく `string` にmapされるので気をつけましょう

e_ntyo — Fri, 28 Feb 2020 09:16:31 +0000

tl; dr

TypeORMで Entity を定義する際、日付時刻 (datetime) ではなく 日付 (date) を格納したいと考えている場合はこの記事のことを思い出してください。TypeORMの内部では、DBMSの date からJavaScriptの Date への変換が大変であるため string で持つ仕様になっているようです。したがって、date なカラムのTypeScriptでの型は直感的には Date ですが、実際には string が正しいようです。

詳細

以下のEntityを例とします。

@Entity('users')
export class User extends AbstractEntity {
  @Column('varchar', {
    name: 'name',
  })
  public name!: string;

  @Column('date', {
    name: 'birthday',
    nullable: true,
  })
  public birthday!: Date; // <- 正しくは `string`
}

ここで、カラム birthday は Date とされていますが、これは不適切で string であるべきです。なぜならTypeORMの内部では、日付情報を決まったフォーマットの文字列、すなわち string 型の値で持つ仕様になっているためです。

TypeORMのCore Comitterである@pleerock氏は、この挙動について次のように言及しています。

date is mapped into string since it causes lot of issues when its mapped into Date because of missing hours minutes and seconds. Only full datetime is mapped into Date object. We had lot of discussions about dates behaviour in past
Date column returns a date string instead of a date object · Issue #2176 · typeorm/typeorm

「時刻情報を含まない date なカラムの値をJSの Date に変換する際、秒・分・時の情報が無いが故に様々な問題を引き起こすため変換せず文字列で持っている」とのことです。

というわけで date なカラムの値を文字列で受け取ることになるわけですが、逆にデータを格納する際の便利のため、 Date から string (各DBMSごとのdate-stringのフォーマットに則った文字列（例えばMySQLなら YYYY-MM-DD もしくは YYYYMMDD )に変換する関数を用意しておくと良いです。

import { format } from 'date-fns';

function convertDateObjectToDateString(date: Date) {
    return format(date, 'YYYYMMDD');
}

string でもらった date なカラムの値を自力で Date にしたいという人は、まあ頑張ってください。

おしまい

hyper-ts で type-safe & stateless なExpressアプリケーションを構築する

e_ntyo — Fri, 02 Aug 2019 02:55:11 +0000

hyper-ts で type-safe & stateless なExpressアプリケーションを構築する

tl; dr

TypeScriptとExpressを使ってアプリケーションを開発するにあたって、以下の課題がある。

現状、 @types/express における型定義は厳密でない
リクエストハンドラの中でごちゃごちゃとやってしまい、ステートフルになりがち

こうした課題に対して、gcanti/hyper-ts が有効である。

1. `@types/express` における型定義はstrictでない

例として、Application インターフェースの render メソッドの型定義を見てみる。

render(view: string, options?: object, callback?: (err: Error, html: string) => void): void;

この型定義は厳密さに欠ける。まず、第二引数のoptionsの型は objectである。（cookieメソッドのオプションは CookieOptionとして定義されている。）

また、これは厳密さどうこうというより誤りだが、callback の型は (err: Error | null, html: string) => void が正しい（検証環境を用意するのは面倒だったので各自で要検証とする）。

Expressに限った話ではなく、JavaScriptライブラリに後付で型定義がつくられる場合はこうして曖昧な状態に留められることが多くある（要出典）。しかしながら、export type Send = (body?: any) => Response;のようにany が使われている箇所も多く、我々のような型定義をなるべく頑張りたい人々にはつらい状況である。

2. リクエストハンドラの中でごちゃごちゃとやってしまい、ステートフルになりがち

以下のコードは、拙作 https://anygma.site のためのRESTful HTTP APIのエンドポイントの実装である。ユーザのテキスト投稿を受け付けるために使われている。

app.post("/posts", async (req, res) => {
  const { title, body, createdById, password } = req.body as PostOption;
  if (!body) {
    return res.status(400).send("本文を入力してください");
  }
  if (body.length > 1200) {
    return res.status(400).send("本文は1200字までです");
  }
  if (title && title.length > 50) {
    return res.status(400).send("タイトルは50字までです");
  }
  if (!createdById) {
    return res.status(400).send("ユーザidが提供されませんでした");
  }
  const userRecord = await admin
    .auth()
    .getUser(createdById)
    .catch(error => {
      console.error({ error });
      return null;
    });
  if (!userRecord) {
    return res.status(400).send(`ユーザ: ${createdById}は存在しません`);
  }
  if (!password) {
    return res.status(400).send("パスワードが設定されていません");
  }
  if (password.length < 8) {
    return res
      .status(400)
      .send("パスワードが短すぎます。8文字以上にしてください。");
  }
  const passwordHash = await bcryptjs.hash(password, 10);

  const doc = await db.collection("/posts").add({
    title,
    body,
    createdById,
    passwordHash
  } as FSPost);
  const snapshot = await doc.get();
  const data = snapshot.data();
  if (!data) {
    return res.status(500).send("投稿の作成に失敗しました");
  }
  const { id } = doc;

  const bucket = admin.storage().bucket();
  const bucketName = bucket.name;
  // 投稿を編集したらプレビュー画像も変更されるようにしたいので、プレビュー画像は投稿のidから一意に決まるようにする
  const fileName = `${id}.png`;
  const previewUrl = `https://storage.googleapis.com/${bucketName}/${fileName}`;
  const bufferOrError = await generatePreview(body).catch(err => {
    console.error({ err });
    return new Error("プレビュー画像の生成に失敗しました");
  });
  if (bufferOrError instanceof Error) {
    return res.status(500).send(bufferOrError.message);
  }
  const tmpPath = join(tmpdir(), `${id}.png`);
  writeFileSync(tmpPath, bufferOrError);
  await bucket
    .upload(tmpPath, {
      metadata: { contentType: "image/png" },
      public: true
    })
    .catch(err => {
      console.log({ err });
      return res.status(500).send("プレビュー画像のアップロードに失敗しました");
    });
  unlinkSync(tmpPath);
  await doc.set({ previewUrl } as Partial<Post>, { merge: true });
  return res.send({
    id,
    title,
    body,
    createdAt: snapshot.createTime ? snapshot.createTime.seconds : undefined,
    createdBy: extractDataFromUserRecord(userRecord),
    previewUrl
  } as Post);
});

実装の詳細はどうでもよく、外部のデータストアへのアクセスやデータのバリデーションなど、同期的な/非同期的な/純粋な/副作用のある様々な処理が１つの関数の中に記述されてしまっている。これではテスタビリティもへったくれもない。幸い、ExpressにはMiddlewareという仕組みがあり、これを使うことである程度処理を分割してつなげることができる。このあと紹介する hyper-ts というライブラリでは、公式の型定義よりもさらに強力な型定義を武器に、このMiddlewareを中心にステートレスなアプリケーションを記述するための仕組みを提供してくれている。

hyper-tsの紹介

公式のREADMEによると、

hyper-ts is an experimental middleware architecture for HTTP servers written in TypeScript.
Its main focus is correctness and type-safety, using type-level information to enforce correct composition and abstraction for web servers.

hyper-tsは type-safety を重視した middleware architecture とのことである。以下は拙作 https://tweet2img.web.app において、ツイートのURLを送るとpng形式の画像が返ってくるAPIエンドポイントの実装である。

// 前略

function badRequest<E = never>(
message: string
): H.Middleware<H.StatusOpen, H.ResponseEnded, E, void> {
return pipe(
  H.status(H.Status.BadRequest),
  H.ichain(() => H.closeHeaders()),
  H.ichain(() => H.send(message))
);
}

function notFound<E = never>(
message: string
): H.Middleware<H.StatusOpen, H.ResponseEnded, E, void> {
return pipe(
  H.status(H.Status.NotFound),
  H.ichain(() => H.closeHeaders()),
  H.ichain(() => H.send(message))
);
}

function serverError<E = never>(
message: string
): H.Middleware<H.StatusOpen, H.ResponseEnded, E, void> {
return pipe(
  H.status(H.Status.ServerError),
  H.ichain(() => H.closeHeaders()),
  H.ichain(() => H.send(message))
);
}

const sendError = (
err: TweetURLError | typeof FailedToGenerateImage
): H.Middleware<H.StatusOpen, H.ResponseEnded, never, void> => {
switch (err) {
  case 'TweetNotFound':
    return notFound(TweetNotFoundMessage);
  case 'InvalidArguments':
    return badRequest(InvalidRequestMessage);
  case 'FailedToGenerateImage':
    return serverError(InternalServerErrorMessage);
}
};

// returns a middleware validating `req.param.tweetURL`
const m = t.interface({
  tweetURL: TweetURL
});
const decoded = H.decodeQuery(m.decode);

const parseTweetURLFromQueryMiddleware = pipe(
  decoded,
  H.mapLeft<t.Errors, ServerError | TweetURLError>(() => InvalidArguments)
);

const checkIfTheTweetExistsMiddleware = (query: {
  tweetURL: TweetURL;
}): H.Middleware<
  H.StatusOpen,
  H.StatusOpen,
  ServerError | TweetURLError,
  ValidatedTweetURL
> =>
  H.fromTaskEither(
    pipe(
      checkIfTheTweetExists(query.tweetURL, {
        TWITTER_BEARER_TOKEN
      }),
      TE.chain(exists =>
        exists
          ? TE.right(query.tweetURL as ValidatedTweetURL)
          : TE.left(TweetNotFound)
      )
    )
  );

const mapTweetURLToImage = (
  url: ValidatedTweetURL
): H.Middleware<
  H.StatusOpen,
  H.StatusOpen,
  ServerError | TweetURLError,
  Buffer
> =>
  H.fromTaskEither(
    pipe(
      generateImage(url),
      TE.mapLeft(e => FailedToGenerateImage)
    )
  );

const respondWithImage = (
  imgBuffer: Buffer
): H.Middleware<
  H.StatusOpen,
  H.ResponseEnded,
  ServerError | TweetURLError,
  void
> =>
  pipe(
    H.status(H.Status.OK),
    H.ichain(() =>
      H.header('Content-disposition', `inline; filename="${new Date()}.png"`)
    ),
    H.ichain(() => H.contentType(H.MediaType.imagePNG)),
    H.ichain(() => H.closeHeaders()),
    H.ichain(() => H.send(imgBuffer))
  );

const getImage = pipe(
  parseTweetURLFromQueryMiddleware,
  H.ichain(checkIfTheTweetExistsMiddleware),
  H.ichain(mapTweetURLToImage),
  H.ichain(respondWithImage)
);

app.get(
  '/img',
  toRequestHandler(
    pipe(
      getImage,
      H.orElse(sendError)
    )
  )
);

`Middleware<I, O, L, A>`

3~44行目では、普段 res.status(HTTP_ERROR_STATUS_CODE).send(ERROR_BODY) などとしてエラーを返している処理をMiddlewareとして定義している。ここでMiddlewareの型 H.Middleware<I, O, L, A>は以下のようなセマンティクスを持っている。

I : ユーザエージェントとHTTPサーバの通信状態を表す Connection 表現を用いて、このミドルウェアが呼びだれたときの通信状態を表現した型。この例ではH.StatusOpenが使われており、レスポンスの status-line が送信可能な状態を表している。
O : I の Input に対して Output （ミドルウェアの処理が終わった時の通信状態）を表現した型。この例ではH.ResponseEndedが使われており、レスポンスヘッダが送信可能な状態（i.e. レスポンスボディのストリーミングが開始されていない状態）を表している。
L : Eitherモナドの左辺値の型。この例では neverが指定されており、エラー表現を表している。
A : Eitherモナドの右辺値の型。この例では void が指定されており、エラーがなかった場合に次のミドルウェアに渡る値の型を表している。

ここで、36行目から44行目にかけて、パターンマッチングのようにしてミドルウェアの返しうるエラーの種類毎にエラーメッセージを send している点に注目してほしい。リクエストハンドラをミドルウェアの合成で表現することで返しうるエラーが明確となり、このような記述が可能になっている。クライアントサイドでTypeScriptを採用していれば、この型を使いまわしてエラーの種類ごとにエラーメッセージを出し分けることもできる。

また、I そして O を定義しておくことで、リクエストヘッダをクローズしたあとに値をセットしようとしたり、最終的に send するMiddlewareのあとに別のMiddlewareを繋げたりしようとしたことをコンパイル時に検出することができる。

io-ts を使ってリクエストbodyやクエリパラメータに実行時型検査をする

46行目から55行目では、実行時型検査をするためのライブラリio-tsを使って、URLのクエリパラメータをパースするミドルウェアを定義している。io-ts を使うことで、プログラムの実行時に期待する型（今回の例では string の亜種である NonEmptyString）と異なる型の値を受け取った場合でも、left(ERROR_INSTANCE) を返すなど適切に処理することが出来るようになる。

最後に

hyper-tsはfp-tsのエコシステムに乗っかっているが、この記事の公開時点でhyper-tsの最新リリースはfp-tsの新しいメジャーバージョンである2.xに対応していないので注意されたし。
- 2.xではAPIにいくつかbreaking changesがあり、いまから使い始めるのであれば2.xを採用するべき。
- 0.5.0ブランチは2.xに対応している（現在の最新リリースは 0.4.0）。
  - この記事に書かれたコードは0.5.0のhyper-tsのAPIを使っているため合わせて注意されたし。
今回登場した Either などのモナドが何なのかよくわかっていなくても、静的型付けを頑張りたいTSプログラマにはhyper-tsをお勧めできる。
- TypeScriptでは現状、純粋な関数として扱っている関数の中で console.log などの純粋でない関数を呼び出してもコンパイルエラーにならない（HaskellやPureScriptなど、言語仕様としてモナドを想定している静的型付け言語の一部ではエラーになる）。これはfp-tsを使っても同様で、fp-tsを使ったからといって全然コンパイルが通らなくてつらいということはない（明らかに純粋な関数がチェインしているところに副作用のある処理を書くことに対して多少の罪悪感は生まれる）。モナドを「便利な道具」として、ぜひ気軽な気持ちで使い始めてほしい。

Elasticlunr.js で日本語と英語が混在した文書の検索に対応する

e_ntyo — Sat, 27 Apr 2019 14:31:19 +0000

tl; dr

Elasticlunr.jsで英語以外の言語に対応するためにはweixsong/lunr-languagesを使う必要がありますが、このライブラリは2019/04/27現在、日本語+他の言語の組み合わせ（複数言語からなる文書の検索）に対応できていません。正確には、サポートしていると書いてありますがこの組み合わせでは動きません。

weixsong/lunr-languages にパッチ的なPRを出しているので、同じ現象で困っている方がいらっしゃいましたらご確認ください。

背景

高速な全文検索を行うための軽量なJavaScriptライブラリとして Elasticlunr.js があります。こちらは標準では英語のみに対応しているため、日本語に対応するためには一手間必要です。これは軽量さを売りにしているライブラリとして正しいやり方でしょうし、やり方も公式ドキュメントやブログ記事に丁寧に書かれています。

デフォルトでは、英語での検索しか出来ない。
多言語対応プラグインを組み込めば、日本語で検索できる様になる。
lunrの多言語対応プラグインをElasticlunr向けにフォークした物を使用する。
weixsong/lunr-languages
※ lunr-languagesリポジトリは２つあるので注意。
MihaiValentin/lunr-languagesはlunr用であり、Elasticlunrで使用するとエラーが発生する。
weixsong/lunr-languagesを使用する必要がある。

— 【JSの全文検索エンジン】elasticlunr.jsを触ってみた～インストールからパイプライン、日本語対応など～ by @well

ですが、日本語に加えて英語など他国の言語にも対応する場合（これは、例えば検索クエリを 東京スカパラダイスオーケストラ MONSTER ROCK などとして、日本語と英語が混在する文書に対して検索を行う場合のことを指します）については、weixsong/lunr-languagesの実装が不十分でありが対応できていませんでした。

elasticlunrというJSの全文検索ライブラリを今触ってるんだけど、多言語対応辛そう
lunr(elasticlunrのベースとなったライブラリ）の多言語対応プラグイン使ってねとなっているが、elasticlunrとlunrのIFが噛み合ってなくて言語によっては動かないという
— うぇる (@well_itskill) 2019年1月22日

例えば、weixsong/lunr-languages のサンプルコードではロシア語と英語の両方に対応する例が挙げられていますが、このどちらかを日本語に変えると動かなくってしまいます。

これはfork元のMihaiValentin/lunr-languagesでは実装されている、日本語の文書のトークンを正規化する機能(trimmerと呼ばれます)がweixsong/lunr-languagesでは未実装であるためです。よくよく見てみるとweixsong/lunr-languages は5年前に更新が止まっているようなリポジトリであり、このようなことが起こっても何らおかしくはないのですが。

余談ですが、私が Elasticlunr.js を使うことになったのは Gatsby.js が検索に対応するためのプラグインとしてgatsby-contrib/gatsby-plugin-elasticlunr-searchを提供しているためです。こちらをforkして内部で weixsong/lunr-languages を噛ませることで複数言語に対応させています。私の周りでGatsby.js自体を使っている人はよく見かけるので、同じ悩みを抱えている人がいたりいなかったりするかもしれないと思ってこの記事を書きました。

— Mark Dalgleish (@markdalgleish) 2019年3月20日

コモナドスケッチ ~ 2. 大改造!!劇的ビフォーアフター ~

e_ntyo — Sat, 08 Dec 2018 08:58:58 +0000

コモナドスケッチ ~ 2. 大改造!!劇的ビフォーアフター ~

e_ntyoです。前回の投稿からだいぶ時間が空いてしまいましたが皆様いかがお過ごしでしょうか。私は先日誕生日を迎え、Twitterのフォロワーからよくわからないものをたくさん頂きました。

さて、この連載はAngularで書かれたSPAをPureScriptで書き換えるというものです。前回はスクラッチでアプリケーションの骨組みをつくり、それを例にとってpurescript-halogenについて（かなりざっくりとですが）解説しました。

次回（今回）以降は非同期処理やTyped CSSについて書く予定でしたが…

連載終了のおしらせ

はい。終わります。

理由は２つありまして、１つは今回の記事を書くタイミングが見つからず、先日ついに 書き換えが完了してしまった ためです。こちらにデプロイ済みです。

じゃあ前回の投稿からこれに至るまでを記事にしてよ、という話なんですが、残念ながら私はPureScript初学者でコード(特にAPIリクエスト周り)がだいぶ汚いのです…Justin氏からアドバイスこそもらったものの、まだ反映できていません。この辺りは別途記事にできればいいなと思っています。

余談ですが、WatchingUのCI環境では前々から気になっていたNix Package Managerを使ってみました。Nixを使ってPureScriptアプリケーションのビルド環境を構築する方法については、Justin氏のこちらの記事が詳しいです。psc-package2nixを使えばめちゃめちゃ簡単にミニマムなPureScriptのビルド環境が手に入ってうれしいです。

もう１つは、Halogenのrealworld exampleが産まれようとしているためです。こちらはpurescript-halogen-formlessの作者で、実務でもHalogenをゴリゴリ使っているというプログラマのthomashoneyman氏によるもので、本体はまだWIPですがガイド（こういう指針でアプリケーションを設計していこうみたいなやつ）の大部分をこちらで読むことが出来ます(少し前までソースコードと同じリポジトリにあったのですが切り離されたようです)。私の記事なんかを読むよりこっちを読んだほうが絶対に良いです。間違いないです。

ガイドには主にアプリケーションモナドを定義して変なことが起こらないようにしようだとか、純粋な関数(単にログイン中のユーザ名を受け取ってheaderやfooterなどのHTML p iなビューを返すやつら)とEffectを含むようなコンポーネント(APIリクエストをしたりlocalStorageにデータを保存したりするやつら)を分離しましょうなどのことが書いてあります。最後の項目だけまだWIPですが、本体が完成する頃には読めるようになるかと思われます。

そういうわけなので、どうせみんな読んでないし…もうゴールしてもいいかな…

次

まだWatchingUでやり残したことはたくさんあるんですが、どうせなら先述のrealworld exampleを読んでから取り掛かりたいというのと、他に作りたいものができたのでそっちを優先しようという気持ちがあります。次はThree.jsのバインディングを使っておもちゃを作ります。できたら記事にしますね。ではまた。

コモナドスケッチ ~ 1. DOMのコラージュ ~

e_ntyo — Tue, 23 Oct 2018 23:12:40 +0000

これはなに？

PureScriptでSPAを書いていく連載記事で、hiruberutoさんのモナドのまほうシリーズのオマージュです。本家はマインクラフトみたいなブラウザゲームをPureScriptで書いていくやつでめっちゃ面白いです✨

なお、「PureScriptが何なのか、どういう利点があるのか」等のメタな内容についてはこの記事で解説しません。(途中でJSフレームワークやECMAScriptとPureScriptを比較することはあるかもしれませんが)。hiruberutoさんの純粋関数型スクリプト言語PureScriptのはじめかたなどが参考になります🙌

tl; dr

slamdata/purescript-halogenを使うとモナディックに、そして型安全にSPAが構築できてすごい
- 今回は主にこのpurescript-halogenの解説になります。需要があれば別途Halogenの解説記事を書くかもしれません📝
purescript-halogenでフルスタックなSPAを書くのであれば、vladciobanu/purescript-halogenがとても参考になる
- ルーティング, global stateの管理, 外部APIとのやり取り, ダイアログの表示など、本家のexamplesではカバーされていない内容が含まれている
- 大変充実した内容なのですが、抽象度がかなり高い上、HaskellのReaderTパターンやモナド変換子についての前提知識が必要です。私のような初心者はまずHalogenのドキュメントとサンプルのソースコードを一通り読むことをオススメします。そしてこの連載も読んでください！！(Halogenの日本語記事はまだほぼありません。)

今回やること

連載をやろうと思い立ったところまでは良かったのですが、作るSPAが思い浮かびませんでした。とりあえずは以前Angularで書いたオタクのハンドルネームを入れるとその人のアウトプットをシュッと収集できるやつ↓の移植を進めていきます。

第一回の今回は、purescript-halogenを使ってインターフェース部分↓のみをつくります。

今後の連載ではユーザ(user1, user2, ...)ごとにアウトプットのタイムラインができて、スタイルも当てていき、最終的にはもとよりカッコよくてランタイムエラーのないアプリケーションに生まれ変わる予定です✨

ソースコードはこちらです。

やっていく

parcel-bundlerで開発環境を用意する

SPA開発となれば、最低限bundlerとホットリロードが効くdev-serverがあってほしいものです。ethul/purs-loader を使うことでWebpackを使っても良いでしょうし、今後特に細かくカスタマイズするつもりがないのであればParcelを使うと楽で良いでしょう。justinwoo氏のEasy PureScript bundling with Parcelが参考になりました。

なお、これは残念なお知らせですが、PureScriptでは多くの関数がカリー化されていることで、たいしたこともしていないのにバンドル後のJSファイルのサイズがとてつもなく大きくなってしまいます。

以前rollup.jsでカリー化を無理やりやめさせて(どうやって？)サイズを小さくするプラグインがあるという話をインターネットのどこかで目にした記憶があるのですが、調べても見つかりませんでした…

purescript-halogenでUIを構築する

次にSPA開発でほしいものというと、やはりUIライブラリ(を内臓するフレームワーク)でしょう。PureScriptのUIライブラリについてはhiruberutoさんがPureScriptのUIライブラリまとめでまとめてくださっています。

ここで挙げられている中で私が最近気になっているのは、既にProductionで使われているライブラリ２つです。１つはpurescript-halogenで、slamdataというスタートアップが開発し、自社サービスに利用しています。特徴を先のまとめ記事から引用すると、

中身の仮想DOM実装は、PureScript製のpurescript-halogen-vdom

Fluxやelm-htmlみたいにアクションを投げて状態を更新するタイプ

状態更新や子のコンポーネントへのクエリまでを含めた計算構造をFreeモナドで定義するガチ勢

要素と属性の組み合わせが正しいかどうかまで静的に型付けする機構がある

slamdataという会社のひとたちが中心に開発している。Halogenを使った製品を実際に提供しているようなので、実績としては間違いなくこの中で一番上

最もサンプルやドキュメントが揃っていてコントリビュータもユーザも多い

ルーターやCSSを型安全に書くライブラリやなども平行して開発されている(他のUIライブラリからでも使えるが)

SVGのサポートがまだないことがおそらく唯一にして最大の欠点。本体とは別に、svgサポートを作っている人はいます (purescript-halogen-svg)

と、かなり良さげな印象です。

先に書いたとおり今回はこのpurescript-halogenを使っていくわけですが、最近LumiというスタートアップがPureScriptを採用し、やはり自作のライブラリを公開しています。purescript-react-basicです。PureScriptの採用とライブラリ誕生の経緯は公式の記事にありますが、主に既存Reactコンポーネントの再利用が目的であると書かれています。

purescript-halogen入門

purescript-halogenでは、React.jsのようにコンポーネントのツリーでUIを構築します。今回はざっくりと以下のようなコンポーネントツリーを想定します。

UserAdd コンポーネントは<input type="text">要素を含み、オタクのハンドルネームを入力するために使います。UserList コンポーネントはUserTimeLine コンポーネントのリストです。移行前の画面でいうところの、ユーザのアウトプットが並んでいるカラム1つがUserTimeLineに、カラム全体の集合がUserList に相当します。

コンポーネントにはそれぞれQuery,State, Input, Outputを定義することができます。それぞれどんなものか、かなりざっくり書くとこうです。

Query: 代数的データ型で、コンポーネントの状態(State)を変更するコマンドを列挙したもの。
- i.e.) Counterコンポーネントなら、Increment, Decrement
State: React.jsのそれ。Stateが更新される度にView(DSLで定義する。SPAならHTMLのはず。)も更新される。
Input: 親子関係にあるコンポーネントについて、親から子に渡すデータ。
- 親のStateが更新されるとInput も自動で更新される。
Message: 親子関係にあるコンポーネントについて、子から親へ送るデータ。AngularでいうEvent。

UserAdd コンポーネントを例にとってみてみます。

module UserAdd where

import Prelude

import Data.Maybe (Maybe(..))
import Data.Symbol (SProxy(..))
import Halogen as H
import Halogen.HTML as HH
import Halogen.HTML.Events as HE
import Halogen.HTML.Properties as HP

type State = { userID :: Maybe String }
initialState = { userID: Nothing } :: State

data Query a
  -- request
  = GetUserID (String -> a)
  -- action
  | UpdateUserID String a
  | AddUserID a

type Slot = H.Slot Query Message

_userAdd = SProxy :: SProxy "userAdd"

data Message = AddedUserID String

userAdd :: forall m. H.Component HH.HTML Query Unit Message m
userAdd =
  H.component
    { initialState: const initialState
    , render
    , eval
    , receiver: const Nothing
    , initializer: Nothing
    , finalizer: Nothing
    }
  where

  render :: State -> H.ComponentHTML Query () m
  render state =
      HH.div_
      [
        HH.input
          [
            HP.type_ HP.InputText,
            HP.placeholder "@e_ntyo",
            HE.onValueChange (HE.input UpdateUserID)
          ]
      ,
        HH.button
          [ HE.onClick (HE.input_ AddUserID) ]
          [ HH.text "追加" ]
      ]

  eval :: Query ~> H.HalogenM State Query () Message m
  eval = case _ of
    GetUserID reply -> do
      _userID <- H.gets _.userID
      case _userID of
        Nothing -> pure (reply "")
        Just id -> pure (reply id)
    AddUserID next -> do
      _userID <- H.gets _.userID
      case _userID of
        Nothing -> do
          H.raise $ AddedUserID ""
          pure next
        Just id -> do
          H.raise $ AddedUserID id
          pure next
    UpdateUserID id next -> do
      H.modify_ (_ { userID = Just id })
      pure next

State には { userID :: Maybe String } という型(レコード型といいます)を定義しています。つまり<input>要素からセットされたユーザIDがセットされているか、何もないかの状態を取るということです。

Query には、requestとよばれるタイプのクエリと、actionとよばれるタイプのクエリのデータ型が定義されています。どちらもコンポーネントのStateを変更しうるコマンドを表しているのですが、requestのほうはその名の通り、そのコマンドを評価する際になんらかの情報を返すことができます。

Queryを評価する関数はevalで、Queryは代数的データ型なのでパターンマッチでいい感じに書くことができます(もちろん抜け漏れがあった場合はコンパイラが教えてくれます)。evalの型はQuery ~> H.HalogenM State Query () Message mで、これはQueryをH.HalogenM State Query () Message mというモナドに変換すると読むことが出来ます。~>は関手の付け替えを表しているようで、圏論では自然変換(Natural Transformation)というそうですが私は圏論はさっぱりなので割愛します🙇

ここで注目するべきは以下の点です。

action のクエリである AddUserIDとUpdateUserID の評価では、それぞれ親コンポーネントにMessageを送信したりStateに変更を加えたりしたあと、pure nextでa型の値を持ち上げたものを返している
- UpdateUserID では、a型の値に加えてユーザIDを表すString型の値も引数に取っている。
- AddUserID が送信したMessageはContainerコンポーネントにてハンドルされ、その際にStateが更新されてリアクティブにUserListへInputで定義したデータが渡る。
  - これらの処理や定義は、それぞれのコンポーネントのファイルに書いてあります。
request のクエリである GetUserID の評価では、pure (next id) として、next に加えて String 型のユーザIDも返している。

各リクエストの評価はdo構文の中で行われており、純粋な計算とこのモナドの中で許されている処理以外はコンパイルエラーとなります。これはかなり頼もしいというか安全です。

また、感の良い方はお気づきかもしれませんが、H.HalogenM State Query () Message mのmは基底のモナドが選べることを意味しています。主にAff(PureScriptにおける非同期処理で使うモナド)が使われるようで、理由は最終的にルートコンポーネントを受け取って処理するrunUI関数ではmがAffになっていなければならないというのと、Affを選ぶとEffectでできること(logやrandomなど)もできて嬉しいというところです。詳しくはこちらにあります。AffではなくEffectを選んだ場合はhoistという関数で型を合わせるようですが、使ったことがなくドキュメントもまだないためよくわかっていません。

render関数は、Stateを受け取ってhtmlを返す関数です。htmlは独自のDSLで記述し、hiruberutoさんの記事でもあったとおり、ちゃんと適切な属性やイベントを設定しないとコンパイルエラーになります。Halogenに対応したtyped cssのライブラリもあり、今後はこれを使っていく予定です。

なお、Halogenは内部ではvdomを使っているため、これが毎回バカ真面目に描画されるのではなく、ちゃんと差分だけ更新されたりすると思います。そのためにリスト系のコンポーネントではReact.jsでいうkeyみたいなものを定義したりします。今回はこの辺りの解説は割愛します。

こうしたコンポーネントを定義していくことで、相当安全にUIが構築できそうな雰囲気です。もちろんコンポーネントのInput, Messageだけでデータをやり取りしていくことは難しいため、tl; drで紹介したサンプルのようにglobal stateを扱うための機構が今後必要になります。

次回予告

この連載の一番の楽しみはサブタイトルを考えることです。DOMのコラージュってなんだよ…なんだと思いますか？私にはわかりません。

次回以降はHalogen以外のライブラリも駆使して、移行作業をバシバシ進めていきます。

slamdata/purescript-affjax + justinwoo/purescript-simple-jsonでユーザのアウトプットタイムラインを実装する
- Angularで書いていた時はrxjsでポーリングを実装できたのですが、PureScriptではどうやるのがスマートでしょうか。地道にsetIntervalで書いていくしかないのか…
thomashoneyman/purescript-halogen-formlessでユーザ名の入力をバリデーションする
- フォームといっても別に<input>１つだけなのですが、面白そうなので使ってみたいです
typed css
- これはもう取り組んでいて、いいね…という感じです。

次回以降も、きっと読みに来てくださいね！最後までお付き合いいただきありがとうございました💓

Monad in TypeScript

e_ntyo — Sun, 29 Apr 2018 13:37:55 +0000

tl; dr

普段はTypeScriptを書いているオタクが、すごいH本を読んだ📖
- Haskellには便利な機能や考え方がたくさんあり、その一部はTypeScriptみたいなプログラミング言語でも表現できることがわかった
- TypeScriptでHaskellみたいなことをしようと思うと、いわゆるモナドライブラリが便利であり、中でもfp-tsが良さそうだった

以下にはfp-tsについて具体的な解説などをコードを交えて書く。

はじめに

前職で、TypeScriptのコードに type Either<Left, Right> = ... みたいなtype aliasを書いていたエンジニアさんにHaskellを勧められ、すごいH本を読んでみた。

Haskellはすごかった。もの凄く強力なチカラを2つ持っている。ガチガチな静的型付けと、モダンな関数型プログラミング技法である。美しく、型安全で、無駄のない処理を書くことができる。

静的型で何でも表す

先ほどのEitherというのも型クラス(Javaなどの一般的なクラスとは違い、どちらかというとインターフェースのようなもの)の一つで、失敗系と成功系の2つの文脈を一つの型として定義できる。HTTPリクエストならエラーメッセージとレスポンスをそれぞれ型として表現できるわけである。

こうした便利な型クラスは他にもたくさんあり、Haskellの他にScalaなんかにも存在する概念らしい。その名をモナドという。モナドをはじめとする"文脈を表現する型クラス"とその扱い方について詳しく知りたい方はMonad, MTL styleなどで調べると良いと思うのだが、厳密さを追求すると高度な数学の話になってしまうし、何より私がわかっていないためこの記事で掘り下げて説明することはしない🙅けれど全くしないわけにもいかないため、他人の解説を引用させて頂いてお茶を濁したい。

Functors, Applicatives, And Monads In Pictures - http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html

画像中の箱は文脈を表している。この画像は、Haskellにおいて箱の種類ごとにどのような演算子(画像中の<$>, <*>, >>=)を使えば、文脈(=箱)を失わずに値を加工できるかを表している。この記事でこれらの記号自体は出てこないため気にしないでほしいのだが、以下の点だけは頭のどこかに記憶しておいてほしい。

Functor, Applicative は箱の種類であり、Monadの親戚である。
箱は型で表現することができる
箱に入った値は、そのままでは箱無しの値を取る関数に渡すことができないため、特殊な関数・演算子を使う必要がある

関数型プログラミング

Haskellはいわゆる純粋関数型プログラミング言語であり、副作用のある処理は副作用のない処理と完全に切り離されている。副作用のない処理を書く場所では、値を目的の形式に加工するにあたって型のキャストや代入操作からは完全に解放され、変換処理そのものに集中できるような仕組みが用意されている。

TypeScriptでHaskell, Scalaみたいなことをする

周知の事実であろうが、JavaScriptでもある程度の関数型プログラミングが可能である。オライリー本も出ている。(内容は古くなってしまっている)。具体的には高階関数を使って副作用のない処理を繋げたり、関数をカリー化して他の関数に渡したりすることができる。

それに、TypeScriptやflowなんかを使えば静的型も使える。ならJavaScriptでもHaskell, Scalaっぽいことができるのでは？という考えに至る。そこで便利なのがモナドライブラリである。モナドライブラリは前述の文脈を表現する型・モナドとそれを扱うための関数などを提供してくれる。

さて、TypeScriptで利用可能なモナドライブラリについてはこちらの記事が詳しい。しかし、こちらの記事の公開後にスター数・規模感共にTypeScriptのモナドライブラリでは最大のfp-tsが現れた。今回の記事ではこちらの紹介をしていきたい。

fp-ts

fp-tsは今話題のPureScript, そしてfantasy-landやScalaにインスパイアされたモナドライブラリらしい。他の有名なモナドライブラリが300 Star前後であるのに対して、規模感もあってか倍以上のStar数を持っている。

どんなことができるのかはREADMEのExamplesにまとまっている。Free Monad, MTL StyleなどHaskellでメジャーな(?)テクニックから、Option, Either , Reader , Writer , State, List などの定番モナド、更にはHaskellでよくWriterの代わりに使えと言われている、デバッグに便利な Trace , 依存型を使って型安全に有限オートマトンを記述できる IxIO なんてものまである(2016年に発表された論文を使った実装のようだが、よくわからなかった…)。

モナドを中心に、fp-tsのいくつかの機能をdigってみる。

Optionモナド

Optionモナドは、値がない可能性のある文脈を表現するためのもので、例えばリストから目的の要素を検索する場合などに役立つ。type Option<A> = None | Some<A> として、ある型AについてnoneもしくはAをSomeでラップしたものを返す。noneではなくnull を、値そのものではなく some で値をラップしたものを使うのは、Option という文脈を損なわないためである。

Scalaから持ち込まれたモナドで、HaskellではMaybeに相当する(はず)。Scalaのことは知らないものでスカラ...😰

import { Option, some, none, option } from 'fp-ts/lib/Option'
import { array } from 'fp-ts/lib/Array'
import { sequence } from 'fp-ts/lib/Traversable'

export function getAllSomesOrNone<A>(xs: Array<Option<A>>): Option<Array<A>> {
  return sequence(option, array)(xs)
}

console.log(getAllSomesOrNone([some(1), some(2), some(3)])) // => some([1, 2, 3])
console.log(getAllSomesOrNone([some(1), none, some(3)])) // => none

このコードはリポジトリのexercise(一問一答形式でfp-tsについて勉強していくもの)に置いてある。このコードでは、Array<Option<A>> な配列を受け取って、配列にnoneが含まれていなければ some で各要素をラップした配列を、含まれていれば none を返す関数getAllsomesOrNoneを定義している。

getAllSomesOrNone で気になるのは、fp-tsのsequenceの実装であろう。

// Traversable.ts より一部を抜粋

// applicativeはモナドcにくるまった関数a -> bを、c[a] -> c[b]な関数に変換する
export function traverse<F, T>(
  F: Applicative<F>,
  T: Traversable<T>
): <A, B>(ta: HKT<T, A>, f: (a: A) => HKT<F, B>) => HKT<F, HKT<T, B>> {
  return T.traverse(F)
}

export interface Traversable<T> extends Functor<T>, Foldable<T> {
  readonly traverse: <F>(F: Applicative<F>) => <A, B>(ta: HKT<T, A>, f: (a: A) => HKT<F, B>) => HKT<F, HKT<T, B>>
}

// HKT: Higher Kinded Types(高階型)
// "型の型"を定義する
export function sequence<F, T>(
  f: Applicative<F>,
  t: Traversable<T>
): <A>(tfa: HKT<T, HKT<F, A>>) => HKT<F, HKT<T, A>> {
  return tfa => t.traverse(f)(tfa, fa => fa)
}

// URIは、Monadの識別子で単なる文字列("Option", "List"など)
export function sequence<F extends URIS, T extends URIS>(
  f: Applicative1<F>,
  t: Traversable1<T>
): <A>(tfa: Type<T, Type<F, A>>) => Type<F, Type<T, A>>

sequenceは、前述の文脈を持つ型であるアプリカティブ(option)と、走査して各要素に同じ関数を使うことができるような型(この表現はかなり乱暴ですが!)traversable(array)を引数に取り、関数を返す。その関数とは、二重の入れ子構造になっている高階型(Option<A>[])を引数にとり、入れる順番を逆にした高階型(Option<A[]>)を返すものである。この例ではsequenceが返した関数に対して Array<Opation<A>> を渡しているため、最終的にgetSomeOrNone からは Option<Array<A>> が返ってきている。目的の型を得られるわけである。

では、sequence はどのようにしてApplicative と Traversable から (tfa: HKT<T, HKT<F, A>>) => HKT<F, HKT<T, A>> を得ているのだろうか？答えはsequense が呼び出している Traversable.traverse 関数にある。この関数は定義にある通り、いかにも部分適用して使ってくださいね😉というような型定義になっている。実際、この関数はt.traverse(f)(tfa, fa => fa) と呼び出されている。ここで、fはOption, tfa は Array<Option<A>>, fa => fa は Option<A> => Option<A> だと考えてほしい。

もちろん、これはOption以外のアプリカティブ(Eitherなど)やArray 以外のtraversable(tupleなど)にも適用できる。型レベルでここまで高度なことができてしまうのである！

しかし…難しい！めちゃめちゃ難しい！頭が痛くなる！！でも慣れてくるといけそうな気がしてくる。(本当か？)何より便利なことは確かなので使えるようになったら嬉しいだろう。今書いているのはTypeScriptなのである。これでサーバサイドのコードもフロントエンドのコードも書けるのだ。

Eitherモナド

Eitherは前述の通りで、失敗系と成功系を表現する型である。

import { Either, left, right } from 'fp-ts/lib/Either'

export function elementAt<A>(xs: Array<A>, i: number): Either<string, A> {
  if (i < 0) {
    return left<string, A>('out of lower bound')
  }
  if (i >= xs.length) {
    return left<string, A>('out of upper bound')
  }
  return right<string, A>(xs[i])
}

console.log(elementAt([1, 2, 3], -1)) // => left('out of lower bound')
console.log(elementAt([1, 2, 3], 10)) // => left('out of upper bound')
console.log(elementAt([1, 2, 3], 1))  // => right(2)

これはもはや解説の必要すらないであろう。便利…！

Stateモナド

最後に紹介しておきたいのがStateモナドである。
Haskellで書くこういうコードが、

import Control.Monad.State

main :: IO ()
main = runStateT code [1..] >> return ()
--
-- layer an infinite list of uniques over the IO monad
--

code :: StateT [Integer] IO ()
code = do
    x <- pop
    io $ print x
    y <- pop
    io $ print y
    z <- pop
    io $ print z
    return ()

--
-- pop the next unique off the stack
--
pop :: StateT [Integer] IO Integer
pop = do
    (x:xs) <- get
    put xs
    return x

io :: IO a -> StateT [Integer] IO a
io = liftIO

fp-tsでこう書ける

import * as stateT from 'fp-ts/lib/StateT'
import { io, IO } from 'fp-ts/lib/IO'
import { Monad2 } from 'fp-ts/lib/Monad'
import { Endomorphism } from 'fp-ts/lib/function'
import * as array from 'fp-ts/lib/Array'
import { State } from 'fp-ts/lib/State'

declare module 'fp-ts/lib/HKT' {
  interface URI2HKT2<L, A> {
    StateIO: StateIO<L, A>
  }
}

const stateTIO = stateT.getStateT(io)

export const URI = 'StateIO'

export type URI = typeof URI

export class StateIO<S, A> {
  readonly _A!: A
  readonly _L!: S
  readonly _URI!: URI
  constructor(readonly value: (s: S) => IO<[A, S]>) {}
  run(s: S): [A, S] {
    return this.value(s).run()
  }
  eval(s: S): A {
    return this.run(s)[0]
  }
  exec(s: S): S {
    return this.run(s)[1]
  }
  map<B>(f: (a: A) => B): StateIO<S, B> {
    return new StateIO(stateTIO.map(f, this.value))
  }
  ap<B>(fab: StateIO<S, (a: A) => B>): StateIO<S, B> {
    return new StateIO(stateTIO.ap(fab.value, this.value))
  }
  ap_<B, C>(this: StateIO<S, (b: B) => C>, fb: StateIO<S, B>): StateIO<S, C> {
    return fb.ap(this)
  }
  chain<B>(f: (a: A) => StateIO<S, B>): StateIO<S, B> {
    return new StateIO(stateTIO.chain(a => f(a).value, this.value))
  }
}

const map = <S, A, B>(fa: StateIO<S, A>, f: (a: A) => B): StateIO<S, B> => {
  return fa.map(f)
}

const of = <S, A>(a: A): StateIO<S, A> => {
  return new StateIO(stateTIO.of(a))
}

const ap = <S, A, B>(fab: StateIO<S, (a: A) => B>, fa: StateIO<S, A>): StateIO<S, B> => {
  return fa.ap(fab)
}

const chain = <S, A, B>(fa: StateIO<S, A>, f: (a: A) => StateIO<S, B>): StateIO<S, B> => {
  return fa.chain(f)
}

const stateTget = stateT.get(io)
export const get = <S>(): StateIO<S, S> => {
  return new StateIO(stateTget())
}

const stateTput = stateT.put(io)
export const put = <S>(s: S): StateIO<S, void> => {
  return new StateIO(stateTput(s))
}

const stateTmodify = stateT.modify(io)
export const modify = <S>(f: Endomorphism<S>): StateIO<S, void> => {
  return new StateIO(stateTmodify(f))
}

const stateTgets = stateT.gets(io)
export const gets = <S, A>(f: (s: S) => A): StateIO<S, A> => {
  return new StateIO(stateTgets(f))
}

const stateTliftF = stateT.liftF(io)
export const fromIO = <S, A>(fa: IO<A>): StateIO<S, A> => {
  return new StateIO(stateTliftF(fa))
}

const stateTfromState = stateT.fromState(io)
export const fromState = <S, A>(fa: State<S, A>): StateIO<S, A> => {
  return new StateIO(stateTfromState(fa))
}

export const stateIO: Monad2<URI> = {
  URI,
  map,
  of,
  ap,
  chain
}

//
// Usage (adapted from https://wiki.haskell.org/Simple_StateT_use)
//

import { log } from 'fp-ts/lib/Console'

/** pop the next unique off the stack */
const pop: StateIO<Array<number>, number> = get<Array<number>>().chain(ns =>
  array.foldL(ns, () => of(0), (h, t) => put(t).chain(() => of(h)))
)

const program1: StateIO<Array<number>, void> = pop
  .chain(x => fromIO(log(x)))
  .chain(() => pop)
  .chain(y => fromIO(log(y)))
  .chain(() => of(undefined))

program1.run([1, 2, 3])

コード量が多いので各実装の解説は控えるが、詰まるところはStateT を利用して State と IO の２つのモナドを組み合わせている。of, ap, map みたいなところも(HaskellやScalaに馴染みのない方にはわかりづらいのだが、Haskellのコードを見てわかるようにその手のプログラミング言語では自分で実装する必要はない)自分で定義しなければならないため、コード量がバカみたいに多いが、やりたいことは113~119行目の6行である。

さいごに

もの凄くわかりづらい&ターゲットが不明な説明になってしまいました…ここ間違ってるよとかこう書いたほうがいいよとかそういうフィードバックはガシガシください。

というかそもそもfp-ts以前にHaskellめっちゃ難しくないですか…？すごHの次に読むべきおすすめチュートリアル/OSS情報を教えてください🙏

Markdownで社内向けドキュメント, 大学のレポート, 本, スライド, ありとあらゆるモノを生成する

e_ntyo — Tue, 27 Feb 2018 19:26:26 +0000

はじめに

私のような学生もしくはエンジニアの皆様、普段は如何にして情報のアウトプットをしておりますでしょうか？

所属するチームや組織によって、アウトプットに求められる形式は様々かと思います。私の場合はこうです。

ドキュメントの種類	求められる形式
大学のレポート	pdf, docx, TeX, htmlなど、許可された形式
社内向けドキュメント	Backlog, Slack, Google Driveで共有するのに便利な形式
発表資料	何らかのスライド形式
社外向けドキュメント	Medium, dev.toの対応形式

私の周りの人々を見ると、「レポート等の文書はワードソフトやTeX, プレゼンテーションは専用のソフトウェア,ブログや社内外のナレッジ共有のためのツールでは独自記法, をそれぞれ使っています」という方が一定数いらっしゃいました。

しかしながら、新しいサービスやソフトウェアを使うたびにその記法や使い方を覚えるのは大変ですし、TeXや専用記法は他の人が編集する際にも面倒になる可能性があります😢

基本的にすべてのアウトプットを統一してMarkdownで記述できたら気持ちがええんじゃ、というモチベーションがある方は以下をお読みください。次のようなことが書いてあります。

Markdownでpdf/html/docx形式の文書, スライドを生成する方法やおすすめツール
Markdownでモノ書きをする上でのtipsや便利ツール

そもそも、なぜMarkdownなのか

レンダラによってはemojiがレンダリングされる(超重要)
GitHub, Qiita, 各種ブログサービスなど、もの書きやエンジニアが使う多くのWebサービスが対応している
~~TeXなんかと違って~~人にやさしく(可読性的に)(甲本ヒロト)、他人が編集しやすい
html + css相当の綺麗な文書が書ける

Markdown to HOGEHOGE

Markdown to 文書

そもそもMarkdownを書く機会がある方々は、しっかり目のMarkdownを書くとき、どのようなツールをお使いでしょうか？今や多くのエディタがMarkdown向けのlinter, realtime previewなどの機能を実装しているため、手元のエディタで書いている方が多いかもしれません。そうした方もこれまでMarkdownをGitHubくらいでしか使ったことがなかったよという方にも、１度HackMDというWebサービスを試して頂きたいです。

HackMDは数式・多種多様なコードハイライト・UMLなどに対応した、強力なMarkdownエディタを備えたナレッジ蓄積・共有サービスです。書いたMarkdownファイルはGoogle Driveのように閲覧/編集権限を指定して保存することができます。数式, ソースコード, UMLが書けるということはレポートや社内ドキュメントはこれで事足りそうです！

また、書いたMarkdownをHTML/ODFにコンバートしてダウンロードすることが可能です。htmlに変換されると何が嬉しいかというと、CSSを使ってレイアウト等を微調整することができます。これでやたらとレポートの体裁にうるさい教授も黙らせることができます。

いや、まだダメです。一部の教授たちはWordかpdfリーダを使わないと文書が読めない病を患っているため、.pdf .docxに変換する必要があります。この野郎。でも大丈夫です、pandocを使えばコマンド一発でMarkdownをpdf .docx に変換することが出来ます。

pandocの具体的な使い方の説明は他の記事に譲ります(リンク先のdemoページを見ればたいていは事足ります。)pandocを利用してオンラインで.md => .hogehoge をやってくれるWebサービスもいくつかありますが、オプションを設定できないため「数式を殺さないようにしたい」「pdfエンジンを指定したい」といった要望には応えられない場合が多いです。自分も結局手元にpandoc環境を構築しました。

これで、Markdownを自分好みの体裁にしたり、いろいろな文書形式に変換するための道筋がわかりました。

Markdown to スライド

ここまではよくある記事でしたが、ここからは若干有益な情報が含まれていますよ!
Markdownでいわゆる発表用スライドを生成できるサービスを２つご紹介します。

1. SlideShip

SlideShipは、オンラインでMarkdownを書いてスライドを作成・公開・利用するWebサービスです。
何度か発表に使ってみたので所感を書いておくと、

よかったところ

LTなどの簡単な発表資料を爆速で作ることができる
豊富なカラーテーマが用意されている
スライドをpdfにコンバートしてダウンロード可能

よくなかったところ

微妙に機能が足りない
スタイルの細かい調整ができない
emojiがレンダリングされない

2. HackMD

HackMDは神なので、独自の記法(といっても大層なものではなく、ごく簡単なものです)でMarkdownを書くと、なんと！HTMLのスライドが出来てしまいます。

これがこういう感じになります。

よかったところ

上の通り、HackMDで普段レンダリングされているものがそのままスライドになる(神！！！)
reveal.js でHTML(CSS, JS)が生成されるため、凝りたいなら自分でいじって調整できる
- SlideShipよりも素の出来がいいためいじらなくてもいい感じになる

よくなかったところ

まだbetaで、いろいろ挙動が怪しい

Markdown to 本

HackMDは本当に神なので、スライドと同じノリで本も吐き出されます。自分はまだ実践していないのですが、こういう感じになるようです。素晴らしい…

まとめ

もう西暦2018年なので、基本的に普段のメモをMarkdownで書いておけばアウトプットはたいていなんとかなります。HackMDは神。ありがとう。

Markdownあるある(はやく言いたい)

Tableがつらい

オンラインのジェネレータがあります。

HackMDはUMLが書けるけれど、その他の図が書けないし、やっぱりPowePointがいい

~~マイクロソフトに魂を売るのか？黙れ。~~ オンラインでいろいろな図を作成するならdraw.io が便利です！

DEV Community: e_ntyo

fp-ts ユーザが Scala with Cats を読み終えたので、fp-ts と Cats の違いをまとめてみた

tl; dr

この記事を書くことにした経緯

対象読者

Scala with Cats

fp-ts と Cats の比較

高カインド型と型コンストラクタ

TypeScript における高カインド型の実装

fp-ts の HKT 実装の弱点その 1 「型レベルで部分適用できない」

fp-ts の HKT 実装の弱点その 2 「HKT を使う上で必要になるボイラープレートコードが多すぎ」

implicit キーワード

implicit と 拡張メソッド

評価戦略

Scala の評価戦略と Cats の Eval

fp-ts にも Eval はあるの？

まとめ

広告

fp-ts 2.8.0 で追加された bind, bindTo について

tl; dr

do notation

fp-ts における do notation

おわりに

elm-tsでReactの代わりにPreactを使う

TL; DR

やり方

おことわり

小規模なSPAをつくってみてわかったFable(F# -> JS)の良いところ

Fable とは

Fable(F#) のよいところ

1. 適当な抽象度

2. TypeScript で普段感じている不満

2.1 パターンマッチ

2.2 Template literals(sprintf)は Type Safe であってほしい

2.3 関数合成が手軽にできてほしい

3. target の Module System

2.4 Language Server の実装やいい感じのビルドツールが存在する

まとめ

TypeORMにおいて、`date` は `Date` でなく `string` にmapされるので気をつけましょう

tl; dr

詳細

hyper-ts で type-safe & stateless なExpressアプリケーションを構築する

hyper-ts で type-safe & stateless なExpressアプリケーションを構築する

tl; dr

1. @types/express における型定義はstrictでない

2. リクエストハンドラの中でごちゃごちゃとやってしまい、ステートフルになりがち

hyper-tsの紹介

Middleware<I, O, L, A>

io-ts を使ってリクエストbodyやクエリパラメータに実行時型検査をする

最後に

Elasticlunr.js で日本語と英語が混在した文書の検索に対応する

tl; dr

背景

コモナドスケッチ ~ 2. 大改造!!劇的ビフォーアフター ~

コモナドスケッチ ~ 2. 大改造!!劇的ビフォーアフター ~

連載終了のおしらせ

次

コモナドスケッチ ~ 1. DOMのコラージュ ~

これはなに？

tl; dr

今回やること

やっていく

parcel-bundlerで開発環境を用意する

purescript-halogenでUIを構築する

purescript-halogen入門

次回予告

Monad in TypeScript

tl; dr

はじめに

静的型で何でも表す

関数型プログラミング

TypeScriptでHaskell, Scalaみたいなことをする

fp-ts

Optionモナド

Eitherモナド

Stateモナド

さいごに

Markdownで社内向けドキュメント, 大学のレポート, 本, スライド, ありとあらゆるモノを生成する

はじめに

そもそも、なぜMarkdownなのか

`implicit` と拡張メソッド

Scala の評価戦略と Cats の `Eval`

fp-ts にも `Eval` はあるの？

1. `@types/express` における型定義はstrictでない

`Middleware<I, O, L, A>`