Right now, a ton of things are hardcoded. This is less than ideal. A Config type would be a better way to centralize these points of configuration.

data Config = Config 
  { configMainIs :: String -- ^ Name of the main function to be exported.
  , ...
  }

• Add a Config data type to the library
• For hardcoded values, refer to the Config instead.
• (optional): Refactor the library to use ReaderT Config IO a instead of Config -> IO a as the type of functions.

As noted in #1, if a user uses non-Prelude types for arguments, they'll be out of scope when copying them into the arguments datatype.

For a Foo module with the preprocessor, we should search for Foo.Import, and import that. That module will need to provide all of the types for the import to work.

Right now, the rendering function looks something like:

unlines
  [ "module " ++ something ++ " where"
  , "import Kale.Discovery"
  , makeSomeString
  , "woo i love strings"
  ]

This kinda sucks! Instead, let's write some limited data types that represents the syntax we want.

data Syntax = ...

data Import = Import Module (Maybe Qualified)

Etc. Finally, we'll write a function render :: Syntax -> String that will be used to turn this into valid Haskell.

Running make test, for example, results in make: 'test' is up to date. without running any commands.

Use newtype over the various Strings that are being passed around to make it difficult to mix them up.

There's a ton of String -> String crap going on in here. Going to need more tests to make sure it's right.

Issue #10 says that we need to have a configuration data type. How do we load that configuration?

Idea: allow the user to specify a config-as-Haskell code that is imported from a specific location.

I think I'm mostly a fan of 3, as we already need to provide the user a way to import a module to provide relevant types (as raised in issue #1). If that module contains a kaleConfig value, then we can import it and use it.

Depending on the type of kaleConfig, we could handle it in different ways:

1. kaleConfig :: Config = just use this
2. kaleConfig :: Config -> Config = given the defaults, modify them like this
3. kaleConfig :: IO Config = bind this out of IO
4. kaleConfig :: Config -> IO Config = given the defaults, load this configuration

Currently, the argument parser only accepts named arguments:

module AsdfTask where

data Args = Args { foo :: String }

generates a command line task used like asdf --foo hello

We should also accept positional arguments:

module PosTask where

data Args = Args String Int

which generates a command line task like pos hello 10

• Setup Travis CI
• Setup HLint check
• Setup editorconfig/stylish-haskell configuration files

kale needs to be able to handle parsing command line arguments, implicitly.

Current strategy

Search for a data Args = Args data type. If it is not present, then we ignore it. If it is not a product type, then we should fail loudly, probably.

Extract the text of the record. So data Args = Args Int gives us Int. data Args = Args { userName :: String } is {userName :: String }. data Args = Args { fooId :: Int <?> "The Foo's ID" } gives us { fooId :: Int <?> "The Foo's ID" }.

Paste the text of the arguments to the record into the creation of that variant of the sum type. So if we have

module FooTask where

data Args = Args { userName :: String }

then the generated code should do:

data Command
  = Foo { userName :: String }

A problem with this is that any duplicate fields need to share a type.

Then, we'll need to transform the Command arguments into the Args constructor:

case cmd of
  Foo {..} -> FooTask.task FooTask.Args {..}

is probably sufficient. hooray for recordwildcards!

This project needs:

1. Haddock API documentation.
2. Example projects
3. Tutorials on getting started
4. A solid README