DEV Community: Ken Aguilar

Haskell - Enforcing Naming Convention with Parsec

Ken Aguilar — Sat, 05 Sep 2020 02:01:25 +0000

In my project migratum I wanted to enforce a naming convention like this

V<version number>__<file name>.sql
+       +         +     +     + +
|       |         |     |     | |
|       |         |     |     | v
|       |         |     |     | Enforce sql extension.
|       |         |     |     v
|       |         |     |     Enforce this dot to indicate the end of the file name.
|       |         |     v
|       |         |     File name need to be alpha numeric. No other symbols, except underscore
|       |         v
|       |         Enforce the double underscore
|       v
|       Version number have to be numbers.
v
Enforce the V character to signify "version"

Ways I can accomplish these are with

Regex
Parser Combinators

I'm not sure how to do this with regex because to be honest, I know very simple regex and I don't have a regex license. I'm decent with parser combinators and plus it's the title of this blog post, so that's what I'm going to use to accomplish the task I set out for.

Parser combinators really shine when you parse something recursive like json. You know how json can contain an array and objects and then these objects and arrays can contain arrays and objects, so on and so forth? Yeah, parser combinators are really neat for that. So don't judge parser combinators solely on this blog post. I chose parser combinators because it's my go-to method for parsing, and I personally think they're convenient.

Before we touch parsing, let's create a type representation of the file name based on the ascii diagram above.

data FilenameStructure 
  = FilenameStructure FileVersion Underscore Underscore FileName Dot FileExtension
  deriving ( Eq, Show )

newtype FileVersion = FileVersion Text
  deriving ( Eq, Show )

newtype Underscore = Underscore Text
  deriving ( Eq, Show )

newtype FileName = FileName Text
  deriving ( Eq, Show )

newtype Dot = Dot Text
  deriving ( Eq, Show )

newtype FileExtension = FileExtension Text
  deriving ( Eq, Show )

Now, we can focus on specific segments of the file name instead of thinking of parsing the entire file name. I think that makes it a bit easier. At least to me it does. I can think of parsing the file version, underscore, filename, etc individually.

Let's start with the imports. Popular libraries that come to mind are parsec, megaparsec, and attoparsec. Evaluate which one suits your project, but on this blog post we're using parsec.

-- parsec
import           Text.ParserCombinators.Parsec (GenParser, ParseError)
import qualified Text.ParserCombinators.Parsec as Parsec

-- text
import qualified Data.Text                     as T

Let's start with the file version parser. Our convention says that we need to start with the character V, then it should be followed by numbers.

fileVersionParser :: GenParser Char st FileVersion
fileVersionParser = do
  vChar <- Parsec.char 'V'
  vNum <- Parsec.digit
  pure $ FileVersion $ T.pack $ ( vChar : vNum : [] )

If we try this in ghci it will look like this

ghci> import Text.ParserCombinators.Parsec
ghci> parse fileVersionParser "" "V69"
ghci> Right ( FileVersion "V69" )

That's what we want, to match Right and return our FileVersion with
the text "V69".

ghci> parse fileVersionParser "" "Vwhat"
ghci> Left (line 1, column2):
unexpected "w"

That's right, it should fail when there's no version number.

ghci> parse fileVersionParser "" "V1what"
ghci> Right ( FileVersion "V1" )

It drops the input that isn't a number.

ghci> parse fileVersionParser "" "what"
ghci> Left (line 1, column 1):
unexpected "w"
expecting "V"

Finally, it will fail if it doesn't find the "V" character.

Woohoo! One parser down, four to go!

Let's do the rest of the parsers, and feel free to try these out in ghci.

underscoreParser :: GenParser Char st Underscore
underscoreParser = Underscore . T.pack . pure <$> Parsec.satisfy isUnderscore

isUnderscore :: Char -> Bool
isUnderscore char = any ( char== ) ( "_" :: String )

fileNameParser :: GenParser Char st FileName
fileNameParser = FileName . T.pack 
  <$> Parsec.many ( Parsec.alphaNum <|> Parsec.satisfy isUnderscore )

dotParser :: GenParser Char st Dot
dotParser = Dot . T.pack . pure <$> Parser.char '.'

fileExtensionParser :: GenParser Char st FileExtension
fileExtensionParser = FileExtension. T.pack <$> Parsec.string "sql"

Then, to create a parser for the whole file name we combine the rest of our parsers.

filenameStructureParser :: GenParser Char st FilenameStructure
filenameStructureParser = FilenameStructure
  <$> fileVersionParser
  <*> underscoreParser
  <*> underscoreParser
  <*> fileNameParser
  <*> dotParser
  <*> fileExtensionParser

We can also do this with the do syntax if that's more convenient.

filenameStructureParser :: GenParser Char st FilenameStructure
filenameStructureParser = do
  version <- fileVersionParser
  u1 <- underscoreParser
  u2 <- underscoreParser
  fileName <- fileNameParser
  dot <- dotParser
  ext <- fileExtensionParser
  pure $ FilenameStructure version u1 u2 fileName dot ext

Finally, our parser "runner"

namingConvention :: String -> Either ParseError FilenameStructure
namingConvention = 
  Parsec.parse filenameStructureParser "Error: Not following naming convention"

Instead of manually trying them out in ghci we can instead do some unit testing. So we don't have to keep messing with the terminal.

module NamingConventionSpec where

import Test.Hspec

spec :: Spec
spec = do
  desribe "Filename" $ do
    it "follows naming convention" $ do
      successResult <- pure $ namingConvention "V1__uuid_extension.sql"
      emptyFileName <- pure $ namingConvention ""
      noExtension <- pure $ namingConvention "V1__uuid_extension"
      noVersion <- pure $ namingConvention "uuid_extension.sql"
      upperCaseFileName <- pure $ namingConvention "V1_UUID_extension.sql"
      symbolFileName <- pure $ namingConvention "V1_UUID+extension.sql"

      -- success cases
      shouldBe successResult ( Right "V1__uuid_extension.sql" )
      shouldBe upperCaseFileName ( Right "V1__UUID_extension.sql" )

      -- failure cases
      shouldBe ( isLeft emptyFileName ) True
      shouldBe ( isLeft noFileExt ) True
      shouldBe ( isLeft noVersion ) True
      shouldBe ( isLeft symbolFilename ) True

Now that we have our parser we can use it check for duplicates, because our types have an Eq instance we can do equality checking.

fileVersion :: FilenameStructure -> FileVersion
fileVersion ( FilenameStructure v _ _ _ _ _ ) = v

getVersion :: Either ParseError FilenameStructure -> Either ParseError FileVersion
getVersion res = case res of
  Left err -> Left err
  Right fs -> Right $ fileVersion fs

checkDuplicate :: [ String ] -> Either ParseError [ String ]
checkDuplicate filenames = do
  versions <- traverse getVersion ( namingConvention <$> filenames )
  if anySame versions
    -- Express your errors however you want, this is just to show that this is 
    -- the error branch.
    then error "Duplicate migration file"
    else Right filenames
  where
    anySame :: Eq a => [ a ] -> Bool
    anySame = isSeen []

    isSeen :: Eq a => [ a ] -> [ a ] -> Bool
    isSeen seen ( x:xs ) = x `elem` seen || isSeen ( x:seen ) xs
    isSeen _ [] = False

When creating your parsers, avoid doing any validation or any "smart" logic. Concentrate on parsing the input and nothing more. Once you have your parsers then you can do whatever you want with the output.

References

Haskell from First Principles

Monadic Parser Combinators

Haskell - Look Ma! No Concrete Implementation!

Ken Aguilar — Sun, 09 Aug 2020 07:04:24 +0000

This is my post about tagless final encoding. There are many like it, but this one is mine. My tagless final encoding post is my best friend. It is my life. I must master it as I must master my life.

I can't think of a good intro so I modified the Rifleman's Creed. Anyway, the tagless final encoding technique has been very helpful in structuring my programs without being burdened about dependencies so much, because of this I can change dependencies and mostly don't have to re-structure my program. This technique also makes it almost effortless to do unit testing.

Just like my other posts let's do a contrived example.

This is our user story.

A command line tool that takes a file path to a text file that contains some text.
The content of the input file will be processed, and the text content will be capitalized.
The processed text content will then be printed to an output file.

Let's start by creating the representation of our application.

{-# LANGUAGE DerivingStrategies         #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module AppM where

newtype AppM a
  = AppM
  { runAppM :: IO a
  } deriving newtype ( Functor, Applicative, Monad, MonadIO )

Then, let's define the capabilities of the app based on the made up user story. First, the cli capability.

module Capability.CLI where

class Monad m => ManageCLI m where
  parseCliCommand :: m Command
  interpretCLI :: Command -> m ()

data Command = Command
  { commandInput  :: Text
  , commandOutput :: Text
  } deriving ( Eq, Show )

Next, the capabalities to manipulate files in the file system.

module Capability.File where

class Monad m => ManageFile m where
  getFileContent :: Text -> m Text
  printContent :: Text -> Text -> m ()

Finally, the capability to manipulate text.

module Capability.TextContent where

class Monad m => ManageTextContent m where
  capitalizeContent :: Text -> m Text

With all these capabilities, I think we are ready to assemble our program. So, let's go back to the AppM module. We have to create instances but skip the implementation for now, and use undefined

{-# LANGUAGE DerivingStrategies         #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE InstanceSigs               #-}
{-# LANGUAGE RecordWildCards            #-}
module AppM where

import           Capability.CLI
import           Capability.File
import           Capability.TextContent

newtype AppM a
  = AppM
  { runAppM :: IO a
  } deriving newtype ( Functor, Applicative, Monad, MonadIO )

startApp :: IO ()
startApp = runAppM $ interpretCLI =<< parseCliCommand

instance ManageCLI AppM where
  parseCliCommand :: AppM Command
  parseCliCommand = undefined

  interpretCLI :: Command -> AppM ()
  interpretCLI Command{..} = do
    file <- getFileContent commandInput
    content <- capitalizeContent file
    printContent commandOutput content

instance ManageFile AppM where
  getFileContent :: Text -> AppM Text
  getFileContent filePath = undefined

  printContent :: Text -> Text -> AppM ()
  printContent outputPath content = undefined

instance ManageTextContent AppM where
  capitalizeContent :: Text -> AppM Text
  capitalizeContent content = undefined

As you can see we were able to assemble our program in interpretCLI without any concrete implementations. When we provide the concrete implementations, we won't get so bogged down by thinking about the entire the program because we've already done that. We only have to think about the concrete implementation of individual capabilities. For example, we just need to think about how to retrieve a file, print a file, etc.

Proceeding to our concrete implementation we can pick optparse-applicative as our cli utility and relude as our prelude.

module AppM where

...
import           Relude
import qualified Data.Text              as T
import           Options.Applicative

instance ManageCLI AppM where
  parseCliCommand :: AppM Command
  parseCliCommand = liftIO 
    $ execParser ( info ( helper <*> parseCommand ) fullDesc )

  interpretCLI :: Command -> AppM ()
  interpretCLI Command{..} = do
    file <- getFileContent commandInput
    content <- capitalizeContent file
    printContent commandOutput content

instance ManageFile AppM where
  getFileContent :: Text -> AppM Text
  getFileContent filePath = readFileText ( T.unpack filePath )

  printContent :: Text -> Text -> AppM ()
  printContent outputPath content = 
    writeFileText ( T.unpack outputPath ) content

instance ManageTextContent AppM where
  capitalizeContent :: Text -> AppM Text
  capitalizeContent content = pure $ T.toUpper content

By using optparse-applicative, here's the implementation of parseCommand

parseCommand :: Parser Command
parseCommand = Command
  <$> strOption ( long "input" <> short 'i' <> metavar "INPUT_FILE" <> help "Input file" )
  <*> strOption ( long "output" <> short 'o' <> metavar "OUTPUT_FILE" <> help "Output file" )

One obvious downside to this is the n^2 instance problem which Vasiliy Kevroletin mentions in his article.

That's it! We import our library code to the Main module and execute the program.

module Main where

import           Relude

import           AppM

main :: IO ()
main = startApp

References

Purescript Halogen Realworld repository

Three Layer Cake by Matt Parson

Introduction to Tagless Final by Vasiliy Kevroletin

Tagles Final Encoding by Juan Pablo Royo Sales

Haskell - Extracting IO

Ken Aguilar — Thu, 30 Jul 2020 22:42:15 +0000

There are more articles out there discussing this topic but this is my take on it. This topic can be long and complicated but I'll try and extract a section of it that we can focus on.

Let's do a contrived example. Let's say we have a function that reads a file, processes it by capitalizing all the characters, then writes the results to another file. This is the first iteration of this function.

{-# LANGUAGE OverloadedStrings #-}
module Lib where

import           Relude

-- text
import qualified Data.Text as T

-- 1. reads the file
-- 2. capitalizes all the characters
-- 3. writes result to the output path
processFile :: FilePath -> FilePath -> IO ()
processFile fp output = do
  inputFile <- readFileText fp
  writeFileText output ( T.toUpper inputFile )

This adequately performs the task we want. The problem comes when we want to test the text processing without interacting with the file system. Sure, we can unit test the text processing it self but what if we want to see how the text processing behaves in the processFile function?

I learned mtl, tagless final encoding, and started reading about free monads, fused-effects, etc to be able to extract IO out; among other things. Then, I totally ignored an easier technique. Which is to make the "side-effecty" functions into a parameter, and give it a basic type constraint of Monad instead of IO, like this

processFileBase
  :: Monad m
  => ( FilePath -> m Text )
  -> ( FilePath -> Text -> m () )
  -> FilePath
  -> FilePath
  -> m ()
processFileBase readFileF writeFileF inputPath outputPath = do
  inputFile <- readFileF inputPath
  writeFileF outputPath ( T.toUpper inputFile )

We can use some type alias to make it less confusing.

type ReadFileF m = FilePath -> m Text
type WriteFileF m = FilePath -> Text -> m ()

processFileBase
  :: Monad m
  => ReadFileF m
  -> WriteFileF m
  -> FilePath
  -> FilePath
  -> m ()

We've extracted out the IO. Yaaay! This function is now more flexible. We can pass in functions as long as they have a Monad instance. If we go back to our IO implementation we can provide it with functions from relude.

processFileWithIO :: MonadIO m => FilePath -> FilePath -> m ()
processFileWithIO inputPath outputPath = processFileBase
  readFileText
  writeFileText
  inputPath
  outputPath

Another advantage of this technique is we can use another library and don't have to restructure our program. Let's say we ended up dropping relude and using
prelude instead. We can massage the writeFile and readFile functions from prelude so it can fit our program. Like so


readFilePrelude :: MonadIO m => FilePath -> m Text
readFilePrelude = liftIO . fmap T.pack <$> Prelude.readFile

writeFilePrelude :: MonadIO m => FilePath -> Text -> m ()
writeFilePrelude fp content = liftIO 
  $ Prelude.writeFile fp ( T.unpack content )

processFileWithIO :: MonadIO m => FilePath -> FilePath -> m ()
processFileWithIO inputPath outputPath = processFileBase
  readFilePrelude
  writeFilePrelude
  inputPath
  outputPath

In testing, we can provide it different functions.

{-# LANGUAGE OverloadedStrings #-}
module ProcessFileSpec where

import qualified Data.HashMap.Strict as HS
import           Lib
import           Relude
import           Test.Hspec

textFileToProcess :: Text
textFileToProcess =
  "Letting the cat out of the bag is a whole lot easier than putting it back in."

spec :: Spec
spec = do
  describe "processFile" $ do
    it "will process the file and capitalize every character" $ do
      ioRef <- newIORef HS.empty
      let
        outPath = "sample-output.txt"

        testReadFile :: Monad m => FilePath -> m Text
        testReadFile _ = pure textFileToProcess

        testWriteFile :: MonadIO m => FilePath -> Text ->  m ()
        testWriteFile outputPath content = liftIO $
          modifyIORef ioRef (\ref -> HS.insert outputPath content ref )

      processFileBase testReadFile testWriteFile "input-path.txt" outPath

      result <- readIORef ioRef

      shouldBe result
        $ HS.singleton outPath
            "LETTING THE CAT OUT OF THE BAG IS A WHOLE LOT EASIER THAN PUTTING IT BACK IN."

Here we're using IORef but you can use Map, List, StateT, WriterT. It's totally up to you. Whatever suits your use-case.

This technique can take you a long way! It is also a good complement to techniques like mtl and tagless final encoding

References

Invert Your Mocks! - Matt Parsons

Typescript - Button Color State with ADTs

Ken Aguilar — Tue, 23 Jun 2020 01:27:58 +0000

I've seen enough typescript code that I can say that booleans are over used. We need to normalize the use of sum types and reserve the use of booleans.

There are not a lot of things that booleans can represent. Even something binary like the state of a light bulb can get confusing when it's represented with a boolean. Should True represent the light bulb being off or on, which one should False represent? I'm sure with lots of comments it will be fine, but as we all know comments are not too effective in conveying information to other contributors.

const toggleLightBulbState = ( lightBulbState: boolean ): boolean => {
  // if the lightbulb is on return false to turn it off.
  if ( lightBulb == true ) {
    return false;
  } 
  // otherwise turn on the light bulb.
  else {
    return true;
  }
}

Imagine this withtout comments, would you able able to understand what this code is doing?

Let's go through a contrived example and deal with button color states and fake http states, and eventually convert it to use sum types.

We'll be using bulma css classes in the example

import React from "react";

const colorToClassName = ( color: string ): string => {
  if ( props.color === "blue" ) {
    return "is-info";
  } 

  else if ( props.color === "red" ) {
    return "is-danger";
  }

  else {
    return "is-warning";
  }
}

export function Button(props: { color: string }) => {
  return  <button className={ colorToClassname(color) }>Hello</button>
}

The parent component

import { Button } from "./Button.tsx";

const responseToColor = ( response: string ) => string {
  if ( response === "successs" ) {
    return "blue";
  }
  else if ( response === "warning" ) {
    return "yellow";
  }
  else {
    return "red";
  }
}

export function App() {
  let httpResponse = "error";
  return (
    <div className="container">
      <div className="section">
        <Button color={responseToColor(httpResponse)} />
      </div>
    </div>
  );
}

Equality checks with strings is definitely error prone but it looks like this is fine, especially for something small scale but imagine an actual application with so many more cases and so much more logic. Depending on booleans and string equality will be a source of great agony. What can help us here is the type checker! Even though typescript is not as strong as something like purescript or haskell it can still help a great deal.

With purescript we can do something like this

-- sum type representing all possible colors this button can render
data ButtonColor
  = Blue
  | Red
  | Yellow

-- transforms ButtonColor to Bulma CSS classes.
-- Pattern match the colors and return the matching css class.
-- These bulma classes are not exposed outside this function.
colorToClassName :: ButtonColor -> String
colorToClassName = case _ of
  Blue -> "is-info"
  Red -> "is-danger"
  Yellow -> "is-warning"

The ButtonColor type that represents all the possible colors the button can render can then be exported so it can be used in the colorToClassName function. With a fake http response, we can model it with a sum type and do a case match and transform that into our button colors.

-- type representing http response status.
data Response
  = Success
  | Error
  | Warning

-- transforms http response to button color.
responseToColor :: Response -> ButtonColor
responseToColor = case _ of
  Success -> Blue
  Error -> Red
  Warning -> Yellow

By using types, the purescript type checker can help us verify our program. I'm using "verify" loosely here, I don't mean formal verification.

After that long tangent let's go back to typescript and see if we can recreate what we did in purescript, and let's do it in react! Let's start with the button component and model the possible color states of this button. For a detailed explanation on sum types in typescript, check out Guilio Canti'sarticle. In typesript, sum types are called discriminated unions. In order to determine which type is being matched in a pattern match it needs a discriminant. We'll be using the tag field as our discriminant. This is used in our "poor man's" pattern matching, which is a switch statement.

import React from "react";

interface Red {
  tag: "red";
}

interface Blue {
  tag: "blue";
}

interface Yellow {
  tag: "yellow";
}

export type ButtonColor
  = Red
  | Blue
  | Yellow

// poor man's pattern matching.
const toClassName = ( b: ButtonColor ): string => {
  switch ( b.tag ) {
    case "blue":
      return "is-info";

    case "red":
      return "is-danger";

    case "yellow":
      return "is-warning";

    default:
      return "";
  };
}

export const blue: Blue = ({ tag: "blue" });
export const red: Red = ({ tag: "red" });
export const yellow: Yellow = ({ tag: "yellow" });

export function Button (props: { color: ButtonColor }) {
  return ( <button className={ "button " + toClassName(props.color) }>Hello</button> );
}

Since I don't like using switch statements, let's modify the code a little bit using the Option type, specifically the utility function fromNullalble and it will come from the library fp-ts. We'll also add the className field to the interfaces.

import React from "react";
import { pipe } from "fp-ts/lib/function";
import { fromNullable, map, getOrElse } from "fp-ts/lib/Option";

interface Red {
  tag: "red";
  className: string;
}

interface Blue {
  tag: "blue";
  className: string;
}

interface  Yellow {
  tag: "yellow";
  className: string;
}

export interface NoColor {
  tag: "noColor";
  className: string;
}

export type ButtonColor
  = Red
  | Blue
  | Yellow
  | NoColor;

// implementation of the colors
export const blue: Blue = ({ tag: "blue", className: "is-info" });
export const red: Red = ({ tag: "red", className: "is-danger" });
export const yellow: Yellow = ({ tag: "yellow", className: "is-warning" });
export const noColor: NoColor = ({ tag: "noColor", className: "" });

interface Colors {
  blue: Blue;
  red: Red;
  yellow: Yellow;
  noColor: NoColor;
}

const colors: Colors = {
  blue,
  red,
  yellow,
  noColor
};

const toClassName = ( b: ButtonColor ): string =>
  // pattern matching
  // This "pattern matching" works because they all have the className field.
  pipe(
    fromNullable(colors[b.tag]),
    map((c: ButtonColor) => c.className),
    getOrElse(() => noColor.className)
  );

export function Button (props: { color: ButtonColor }) {
  return ( <button className={ "button " + toClassName(props.color) }>Hello</button> );
}

fromNullable transforms it into an Option type which is another sum type with None and Some<A> as its inhabitants. If we access a property that is not available in colors it will go to the getOrElse function and return noColor, otherwise it will match a color then access the className property.

Now, let's look at the parent component and model the fake http response into something we can understand or something that makes sense in the context of the app, and transform that fake http response to a button color.

Success, Error, and Warning are the possible states for our fake http response here. They are then used in Response to form a union of all possible states of a fake http response.

import React from 'react';
import './App.css';
import {
  Button, blue, red, yellow, ButtonColor, Blue, Red, Yellow
} from "./Button";
import { pipe } from "fp-ts/lib/function";
import { fromNullable, getOrElse, map } from "fp-ts/lib/Option";

interface Success {
  tag: "success";
  color: Blue;
}

interface Error {
  tag: "error";
  color: Red;
}

interface Warning {
  tag: "warning";
  color: Yellow;
}

type Response
  = Success
  | Error
  | Warning

interface Responses {
  success: Success;
  error: Error;
  warning: Warning;
}

export const success: Success = ({ tag: "success", color: blue });
export const error: Error = ({ tag: "error", color: red });
export const warning: Warning = ({ tag: "warning", color: yellow });

const responses: Responses = {
  success,
  error,
  warning
}

const responseToColor = (res: Response): ButtonColor =>
  // pattern matching
  pipe(
    fromNullable(responses[res.tag]),
    map((r: Response) => r.color),
    getOrElse(() => red as ButtonColor) // have to tell typescript red is a member of ButtonColor
  );

export function App() {
  let fakeHttpResponse = error;
  return (
    <div className="container">
      <div className="section">
        <Button color={responseToColor(fakeHttpResponse)} />
      </div>
    </div>
  );
}

As a result we have eleminated booleans in our tiny app and made the possible states of button colors and fake http response more explicit. We didn't have to figure out whether True would mean "blue", "red", or "yellow". We didn't have to write long comments explaining how booleans would represent our fake http response.

Acknowledgements

Functional design: Algebraic Data Types - Guilio Canti

fp-ts

Example Repo

Button States

Nix - Trying out Haskell with less hassle

Ken Aguilar — Wed, 10 Jun 2020 01:07:53 +0000

I heard you want to try out haskell but like me you hesitate because you don't know how to setup your enviroment for Haskell. Okay, hear me out. Nix can be the solution, I know you have to learn more. However, it's not that much. At least that's what I see. Just learn a little bit of nix now and learn as you go!

So if I convinced you to learn a little bit of nix. Go ahead and download it from their website.

Now, instead of worrying what system configuration you have to do, you just do this

mkdir my-project
nix-shell --pure -p ghc cabal-install --run "cabal init"

What's happening here is you're telling nix to go get ghc(compiler) and cabal-install(build tool), and run the command cabal init. This will generate a very small scaffold for a haskell project. Since we used the flag --pure it won't install anything global in your system.

Your my-project directory should look like this

my-project
|-- CHANGELOG.md
|-- Main.hs
|-- my-project.cabal
|-- Setup.hs

Main.hs should contain the Hello World program. This is also where you want to write your experiment haskell code.

Since you used ghc and cabal in a pure environment you won't find them when you try to execute cabal in the console. So you won't be able to run this project as is. What you can do is play with your haskell
project in a nix-shell. You can do this by first generating a default.nix file. This can be done by doing this command in your project directory

nix-shell --pure -p cabal2nix --run "cabal2nix ." > default.nix

This will generate the default.nix file and will contain

{ mkDerivation, base, stdenv }:
mkDerivation {
  pname = "my-project";
  version = "0.1.0.0";
  src = ./.;
  isLibrary = false;
  isExecutable = true;
  executableHaskellDepends = [ base ];
  license = "unknown";
  hydraPlatforms = stdenv.lib.platforms.none;
}

This file describes your project. It's like a function that takes in nix stuff.

For the last part, write the shell.nix file.

{ nixpkgs ? import <nixpkgs> {} }:

let
  inherit (nixpkgs) pkgs;
  inherit (pkgs) haskellPackages;

  project = haskellPackages.callPackage ./default.nix {};

in
pkgs.stdenv.mkDerivation {
  name = "my-project";
  buildInputs = project.env.nativeBuildInputs ++ [
    haskellPackages.cabal-install
  ];
}

When you perform nix-shell --pure in your project directory. It will go into a nix environment and you'll see your command prompt turn like this

[nix-shell:~/my-project]$

In this environment you'll have access to cabal. So you can build and run your project with cabal new build and cabal new-run.

If you want to expirement with a haskell package from hackage like the text package, you can add it to your my-project.cabal file, in the build-depends section.

cabal-version:       >=1.10
-- Initial package description 'my-project.cabal' generated by 'cabal
-- init'.  For further documentation, see
-- http://haskell.org/cabal/users-guide/

name:                my-project
version:             0.1.0.0
-- synopsis:
-- description:
-- bug-reports:
-- license:
license-file:        LICENSE
-- author:
-- maintainer:
-- copyright:
-- category:
build-type:          Simple
extra-source-files:  CHANGELOG.md

executable my-project
  main-is:             Main.hs
  -- other-modules:
  -- other-extensions:
  build-depends:       base >=4.13 && <4.14
                     , text
  -- hs-source-dirs:
  default-language:    Haskell2010

You should also add this to your default.nix file, so later on when you do decide to build your project with nix-build you don't have to chase around packages. I'll probably cover nix-build in another post.

{ mkDerivation, base, stdenv, text }:
mkDerivation {
  pname = "my-project";
  version = "0.1.0.0";
  src = ./.;
  isLibrary = false;
  isExecutable = true;
  executableHaskellDepends = [ base text ];
  license = "unknown";
  hydraPlatforms = stdenv.lib.platforms.none;
}

References

Getting Started Haskell Project with Nix - Soares Chen

Nix Shorts - Justin Woo

Haskell - Generating lenses for third party libraries

Ken Aguilar — Tue, 09 Jun 2020 21:14:29 +0000

This is going to be a short post, maybe even a tweet size post. I'm going to highlight how to generate lenses for third party libraries because when I was searching for this information it wasn't that easy to find.

My concern was less on the mechanics on how to generate them but more on best practices, I wasn't sure if generating lenses for data types I don't own is a good practice. When I asked in fp-chat, I was told to "Go hog wild!" and didn't get any opposing views. So that gave me the peace of mind to do this.

I'm going to use the purescript language library as an example since it's the most recent library I had to work with when I was working with my project, umu-halogen.

I'm going to use makeLenses from Control.Lens.TH. The default configuration of makeLenses is it will only generate lenses for record fields that are prefixed with an underscore.

data Person = Person
  { firstName :: Text -- does not generate lens for this field.
  , _lastName :: Text -- generates the lens for this field.
  } deriving ( Eq, Show )

makeLenses ''Person

Before I can start generating lenses for the types I don't own, I have to change the makeLenses configuration a little bit.

module Util where

import           Language.Haskell.TH
import           Control.Lens.Operators
import           Control.Lens.TH

mkCustomLenses :: Name -> DecsQ
mkCustomLenses = makeLensesWith
  $ lensRules
  & lensField
  .~ (\_ _ name -> [TopName ( mkName $ nameBase name ++ "L" )]) -- you can append whatever suits your code base here, I chose to append "L"

It has to be in a separate module from where you generate the lenses because the compiler will complain with this error

GHC stage restriction:
      `mkCustomLenses' is used in a top-level splice, quasi-quote, or annotation,
      and must be imported, not defined locally

After that setup you can start generating lenses!

module Optics where

-- util
import           Util

-- purescript
import           Language.PureScript.CST.Types

makePrisms ''Declaration
makePrisms ''Guarded
makePrisms ''Expr

mkCustomLenses ''ValueBindingFields
mkCustomLenses ''Name
mkCustomLenses ''Ident
mkCustomLenses ''Labeled
mkCustomLenses ''Where
mkCustomLenses ''Wrapped
mkCustomLenses ''Separated
mkCustomLenses ''Module

Now, if I want to manipulate Separated I can do something like

updateToEmptyList :: Separated a -> Separated a
updateToEmptyList s = s & sepTailL .~ []

When it comes to sum types you can just use makePrisms to generate prisms.

References

Optics by Example - Chris Penner

Lens Tutorial

Haskell - Boolean Blindness == True

Ken Aguilar — Thu, 16 Apr 2020 09:02:53 +0000

What does the title even mean? True? for what? Good? Bad? Useful? If it was False, would we see any meaning?

Even the state of a light bulb cannot be properly represented by booleans. Would True mean the light is on? or would it mean off?

What if the decision on whether Boolean Blindess is bad or good is represented with a sum type

data Decision 
  = Bad
  | Good
  deriving Show

makeDecision :: Decision -> Text
makeDecision decision = case decision of
  Bad -> "Boolean blindness is " <> ( show Bad ) <> "!"
  Good -> "Boolean blindess is " <> ( show Good ) <> "!"

I think using the sum type gives it meaning. Now we can make a decision about Boolean Blindess.

I lessen confusion in my code by using booleans conservatively.

Purescript - Halogen Routing

Ken Aguilar — Sun, 29 Mar 2020 00:45:37 +0000

This entry will be pretty similar to my previous purescript-react-basic-hooks routing entry. Where I go over how routing works within the framework. This time it will be be using the halogen UI framework.

Thanks to the halogen realworld example it was easy to figure out how to do routing in halogen.

Here's my understanding of it. I'll and try and extract the routing part of the example and focus on that in this entry.

Router

First off, the router component. This component is the parent component. It's the component that will decide what to render based on the route that's being queried to it. The render function case matches on the Route then renders the component.

module Component.Router where

import Prelude
import Data.Maybe ( Maybe(..), fromMaybe )
import Data.Either ( hush )
-- Internal Page
import Page.Home as Home
import Page.About as About
-- Internal Service
import Service.Route
import Service.Navigate
-- Web
import Web.Event.Event ( preventDefault )
import Web.UIEvent.MouseEvent ( toEvent, MouseEvent )
-- Effect
import Effect.Class ( class MonadEffect, liftEffect )
-- Routing
import Routing.Duplex
import Routing.Hash
-- Halogen
import Halogen as H
import Halogen.HTML as HH
import Halogen.HTML.Properties as HP
import Halogen.HTML.Events as HE

type State =
  { route :: Maybe Route
  }

data Query a = Navigate Route a

data Action
  = Initialize
  | GoTo Route MouseEvent

type ChildSlots =
  ( home :: Home.Slot Unit
  , about :: About.Slot Unit
  )

component
  :: forall i o m
  . MonadEffect m
  => Navigate m
  => H.Component HH.HTML Query i o m
component =
  H.mkComponent
  { initialState: const { route: Nothing }
  , render
  , eval: H.mkEval $ H.defaultEval
    { handleAction = handleAction
    , handleQuery = handleQuery
    , initialize = Just Initialize
    }
  }

-- Renders a page component depending on which route is matched.
render :: forall m. State -> H.ComponentHTML Action ChildSlots m
render st = navbar $ case st.route of
  Nothing -> HH.h1_ [ HH.text "Oh no! That page wasn't found" ]
  Just route -> case route of
    Home -> HH.slot Home._home unit Home.component unit absurd
    About -> HH.slot About._about unit About.component unit absurd

handleAction
  :: forall o m
  . MonadEffect m
  => Navigate m
  => Action
  -> H.HalogenM State Action ChildSlots o m Unit
handleAction = case _ of
  -- Handles initialization of the route
  Initialize -> do
    initialRoute <- hush <<< ( parse routeCodec ) <$> H.liftEffect getHash
    navigate $ fromMaybe Home initialRoute
  --  Handles the consecutive route changes.
  GoTo route e -> do
    liftEffect $ preventDefault ( toEvent e )
    mRoute <- H.gets _.route
    when ( mRoute /= Just route ) $ navigate route

handleQuery :: forall a o m. Query a -> H.HalogenM State Action ChildSlots o m ( Maybe a )
handleQuery = case _ of
  -- This is the case that runs every time the brower's hash route changes.
  Navigate route a -> do
    mRoute <- H.gets _.route
    when ( mRoute /= Just route ) $
      H.modify_ _ { route = Just route }
    pure ( Just a )

navbar :: forall a . HH.HTML a Action -> HH.HTML a Action
navbar html =
  HH.div_
  [ HH.ul_
    [ HH.li_
      [ HH.a
        [ HP.href "#"
        , HE.onClick ( Just <<< GoTo Home )
        ]
        [ HH.text "Home" ]
      ]
    , HH.li_
      [ HH.a
        [ HP.href "#"
        , HE.onClick ( Just <<< GoTo About )
        ]
        [ HH.text "About" ]
      ]
    ]
  , html
  ]

Page

This is how these pages are defined. These components will render the text Home and About. In a non-trivial application, these components will hold several components to form a "page", but for simplicity I left them off to just render text inside an h1.

Route

The key thing here is the Route sum type. These are all the
possible routes in the application. The rest of the code is for
routing-duplex to help me encode and decode the routes. The routes can be directly written as strings but I prefer the safety of types. Plus, the string definition only stays here. So this lessens the fishing later on if ever there is a bug in the routing.

module Service.Route where

import Prelude
import Data.Generic.Rep ( class Generic )
import Data.Generic.Rep.Show ( genericShow )
-- Routing
import Routing.Duplex ( RouteDuplex', root )
import Routing.Duplex.Generic ( noArgs, sum )
import Routing.Duplex.Generic.Syntax ((/))

-- All possible routes in the application
data Route
  = Home
  | About

derive instance genericRoute :: Generic Route _
derive instance eqRoute :: Eq Route
derive instance ordRoute :: Ord Route

instance showRoute :: Show Route where
  show = genericShow

routeCodec :: RouteDuplex' Route
routeCodec = root $ sum
  { "Home": noArgs
  , "About": "about" / noArgs
  }

Navigation

Navigation capbility of this app is defined in a type class. This technique is known as tagless-final-encoding. It's a technique where we define a capability or method without concrete implementations and only a small set of requirements. In this case, the minimum requirement is it needs to be a Monad. Then, an instance for HalogenM is defined here to save us from calling lifteverywhere inside the action (e.g lift $ navigate Home).

module Service.Navigate where

import Prelude

-- Internal Route
import Service.Route
-- Halogen
import Halogen

class Monad m <= Navigate m where
  navigate :: Route -> m Unit

instance navigateHalogenM :: Navigate m => Navigate ( HalogenM state action slots msg m ) where
  navigate = lift <<< navigate

AppM

AppM is a custom application monad that will provide concrete implementation for the capabilities, in this case it will only implement Navigation. As you'll notice this only provides a natural transformation from AppM to Aff. In a typical application this will wrap the ReaderT pattern. This is also the technique used in the [halogen real world example][halogen realworld]. I learned about this pattern here.

module AppM where

import Prelude
-- Internal Service
import Service.Navigate
import Service.Route
-- Effect
import Effect.Class ( class MonadEffect, liftEffect )
-- Aff
import Effect.Aff ( Aff )
import Effect.Aff.Class ( class MonadAff )
-- Routing
import Routing.Hash ( setHash )
import Routing.Duplex ( print )

newtype AppM a = AppM ( Aff a )

runAppM :: AppM ~> Aff
runAppM ( AppM m ) = m

derive newtype instance functorAppM :: Functor AppM
derive newtype instance applyAppM :: Apply AppM
derive newtype instance applicativeAppM :: Applicative AppM
derive newtype instance bindAppM :: Bind AppM
derive newtype instance monadAppM :: Monad AppM
derive newtype instance monadEffectAppM :: MonadEffect AppM
derive newtype instance monadAffAppM :: MonadAff AppM

instance navigateAppM :: Navigate AppM where
  navigate = liftEffect <<< setHash <<< print routeCodec

Main

Finally, the Main module. This is where the application is ran. This is also the place where the browser's route is observed. Whenever the route changes the callback of matchesWith will be called. This callback will query the router component with Navigate passing the new route.

module Main where

import Prelude
import Data.Maybe ( Maybe(..) )
-- Internal
import AppM ( runAppM )
-- Internal Components
import Component.Router as Router
-- Internal Service
import Service.Route
-- Effect
import Effect ( Effect )
import Effect.Class ( liftEffect )
-- Aff
import Effect.Aff ( Aff, launchAff_ )
-- Routing
import Routing.Duplex ( parse )
import Routing.Hash ( matchesWith )
-- Halogen
import Halogen as H
import Halogen.HTML as HH
import Halogen.Aff as HA
import Halogen.VDom.Driver ( runUI )

main :: Effect Unit
main = HA.runHalogenAff do
  body <- HA.awaitBody
  let
    rootComponent :: H.Component HH.HTML Router.Query {} Void Aff
    rootComponent = H.hoist runAppM Router.component

  -- Run the application
  halogenIO <- runUI rootComponent {} body

  -- Listen to the route changes.
  void $ liftEffect $ matchesWith ( parse routeCodec ) \mOld new ->
    when ( mOld /= Just new ) do
      launchAff_ $ halogenIO.query $ H.tell $ Router.Navigate new
  pure unit

References

Purescript Halogen Realworld Example

Tagless Final Encoding

ReaderT Design Pattern

Three Layer Haskell Cake

Purescript - React Basic Hooks Routing

Ken Aguilar — Fri, 27 Mar 2020 03:32:07 +0000

When I started doing web applications with purescript react and halogen I had no clue how to do things. One of those things is routing. It wasn't that hard for halogen because of the realworld example. It's built ready for production. It even has great documentation!

Unfortunately, when it came to react-basic-hooks this information wasn't readily available. So here's my take on routing with react-basic/react-basic-hooks.

The router component is the parent of all the components. The router component will decide which component to render depending on the Route.

Router

module Component.Router where

import Prelude
import Data.Either ( hush )
import Data.Maybe ( fromMaybe )
-- Internal Page
import Page.Home as Home
import Page.About as About
-- Internal Service
import Service.Route
import Service.Navigate
-- Internal Component
import Component.Store ( mkRouteStore )
-- Effect
import Effect ( Effect )
-- Routing
import Routing.Duplex ( parse )
import Routing.Hash ( getHash )
-- React
import React.Basic.Hooks ( ReactComponent, ReactContext )
import React.Basic.Hooks as React
import React.Basic.DOM as RD
import React.Basic.Events as RE

mkComponent :: Effect ( ReactComponent {} )
mkComponent = do
  -- Grab initial route. 
  -- This will try to match the browser's hash route. 
  mInitialRoute <- hush <<< ( parse routeCodec ) <$> getHash
  -- If it doesn't find a match it will default to the home route.
  -- Then a context is created on that route.
  routeContext <- React.createContext ( fromMaybe Home mInitialRoute )
  store <- mkRouteStore routeContext
  nav <- mkRouter routeContext
  React.component "RouterContainer" \props -> do
    pure $ React.element store { content: [ React.element nav {} ]}

-- This is the function that will match Route and render the right element that
-- matches that route.
mkRouter
  :: ReactContext Route
  -> Effect ( ReactComponent {} )
mkRouter routeContext = do
  home <- Home.mkComponent
  about <- About.mkComponent
  navbar <- mkNavbar
  React.component "Router" \props -> React.do
    route <- React.useContext routeContext
    pure
      $ React.fragment
        [ React.element navbar {}
        , case route of
             Home -> React.element home {}
             About -> React.element about {}
        ]

mkNavbar :: Effect ( ReactComponent {} )
mkNavbar =
  React.component "Navbar" $ const $ do
    pure
      $ RD.nav
        { children:
          [ RD.button
            { children: [ RD.text "Home" ]
            , onClick: RE.handler_ $ navigate Home
            }
          , RD.button
            { children: [ RD.text "About" ]
            , onClick: RE.handler_ $ navigate About
            }
          ]
        }

Route

This is how Route is defined. It's a sum type of all possible routes in the application. The rest of this code is definition for the routing-duplex interpreter and printer. The routes can be directly written as strings but safety with types is what I prefer; routing and routing-duplex provide that for me.

module Service.Route where

import Prelude hiding ((/))

-- Generic
import Data.Generic.Rep ( class Generic )
import Data.Generic.Rep.Show ( genericShow )
-- Routing
import Routing.Duplex
import Routing.Duplex.Generic
import Routing.Duplex.Generic.Syntax ( (/) )

-- All possible routes in the application
data Route
  = Home
  | About

derive instance genericRoute :: Generic Route _
derive instance eqRoute :: Eq Route
derive instance ordRoute :: Ord Route

instance showRoute :: Show Route where
  show = genericShow

routeCodec :: RouteDuplex' Route
routeCodec = root $ sum
  { "Home": noArgs
  , "About": "about" / noArgs
  }

Page

The page components are defined here. They're trivially defined components that will display the text "Home" and "About". In a non-trivial app, these would be the components that will encapsulate an entire page.

Route Store

This is the component that will watch the route changes. Everytime the hash route changes, it will run setRoute and updates the Route. This component will then pass it on to its content.

module Component.Store where

import Prelude
import Data.Maybe ( Maybe(..) )
-- Internal Service
import Service.Route
-- Effect
import Effect ( Effect )
-- Routing
import Routing.Hash ( matchesWith )
import Routing.Duplex ( parse )
-- React
import React.Basic.Hooks ( ReactComponent, ReactContext, (/\), JSX )
import React.Basic.Hooks as React

mkRouteStore :: ReactContext Route -> Effect ( ReactComponent { content :: Array JSX } )
mkRouteStore context =
  React.component "Store" \props -> React.do
    r <- React.useContext context
    route /\ setRoute <- React.useState r
    React.useEffect route $ matchesWith ( parse routeCodec ) \mOld new -> do
      when ( mOld /= Just new ) $ setRoute $ const new
    pure
      $ React.provider context route props.content

Navigation

The only capability of this app is navigation, but if there are other capabilities like requesting data, logging, and authentication it will also be defined similar to this.

module Service.Navigate where

import Prelude
-- Internal Service
import Service.Route
-- Effect
import Effect ( Effect )
-- Routing
import Routing.Duplex
import Routing.Hash

class Monad m <= Navigate m where
  navigate :: Route -> m Unit

instance navigateEffect :: Navigate Effect where
  navigate = setHash <<< print routeCodec

I thought this was a great article on
tagless-final-encoding. This is the technique being used here. Code re-use can be easier achieved with this technique because I don't have to change big chunks of the app if I need to implement it in another context. This app runs on Effect so I only have to define an instance for that. If the application needs to run on Aff then I'll define a new instance for Aff

React runs on Effect so that's why I've defined an Effect instance.

Main

Finally, the Main module. This is where purescript-react-basic-hooks runs application. Nothing really special, it looks for an element with id of app then appends the application to that DOM node.

module Main where

import Prelude
import Data.Maybe ( Maybe(..) )
-- Web
import Web.DOM.NonElementParentNode ( getElementById )
import Web.HTML.HTMLDocument ( toNonElementParentNode )
import Web.HTML.Window ( document )
import Web.HTML ( window )
-- Internal
import Component.Router as Router
-- Effect
import Effect ( Effect )
import Effect.Exception ( throw )
-- React
import React.Basic.Hooks ( element )
import React.Basic.DOM as R

main :: Effect Unit
main = do
  mApp <- getElementById "app" =<< ( map toNonElementParentNode $ document =<< window )
  case mApp of
    Nothing -> throw "App element not found."
    Just app -> do
      mainComponent <- Router.mkComponent
      R.render ( element mainComponent {} ) app

References

Purescript Halogen Realworld

React Basic Hooks

Routing Duplex

Routing

Tagless Final Encoding by Juan Pablo Royo

Introduction to Tagless Final by Serokell

Purescript - React Basic Hooks, useAff

Ken Aguilar — Thu, 27 Feb 2020 18:33:14 +0000

According to the documentation, useAff is defined like this.

useAff :: forall key a. Eq key => key -> Aff a -> Hook (UseAff key a) (Result a)

Aff is used for asynchronous effects. The docs on Aff is a great place to learn about it!

Back to useAff, when I first encountered this function I didn't
really know what it does. Sure, the type signature gave me some clues, like I need to give me it some key with the condition that this key has to have an Eq instance. The second parameter needs an Aff, then it will return some type Hook. Based on the second parameter this tells me that this is the function I need to make asynchronous effects.

This is my login component using useAff but it didn't start out like this. My first implementation for useAff was something like this

useAff unit $ do
    submitLogin isSubmitting { email: login.email, password: login.password }

I was very confused on why it's only getting called once after render. I also
tried something like this.

useAff "pleaseWork" $ do
    submitLogin isSubmitting { email: login.email, password: login.password }

Of course that didn't work.

I kept going back to this example and this repo, and kept wondering what I'm doing different. Then I had my "eureka" moment. I said to myself, "Maybe the Eq constraint has something to do with it. Maybe it checks the equality of the key parameter I passed in, and if it changes something will happen?" So I changed my implementation to this

useAff login $ do
    submitLogin isSubmitting { email: login.email, password: login.password }

login changes when the button is clicked on this line.
It worked!

References

Purescript React Basic Hooks Documentation

Purescript React Basic Hooks Examples

Purescript React Basic Dogs repo by Peter Murphy

Purescript Aff Documentation

Miles Frain for answering my questions in fpchat

Typescript - Manipulating Deeply Nested Immutable Objects with Lenses

Ken Aguilar — Wed, 29 Jan 2020 22:46:42 +0000

Javascript doesn't really have an immutable object but with typescript I can
prevent compilation if there's a rogue function that will try to mutate an object.

Let's say I have this object, and let's assume the values are always there
because if I start talking about the possibility of null then I have to talk
about prisms. So let's take it easy and stick with lenses for now.

const bankIdentity: BankIdentity = {
  account: {
    owner: {
      address: {
        data: {
          city: "Malakoff",
          region: "NY",
          street: "2992 Cameron Road",
          postal_code: "14236",
          country: "US"
        },
        primary: true
      }
    }
  }
};

It has this type.

interface Address {
  readonly city: string;
  readonly region: string;
  readonly street: string;
  readonly postal_code: string;
  readonly country: string;
}

interface AddressData {
  readonly data: Address;
  readonly primary: boolean;
}

interface Owner {
  readonly address: AddressData;
}

interface Account {
  readonly owner: Owner;
}

interface BankIdentity {
  readonly account: Account;
}

Accessing a value

Without using any library I can manipulate this object no problem.
When I want to access a field, I just do the dot syntax and it gives me the
value of that field.

const cityRes =  bankIdentity.account.owner.address.data.city;

// "Malakoff"

Setting a new value and returning the whole object

It becomes a hassle when I have to set a new value.

const cityRes = Object.assign({}, bankIdentity, { 
    account: { 
        owner: { 
            address: { 
                data: Object.assign({}, bankIdentity.account.owner.address.data, { 
                    city: "Another City"
                }) 
            } 
        } 
    }
});

// { account:
//    { owner:
//       { address:
//          { data:
//             { city: 'Another City',
//               region: 'NY',
//               street: '2992 Cameron Road',
//               postal_code: '14236',
//               country: 'US' 
//             } 
//         } 
//      } 
//  } 
//}

Applying a function and returning the whole object

Same ugliness can be seen when applying a function to the field.

const capitalize = (s: string): string => s.toUpperCase();

const cityRes = Object.assign({}, bankIdentity, {
    account: {
      owner: {
        address: {
          data: Object.assign({}, bankIdentity.account.owner.address.data, { 
            city:  capitalize(bankIdentity.account.owner.address.data.city) 
          })
        } 
      } 
    }
  });


// { account:
//    { owner:
//       { address:
//          { data:
//             { city: 'MALAKOFF',
//               region: 'NY',
//               street: '2992 Cameron Road',
//               postal_code: '14236',
//               country: 'US' 
//             } 
//         } 
//      } 
//  } 
//}

monocle-ts

Lenses to the rescue! Unfortunately I don't think it's possible or at least easy
to generate lenses based on the objects like what makeLenses does,
so I have to hand code all of them.

import { Lens } from "monocle-ts";

const account = Lens.fromProp<Bankdentity>()("account");
const owner = Lens.fromProp<Account>()("owner");
const address = Lens.fromProp<Owner>()("address");
const data = Lens.fromProp<AddressData>()("data");
const city = Lens.fromProp<Address>()("city");
const region = Lens.fromProp<Address>()("region");
const street = Lens.fromProp<Address>()("street");
const postalCode = Lens.fromProp<Address>()("postal_code");
const country = Lens.fromProp<Address>()("country");

Well... accessing a value with monocle-ts looks pretty verbose.

const cityRes = account
  .compose(owner)
  .compose(address)
  .compose(data)
  .compose(city)
  .get(bankIdentity);

// "Malakoff"

I guess I can do it like this

const cityRes = Lens.fromPath<BankIdentity>()(["account", "owner", "address", "data", "city"]).get(bankIdentity);

// "Malakoff"

but I think it's better to just use the dot syntax, at least in my opinion.

Lenses shine when it comes to updating and applying a function to a deeply
nested value.

Setting a value and returning the whole object

const cityRes = account
  .compose(owner)
  .compose(address)
  .compose(data)
  .compose(city)
  .set("Another City")(bankIdentity);

// { account:
//    { owner:
//       { address:
//          { data:
//             { city: 'Another City',
//               region: 'NY',
//               street: '2992 Cameron Road',
//               postal_code: '14236',
//               country: 'US' 
//             } 
//         } 
//      } 
//  } 
//}

I think that looks a lot cleaner than using Object.assign.

Applying a function and returning the whole object

Yep. That definitely looks a lot cleaner.

const capitalize = (s: string): string => s.toUpperCase();

const cityRes = account
  .compose(owner)
  .compose(address)
  .compose(data)
  .compose(city).modify(capitalize)(bankIdentity);

// { account:
//    { owner:
//       { address:
//          { data:
//             { city: 'MALAKOFF',
//               region: 'NY',
//               street: '2992 Cameron Road',
//               postal_code: '14236',
//               country: 'US' 
//             } 
//         } 
//      } 
//  } 
//}

References

Haskell - My Setup/Workflow

Ken Aguilar — Tue, 26 Nov 2019 07:31:48 +0000

Tools:

My setup matches my personality and that is I always go for the simplest solution. I download all these tools using nixpkgs and I enable haskell-mode in doom-emacs. That's it! I start writing Haskell.

This is how my development workspace looks like.

Once I start writing Haskell I have another terminal open that runs ghcid. It has very fast development feedback loop, it's how I know if my types are matching. I use typed-holes heavily so ghcid can tell me what types I need for a section of my code.

Here's a contrived example

add :: Integer -> Integer -> Integer
add x y = x `_whatdo` y

This will be ghcid's response in the repl

<interactive>:3:13: error:
    • Found hole: _what :: Integer -> Integer -> Integer
      Or perhaps ‘_what’ is mis-spelled, or not in scope
    • In the expression: _what
      In the expression: x `_what` y
      In an equation for ‘add’: add x y = x `_what` y
    • Relevant bindings include
        y :: Integer (bound at <interactive>:3:7)
        x :: Integer (bound at <interactive>:3:5)
        add :: Integer -> Integer -> Integer (bound at <interactive>:3:1)
      Valid hole fits include
        add :: Integer -> Integer -> Integer (bound at <interactive>:3:1)
        seq :: forall a b. a -> b -> b
          with seq @Integer @Integer
          (imported from ‘Prelude’
           (and originally defined in ‘ghc-prim-0.5.3:GHC.Prim’))
        (-) :: forall a. Num a => a -> a -> a
          with (-) @Integer
          (imported from ‘Prelude’ (and originally defined in ‘GHC.Num’))
        asTypeOf :: forall a. a -> a -> a
          with asTypeOf @Integer
          (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))
        const :: forall a b. a -> b -> a
          with const @Integer @Integer
          (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))
        max :: forall a. Ord a => a -> a -> a
          with max @Integer
          (imported from ‘Prelude’
           (and originally defined in ‘ghc-prim-0.5.3:GHC.Classes’))
        (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)

This tells me that I need a function that takes two Integer that also outputs an Integer. This even tells me the "Relevant bindings" and "Valid hole fits" which is amazing. ghcid helps as much as it can. This flow goes a very long way. It starts getting hazy for me when it comes to lens errors, but I'm sure if I use lens more often I'll be able to decipher what ghcid is telling me much quickly. This even works in the type level.

add :: _whatdo
add x y = x + y

ghcid repl will respond with

<interactive>:8:1: error:
    • Couldn't match expected type ‘_whatdo’
                  with actual type ‘Integer -> Integer -> Integer’
      ‘_whatdo’ is a rigid type variable bound by
        the type signature for:
          add :: forall _whatdo. _whatdo
        at <interactive>:7:1-14
    • The equation(s) for ‘add’ have two arguments,
      but its type ‘_whatdo’ has none
    • Relevant bindings include
        add :: _whatdo (bound at <interactive>:8:1)

ghcid is the reason I don't use any IDE or any fancy editor plugins. I only have syntax highlighting and some formatting in my emacs.

When it comes to actually running my code I usually use cabal. After ghcid tells me my code is clear I run

cabal new-build
cabal new-run

Sometimes I use stack because of yesod. That's mostly for work.

I'm aware of the holy war between stack, cabal, and nix, I hope this blog doesn't get involved in that war. I use all of them. They all have a spot in my workflow.