Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instead of hardcoding values, use a Config type #10

Open
3 tasks
parsonsmatt opened this issue Nov 17, 2017 · 2 comments
Open
3 tasks

Instead of hardcoding values, use a Config type #10

parsonsmatt opened this issue Nov 17, 2017 · 2 comments

Comments

@parsonsmatt
Copy link
Owner

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.
@xldenis
Copy link

xldenis commented Nov 20, 2017

I think this can be combined with #12, the name of the import module can just be defined in the configuration.

@xldenis
Copy link

xldenis commented Nov 20, 2017

As for the config, it makes sense to just use optparse to parse the config value from the arguments given to the preprocessor (see hspec-megaparsec).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants